Subject: [BEHAVE] MESSAGE-INTEGRITY in STUN error responses

From: Benny Prijono <[email-masked]>
Date: Wed, 23 May 2007 06:02:52 +0100

All,

Apologies if this has been discussed, but I have some doubts
regarding the processing of STUN error responses which requests had
included MESSAGE-INTEGRITY attribute.

Few doubts:

  - In 8.3.2.  Processing Responses, it says

      "All responses that were not discarded, whether success
       responses or error responses, MUST first be authenticated
       by the client."

    I'm assuming that this means STUN response (success or error)
    with missing or incorrect M-I will be discarded before it
    reaches client transaction FSM.

    And if so, I'm assuming that client would continue retransmitting
    the request, as if it had not receive any response.

  - If the above are true, then I think there need to be some
    exception for some error responses which by definition cannot
    contain M-I, so they cannot be authenticated.

    Reading Section 9.1.1. "Receive Request Message", I reckon these
    error responses cannot contain M-I thus client should not
    authenticate them:

      401 (Unauthorized)
      432 (Missing Username)
      434 (Missing Realm)
      436 (Unknown Username)
      431 (Integrity Check Failure)

   And probably 420 (Unknown Attribute), and few others (I can look
   for them, but for now I just want to be sure that what I'm
   saying makes sense at all).

Comments?

cheers,
  -benny

-- 
Benny Prijono
http://www.pjsip.org

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 23 May 2007 10:21:15 +0300

>     error responses cannot contain M-I thus client should not

The client will only receive a legitimate 401 if it did not authenticate in 
the first place, so it will not expect a M-I in the response either.

>       432 (Missing Username)

A conforming client will never emit authenticated messages without a USERNAME, 
so...

>       431 (Integrity Check Failure)

These are the real issues. In practice, either you drop the errors, or you 
rely on the transaction ID. While the latter is vulnerable to a MITM attack, 
that's a not really a concern since an active MITM can pretty much always DoS 
the service anyway. However, this relies on really non-predictable 
transaction IDs.

>    saying makes sense at all).

There should normally be no problem authenticating a 420, unless a new 
attribute that does influence M-I in a non-backward compatible manner is 
defined. I surely hope we will not do that, and in any case, it should not be 
an issue for clients implementing the current drafts.

-- 
Rémi Denis-Courmont

---

From: Benny Prijono <[email-masked]>
Date: Wed, 23 May 2007 10:14:10 +0100

> the first place, so it will not expect a M-I in the response either.

You're right.

> A conforming client will never emit authenticated messages without a USERNAME, 

But the error code is there anyway, so...

> the service anyway. However, this relies on really non-predictable 

