Subject: Secdir last call review of draft-ietf-tram-stunbis-16

From: Matthew Miller <[email-masked]>
Date: Fri, 09 Mar 2018 13:50:10 -0800

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

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

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 11 Mar 2018 06:55:13 -0700

Hi,

Thanks for the review.

Please see inline.

> 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 HTPP and SIP)?

> since the purpose appears to be for backwards compatibility with existing

Fixed.

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

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: "Matthew A. Miller" <[email-masked]>
Date: Fri, 16 Mar 2018 05:35:18 -0600

On 18/03/11 07:55, Marc Petit-Huguenin wrote:
>> 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.

> 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