On 18/03/11 07:55, Marc Petit-Huguenin wrote: > Hi, > > Thanks for the review. > > Please see inline. > > On 03/09/2018 01:50 PM, Matthew Miller wrote: >> Reviewer: Matthew Miller >> Review result: Has Issues >> >> [ I realize how unfortunate it is this arrives well past last call. >> I beg forgiveness and ask that you accept the comments as you would >> have if they arrived on time. ] >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should >> treat these comments just like any other last call comments. >> >> Document: draft-ietf-stunbis-16 >> Reviewer: Matthew A. Miller >> Review Date: 2018-03-07 >> IETF LC End Date: 2018-02-20 >> IESG Telechat date: 2018-04-05 >> >> Summary: This document obsoletes 5389, adding some protection to >> downgrade attacks against message integrity usage, as well >> incorporating DTLS (over UDP). >> >> The document is mostly ready, but there are a couple of issues I >> have. >> >> Major Issues: N/A >> >> Minor Issues: >> >> * I am wondering why a more robust password algorithm (key derivation >> function) was not defined (e.g., HKDF-SHA-256) instead of or in addition >> to, a simple salted "SHA-256" hash. Some amount of parameterization is >> accounted for in the PASSWORD-ALGORITHM/S attributes. I think it is >> perfectly fair and appropriate to take this issue as "asking for a quick >> rationale (that maybe ought to be highlighted better in the document)" >> over "use a real key derivation function". > > We proposed other algorithms to the Working Group but there was no consensus past using what we have today in the draft. >> We basically wanted to keep STUN aligned with HTTP Digest and SIP Digest as much as possible. Rereading both RFC 7616 and draft-yusef-sipcore-digest-scheme I can not find mention of using a key derivation function for these. > > Can you explain how that could be used with STUN (and potentially with HTTP and SIP)? Thank you for the extra context. The way this authentication is done looks like something that would benefit from a more robust KDF. I hesitate to add this, but these authentication schemes are quite distant from HTTP (and SIP) digest authentication. While they are using the same hash algorithm, how the inputs are processed are radically different from what STUN(bis) defines. But, my intent is not to boil this ocean. It's not clear to me this would be a worthwhile improvement by itself, and there is already a warning in the security considerations about the weaknesses of the authentication schemes. I'm willing to consider this point addressed. > >> >> * The description for 17.5.1. "MD5" list the key size as 20 bytes, but the >> hash length of MD5 is 16 bytes (128 bits). I think this is merely a typo, >> since the purpose appears to be for backwards compatibility with existing >> systems. > > Fixed. > >> >> * Both 17.5.1.1. "MD5" Section 9.2.2. "HMAC Key" (long-term credential) >> and Section appear to define the same functional algorithm, but with subtle >> syntax differences. As far as I can tell, they are actually the same >> algorithm; would it not be acceptable to have Section 9.2.2 point to >> Section 17.5.1.1 for the algorithm description? >> >> > > This is going into the IANA registry so I left things there. I fixed the discrepancy with section 9.2.2. > > I also fixed the definition of the key for SHA-256, which must use OpaqueString for the realm. > Thanks very much. - m&m Matthew A. Miller
Attachment:
signature.asc
Description: OpenPGP digital signature
