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.
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.
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.
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.
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).
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...
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.
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.
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".
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...
Best regards,
Pasi
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf