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

From: <[email-masked]>
Date: Mon, 3 Apr 2006 13:45:02 +0300

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: Russ Housley <[email-masked]>
Date: Mon, 03 Apr 2006 09:51:43 -0400

>    of combining them in one type?

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.

Russ

---

From: <[email-masked]>
Date: Mon, 3 Apr 2006 17:44:44 +0300

> if only user was present, and t would me meaningless if only domain 

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: Mon, 03 Apr 2006 11:09:59 -0400

Pasi:

My comments were with respect to the user_principal_name within the 
UpnDomainHint.  Sorry for being ambiguous.

Russ