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

["Stefan Santesson" <[e-mail]>]

I was made aware of these comments that in some mysterious way didn't
make its way to my inbox. Sorry for the delay.

Comments in-line;

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

>Date: Tue, 28 Feb 2006 10:54:35 -0800
>From: Wan-Teh Chang <[e-mail]>
>To: [e-mail]
>Cc: [e-mail]
>Subject: Re: [TLS] Re: Last Call: 'TLS User Mapping
>         Extension'      toProposedStandard
>
>Russ Housley wrote:
>>
>>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 ....
>
>I agree.  A rationale like the above would be a good addition to the 
>Internet-Draft to strengthen its motivation.
>

<Stefan> This could easily be accommodated in the rationale section.


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

<Stefan> I really don't think we should mess with the certificate
message as it is widely deployed as it is and does not include
extensibility to accommodate name hints.

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

<Stefan> This must be up to local policy. There are many ways the client
can have or obtain this knowledge. E.g. the client could know this from
the host address it is using for connecting to 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.)
>

<Stefan> I don't think there is a need for any new mechanisms here.

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

<Stefan> Yes, that is possible and also a typical issue for local policy
on the application layer. The client application, in cooperation with
the user will know what account it is trying to access, this will
according to local policy translate to a UPN. The protocol we define
here only describes how to communicate that UPN, not how you conclude
the UPN for a client. The important fact is that having many UPNs for a
single user is possible using the same certificate. This standard
proposal enables that.

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

<Stefan> We can't define a new user mapping type just to have one more.
There has to be a use case with a need for one. The current hint can be
used with a wide set of account names in practically any environment
that use the principles of user@domain.

But the extensibility is there in case a new need is there in the
future.
The security AD (Russ) has assisted in developing that part of the
document.

It also worth noting that the RedHat team has publicly said that they
are also considering using this standard with the same name form.

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

<Stefan> No, you need the user mapping before you can validate the
certificate. The server uses that data to locate the information it
needs to successfully verify the certificate sent in the next step. The
current order is therefore more logical.

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

<Stefan> In our current primary use case the UpnDomainHint carries the
name of an domain user account. The server locates that account and
retrieves the certificate of that user that maps to this account. The
server then checks that the validated certificate sent over the TLS
handshake is consistent with the internally retrieved certificate. This
relieves the client from the requirement in current environments to
carry a UPN name in the client's certificate and as such enables use of
legacy PKI deployments.

It is important to note that this relieves the user from dependency on
Microsoft PKI deployment. That is the customer's requirement and the
rationale for doing this.

>Wan-Teh Chang
>
>
>_______________________________________________
>Ietf mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/ietf
>

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