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

["Stefan Santesson" <[e-mail]>]

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