Subject: RE: [TLS] draft-ietf-tls-psk and identity

From: [email-masked]
Date: Fri, 10 Jun 2005 14:40:06 +0300

Sam Hartman wrote:
> Hi.  The PSK draft is now before the IESG for final approval.
> 
> As one of the people reviewing the draft, I have two questions
> I'd like to ask.
>
> The first is why is the identity not labeled.  In other cases
> where we've had a lot of name spaces, we have chosen to label
> the identity with which name space it comes from.  Why did you
> choose to just have an opaque string?  How frequent will it be
> that identities from one namespace might be confused with
> identities from another namespace.  It seems like for example
> NAIs and email addresses might be confused.  These seem like
> they might both be commonly used.  Other identities look
> similar to email addresses.
>
> What would the costs of labeling be?  Would it be worth the cost?

As Peter already responded, labeling the identity with its
namespace/type was discussed several times during the design 
process, as was using different encodings for different 
namespaces (IPv4 addresses as four octets, X.500 DNs as 
DER-encoded, etc.). 

There were arguments both for and against labeling.  I've
summarized below some of these arguments (not totally
objectively, as I supported the alternatively that was 
chosen -- but I think it's fair to say that both alternatives 
have good arguments for them, so the choice is some kind of 
trade-off).

The choice was largely motivated by the question "given two
administrators who agree on what identity and key to use, which
design is going to result in less interoperability problems?"
There were several reasons that seemed to suggest the answer
would be "no labels":

- If labels are used, different implementations will support 
  different sets of namespaces. This certainly increases the 
  chances of problems, even though they can be reduced by 
  specifying which namespaces implementations MUST/SHOULD/MAY 
  support.

- It is almost certainly necessary to have a label for opaque 
  identities (like ID_KEY_ID in IKEv2) since we can't anticipate 
  all possible namespaces. Basically, this opaque namespace
  inherits all the weaknesses in the "no labels" approach
  or even worse (e.g. IKEv2 leaves ID_KEY_ID as vendor-specific
  octet stream, so don't even know whether it's supposed to 
  be ASCII, let alone  UTF-8 or stringprep-processed)

- Labels are one more thing the endpoints need to agree on:
  for instance, should "[email-masked]" be labeled as a NAI,
  email address, opaque, or something else? Or is "steve.jobs" 
  a NAI, FQDN, opaque, or something else?

- The confusion between namespaces was not considered important,
  e.g.,  it was not considered realistic that a single TLS 
  server would have different keys for the NAI "steve.jobs" 
  and FQDN "steve.jobs". 

- Labels can increase implementation complexity, especially
  if different namespaces use different encodings.

There are certainly other valid questions you could ask, and
arguments for using labels and different encodings:

- Some identity types are "nicer" to encode in some other 
  format than UTF-8 string (e.g. IPv6 address as 16 octets,
  X.500 DNs as DER)

- Some have several different string formats (e.g. "::1" vs 
  "0:0:0:0:0:0:0:1" for IPv6 addrsses). This is one more
  thing the endpoints have to agree about (but if at least 
  one of the endpoints allows entering arbitrary strings
  in the management interface, the administrators can simply 
  agree on this: it's not possible that the other endpoint
  would not support this namespace type or encoding).

- Identities may have more semantics than just selecting the
  right key to use (e.g. authenticating with key identified 
  as "[email-masked]" allows you to access email stored 
  in /var/mail/joe). However, this are largely a local issue, 
  and does not have to be visible in the on-the-wire encoding
  in TLS protocol.

- Identities may come from somewhere else than human-operated
  management interfaces. (But this is probably the same place 
  the keys come from; so we're talking about some key distribution 
  system here... and presumably that system anyway specifies in
  more detail what identities look like in that system.)

How much weight each of these arguments carries depends a lot on 
what kind of scenario you have in your mind (e.g. administrators
configuring things manually in some management interface vs. 
something else).

> Secondly, I'm concerned about internationalization.  Scetion
> 5.4 says that an appropriate stringprep profile should be used
> but does not say what this profile is.
> 
> The PSK draft seems to want client management interface to be
> able to take arbitrary identity forms without knowing about
> these identity forms.  However the preparation and
> normalization strategy the IETF has adopted assume that the
> entity processing an ID needs to apply ID-form-specific
> normalization to that ID.

> What alternatives have been considered for
> internationalization?  Who has reviewed the
> internationalization concerns of this draft?

Different stringprep profiles are appropriate for different
identity types (e.g Nameprep for FQDN, SASLprep for usernames).

No formal review of the i18n concerns has been done.

> Would things work better if the client management interface
> preserved the ID and never normalized, requiring that the
> server use some stringprep (and possibly other) normalization/
> canonicalization after determing the appropriate ID form?  

I like your suggestion. The important part is that stringprep
processing is done before the identity is used, and the server
knows better how it's going to use the identity (e.g. if the
identity is FQDN, the lookup to find the right key might be
case-insensitive, so it'll do some processing anyway).

How about changing this text in 5.4:

o  Entering PSK identities consisting of up to 128 printable
   Unicode characters.  Supporting as wide character repertoire
   and as long identities as feasible is RECOMMENDED, as is
   processing the character string with an appropriate
   stringprep [10] profile.

to this:

o  Entering PSK identities consisting of up to 128 printable
   Unicode characters.  Supporting as wide character repertoire
   and as long identities as feasible is RECOMMENDED.

And adding this text just before Section 5.1?

   This document does not specify how the server stores the keys
   and identities, or how exactly it finds the key corresponding
   to the identity it receives. For instance, if the identity is
   a domain name, it might be appropriate to do a
   case-insensitive lookup. It is RECOMMENDED that before
   looking up the key, the server processes the PSK identity
   with a stringprep profile [10] appropriate for the identity
   in question (such as Nameprep [NAMEPREP] for domain names or
   SASLprep for usernames [SASLPREP]).

On the other hand, it's not clear that this would be a very big
improvement, so I'm fine with leaving the text as is as well...

Best regards,
Pasi

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 13 Jun 2005 15:01:12 -0400

I think your proposed text is a significant improvement.  If the
working group is OK with this proposed change I'd be happy to clear my
discuss.  You have certainly convinced me you have carefully
considered the issue of identity tagging.

There is one minor error in your text: the nameprep profile of
stringprep is applied to domain name components not domain names.

How about the following as a replacement new paragraph:

   This document does not specify how the server stores the keys and
   identities, or how exactly it finds the key corresponding to the
   identity it receives. For instance, if the identity is a domain
   name, it might be appropriate to do a case-insensitive lookup. It
   is RECOMMENDED that before looking up the key, the server processes
   the PSK identity with a stringprep profile [10] appropriate for the
   identity in question (such as Nameprep [NAMEPREP] for components of
   domain names or SASLprep for usernames [SASLPREP]).