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

[Wan-Teh Chang <wtchang at redhat.com>]

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.

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


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf