Subject: [TLS] RE: Last call comments for draft-santesson-tls-(ume-04, supp-00)

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 3 Apr 2006 12:16:33 +0100

Pasi,

Thanks for the good review work.

I agree to all points and requests for changes except for the following
issues/concerns:

4) I would much rather keep the current user mapping hint definition.
Both ways works technically and it is more a matter of taste. The
current hint type form is already implemented in code and thus it would
mean a lot of work for little gain to change it.

5) I do not disagree. We originally had a ref to 1034 but Kurt advised
us that we should refer to 1123. Apparently this was not correct. RFC
3280 makes the same type of reference to 1024 for information contained
in the dNSName subject alt name.

6) For this draft we mean that it should be a domain name according to
the "preferred name syntax" as discussed before. This name form is not
specific to Microsoft. If this is not enough then we could provide some
information in an informational Annex as you suggested.

7) I had the same concerns. I'm not sure whether a document that is
referenced in a SHOULD statements is to be considered informative or
normative. I will align the document with the decision made.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: den 3 april 2006 12:45
> To: Stefan Santesson; [email-masked]
> Cc: [email-masked]
> Subject: Last call comments for draft-santesson-tls-(ume-04,supp-00)
> 
> Some additional last call comments for draft-santesson-tls-ume-04
> and draft-santesson-tls-supp-00:
> 
> 1) The IANA considerations sections in both documents are
>    incomplete (missing the requests to assign new numbers),
>    in some details correct (number ranges overlap), and unclear.
>    Here's a proposal for better text:
> 
>    draft-santesson-tls-supp:
> 
>    This document defines a new TLS handshake message,
>    "supplemental_data", assigned a value of TBD-BY-IANA from the TLS
>    HandshakeType registry defined in [RFC4346].
> 
>    This document establishes a new registry, to be maintained by IANA,
>    for TLS Supplemental Data Types.  Initially, the registry is empty.
>    Values from the range 0-16385 are assigned via Standards Action
>    [RFC2434].  Values from the range 16386-65279 are assigned via
>    Specification Required [RFC2434].  Values from the range
>    65280-65535 are reserved for Private Use [RFC2434].
> 
>    draft-santesson-tls-ume:
> 
>    This document defines a new TLS extension, "user_mapping", assigned
>    a value of TBD-BY-IANA1 from the TLS Extension Type registry
>    defined in [RFC4366].
> 
>    This document defines a new TLS supplemental data type,
>    "user_mapping_data", assigned a value of TBD-BY-IANA2 from the TLS
>    Supplemental Data Type registry defined in
>    [draft-santesson-tls-supp].
> 
>    This document establish a new registry, to be maintained by IANA,
>    for TLS User Mapping Types. Initially, the registry contains one
>    entry: upn_domain_hint (0). Values from the range 1-63 are assigned
>    via Standards Action [RFC2434].  Values from the range 64-223 are
>    assigned via Specification Required [RFC2434]. Values from the
>    range 224-255 are reserved for Private Use [RFC2434].
> 
> 2) tls-ume, Section 5: "The client SHOULD only send the
>    UserMappingDataList in the supplemental data message if it is
>    agreed upon in the hello message exchange"
> 
>    This is wrong (and violates a "MUST" in tls-supp): the user
>    mapping data list MUST NOT be sent if it was not agreed in the
>    ClientHello/ServerHello exchange.
> 
> 3) Security considerations in both documents should explicitly
>    point out that the information is not encrypted (and thus visible
>    to eavesdroppers), and is sent before the peer is authenticated
>    (unless the "double-handshake" trick is used). This may be obvious
>    to the authors, but not to everyone reading these documents...
> 
> 4) tls-ume: Would it make sense to define two UserMappingData types,
>    one for "user@domain" and another one for just "domain", instead
>    of combining them in one type?
> 
> 5) tls-ume, Section 3: ".. contain a domain name in the "preferred
>    name syntax," as specified by RFC 1123". RFC 1123 never even
mentions
>    the term "preferred name syntax" (it is mentioned in RFC 1034,
>    though).
> 
> 6) tls-ume: The document should contain at least an informative
>    reference to a document describing what this Microsoft UPN is.
>    Simply saying it's of the form "user@domain" is not very helpful.
>    For instance, does "domain" mean it's a DNS name? (Windows uses
>    the word "domain" also for names that don't have anything to
>    do with DNS). Is the domain part an IDN-aware or IDN-unaware
>    domain name slot? (Or neither?) Are some special characters
>    (e.g., punctuation, at sign) in the "user" part forbidden,
>    or escaped/encoded somehow specially?
> 
> 7) References in tls-ume: IMHO references N7,N8,N9 seem more
>    Informative than Normative. Reference N5 is never cited in text.
>    RFC 1123 is cited in the text, but not included in reference list.
> 
> Best regards,
> Pasi

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

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 4 Apr 2006 10:24:32 +0100

Will do.

Stefan Santesson

> Sent: den 4 april 2006 11:17
> To: Stefan Santesson; [email-masked]
> Cc: [email-masked]
> Subject: RE: Last call comments for
draft-santesson-tls-(ume-04,supp-00)
> 
> Stefan,
> 
> Thanks for the clarification. Please include text about this
> in the draft as well.
> 
> Best regards,
> Pasi
> 
> > From: ext Stefan Santesson [mailto:[email-masked]]
> > Sent: 04 April, 2006 02:08
> > To: Russ Housley; Eronen Pasi (Nokia-NRC/Helsinki)
> > Cc: [email-masked]
> > Subject: RE: Last call comments for
> > draft-santesson-tls-(ume-04,supp-00)
> >
> > Sometimes it is sufficient to specify the domain as the user name is
> > provided by the cert but that cert is used to access multiple
accounts
> > in different domains. In other cases the full name@domain is needed.
> >
> > We chose to provide for both alternatives using the same hint type.
> > This works well and I would prefer to keep it that way.
> >
> >
> > Stefan Santesson
> > > From: Russ Housley [mailto:[email-masked]]
> > > Sent: den 3 april 2006 17:10
> > > To: [email-masked]; Stefan Santesson
> > > Cc: [email-masked]
> > > Subject: RE: Last call comments for
> > draft-santesson-tls-(ume-04,supp-00)
> > >
> > > Pasi:
> > >
> > > My comments were with respect to the user_principal_name within
the
> > > UpnDomainHint.  Sorry for being ambiguous.
> > >
> > > Russ
> > >
> > >
> > > >Russ Housley wrote:
> > > > >
> > > > > Pasi:
> > > > >
> > > > > I do not think so.  The name is user@domain.  It would be
> > meaningless
> > > > > if only user was present, and t would me meaningless if only
> > domain
> > > > > was present.
> > > >
> > > >I don't know if it's meaningless or not, but the current draft
does
> > > >say that
> > > >
> > > >    The UpnDomainHint MUST at least contain a non empty
> > > >    user_principal_name or a non empty domain_name. The
> > UpnDomainHint
> > > >    MAY contain both user_principal_name and domain_name.
> > > >
> > > >In other words, one of the fields can be empty. And since the
> > > >user_principal_name field is of the form "user@domain",
> > > >it looks like the UpnDomainHint structure can actually contain
> > > >two _different_ domain names. In other words, the spec does
> > > >allow things like:
> > > >
> > > >   UserMappingData {
> > > >     user_mapping_version = upn_domain_hint(0)
> > > >     UpnDomainHint {
> > > >       user_principal_name = "[email-masked]"
> > > >       domain_name = "bar.example.net"
> > > >     }
> > > >   }
> > > >
> > > >But the draft currently does not explain what this would mean,
> > > >or what the domain-name-only hints are (perhaps they're
> > "Host Mapping
> > > >Data" for host certificates instead of user certs, or something).
> > > >This needs to be clarified.
> > > >
> > > >Best regards,
> > > >Pasi
> >
> >

---

From: Russ Housley <[email-masked]>
Date: Tue, 04 Apr 2006 07:16:59 -0400

Stefan,

Nothing in the document explains this use case.  So, you need to add 
text that explains the processing in each possible case.  Are there 
two cases or three?

Russ

 > provided by the cert but that cert is used to access multiple accounts
 > > My comments were with respect to the user_principal_name within the
 > > >I don't know if it's meaningless or not, but the current draft does
 > > >say that
 > > >

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 4 Apr 2006 23:28:04 +0100

I'm sorry if my text was unclear.

If you specify UPN, then domain is automatically included in the UPN.
I'm preparing a new text proposal. I will send it tomorrow morning.
That will include processing and normalization of the domain component
which is Unicode UTF-8 normalized with Nameprep.

Stefan Santesson

> Sent: den 4 april 2006 20:15
> To: Stefan Santesson; [email-masked]
> Cc: [email-masked]
> 
> It is okay with me, but your description does not match the
> text.  Based on your note, the domain must be present, and the upn is
> optional.  The text that Pasi quoted needs to be replaced with a
> sentence that says this.
> 
> Then, you need to add a paragraph that explains the processing when
> only the domain is present, and then an paragraph that explains the
> processing when both the domain and the upn are present.
> 
> Russ
> 
> 
> At 07:07 PM 4/3/2006, Stefan Santesson wrote:
accounts
the
does
UpnDomainHint
> > > >or what the domain-name-only hints are (perhaps they're "Host
Mapping