ietf
[Top] [All Lists]

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

2006-03-20 11:36:01
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 <wtchang(_at_)redhat(_dot_)com>
To: tls(_at_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org
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(_at_)domain(_dot_)

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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>