Re: [Secdispatch] [EXTERNAL] Re: Requesting agenda time for draft-halen-fed-tls-auth

[Mike Ounsworth <[e-mail]>]

The draft itself sounds like it's trying to solve the problem of meshing multiple PKIs into a single trust hierarchy, which you can already do within existing PKIX standards via cross-certs (with name constraints, pathlen constraints, etc) to the CA of each trust domain (either pairwise or via a central "bridge CA").

The email thread sounds like it's also trying to solve service discovery at the same time. It's doing this via a mashup of federated SAML and PKI. No doubt this is an interesting solution to real problems, but it's not clear to me that we benefit from making it into an Internet standard. Are you seeing multiple vendors with similar but not-quite-compatible implementations that are in need of standardization?


About this point:

> Issuers are for reverse proxys that do not support optional_no_ca. Pin
> validation is performed by the application

The HTTPbis WG has "draft-ietf-httpbis-client-cert-field" coming down the pipeline (formerly "draft-bdc-something-something-certificate") which should help shepherd reverse proxy vendors into better support for delegating client cert validation back to the application. To me, the option to make reverse proxies "dumber" in a standard way seems like a better solution than building a federated SAML layer on top in order to make reverse proxies "smarter".

---
Mike Ounsworth

-----Original Message-----
From: Secdispatch <[e-mail]> On Behalf Of Michael Richardson
Sent: July 12, 2022 4:32 PM
To: Stefan Halen <stefan.halen=[e-mail]>
Cc: [e-mail]
Subject: [EXTERNAL] Re: [Secdispatch] Requesting agenda time for draft-halen-fed-tls-auth

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________

Stefan Halen <stefan.halen=[e-mail]> wrote:
    > The metadata is also used for discovery. The client normally select a
    > server based on metadata claims (e.g., organization, tags). The client
    > connects to the server's base_uri, also found in metadata.

    > The federation operator must keep track of the members and which
    > combinations of tags and peer type each member may publish.

    > To enable self-signed certificates, there is the possibility of
    > publishing issuers.

Perhaps I'll understand the problem more after you revise the document, or maybe your slides will motivate things.  I am generally enthusiastic about anything that pushes for more use of mutual TLS authentication!

I understood part of the solution, but I completely did not understand what problem you are dealing with!!!

    > Issuers are for reverse proxys that do not support optional_no_ca. Pin
    > validation is performed by the application

If I understood this comment, the issue is that are TLS terminating proxies that can only validate client TLS certificates from CAs that they have been configured with.

They can not opportunistically use a certificate provided in the TLS setup to complete the TLS connection, and then allow an application framework behind them to indicate if the client certificate should have been accepted or not.

I don't yet understand how your protocol solves this, but I think that
RFC8995 could suffer from this constraint in the Registrar->MASA connection.

https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/
tried to find a place to be adopted, and I think that had it gotten somewhere that it might have helped you.
(Yes, there are issues of how to make this work with TLS 1.3 re-authentication)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>, Sandelman Software Works  -= IPv6 IoT consulting =-



Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.