Subject: [BEHAVE] rfc3489bis-08 last minute comment: 401 still problematic

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 14 Aug 2007 14:46:09 +0300

Hello,

It was recently agreed that incorrect usernames and incorrect message 
integrity hashes would be treated identically by STUN servers, which is to 
say, yield a 401 error. The idea is that an attacker cannot probe for valid 
usernames separately from the shared secret.

However, at the moment, this is still possible because stale nonce 
verification is done AFTER username validation, but BEFORE message integrity 
validation. IMHO, it should be done after both, otherwise a bad username 
yields 401, but a bad message integrity along with a bad nonce yields 438.

Therefore, I would suggest replacing that (§10.2.2)
"
   o  If the NONCE is no longer valid, the server MUST generate an error
      response with an error code of 438 (Stale Nonce).  This response
      MUST include a NONCE and REALM attribute.

   o  Using the password associated with the username in the USERNAME
      attribute, 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 attribute, the server MUST
      reject the request with an error response.  This response MUST use
      an error code of 401 (Unauthorized).  It MUST include a REALM and
      NONCE attribute.
"
with this:
"
   o  Using the password associated with the username in the USERNAME
      attribute, 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 attribute, the server MUST
      reject the request with an error response.  This response MUST use
      an error code of 401 (Unauthorized).  It MUST include a REALM and
      NONCE attribute.

   o  Otherwise, if the NONCE is no longer valid, the server MUST
      generate an error response with an error code of 438 (Stale Nonce).
      This response MUST include a NONCE and REALM attribute.
"

Best regards,

-- 
Rémi Denis-Courmont

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Aug 2007 09:00:18 -0400

Well, this is a dual-edged sword.

Though you are correct, that such a change would stop a user from being 
able to probe for usernames separately from passwords, it does allow an 
attacker to cause the server to compute message integrity for any 
request, as long as the attacker knows a valid username. With the 
current ordering, they need to know the current username and have a 
valid nonce. Having a valid nonce helps eliminate the impact of DDOS 
attacks. With your change, if an attacker can guess a username, they can 
have a botnet army each send requests with valid usernames and invalid 
nonces and MI, and cause the server to do lots of hashing without return 
routability.

I think the current text is the lesser of two evils in this.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 14 Aug 2007 16:05:19 +0300

> nonces and MI, and cause the server to do lots of hashing without return

True. Then perhaps NONCE should be checked before both USERNAME and M-I. It 
cannot depend on the username anyway (since the server must return a valid 
NONCE to an unauthenticated request).

No?

-- 
Rémi Denis-Courmont

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Aug 2007 09:44:31 -0400

OK, here is the text now:

<section title="Receiving a Request">

<t>
   After the server has done the basic processing of a request, it
   performs the checks listed below in the order specified:
</t>

<list style="symbols">
   <t>If the message does not contain a MESSAGE-INTEGRITY attribute,
     the server MUST
     generate an error response with an error code of
     401 (Unauthorized). This response MUST include a REALM value. It is
     RECOMMENDED that the REALM value be the domain name of
     the provider of the STUN server. The response MUST
     include a NONCE, selected by the server.
   </t>

   <t>
     If the message contains a MESSAGE-INTEGRITY
     attribute, but is missing the USERNAME, REALM or
     NONCE attributes, the server MUST generate an error
     response with an error code of 400 (Bad Request).
   </t>

   <t>
     If the NONCE is no longer valid, the server MUST
     generate an error response with an error code of 438
     (Stale Nonce). This response MUST include a NONCE and REALM
     attribute.
   </t>

   <t>
     If the username in the USERNAME attribute is not valid, the server
     MUST generate an error response with an error code of
     401 (Unauthorized). This response MUST include a REALM value. It is
     RECOMMENDED that the REALM value be the domain name of
     the provider of the STUN server. The response MUST
     include a NONCE, selected by the server.
   </t>

   <t>Using the password associated with the username in
     the USERNAME attribute,
     compute the value for the message-integrity as
     described in
     <xref target="message_integrity"/>. If the
     resulting value does not match the contents of the
     MESSAGE-INTEGRITY attribute, the server MUST
     reject the request with an error response. This
     response MUST use an error code of 401 (Unauthorized). It MUST 
include a REALM
     and NONCE attribute.
   </t>
</list>

<t>If these checks pass, the server continues to process the
   request or indication. Any response generated by the server
   MUST include the MESSAGE-INTEGRITY attribute, computed
   using the username and password utilized to authenticate
   the request. The REALM, NONCE, and USERNAME attributes SHOULD NOT
   be included. </t>

</section>

That work?

-Jonathan R.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 14 Aug 2007 16:45:52 +0300

> That work?

Looks good, thanks.

-- 
Rémi Denis-Courmont

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 14 Aug 2007 12:49:54 -0700

>   request or indication. Any response generated by the server

Per 10.2, the long-term credential mechanism cannot be used to protect
indications.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Aug 2007 12:12:41 -0400

Fixed, thanks.

-Jonathan R.