Subject: RE: draft-santesson-tls-ume Last Call comment

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 21 Mar 2006 17:06:30 -0000

Kurt,

I've spent some time over this topic with Russ Housley and Paul Hoffman
here at the IETF and the conclusion is that we should not specify any
granular encoding or matching rules for the hints.

The client's use of the name hint requires the client to know its
account name and as such the client will also know in what form the
server needs it.

The client should never send the name hint in a way where the server
needs to process it in order to map the hint to an account.

There reference will be fixed (or removed).

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: den 7 mars 2006 18:35
> To: [email-masked]
> Subject: draft-santesson-tls-ume Last Call comment
> 
> I note the IETF last call was issued for rev. 2.  That
> revision no longer exists, hence I reviewed rev. 3.
> 
> This document specification of a "User Principal Name",
> I believe, is inadequate.
> 
> The I-D indicates that a user_principal_name is a sequence of
> 0 to 65535 bytes in the form of user@domain.  However,
> such a form implies the value is a character string,
> but there is no mention of what character set/encoding
> is used here.  I would think interoperability
> requires both client and server to have a common
> understand of what character set/encoding is to
> be used.  Additionally, there is no discussion
> of UPN matching.  Are byte sequences that differ
> only due to use of different Unicode normalizations
> to be consider the same or differ?  Are values
> case sensitive or not?  etc..
> 
> The domain_name field suffers not only from the
> above problem, but is flawed due to use of the
> outdated "preferred name syntax" of RFC 1034.
> This syntax doesn't allow domains such as
> 123.example.  The text should likely reference
> the RFC 1123 which updates the "preferred name
> syntax" for naming hosts.
> 
> Additionally, no mention of how International
> domain names (IDNs) are to be handled.
> 
> I recommend ABNF be used to detail the syntax
> of each of these fields and that the I-D detail
> how values of these fields are to be compared.
> Additionally, the I-D should discuss how IDNs
> are to be handled.
> -- Kurt
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 21 Mar 2006 11:19:12 -0600

>account name and as such the client will also know in what form the

What about character set/encoding?

- Kurt

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 Mar 2006 01:03:30 -0500

Kurt:

Would text like the following (which is largely stolen from 
draft-ietf-tls-psk) solve your concern:

This document does not specify how the server stores the 
user_principal_name, or how exactly it might be used to locate a 
certificate.  For instance, it might be appropriate to do a 
case-insensitive lookup.  It is RECOMMENDED that the server processes 
the user_principal_name with a stringprep profile [STRINGPREP] 
appropriate for the identity in question, such as SASLprep [SASLPREP].

Russ

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 22 Mar 2006 09:04:02 -0600

At 12:03 AM 3/22/2006, Russ Housley wrote:
>Kurt:
>
>Would text like the following (which is largely stolen from draft-ietf-tls-psk) solve your concern:

No.  While the language does address part of the question:
        how/where canonical of the user_principal_name
      string is performed?
it neither addresses this question:
        how/where canonical of the domain_name
      string is performed?
nor address the question:
        what character set/encoding is used on the wire in
        transferring these character strings?

I also suspect that the selection of SASLprep here, which
is intended to be used for simple usernames and passwords,
is appropriate for all of the user_principal_name string.
My understanding is that the user_principal_name is
composed of both a simple username part and a domain
part.  Components of the latter likely should instead
be prepared by nameprep (if allowed to carry IDNA
components).   Also, as the user part of the 
user_principal_name is, it appears from casual
examination of various MS documents, to be
case insensitive, SASLprep should not be used.

Kurt

>This document does not specify how the server stores the user_principal_name, or how exactly it might be used to locate a certificate.  For instance, it might be appropriate to do a case-insensitive lookup.  It is RECOMMENDED that the server processes the user_principal_name with a stringprep profile [STRINGPREP] appropriate for the identity in question, such as SASLprep [SASLPREP].
>
>Russ
>

---

From: <[email-masked]>
Date: Wed, 22 Mar 2006 17:59:14 +0200

Russ,

RFC 4279 has one additional requirement that is quite important
in this context: "identity MUST be first converted to a character 
string, and then encoded to octets using UTF-8".

If my user name contains the "Latin small letter A with diaeresis",
it's important to specify whether the bytes-on-the-wire should contain
that in ISO 8859-1, Windows code page 1254, UTF-8 encoded Unicode,
little-endian UTF-16 encoded Unicode, or big-endian UTF-16 encoded
Unicode.

In other words, I don't think treating the identity as an _octet_ 
string is a good approach. The UPN looks more like a _character_ 
string to me, and then we need to specify how the characters get
encoded to octets. Just assuming that the client knows what encoding 
the server is expecting sounds like a recipe for interoperability 
problems...