I'm in favor of accepting these error responses even if they don't 
have M-I. If we drop these error responses when they don't have M-I 
(and they can't have M-I), this kind of defeat the purpose of the 
error codes, since they can never reach transaction FSM.

> an issue for clients implementing the current drafts.

I don't mind with authenticating 420.

What about 400 (Bad Request)? This error can be generated in the 
parser because of malformed request, so the server may not be able 
to generate M-I.

cheers,
  -benny

-- 
Benny Prijono
http://www.pjsip.org

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 23 May 2007 09:16:35 -0700

Hi.  This did come up during rfc3489bis's working group last call, and
Philip, Jonathan, and I took a shot at clarifying which error codes could
have Message-Integrity.  Here is the current work-in-progress text for that
section.  

   Except where noted, if the request included the USERNAME attribute
   and was protected with a valid MESSAGE-INTEGRITY attribute, the error
   response MUST also be protected with its own MESSAGE-INTEGRITY
   attribute.  The following response codes, along with their
   recommended reason phrases (in brackets) are defined:

   300  Try Alternate: The client should contact an alternate server for
        this request.  This error response MUST only be sent if the
        request included a USERNAME attribute and a valid MESSAGE-
        INTEGRITY attribute; otherwise it MUST NOT be sent and error
        code 400 is suggested.  This error response MUST be protected
        with the MESSAGE-INTEGRITY attribute, and receivers MUST
        validate the MESSAGE-INTEGRITY of this response before
        redirecting themselves to an alternate server.

             Note: failure to generate and validate message-integrity
             for a 300 response allows an on-path attacker to falsify a
             300 response thus causing subsequent STUN messages to be
             sent to a victim.

   400  Bad Request: The request was malformed.  The client SHOULD NOT
        retry the request without modification from the previous
        attempt.

   401  Unauthorized: The request did not contain the expected MESSAGE-
        INTEGRITY attribute.  The server MAY include the MESSAGE-
        INTEGRITY attribute in its error response.

   420  Unknown Attribute: The server received STUN packet containing a
        mandatory attribute which it did not understand.  The server
        MUST put this unknown attribute in the UNKNOWN-ATTRIBUTE
        attribute of its error response.

   430  Stale Credentials: The request did contain a MESSAGE-INTEGRITY
        attribute, but it used a shared secret that has expired.  The
        client should obtain a new shared secret and try again.  The
        server MAY include the MESSAGE-INTEGRITY attribute in its error
        response.

   431  Integrity Check Failure: The request contained a MESSAGE-
        INTEGRITY attribute, but the HMAC failed verification.  This
        could be a sign of a potential attack, or client implementation
        error.  The server MAY include the MESSAGE-INTEGRITY attribute
        in its error response.

   432  undefined

             The previous version of this specification defined this
             value, but its use has been deprecated.

   433  Use TLS: The server received a shared secret request over an
        unencrypted channel, and it needs to be re-sent over TLS.

   434  Missing Realm: The server expected a REALM attribute in the
        request, but none was present. [[dwing: need to consider if we
        keep this one.]]

   435  Missing Nonce: The server expected a NONCE attribute in the
        request, but none was present.  This error response is used in
        conjunction with the NONCE attribute to cause the client to send
        the NONCE value in a subsequent request.

             This error code and the NONCE procedure apply to only some
             STUN usages.

   436  Unknown Username: The USERNAME supplied in the request is not
        known or is not known to the server.  With this error code, the
        server cannot compute the MESSAGE-INTEGRITY, and thus SHOULD NOT
        include the MESSAGE-INTEGRITY attribute in the response.

   438  Stale Nonce: The NONCE attribute was present in the request but
        wasn't valid.

   500  Server Error: The server has suffered a temporary error.  The
        client should try again.

   600  Global Failure: The server is refusing to fulfill the request.
        The client should not retry.

Comments welcome.  I had one question on your post, where you suggested that
error code 420 (unknown attribute) didn't need Message-Integrity.  I think
it should.

-d

> -----Original Message-----
> From: Benny Prijono [mailto:[email-masked]] 
> Sent: Tuesday, May 22, 2007 10:03 PM
> To: [email-masked]
> Subject: [BEHAVE] MESSAGE-INTEGRITY in STUN error responses
> 
> 
> All,
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 23 May 2007 09:20:53 -0700

> From: Rémi Denis-Courmont [mailto:[email-masked]] 
> Sent: Wednesday, May 23, 2007 12:21 AM
> To: [email-masked]
> Subject: Re: [BEHAVE] MESSAGE-INTEGRITY in STUN error responses
> 
> A conforming client will never emit authenticated messages 
> without a USERNAME, so...

Yeah, that's why we're deprecating that error in -07.  

> These are the real issues. In practice, either you drop the 
> errors, or you rely on the transaction ID. While the latter is 
> vulnerable to a MITM attack, that's a not really a concern since an 
> active MITM can pretty much always DoS the service anyway.  However, 
> this relies on really non-predictable transaction IDs.

Transaction IDs are required to be random and evenly distributed, which
should protect against that.  Fortunately, a STUN client implementation that
screws up its transaction ID generation only makes itself vulnerable to such
attacks.

> There should normally be no problem authenticating a 420, 

Agreed.

> unless a new attribute that does influence M-I in a non-backward 
> compatible manner is defined.  I surely hope we will not do that, and 
> in any case, it should not be an issue for clients implementing the 
> current drafts.

Yeah, that would be a problem.

Recall that in Prague we decided we needed to support new hashes for
Message-Integrity, but over the last week I have come up with some 
concerns with our initial plan to simply define new attributes that
were fancier/faster/newer hashes.  I'll get a message to the list on
that concern shortly.

-d

---

From: Benny Prijono <[email-masked]>
Date: Wed, 23 May 2007 18:29:10 +0100

> have Message-Integrity.  Here is the current work-in-progress text for that

This is exactly what I was looking for, thanks.

>         retry the request without modification from the previous

Shouldn't we make M-I inclusion a MAY here? The parser may find
error before reaching USERNAME attribute, so in this case the server
won't be able to generate M-I.

> error code 420 (unknown attribute) didn't need Message-Integrity.  I think

I don't mind that.

It's just that 420 is normally found out during parsing process, so
it might be easier if the server just respond with 420 there,
without having to pass the response to authentication layer. But
I suppose this is not a big deal.

  -benny

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 23 May 2007 10:43:19 -0700

...
> won't be able to generate M-I.

Agreed.  Here is the revised text (with lowercased MAY NOT):

   400  Bad Request: The request was malformed.  The client SHOULD NOT
        retry the request without modification from the previous
        attempt.  The server may not be able to generate a valid
        MESSAGE-INTEGRITY for this error, so the client MUST NOT expect
        a valid MESSAGE-INTEGRITY attribute on this response.

> > error code 420 (unknown attribute) didn't need 
> > Message-Integrity.  I think it should.
> 
> I don't mind that.
> 

I agree that's when it would normally be found, but by making this
decision (to have 420 include Message-Integrity), we are requiring
the server to validate the Message-Integrity of the request.  Is
that alright.  I expect it is, but it will incur additional 
processing on the server because it now has to first validate
the Message-Integrity attribute and then walk through all of the
mandatory attributes to see if there is one it didn't understand.

-d