RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' to ProposedStandard

Pasi:

>My personal comments about draft-santesson-tls-ume-01:
>
>The draft defines an extension to TLS that allows the client to send
>"user mapping" information to the TLS server. The server uses this
>information to fetch authentication/authorization-related information
>from a directory server.

I do not think this is a good summary of the purpose of this 
document.  Currently in the Microsoft environment, a 
Microsoft-specific certificate extension that contains the username 
is required.  This extension allows certificates without this 
Microsoft-specific extension to be used.  The document refers to 
these as "legacy" certificates.  In fact, these are the certificates 
that are in common use in many large enterprises.

>The draft is quite similar to draft-housley-tls-authz-extns, which
>allows sending X.509 attribute certificates and SAML assertions in
>TLS. The main difference seems to be that we only send a pointer to
>the authorization information (a bit like IKEv2, which supports
>sending an URL of the certificate instead of the cert itself).  From a
>purely technical point of view, it would probably make sense to merge
>these drafts.  The tls-authz-extns draft does some details better:
>e.g., the information is sent encrypted, and only after the server has
>been authenticated.

Based on the comments that I received from Eric Rescorla on 
draft-housley-tls-authz-extns, this draft is likely to move in a 
somewhat different direction; however, that is a discussion for a 
different thread.

>The solution is also quite similar to the "client_certificate_url"
>extension defined in RFC 3546 (the "User Principal Name" could be
>considered as one type of certificate URL). Here even the placement
>of the handshake messages is identical to tls-ume. Unfortunately,
>it seems that sending both CertificateURL and Certificate handshake
>messages is not allowed, complicating the situation.

The change proposed here would require action by the TLS WG.  And, 
this alternative approach was not raised at the Vancouver IETF when 
this solution was presented to the TLS WG.

>However, it might be that process and timing issues make mergers
>infeasible.  Also, the authors of draft-santesson-tls-ume seem to
>be unwilling to make changes to the protocol.

This is not the case.  I raised a significant concern when I did my 
AD review, and after discussion of several alternative solutions, 
they picked one and changed the document.  I understand that they are 
also changing their implementation to match the document.

>About the technical details: In general, the solution seems to work,
>and does not contain any serious flaws. I don't count sending the user
>mapping information unencrypted as a serious flaw -- this information
>is sent only when a client certificate is also sent, and the client
>certificate is not encrypted either (unless the double-handshake hack
>is used, in which case the user mapping information would be
>encrypted, too).

I agree with this assessment.

>It's probably not the most elegant design possible (see e.g. Eric
>Rescorla's review).
>
>However, I think we should clearly "distinguish between 'it won't
>work' and 'it could/should work better'" (as Dave Crocker well put it
>in one email). The document solves a real (but maybe not extremely
>large or important) problem, and the solution works. That's better
>than many documents these days...

I think that the folks that are using enterprise PKIs would like to 
see this capability, and Microsoft is prepared to make it available in Vista.

>Given these, I think this would be an excellent document for
>Informational, especially if the title was changed to "Microsoft TLS
>User Mapping Extension" to indicate that it's a proprietary extension
>where the IETF community had no chance to change anything.  I also
>think vendors should be encouraged to publish their extensions, even
>if they are not perfect.

I disagree with this point.  When I did my AD review, I considered 
the Microsoft-specific nature of the document.  The structure easily 
accommodates additional name forms.  Thus, I do not think we should 
ask for "Microsoft" in the document title.

>However, due to the IANA allocation rules in 2246bis, this draft is
>being last called for standards track, and this is slightly more
>problematic.
>
>One observation is that the TLS allocation rules are quite strict, and
>not always totally logical. "Specification Required" is sufficient to
>get a ClientCertificateType number, and "IETF Consensus" gets you an
>ExtensionType number. But many extensions (including this one, and
>also some of the extensions in 3546bis) also require a handshake
>message number, and thus Standards Track. Or in other words: the
>degree of consensus and process required for a document that extends
>TLS depends heavily on minor technical details, not on what the
>extension actually does.
>
>RFC 2026 also says that "A Proposed Standard specification is
>generally stable, has resolved known design choices, is believed to be
>well-understood, has received significant community review, and
>appears to enjoy enough community interest to be considered valuable."
>
>I don't think we're quite there yet with this document.

We need to strike a balance.  In this case, Microsoft is trying to 
follow the IANA allocation rules in 2246bis.  We do not want to 
punish them for trying to be good IETF participants.

>On the other hand, I also think that just refusing to publish this
>document would be a highly unproductive approach. If the document
>solves a reasonable problem, the solution works, and it looks likely
>it will be widely deployed, I don't think preventing publication on
>minor process details would exactly "make the Internet work better".

We agree on this point.

>I'm not sure what would be the best way to handle this, though.  Merge
>this with draft-housley-tls-authz-extns? Refine the technical details
>so that it does not need a new handshake message number? (E.g., map the
>UPN to an URL, and use the existing CertificateURL message?) Change the
>IANA allocation rules for TLS? I don't have a strong opinion here...

Since the direction for draft-housley-tls-authz-extns remains 
unclear, I do not think we should delay draft-santesson-tls-ume while 
the other document gets sorted out.

Russ

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf