Subject: [tram] Comments on draft-ietf-tram-stunbis-04

From: Jonathan Lennox <[email-masked]>
Date: Mon, 20 Jul 2015 23:11:29 +0000

Inspired by the pleas in the TRAM working group today, I decided read over draft-ietf-tram-stunbis-04.

(Note that I’ve only reviewed the diff from RFC 5389, not re-reading the document from scratch, so this only catches new problems, not old problems.)

Section 8.1: "The DNS SRV service name is the content of the <host> part.”
This is wrong — the DNS SRV service name is “stun” or “stuns”.  This seems to have gotten mangled in the conversion to describing the resolution process in terms of the URL.

Section 9.1.3:

“If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the	
value for the message integrity as described in Section 14.5,	
using the password associated with the username. If the MESSAGE-	
INTEGRITY-SHA256 attribute is not present, and using the same	
password, compute the value for the message integrity as described	
in Section 14.4. If the resulting value does not match the	
contents of the MESSAGE-INTEGRITY-SHA256 attribute or the MESSAGE-	
INTEGRITY attribute:”

Is this saying that a SHA-1 message integrity value (described in Section 14.4) can be carried in a MESSAGE-INTEGRITY-SHA256 attribute?  That doesn’t seem right.

Section 9.1.4:

“The client looks for the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-	
INTEGRITY attribute in the response. If present, the client computes	
the message integrity over the response as defined in Section 14.4 or	
Section 14.5, using the same password it utilized for the request.	
If the resulting value matches the contents of the MESSAGE-INTEGRITY	
or MESSAGE-INTEGRITY-SHA256 attribute, the response is considered	
authenticated. If the value does not match, or if both MESSAGE-	
INTEGRITY and MESSAGE-INTEGRITY-SHA256 were absent, the response MUST	
be discarded, as if it was never received. This means that	
retransmits, if applicable, will continue.”

Parallelism failure. Sometimes MESSAGE-INTEGRITY is listed first, and sometimes MESSAGE-INTEGRITY-SHA256.  If read literally it would seem to imply you were swapping the values.  The two algorithms should be consistently listed in order, and it should be made clear that they apply respectively.

Additionally, it should say that if the client only sent one algorithm in the request (because of the external indication in section 9.1.2, or this being a subsequent request as defined in 9.1.5) the algorithm in the response has to match.

Section 9.1.5:

“A client sending subsequent requests to the same server a MAY choose	
to send only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY	
attribute depending upon the attribute that was received in the	
response to the initial request.”

This should probably be required to be the literal same server —i.e., the same IP and port — not just the same URL or SRV lookup.

Section 9.2.3:

There seems to be a random github URL pasted into the document.

“If the NONCE attribute starts with the value "obMatJos2" but the	
PASSWORD-ALGORITHMS attribute is not present or is not identical	
to the PASSWORD-ALGORITHMS attribute sent in the response, the	
server MUST generate an error response with an error code of 400	
(Bad Request). This response SHOULD NOT include a USERNAME,	
NONCE, REALM, MESSAGE-INTEGRITY, or MESSAGE-INTEGRITY-SHA256	
attribute.”

Doesn’t this break backward compatibility with RFC 5389 (i.e., MD5-algorithm-only) clients?  It’s a server’s choice whether to support MD5 as a password algorithm, but presumably if it does it’s doing so for a reason (i.e. an old password database or supporting old clients).

I think this should say that if PASSWORD-ALGORITHMS doesn’t match, the request is dropped; but if the request contains neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM, the request is processed as though PASSWORD-ALGORITHM were MD5.  (And MD5 should be added to PASSWORD-ALGORITHMS, see below.)  Depending on the list in PASSWORD-ALGORITHMS, this may either be supported, or trigger a 400.

It’s a 400 if only one of PASSWORD-ALGORITHM or PASSWORD-ALGORITHMS is present, or if PASSWORD-ALGORITHM doesn’t match one of the entries in PASSWORD-ALGORITHMS.

Meanwhile, to prevent bid-down, the *client* requirements should say that if the nonce begins with obMatJos2 but PASSWORD-ALGORITHMS is not present, the response should be ignored.

“If these checks pass, the server continues to process the request.	
Any response generated by the server (excepting the cases described	
above) MUST include both the MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-	
SHA256 attributes, computed using the username and password utilized	
to authenticate the request.”

