TLS User Mapping Extension
draft-santesson-tls-ume-07

[Ballot discuss]
Removed all my discuss level issues on tls-supp

On tls-ume, removed all my comment with exception of one

>> Reading this document I don't understand how I would build a client that
>> interoperated with some other server without a lot more information. For
>> example, if the user_principal_name has user@domain, I don't understand why
>> we also need a domain_name. I expect that we probably do need both but for a
>> reason that is not explained here. The draft defines the syntax to encode
>> some bits on the wire stuff but provided no semantic level information of
>> what I need to put in the fields or how they are used. I am confused about
>> if the client certificate is a user certificate or device certificate. And
>> if it is a device certificate, is the UPN temporarily bound to it? I suspect
>> that I would have no problems with the type of system this document
>> contemplates, I just don't see enough information to know how to build it.
>
> I pushed on this point very hard, and got the encoding added to the
> document.  It seems that an account name will be typed by the user,
> and the specified encoding will be applied, and it will be sent to
> the server to perform whatever validation it wants.

After the last phone call, I understand the desire/need to have the general
container mechanism in UME be standards track. However, the specific
instance defined of UPN and upnDomainHint still leave me somewhat confused
on how I would implement it in a way that had any hope of interoperating
with a server some other vendor had implemented.

I read things like
  "This has
  however several drawbacks since it prevents the use of certificates
  with an absent UPN and also requires re-issuance of certificates or
  issuance of multiple certificates to reflect account changes or
  creation of new accounts."

And I assume that somehow this whole thing allows me to chose some certificate that is not bound to a UPN and somehow treat it like it was bound to a UPN and that it authenticates me. I don't know what certificate the client should use.

I read things like
    " Upon receipt
  and successful completion of the TLS handshake, the server MAY use
  this hint to locate the user's account from which user information
  and credentials MAY be retrieved to support authentication based on
  the client certificate."
And I wonder how this works.

I have no idea why it would ever be needed to have both a UPN and a domain hint. I suspect this is because in some cases the domain in the UPN will not be the same as the domain hint but I have no clue what a client should put in either.

To summarize, as a client implementer, I don't know what certificate to use, what to put in the UPN, or what to put in the domain Hint. As a server implementers, I don't know what to do with these.

I don't want to put words in Stefan's mouth but I get the feeling that he saying something along lines of... Look UPN/domainHint is a container, vendor X has clients that put some bits in it and the servers from vendor X know what to do with the bits. Vendor Y could use this for their bits with their clients and servers. The is no clear way that vendor Y would know how to put vendor X's bits in the container. And yes, if a client from vendor Y put vendors Y bits in the container and sent them to a vendor X server, it would not work.

Is this a somewhat accurate summary of where we are on this? If I am misunderstanding, then we can sort me out. If this is about right, then we can decide what to do next - perhaps this is fine.

[Ballot discuss]
Section 1 paragraph 3 of the -ume draft now says:

> The TLS extension in combination with the
> defined hint type provide a significant improvement to this situation
> as it allows a single certificate to be mapped to one or more
> accounts of the user and does not require the certificate to contain
> a UPN.

Could we possibly change the last line to "a proprietary UPN."?
That would relieve my remaing concern at the proprietary reference
earlier in the paragraph.

[Ballot discuss]
I believe draft-santesson-tls-ume-05.txt needs an internationalization considerations section.  As it stands now, the draft specifies:

The user_principal_name parameter, when specified, SHALL contain a
  Unicode UPN, encoded as a UTF-8 string in the following form:

      user@domain

  For example the UPN 'foo@example.com' represents user 'foo' at domain
  'example.com'.

  The user_principal_name field, when specified, SHALL be of the form
  "user@domain", where "user" is a UTF-8 encoded Unicode string that
  does not contain the "@" character, and "domain" is a domain name
  meeting the requirements in the following paragraph.

  The domain_name field, when specified, SHALL contain a domain name in
  the usual text form: in other words, a sequence of one or more domain
  labels separated by ".", each domain label starting and ending with
  an alphanumeric character and possibly also containing "-"
  characters.  This field is an "IDN-unaware domain name slot" as
  defined in RFC 3490 [N7] and therefore, domain names containing non-
  ASCII characters have to be processed as described in RFC 3490 before
  being stored in this field.

I think that is: "this a UTF-8 string, except that anything that is after the @ sign is
an ACE encoding of UCS that is restricted by the hostname permitted
characters".  Spelling this out a little more carefully is going to be required
for an implementor to get this right.  It also seems like the document might
need to describe how this differs from the existing syntax (if it does) of
UPNs stored in directories, as folks will likely want to map this code.

Also, this document appears to inherit the c-like syntax of the TLS RFCs; that's
fine, but it needs to say explicitly where to look for the rules.

[Note]: 'The IETF Last Call is scheduled to end on April 11th.  The author is working on an update to address the comments that have been received.  The updates will be in the area of internationalization.' added by Russ Housley

[Ballot comment]
I am clearing my DISCUSS, entering a comment instead.

Originally we had (from Bert Wijnen):

------------------

W.r.t draft-santesson-tls-ume-04.txt draft:

    struct {
            opaque user_principal_name<0..2^16-1>;
            opaque domain_name<0..2^16-1>;
    } UpnDomainHint;

So they cater for 64K for username and domain name??
Wow... we need more bandwidth in our future networks

I also find the use of SHALL and MAY not so great.
Maybe I am too senstitive to those keywords possibly many of the uppercase uses can be just lowercase?

On page 6, I am surprised it is only RECOMMENDED to use some form of stringPrep.
That feels like the current MS implementations does not do it and so only deals with US ASCII for now? Which I think is not good.

---------------

The stringPrep issue was the main reason of the DISCUSS. In the new version they took away ALL of the stringPrep material. I think this is good for the domain name, they now refer to rfc3490 for that, but I doubt that this is good for the user_principal_name. I suggest that the APPS ADs have a look at this.

[Ballot discuss]
draft-santesson-tls-ume-05.txt says (section 1)

  The UPN (User Principal Name) is a name form defined by Microsoft
  which specifies a user's entry in a directory in the form of
  userName@domainName.  Traditionally Microsoft has relied on such UPN
  names to be present in the client certificate when logging on to a
  domain account.

This is inappropriate wording for an IETF standard.

I also note that the UPN format is defined in the middle of section
3. Is that the basic normative definition? If so I believe it should be
a separate section, explicitly referenced. So here is a suggestion for
rewriting the above paragraph:

  The UPN (User Principal Name) is a name form defined in Section X.X
  below which specifies a user's entry in a directory in the form of
  userName@domainName.  At least one vendor has relied on such UPN
  names to be present in the client certificate when logging on to a
  domain account.


Similarly,

5  Security Considerations

  The UPN sent in the UserMappingDataList is unauthenticated data that
  MUST NOT be treated as a trusted identifier. Authentication of the
  user represented by that UPN MUST rely solely on validation of the
  client certificate. One way to do this in the Microsoft environment
  is to use the UPN to locate and extract a certificate of the claimed
  user from the trusted directory and subsequently match this
  certificate against the validated client certificate from the TLS
  handshake.

The proprietary reference seems quite inappropriate in an IETF standard.
Could we simply delete "in the Microsoft environment"?

[Ballot comment]
From Gen-ART review by Tom Taylor on draft-santesson-tls-ume-04.txt:


Substantive comments:

1. Section 1.2 Design Considerations, second sentence. This sentence is talking about a possible alternative design approach to protect the data being sent. A concern over inappropriate dissemination is expressed in the Security Considerations section of the draft.

The proposal in the Security Considerations section that the client use discretion in sending the information is a half-hearted look at the issue, since an attacker can view the SupplementalData in transit. The authors may need to make up their minds whether exposure is an issue or not.

2. The protocol requires assignment of an extension type number to the user_mapping extension. Similarly, a supplemental data type number needs to be assigned to user_mapping_data. I suppose this can be left to IANA to assign the next available number, since the numbering sequence doesn't seem to have any protocol significance.

3. A literal reading of 2246bis section 4.3 suggests, based on the upper bounds of the various data structures in section 3 of the present document, that the user_mapping_data_list doesn't provide enough space to hold even one instance of UserMappingData. Is such a cavalier use of upper bounds normal TLS specification usage?

4. Is there any relationship between the value of user_principal_name and the value of domain_name, if they are both present in the same UpnDomainHint instance?

5. In section 4, after the user_mapping extension has been negotiated, the sending of the SupplementalData message is only a MAY. Is this the intended strength?

6. In section 5, Security Considerations, there are two SHOULD bullets for client behaviour. The first one raises a question in my mind that may need additional text in draft-santesson-tls-supp-00.txt. The question is: what is the behaviour expected of a server that receives supplemental data of a type that has not been negotiated as an extension?

7. Same bullets: any time a SHOULD is specified, the document should also describe the exceptional case. When would a client send supplemental data it has not negotiated? Isn't this a protocol violation? What exception do you see for the second bullet?


----------------------

Editorial
---------

1. The fifth and sixth paragraphs of the introduction are a bit awkward. You alternate between failure and success cases. Also, there is an alternation between present and future tense. I suggest a rearrangement like this:

  "The new TLS extension (user_mapping) is sent in the client hello
  message. Per convention defined in RFC 4366 [N4], if the
  server does not understand the extension, it responds with a
  server hello omitting it. In response, the client proceeds as
  normal, and does not include the UserMappingDataList data in the TLS
  handshake. Note that the SupplementalData handshake message may still
  be sent because of other mutually-agreed extensions.

  "If the new extension is understood, the server places the same
  extension (user_mapping) in the server hello message, to
  inform the client that the server understands it. In response,
  the client inserts UserMappingDataList data into a SupplementalData
  handshake message sent prior to the Client's Certificate message. The
  server will then parse this message, extracting the client's domain,
  and store it in the context for use when mapping the certificate to
  the user's directory account. Note that the SupplementalData
  handshake message may also contain data relating to other
  mutually-agreed extensions."

I added a sentence to each paragraph that you may also find useful to add.


2. Section 4 repeats some of the material that was stated more clearly and completely in section 2. Could you combine the sections, or take the repeated material out of section 4 and refer back to section 2?

3. In the Acknowledgements, you have an extra 'o' in "Rescorla".

[Ballot discuss]
Discuss level issues on tls-supp

Holding a discuss for IANA

I like the idea of allowing the TLS handshake to cary an application defined
BLOB and have no problem with that. I do want to avoid defining a container
that is used for undocumented extensions to TLS. So I think it should be
made clear that  this is for use of application's data (meaning data passed
up to the application above TLS). Having a future specification that used
this to cary data used by TLS itself would not be appropriate.

I may be confused but it did not seem clear to me if there could be more
than one supplemental data in a message. If this is clear in the draft and I
just missed it, ignore this - if it is not clear, we should clarify. I'm
assuming we want one per message but each one can have multiple elements. I
don't care so much what the answer is as long as it is clear what the answer
is.


Discuss level issues on tls-ume

Holding a discuss for IANA

I don't understand why this needs to be PS. Could it be Informational? This
would help resolve my next issue.

Reading this document I don't understand how I would build a client that
interoperated with some other server without a lot more information. For
example, if the user_principal_name has user@domain, I don't understand why
we also need a domain_name. I expect that we probably do need both but for a
reason that is not explained here. The draft defines the syntax to encode
some bits on the wire stuff but provided no semantic level information of
what I need to put in the fields or how they are used. I am confused about
if the client certificate is a user certificate or device certificate. And
if it is a device certificate, is the UPN temporarily bound to it? I suspect
that I would have no problems with the type of system this document
contemplates, I just don't see enough information to know how to build it.




The stuff after this is just a comment and not part of my discuss.

I don't understand why these were not done as WG documents. They seem well
within the scope of the TLS WG. At this point, I'm not convinced that doing
them in the WG would significantly improve them so I am fine with them as
they are but it does seem weird.

Questions or comments on tls-supp

It is unclear if the code points are allocated in an appropriately balanced
way between Standards Action, Specification Required, and Private. A way to
deal with this would be to make all the ranges smaller and leave a large
Reserved range that future specification could allocate once it became clear
how the space will get used up. I don't really care about this too much as
all the sizes look big enough forever (famous last words).

Might be nice if security consideration pointed out what level of integrity
or confidentially (or lack thereof) was provided for the supplemental data.

Questions or comments on on tls-ume

Internationalization issues that others have mentioned.

[Ballot discuss]
Discuss level issues on tls-supp

Holding a discuss for IANA

I like the idea of allowing the TLS handshake to cary an application defined
BLOB and have no problem with that. I do want to avoid defining a container
that is used for undocumented extensions to TLS. So I think it should be
made clear that  this is for use of application's data (meaning data passed
up to the application above TLS). Having a future specification that used
this to cary data used by TLS itself would not be appropriate.

