Subject: [Gen-art] Gen-ART review of draft-santesson-tls-ume-04.txt

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 12 Apr 2006 16:05:02 -0400

I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Document: draft-santesson-tls-ume-04.txt
Intended Status: Proposed Standard (Individual submission via AD)
Shepherding AD: Russ Housley
Review Trigger: IETF Last Call (ends 13 April 2006)

Summary: This draft raised some questions in my mind that may need to be 
answered before it goes forward. One of these questions actually implies 
the need for new text in draft-santesson-tls-supp-00.txt.

I have some suggestions for editing.

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

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".

Hope these comments are helpful. Sorry they're so late.

Tom Taylor

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 13 Apr 2006 11:17:26 -0400

Tom:

>Summary: This draft raised some questions in my mind that may need 
>to be answered before it goes forward. One of these questions 
>actually implies the need for new text in draft-santesson-tls-supp-00.txt.
>
>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.

I do not agree.  The solution is not described will in 
draft-santesson-tls-supp-00.txt, but the double handshake is the 
solution.  I have written a description of it in the security 
considerations of draft-housley-tls-authz-extns-03.txt.  I'm please 
to include that text in this document if you believe it will help.

>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.

Leaving the number assignment to IANA is the usual practice.

>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?

I think of these values as maximum buffer sizes.  Take a look at 
2246bis, and you will see many cases like this.

>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?

Text was added in draft-santesson-tls-ume-05.txt to address a similar 
Last Call comment.  It has already had many eyes look at it, so I 
hope you are also satisfied.

>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?

Text was added in draft-santesson-tls-ume-05.txt to address a similar 
Last Call comment.  It has already had many eyes look at it, so I 
hope you are also satisfied,

>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?

Good point.  I suggest:

OLD:

    If present, the SupplementalData handshake message MUST contain a
    non-empty SupplementalDataEntry structure carrying data associated
    with at least one defined SupplementalDataType.  An explicit
    agreement that governs presence of any supplemental data MUST be
    concluded between client and server for each SupplementalDataType
    using the TLS extensions in the client and server hello messages.

NEW:

    If present, the SupplementalData handshake message MUST contain a
    non-empty SupplementalDataEntry structure carrying data associated
    with at least one defined SupplementalDataType.  An explicit
    agreement that governs presence of any supplemental data MUST be
    concluded between client and server for each SupplementalDataType
    using the TLS extensions in the client and server hello messages.
    Receiving an unexpected SupplementalData handshake message
    results in a fatal error, and the receiver MUST close the connection
    with a fatal unexpected_message alert.

>violation? What exception do you see for the second bullet?

Is this handled by the above text too?

Russ

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Apr 2006 17:58:54 +0200

Russ,

My DISCUSS is not about these points which I put more in
the useful clarification category. The DISCUSS is specifically
about the proprietary references in the draft which aren't
suitable for standards track. I'll drop it if it goes for
Informational with Microsoft in the title.

    Brian

Russ Housley wrote:
>> Summary: This draft raised some questions in my mind that may need to 
>> be answered before it goes forward. One of these questions actually 
>> implies the need for new text in draft-santesson-tls-supp-00.txt.
>>
>> is talking about a possible alternative design approach to protect the 
>> data being sent. A concern over inappropriate dissemination is 
>> 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.
> 
> 
> considerations of draft-housley-tls-authz-extns-03.txt.  I'm please to 
> include that text in this document if you believe it will help.
> 
>> 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.
> 
> 
> Last Call comment.  It has already had many eyes look at it, so I hope 
> you are also satisfied.
> 
> Last Call comment.  It has already had many eyes look at it, so I hope 
> you are also satisfied,
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 13 Apr 2006 14:24:49 -0400

Inline.

> Tom:
...
> include that text in this document if you believe it will help.
[PTT] Perhaps the second sentence of section 1.2 could be modified to 
refer to the double handshake solution?

> Leaving the number assignment to IANA is the usual practice.
[PTT] I see that has been added to the IANA Considerations section in 
-05. I didn't realize -05 had come out, BTW -- must have misread some of 
the messages that went by.

> 2246bis, and you will see many cases like this.

[PTT] OK
> Last Call comment.  It has already had many eyes look at it, so I hope 
[PTT] OK, I found it -- not quite where I expected, but it works.

> Last Call comment.  It has already had many eyes look at it, so I hope 
[PTT] I'll have to take your word for it -- I see no change.

>    with a fatal unexpected_message alert.

[PTT] Looks good.
> Is this handled by the above text too?
[PTT] Still not sure why the first bullet is a SHOULD, given that the 
above text implies a MUST.

---

From: "Stefan Santesson" <[email-masked]>
Date: Sat, 15 Apr 2006 02:33:52 +0100

A few comments in line;

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: den 13 april 2006 20:25
> To: Russ Housley
> Cc: Stefan Santesson; Ari Medvinsky; Joshua Ball; [email-masked]
> Subject: Re: Gen-ART review of draft-santesson-tls-ume-04.txt
> 
> Inline.
> 
> Russ Housley wrote:
> > Tom:
> >
> ...
> >> Substantive comments:
> >>
the
> >> the issue, since an attacker can view the SupplementalData in
transit.
> > considerations of draft-housley-tls-authz-extns-03.txt.  I'm please
to
> >> 2. The protocol requires assignment of an extension type number to
the
> >> 4. Is there any relationship between the value of
user_principal_name
> > Last Call comment.  It has already had many eyes look at it, so I
hope
> >> 5. In section 4, after the user_mapping extension has been
negotiated,
> > Last Call comment.  It has already had many eyes look at it, so I
hope
> [PTT] I'll have to take your word for it -- I see no change.
[Stefan] There has been no new wording on this and the MAY is
intentional. E.g. If the extension exchange made it clear to the client
that none of the supplemental messages it intended to send are supported
by the server, then it may not send any.

> >> 6. In section 5, Security Considerations, there are two SHOULD
bullets
> above text implies a MUST.
[Stefan] You are correct. The SHOULD is an error and this is further
complicated by the fact that both bullets are sub-requirements of a
leading SHOULD statement. The first bullet is redundant as it is covered
in the protocol text as a MUST. I have made a proposal to remove it. 

The proposal is:

OLD:
   To avoid superfluously sending this information, two techniques
   SHOULD be used to control its dissemination.

      - The client SHOULD only send the UserMappingDataList in the
        supplemental data message if it is agreed upon in the hello
        message exchange, preventing the information from being sent
        to a server that doesn't understand the User Mapping Extension.

      - The client SHOULD further only send this information if the
        server belongs to a domain to which the client intends to
        authenticate using the UPN as identifier.

NEW:
   To avoid superfluously sending this information, clients SHOULD 
   only send this information if the server belongs to a domain to
   which the client intends to authenticate using the UPN as
   identifier.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Sat, 15 Apr 2006 09:21:17 -0400

Looks good to me.