Why do you want both?  For short-term you only send MESSAGE-INTEGRITY-SHA256 if the client supported it.

Section 9.2.4:

“If the response is an error response with an error code of 401	
(Unauthorized), the client SHOULD retry the request with a new	
transaction. This request MUST contain a USERNAME, determined by the	
client as the appropriate username for the REALM from the error	
response. The request MUST contain the REALM, copied from the error	
response. The request MUST contain the NONCE, copied from the error	
response. If the response contains a PASSWORD-ALGORITHMS attribute,	
the request MUST contain the PASSWORD-ALGORITHMS attribute with the	
same content. If the response contains a PASSWORD-ALGORITHMS	
attribute, and this attribute contains at least one algorithm that is	
supported by the client then the request MUST contain a PASSWORD-	
ALGORITHM attribute with the first algorithm supported on the list.”

This text seems to imply that if the PASSWORD-ALGORITHMS list contains only algorithms the client doesn’t recognize, the client goes ahead and uses MD5. Does this make sense? I think the client should give up if it doesn’t support any of the algorithms. 

"if the response contains a MESSAGE-INTEGRITY-SHA256 attribute then	
the request MUST contain a MESSAGE-INTEGRITY-SHA256 attribute,	
computed using the password associated with the username in the	
USERNAME attribute. Else the request MUST contain the MESSAGE-	
INTEGRITY attribute, computed using the password associated with the	
username in the USERNAME attribute. The client MUST NOT perform this	
retry if it is not changing the USERNAME or REALM or its associated	
password, from the previous attempt.”

We’re still talking about the 401 Unauthorized here, right? The text says the response SHOULD NOT contain MESSAGE-INTEGRITY-SHA256, since there’s no way to know the username to use.

That said, it seems to me to be reasonable to say that if the response contains PASSWORD-ALGORITHMS, the followup request should be authenticated using MESSAGE-INTEGRITY-SHA256 only, since we know that both the client and server are stunbis.

Section 14.10:

“The PASSWORD-ALGORITHMS attribute is present only in responses.”

Not true, it’s in followup requests, as mentioned, to prevent bid-down.

Section 17.4:

Salted SHA-256 is still listed in the password algorithms table, despite being otherwise deleted from the document.

Should we define MD5 as a PASSWORD-ALGORITHM value? The use case is a server that wants to upgrade to stunbis, but wants to keep using its existing (md5-hashed) password database without forcing users to re-enter their password.  (This would mean a case where long-term authentication uses the MD5 password algorithm, but MESSAGE-INTEGRITY-SHA256 integrity.)

Section 17.5:

Should register the stuns over UDP port.

A general question about the PASSWORD-ALGORITHM transition process: do we want to support the use case where a server is gradually transitioning its existing database to have SHA-256 as the password hash algorithm (as users change passwords)?  This might result in a case where some users have MD5-hashed passwords in the database, and some have SHA-256 — but the server doesn’t yet know when responding to the initial request which user is making the request, and thus which password algorithms are actually supported for this specific user.  Supporting this would require either putting USERNAME in the initial request (which seems bad in the absence of a known realm), or else allowing a server to respond to a followup request with another 401 Unauthorized response, with a shorter PASSWORD-ALGORITHMS list (resulting in long-term authentication requiring three transactions for stunbis clients whose users who are still on MD5).  Despite the triple transaction, I’m inclined to recommend the latter.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 21 Jul 2015 05:12:33 +0200

> Inspired by the pleas in the TRAM working group today, I decided read over draft-ietf-tram-stunbis-04.

Thanks for the review, it is much appreciated.  I will work diligently on this as soon I am back from Europe. 

> A general question about the PASSWORD-ALGORITHM transition process: do we want to support the use case where a server is gradually transitioning its existing database to have SHA-256 as the password hash algorithm (as users change passwords)?  This might result in a case where some users have MD5-hashed passwords in the database, and some have SHA-256 — but the server doesn’t yet know when responding to the initial request which user is making the request, and thus which password algorithms are actually supported for this specific user.  Supporting this would require either putting USERNAME in the initial request (which seems bad in the absence of a known realm), or else allowing a server to respond to a followup request with another 401 Unauthorized response, with a shorter PASSWORD-ALGORITHMS list (resulting in long-term authentication requiring three transactions for stunbis clients whose users who are still on MD5).  Despite the triple transaction, I’m inclined to
  recommen
d the latter.
> 
> 
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
> 

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