Eric, Thank you for your feedback. Below are the problems that I see with the alternative proposals that you suggested when compared to the approach taken in the current draft: 1) Proposal 1: Send the user mapping extension in the initial Client Hello (as data along with the extension value). a) Problem: Privacy/Lack of user consent in information disclosure. The UPN sent in the user extension, uniquely identifies a principal - something that users concerned with preserving their privacy may object to (i.e., the large majority of SSL sites are server side auth only; the user was anonymous and now the user is identified by the UPN). To mitigate this problem to some extent (as I think you pointed out), the client can be configured to only send the user mapping information to some subset of servers (e.g., based on domain names). However, this completely lacks end user consent. The user's principal name will be automatically sent to every SSL server in the above list (as configured by admin) - even if the user does not wish to be identified to the target server (in SSL sessions with server side auth only and mutual auth). In contrast, if the mapping extension is sent on the third leg before the certificate msg (as it is in the current draft), the user has the option to bail out of client auth and not disclose the UPN or any data in the cert (e.g., by not typing the pin for the smartcard). b) Problem: Performance. In your email you stated that the UserMapping extension is likely to be around ~ 100 bytes and that's negligible and thus it is ok to send in the initial ClientHello msg - even if the server does not need it as is the case for server side auth only TLS connections. I disagree. As you know TLS is used in many different scenarios, for example: EAP/TLS (RFC http://www.ietf.org/rfc/rfc2716.txt) is used for Radius, wireless 802.1x, RAS (dial up), etc. The MTU in EAP is 1600 bytes. Thus even 100 bytes can cause additional fragmentation causing additional latency for RAS (consider dial up across geographically dispersed end points). Furthermore, per the current draft the userMapping structure can be extended, to carry multiple user mapping hints, thus causes further degradation in this scenario ... 2) Proposal 2: 1. Do an ordinary TLS handshake without offering UME. 2. Initiate a TLS rehandshake and send the UMDL in an extension in the ClientHello. This is essentially saying that the current extensibility mechanism in TLS is broken and that the userMapping extension in contrast to all other extension requires to 2 handshakes instead of one. The method that you are proposing is inconsistent with the approach used for every other TLS extension. >From a performance standpoint, proposal 2 is still a bad choice. You stated that "The performance issue is quite modest with modern servers". While servers are getting faster, user load tends to follow suit; furthermore, this proposal costs additional latency. In contrast, the approach used in the current draft does not suffer from these problems. Regards, -Ari -----Original Message----- From: Eric Rescorla [mailto:ekr@xxxxxxxxxxxxxxxxxxxx] Sent: Saturday, February 18, 2006 5:31 PM To: ietf@xxxxxxxx Cc: tls@xxxxxxxx; iesg@xxxxxxxx Subject: [TLS] Re: Last Call: 'TLS User Mapping Extension' to ProposedStandard BACKGROUND This document describes an extension to TLS which allows the client to give the server a hint (the User Principal Name) about which directory entry to look up in order to verify the client's identity. This works as follows: 1. The client offers the extension (called UME) in the ClientHello message. 2. The server accepts the extension. 3. The client sends the new HandshakeType to the server before sending its Certificate message. The packet flow looks like this (cut-and-pasted from the draft): Client Server ClientHello /* with user_mapping ext */ --------> ServerHello /* with user-mapping ext */ Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone --> UserMappingDataList Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data New handshake message marked by --> on the left. This document was presented to the TLS WG in Vancouver and there was only a very small amount of interest. The authors posted the -00 version of their draft on January 10. Some minor comments were made by a single WG member and these were addressed. The authors asked for a preliminary code point assignment on January 14. I provided a number of technical comments (including suggesting an alternate approach, described below) at that time, but was told that the implementation was already too far along to be changed significantly. Since the IETF would not have change control, this is an inappropriate work item for the TLS WG and therefore the authors appear to have decided on an Individual Submission. The reason for the intended status of Proposed Standard is that this extension defines a new Handshake Type and the TLS WG has decided that new Handshake Types require a Standards Action (See S 7.4 of draft-ietf-tls-rfc2246-13, in RFC-Ed queue). Contrary to the the Last Call announcement, the comments I raised originally have not been addressed--except to be told they weren't possible. For the reasons indicated below, I believe this document should not be advanced to Proposed Standard as-is. REVIEW COMMENTS The obvious design here would simply be to place the information in the UserMappingDataList (UMDL) message directly in the ClientHello extension. The draft argues that this is bad for the following reason: The reason the mapping data itself is not placed in the extension portion of the ClientHello is to prevent broadcasting this information to servers that don't understand the extension. Additionally, if new mapping information were to be considered confidential, the addition of a new handshake message allows the data to be encrypted using the servers public key. No other modifications to the protocol are required. The messages are detailed in the following sections. This is unconvincing for a number of reasons. First, TLS handles the case where an extension is not understood just fine. It's ignored. Since the extension appears to be less than 100 bytes, there's no performance issue. The authors suggest that there is a security issue: As the client is the initiator of this TLS extension, it needs to determine when it is appropriate to send the User Mapping Information. It may not be prudent to broadcast this information to just any server at any time, as it can reveal network infrastructure the client and server are using. - The client SHOULD only send the UserMappingDataList handshake message if it is agreed upon in the Hello exchange, preventing the information from being sent to a server that doesn't understand the User Mapping Extension. - The client SHOULD further only send this information if the server belongs to a domain to which the client intends to authenticate using the UPN as identifier. However, the second piece of information (the domain name of the server) is generally available to the client prior to the connection initiation, since it's used to look up the server's address. So, the client could decide whether to send the UMDL data prior to handshake initiation. One difference here is that the client now has the server's certificate and that certificate could potentially contain some X.509 Extension that indicated that the server was authorized to receive the UMDL data. However, this is of very limited security value because in the static RSA modes which are common with SSL/TLS, the server has not proved possession of the corresponding private key at this point in the handshake. Note that this draft does not describe any such extension. An attacker who wished to impersonate the server in order to capture the UMDL would be able to do so with a simple replay/cut-and-paste attack. Moreover, because the UMDL is sent in the clear (the draft claims that it could be encrypted but provides no facility for doing so) any passive attacker can capture the UMDL by observing a single handshake. At best this strategy stops the client from inadvertantly sending the UMDL to a server which it *thinks* should support it (because it's got the right domain name) but which actually doesn't (perhaps because it's broken?). This seems to be of extremely limited value. AN ALTERNATE DESIGN There is an alternate design which has superior security properties and does not involve defining a new HandshakeType. 1. Do an ordinary TLS handshake without offering UME. 2. Initiate a TLS rehandshake and send the UMDL in an extension in the ClientHello. Because the second TLS handshake is conducted over the TLS session established in step (1), the entire UMDL extension exchange is protected. A passive attacker cannot capture the UMDL data and an active attacker cannot impersonate the server and force the transmission of the UMDL. This approach has two (modest) drawbwacks. 1. It is slower because it requires two handshakes. 2. The client may have to authenticate twice (this is a special case of (1)). The second case can be easily ameliorated by having the client send an extension (empty UME?) in the first handshake as a signal that it wants to do UMDL and that the server should hold off on demanding client authentication until the rehandshake happens. The performance issue is quite modest with modern servers. Indeed, it's quite common for web servers to do a first handshake without cert-based client auth and then rehandshake with client auth if the client asks for a sensitive page. Note: there is an alternate design in which you do a client auth in the first handshake and then do a resumption in the second one but do UME. This is rather faster, both in terms of computation and round trips but is technically precluded by S 2.3 of RFC3546 which requires ignoring extensions if you do a resume. One could imagine relaxing this restriction but that hasn't been done yet. Note also that if the client isn't worried about the sensitivity of the UMDL, then it can simply offer the UME extension with a UMDL in the first handshake and skip the second handshake. Another (hacky) approach would be for the client to probe the server with an initial ClientHello (and no UME) and then abort the handshake and restart if it decides that it likes the server and wants to do UME. This would have equivalent security properties to this draft at the cost of a single round trip. SUMMARY The technique described in this document appears to be of limited usefulness. In particular, the lack of confidentiality for the UMDL is a big limitation in extending it to other applications than the one envisioned by Microsoft. There are alternate designs which don't have those limitations and don't involve allocating a new HandshakeType value. This document should not advance as a Proposed Standard. -Ekr _______________________________________________ TLS mailing list TLS@xxxxxxxxxxxxxx https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf