A few comments in line; Stefan Santesson Program Manager, Standards Liaison Windows Security
> -----Original Message----- > From: Tom-PT Taylor [mailto:[EMAIL PROTECTED] > Sent: den 13 april 2006 20:25 > To: Russ Housley > Cc: Stefan Santesson; Ari Medvinsky; Joshua Ball; gen-art@ietf.org > 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 Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art