I may be confused but it did not seem clear to me if there could be more
than one supplemental data in a message. If this is clear in the draft and I
just missed it, ignore this - if it is not clear, we should clarify. I'm
assuming we want one per message but each one can have multiple elements. I
don't care so much what the answer is as long as it is clear what the answer
is.


Discuss level issues on tls-ume

Holding a discuss for IANA

I don't understand why this needs to be PS. Could it be Informational? This
would help resolve my next issue.

Reading this document I don't understand how I would build a client that
interoperated with some other server without a lot more information. For
example, if the user_principal_name has user@domain, I don't understand why
we also need a domain_name. I expect that we probably do need both but for a
reason that is not explained here. The draft defines the syntax to encode
some bits on the wire stuff but provided no semantic level information of
what I need to put in the fields or how they are used. I am confused about
if the client certificate is a user certificate or device certificate. And
if it is a device certificate, is the UPN temporarily bound to it? I suspect
that I would have no problems with the type of system this document
contemplates, I just don't see enough information to know how to build it.




The stuff after this is just a comment and not part of my discuss.

I don't understand why these were not done as WG documents. They seem well
within the scope of the TLS WG. At this point, I'm not convinced that doing
them in the WG would significantly improve them so I am fine with them as
they are but it does seem weird.

Questions or comments on tls-supp

It is unclear if the code points are allocated in an appropriately balanced
way between Standards Action, Specification Required, and Private. A way to
deal with this would be to make all the ranges smaller and leave a large
Reserved range that future specification could allocate once it became clear
how the space will get used up. I don't really care about this too much as
all the sizes look big enough forever (famous last words).

Might be nice if security consideration pointed out what level of integrity
or confidentially (or lack thereof) was provided for the supplemental data.

Questions or comments on on tls-ume

Internationalization issues that others have mentioned.

[Ballot discuss]
Following comments were provided by Bert Wijnen. He thinks and I agree they deserve a DISCUSS. I will not be in the meeting tomorrow, but if appropriate answers are provided today, I can still clear by tomorrow morning.

--------------------------------------------------
W.r.t draft-santesson-tls-ume-04.txt draft:

    struct {
            opaque user_principal_name<0..2^16-1>;
            opaque domain_name<0..2^16-1>;
    } UpnDomainHint;

So they cater for 64K for username and domain name??
Wow... we need more bandwidth in our future networks

I also find the use of SHALL and MAY not so great.
Maybe I am too senstitive to those keywords possibly many of the uppercase uses can be just lowercase?

On page 6, I am surprised it is only RECOMMENDED to use some form of stringPrep.
That feels like the current MS implementations does not do it and so only deals with US ASCII for now? Which I think is not good.

-------------

[Ballot comment]
From Gen-ART review by Tom Taylor on draft-santesson-tls-supp-00.txt:

In the second sentence of section 7 IANA Considerations, the term "TLS Authorization Data Format identifiers" is used. I believe that should be "TLS Supplemental Data Format identifiers".

(This is not a DISCUSS because I understand a -01 revision with this
correction has been submitted)

[Note]: 'The IETF Last Call is scheduled to end on April 11th.  The author is working on an update to address the comments that have been received.  The updates will be in the area of internationalization.' added by Russ Housley

IANA Last Call Comments:
Upon approval of this document the IANA will establish a new registry for TLS UserMappingType values.  The first entry in the registry is upn_domain_hint(0). Registration Procedures will be as follows:
range 0-63 (decimal) are assigned via Standards Action
range 64-223 (decimal) are assigned via Specification Required
range 224-255 (decimal) are reserved for Private Use

Should this new registry be nested within an existing location or should it be a stand-alone registry?

As the document is now, we understand the above to be the only IANA Actions, however we saw comments from Pasi Eronen that it may be missing some action requests for the IANA.  If this is the case the IANA Considerations section will need to be updated.

AD Review:  Comments provided to the author.  One of the comments is a
show-stopper.  I'm not convinced that the specified extension should
have no data.  In the future, a new mapping type will be defined, say
upn_foobar_hint.  We could encounter one implementation that supports the
UserMappingDataList, but only the upn_domain_hint, and another implementation
that supports the UserMappingDataList, but only the upn_foobar_hint.  The two
cannot interoperate, but the hello message exchange does not help sort it
out.  I think the client hello should include the UserMappingTypes supported
by the client, and the server hello should include the union of the
UserMappingTypes supported by the client and server.  That is, the server
should drop the ones that are not supported.  If the union is the null set,
then the server ought to omit the extension altogether.