RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' to ProposedStandard
<Pasi.Eronen@nokia.com> Tue, 21 February 2006 15:00 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBZ0U-0002SO-2r; Tue, 21 Feb 2006 10:00:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBXk6-0006P2-6A; Tue, 21 Feb 2006 08:39:50 -0500
Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBXZQ-0002D3-Lj; Tue, 21 Feb 2006 08:28:49 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1LDRraw006688; Tue, 21 Feb 2006 15:27:54 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Feb 2006 15:28:04 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Feb 2006 15:28:02 +0200
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 21 Feb 2006 15:28:15 +0200
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2402436156@esebe105.NOE.Nokia.com>
In-Reply-To: <20060219013238.779CC22241D@laser.networkresonance.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Re: Last Call: 'TLS User Mapping Extension' to ProposedStandard
Thread-Index: AcY09EnHtfbfnUp9T8WKO8+PpaeZ4QB9gfQA
From: Pasi.Eronen@nokia.com
To: ietf@ietf.org, tls@ietf.org, iesg@ietf.org
X-OriginalArrivalTime: 21 Feb 2006 13:28:02.0832 (UTC) FILETIME=[A3FF9100:01C636EA]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc:
Subject: RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' to ProposedStandard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org
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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Eric Rescorla
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Steven M. Bellovin
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Bill Fenner
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Russ Housley
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Russ Housley
- Is round-trip time no longer a concern? (was: Re:… Dave Crocker
- Re: Is round-trip time no longer a concern? Russ Allbery
- Re: Is round-trip time no longer a concern? (was:… Steven M. Bellovin
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Bill Strahm
- Re: Is round-trip time no longer a concern? (was:… Dave Cridland
- Re: Is round-trip time no longer a concern? Harald Tveit Alvestrand
- Re: Is round-trip time no longer a concern? Peter Dambier
- RE: Last Call: 'TLS User Mapping Extension' to Pr… Pasi.Eronen
- Re: Is round-trip time no longer a concern? Eric Rescorla
- Re: Is round-trip time no longer a concern? Keith Moore
- Re: Is round-trip time no longer a concern? Dave Cridland
- Re: Is round-trip time no longer a concern? Dave Crocker
- Re: Is round-trip time no longer a concern? Eric Rescorla
- Re: Is round-trip time no longer a concern? Tony Finch
- Re: Is round-trip time no longer a concern? Steven M. Bellovin
- Re: Is round-trip time no longer a concern? Dave Crocker
- RE: Last Call: 'TLS User Mapping Extension' to Pr… Gray, Eric
- RE: [TLS] Re: Last Call: 'TLS User Mapping Extens… Pasi.Eronen
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Bernard Aboba
- RE: Last Call: 'TLS User Mapping Extension' to Pr… Russ Housley
- RE: [TLS] Re: Last Call: 'TLS User Mapping Extens… Russ Housley
- RE: [TLS] Re: Last Call: 'TLS User Mapping Extens… Stefan Santesson
- RE: Last Call: 'TLS User Mapping Extension' to Pr… Stefan Santesson
- RE: Last Call: 'TLS User Mapping Extension' to Pr… Stefan Santesson
- RE: Re: [TLS] Re: Last Call: 'TLS User Mapping Ex… Stefan Santesson
- RE: Re: [TLS] Re: Last Call: 'TLS User Mapping Ex… Stefan Santesson
- RE: Re: [TLS] Re: Last Call: 'TLS User Mapping Ex… Russ Housley
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Simon Josefsson
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Jeffrey Hutzelman
- RE: [TLS] Re: Last Call: 'TLS User Mapping Extens… Ari Medvinsky