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

["Tom-PT Taylor" <[e-mail]>]

Looks good to me.

Stefan Santesson wrote:
> A few comments in line;
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> 
>> -----Original Message-----
>> From: Tom-PT Taylor [mailto:[e-mail]]
>> Sent: den 13 april 2006 20:25
>> To: Russ Housley
>> Cc: Stefan Santesson; Ari Medvinsky; Joshua Ball; [e-mail]
>> Subject: Re: Gen-ART review of draft-santesson-tls-ume-04.txt
>>
>> Inline.
>>
>> Russ Housley wrote:
>>> Tom:
>>>
>> ...
>>>> 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.
>>> 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.
>>>
>> [PTT] Perhaps the second sentence of section 1.2 could be modified to
>> refer to the double handshake solution?
>>
>>>> 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.
>>>
>> [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.
>>
>>>> 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.
>> [PTT] OK
>>>> 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.
>>>
>> [PTT] OK, I found it -- not quite where I expected, but it works.
>>
>>>> 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,
>>>
>> [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
>>>> 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.
>> [PTT] Looks good.
>>>> 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?
>>> 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.
>>
> [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.
> 
> 
> 
> 
>>> Russ
>>>
>>>
>>>
> 
> 
> 


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