Subject: RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 28 Feb 2006 14:53:07 -0000

Adding to Ari's arguments.
There is one more argument why it would less functional to send the
mapping data in the extension.

The current draft under last call also includes a negotiation mechanism
where the client and server can agree on what type of mapping data they
support.

If the mapping data is sent in the client hello, the client has no clue
on what data the server needs unless prior knowledge has been
established. It must then send all types of mapping data that it
believes the server might need. This is less desirable than sending just
the type of data the server explicitly has stated that it prefers out of
the types the client has stated that it supports.

While it would be technically possible to implement the same solution
along with Eric's alternative suggestions, I don't think it has been
demonstrated that it would provide any significant advantages.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

-----Original Message-----
From: Ari Medvinsky [mailto:[email-masked]] 
Sent: den 21 februari 2006 02:32
To: Eric Rescorla; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [TLS] Re: Last Call: 'TLS User Mapping Extension'
toProposedStandard

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:[email-masked]] 
Sent: Saturday, February 18, 2006 5:31 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 28 Feb 2006 07:14:55 -0800

> demonstrated that it would provide any significant advantages.

I don't want to get into a long point-by-point here. Suffice to say
that I don't agree with either this analyis or Ari's. It would,
as I noted, have the advantage of actually applying confidentiality
for data you claim is sensitive while avoiding the need to declare
a new code point. I consider both of these to be significant advantages.

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Tue, 28 Feb 2006 10:26:16 -0500

I can see many situations where the information in this is not 
sensitive.  In fact, in the primary use case, the use mapping 
information is not sensitive.  An enterprise PKI is used in this 
situation, and the TLS extension is used to map the subject name in 
the certificate to the host account name.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 28 Feb 2006 07:51:04 -0800

> the certificate to the host account name.

But then we're left with the performance rationale that the user has
some semi-infinite number of mappings that makes it impossible to send
all of them and too hard to figure out which one. In light of the fact
that in the original -01 proposal there wasn't even any negotiation
for which type of UME data should be sent, is there any evidence that
this is going to be an important/common case?

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Tue, 28 Feb 2006 11:18:58 -0500

>this is going to be an important/common case?

This requires a crystal ball....  Apparently yours is different than 
mine, as the negotiation that you reference above was added to 
resolve comments from my AD review.

We all know that there is not going to be a single name form that is 
useful in all situations.  We also know that you cannot put every 
useful name form into the certificate.  In fact, the appropriate 
value can change within the normal lifetime of a certificate, so 
putting it in the certificate will result in high revocation rates.

This is the reason that I believe this TLS extension will be useful 
in environments beyond the one that was considered by the Microsoft 
authors.  Your perspective may differ ....

Russ

---

From: Wan-Teh Chang <[email-masked]>
Date: Tue, 28 Feb 2006 10:54:35 -0800

Russ Housley wrote:
> useful in all situations.  We also know that you cannot put every useful 
> name form into the certificate.  In fact, the appropriate value can 
> change within the normal lifetime of a certificate, so putting it in the 
> certificate will result in high revocation rates.
> 
> This is the reason that I believe this TLS extension will be useful in 
> environments beyond the one that was considered by the Microsoft 

I agree.  A rationale like the above would be a good
addition to the Internet-Draft to strengthen its
motivation.

Re: EKR's suggested alternatives

While adding a new HandshakeType will incur the costs of
a Standards track RFC, we should not go out of our way
to avoid it.  The proposed solution in the Internet-Draft
looks clean and natural to me.

Instead of adding a new HandshakeType, can we extend the
Certificate message to include the user mapping data list
as ancillary data?

Re: draft 02

1. Sec. 5 "Security Considerations" says:

   - 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.

I have some questions about this paragraph.

How does the client determine which domain the server
belongs to without asking the server?

Should the server send its domain to the client in
the ServerHello user-mapping extension?  (This would
be analogous to the certificate_authorities field in
the CertificateRequest message.)

Is it possible or common for a client to belong to
multiple domains and have multiple UPNs?  If so,
how does a client that belongs to multiple domains
pick a UPN to send to the server?

2. It would be good to define at least one other
UserMappingType as a proof that the framework can
be applied to a non-Microsoft environment.

3. If the UserMappingDataList and Certificate messages
may be sent in either order, it would be good to specify
that UserMappingDataList be sent after Certificate.
This order would highlight UserMappingDataList's role
of providing additional information to augment the
certificate, and the implicit requirement that
UserMappingDataList only be used in conjunction with
a client certificate.  (I assume that the server cannot
send a ServerHello with user-mapping extension without
following with a CertificateRequest message.)

4. I'd be interested in a use case that elaborates how
a server uses the UpnDomainHint and the client certificate
to locate a user in a directory database and what the
server can do when the user has been located.

Wan-Teh Chang