(However, I do agree with Stefan that we probably should not specify
any more granular matching rules or ABNF...)

Best regards,
Pasi 

> From: ext Russ Housley [mailto:[email-masked]] 
> Sent: 22 March, 2006 08:04
> To: Kurt D. Zeilenga; Stefan Santesson
> Cc: [email-masked]
> Subject: RE: draft-santesson-tls-ume Last Call comment
> 
> Kurt:
> 
> > >I've spent some time over this topic with Russ Housley and 
> > >Paul Hoffman here at the IETF and the conclusion is that we 
> > >should not specify any granular encoding or matching rules for 
> > >the hints.
> > >
> > >The client should never send the name hint in a way where 
> > >the server needs to process it in order to map the hint to 
> > >an account.
> > >

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 Mar 2006 11:47:24 -0500

Kurt:

Okay.  I think I get your point.  I'll try one more time, but if that 
does not satisfy you, then you will have to respond with proposed 
text.  I'm trying to address Pasi's comment too.

Based on updates from a previous comment, the document will say:

    The domain_name parameter, when specified, SHALL contain a domain
    name in the "preferred name syntax," as specified by RFC 1123.

I think that this resolves your concern about the encoding of domain_name.

I propose the following text to handle the same concern for 
user_principal_name:

    The user_principal_name parameter, when specified, SHALL contain
    an Unicode UPN, encoded as a UTF-8 string.

Now, for the rest:

    This document does not specify how the server stores the
    user_principal_name, or how exactly it might be used to locate a
    certificate.  For instance, it might be appropriate to do a
    case-insensitive lookup.  It is RECOMMENDED that the server
    processes the user_principal_name with a stringprep profile
    [STRINGPREP] appropriate for the identity in question, such as
    Nameprep [NAMEPREP] for the portion domain portion of UPN
    and SASLprep [SASLPREP] for the user portion of the UPN.

Russ

At 10:04 AM 3/22/2006, Kurt D. Zeilenga wrote:
> case-insensitive lookup.  It is RECOMMENDED that the server 
> processes the user_principal_name with a stringprep profile 
> [STRINGPREP] appropriate for the identity in question, such as 
> SASLprep [SASLPREP].
> >
> >Russ
> >

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 26 Mar 2006 14:48:17 -0800

First, I think much of my concern is a due to having no clue
what a "user principal name" is in the context of this draft.
It seems to be some identifier used in some directory service.
The only clue given in the document is that it is a "name form
defined by Microsoft".  It is odd that there is no reference,
not even an informative one, to this definition.

As I am lacking clue, I doubt I can offer appropriate text provding
the (necessary) clue that independent developers will need to
produce an interoperable implementation.   But I will, nevertheless,
try in hopes it help you and other better understand my concerns.
It will likely need to be reworked by the I-D authors based upon
their understanding of what a UPN is. 

At 08:47 AM 3/22/2006, Russ Housley wrote:
>Kurt:
>
>Okay.  I think I get your point.  I'll try one more time, but if that does not satisfy you, then you will have to respond with proposed text.  I'm trying to address Pasi's comment too.
>

I would suggest instead:
   The domain_name parameter, when specified, provides a DNS
   [RFC1034][RFC2181] host name [RFC1123] represented as an ASCII
   [ASCII] character string conforming to the <domain> production
   provided in Section 2.1 of [draft-zeilenga-ldap-cosine].

   It is also noted that applications supporting Internationalized
   Domain Names SHALL use the ToASCII method [RFC3490] to produce
   <label> components of this <domain> production.

>I propose the following text to handle the same concern for user_principal_name:
>

I note that SASLprep is case-insensitive and hence may not
be appropriate for the user portion of a UPN.  I note that
Nameprep has to be applied component wise.  I also think it
odd to allow both toUnicode and toASCII domain component
forms on the wire.  The specification should choice one or
the other (I recommend the latter).

However, based in part with off line discussions with Stefan,
I suggest.

   This document does not detail the syntax or semantics of
   a User Principal Name beyond that it is a string of UTF-8
   encoded Unicode characters (with no required normalization)
   where at least of these characters is the COMMERCIAL AT
   ("@" U+0040) character.  The syntax and semantics of User
   Principal are application specific.  It is expected that
   applications calling for the use of this extension detail
   these syntax and semantics.

I note that I believe independent developers have near-zero
chance of producing an interoperable implementation of this
I-D (as is, or as modified by the various suggestions).  The
developer, it seems, has to depend on knowledge gained outside
of this I-D.

Regards, Kurt