Subject: [tram] STUN Origin Open Issue: Integrity Protection

From: Alan Johnston <[email-masked]>
Date: Fri, 1 Aug 2014 10:07:19 -0500

In draft-ietf-tram-stun-origin-00, the Security Considerations says:

   The STUN MESSAGE-INTEGRITY attribute can provide integrity protection
   for all attributes present in a STUN request.  However, MESSAGE-
   INTEGRITY is not present in the initial STUN message sent, so the
   initial ORIGIN attribute will not have integrity protection and hence
   could be modified or removed from a STUN request without the server
   knowing.  Subsequent STUN requests containing the MESSAGE-INTEGRITY
   attribute will provide integrity protection for the contents of the
   ORIGIN attribute.  The strength of this protection is a function of
   the secret used to generate the MESSAGE-INTEGRITY value.

Justin has proposed changing it to:

   The STUN MESSAGE-INTEGRITY attribute can provide integrity protection
   for all attributes present in a STUN request.  However, when using
   STUN's long-term credential mechanism, as is done in TURN, MESSAGE-
   INTEGRITY is not present in the initial STUN message sent, and so the
   initial ORIGIN attribute will not have integrity protection. Hence,
   it could be modified or removed from a STUN request without the server
   knowing, which could affect the server's choice of REALM.

   With the long-term credential mechanism, subsequent STUN requests will

   contain the MESSAGE-INTEGRITY attribute and will provide integrity
protection
   for the contents of the ORIGIN attribute(s).  To mitigate any potential
concerns
   arising from the unprotected attribute in the initial message, servers
SHOULD
   verify that the ORIGIN attribute(s) present in the authenticated STUN
requests
   match those that were received in the initial, unauthenticated requests.

   The strength of the integrity protection is a function of
   the secret used to generate the MESSAGE-INTEGRITY value.

Anyone object to this clarification?  Any other suggested edits to the
Security Considerations section?

- Alan -

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 1 Aug 2014 08:42:55 -0700

I agree with the changes.

Thanks
Oleg

On Fri, Aug 1, 2014 at 8:07 AM, Alan Johnston <[email-masked]>
wrote:

> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 1 Aug 2014 15:40:44 -0700

I realized when looking at a code review for this that the stateless-stack
approach makes it difficult to enforce this as written. Instead, I think
the advice should be that the ORIGIN attributes in the authenticated
request MUST be verified to be consistent with the REALM value that is
supplied.

On Fri, Aug 1, 2014 at 8:42 AM, Oleg Moskalenko <[email-masked]> wrote:

>>    for the contents of the ORIGIN attribute(s).  To mitigate any
>> potential concerns

---

From: Alan Johnston <[email-masked]>
Date: Mon, 11 Aug 2014 11:22:25 -0500

Justin & Oleg,

Thanks for the feedback.  I will change the one requirement to a MUST:

To mitigate any potential concerns arising from the unprotected attribute
in the initial message, servers MUST verify that the ORIGIN attribute(s)
present in the authenticated STUN requests match those that were received
in the initial, unauthenticated requests.

Having running code is a good thing!

- Alan -

On Fri, Aug 1, 2014 at 5:40 PM, Justin Uberti <[email-masked]> wrote:

>>>    arising from the unprotected attribute in the initial message,
>>> servers SHOULD

---

From: Justin Uberti <[email-masked]>
Date: Mon, 11 Aug 2014 09:53:26 -0700

As mentioned I think what you describe is hard to do when using stateless
stack - see my email on Aug 1 for a suggestion on how to resolve this.

On Mon, Aug 11, 2014 at 9:22 AM, Alan Johnston <[email-masked]>
wrote:

>> I realized when looking at a code review for this that the
>> stateless-stack approach makes it difficult to enforce this as written.
>> Instead, I think the advice should be that the ORIGIN attributes in the
>> authenticated request MUST be verified to be consistent with the REALM
>> value that is supplied.
>>
>>
>>> On Fri, Aug 1, 2014 at 8:07 AM, Alan Johnston <[email-masked]
>>> > wrote:
>>>
>>>>    verify that the ORIGIN attribute(s) present in the authenticated
>>>> STUN requests

---

From: Alan Johnston <[email-masked]>
Date: Sun, 17 Aug 2014 13:42:31 -0500

Justin,

I now understand your issue.  There is no real way for a client or server
to enforce that the ORIGIN attribute be the same across requests.  The
existing text about MESSAGE-INTEGRITY isn't all that useful, either.
 Instead,  I suggest we include text saying that only DTLS or TLS transport
provides integrity protection in all cases for ORIGIN attributes.

I'll send the suggested text in another list mail.

- Alan -

On Mon, Aug 11, 2014 at 11:53 AM, Justin Uberti <[email-masked]> wrote:

>>>> On Fri, Aug 1, 2014 at 8:07 AM, Alan Johnston <
>>>> [email-masked]> wrote:
>>>>

---

From: Oleg Moskalenko <[email-masked]>
Date: Sun, 17 Aug 2014 14:20:46 -0700

Alan, that's not exactly true. Coturn 4.1.2.1 enforces the origin policy. But the problem is the reason why we enforce that. Let me read the document and i ll provide my thoughts.

Thanks
Oleg

Sent from my iPhone

> On Aug 17, 2014, at 11:42 AM, Alan Johnston <[email-masked]> wrote:
> 
> Justin,
> 
> I now understand your issue.  There is no real way for a client or server to enforce that the ORIGIN attribute be the same across requests.  The existing text about MESSAGE-INTEGRITY isn't all that useful, either.  Instead,  I suggest we include text saying that only DTLS or TLS transport provides integrity protection in all cases for ORIGIN attributes.  
> 
>> As mentioned I think what you describe is hard to do when using stateless stack - see my email on Aug 1 for a suggestion on how to resolve this.
>> 
>> 
>>> On Mon, Aug 11, 2014 at 9:22 AM, Alan Johnston <[email-masked]> wrote:
>>> Justin & Oleg,
>>> 
>>> To mitigate any potential concerns arising from the unprotected attribute in the initial message, servers MUST verify that the ORIGIN attribute(s) present in the authenticated STUN requests match those that were received in the initial, unauthenticated requests.
>>> 
>>>> I realized when looking at a code review for this that the stateless-stack approach makes it difficult to enforce this as written. Instead, I think the advice should be that the ORIGIN attributes in the authenticated request MUST be verified to be consistent with the REALM value that is supplied.
>>>> 
>>>> 
>>>>>> On Fri, Aug 1, 2014 at 8:07 AM, Alan Johnston <[email-masked]> wrote:
>>>>>>    contain the MESSAGE-INTEGRITY attribute and will provide integrity protection 
>>>>>>    for the contents of the ORIGIN attribute(s).  To mitigate any potential concerns 
>>>>>>    arising from the unprotected attribute in the initial message, servers SHOULD 
>>>>>>    verify that the ORIGIN attribute(s) present in the authenticated STUN requests
>>>>>> Anyone object to this clarification?  Any other suggested edits to the Security Considerations section?
>>>>>> 
>>>>>> - Alan -
>>>>>>

---

From: Oleg Moskalenko <[email-masked]>
Date: Sun, 17 Aug 2014 15:40:47 -0700

Alan, I checked the new edition. The message-integrity wording is accurate and it is similar to how i understand this issue. So i agree with the new edition.

Thanks!
Oleg

Sent from my iPhone

---

From: Justin Uberti <[email-masked]>
Date: Sun, 17 Aug 2014 22:48:01 -0700

I agree, this is the simplest advice.

On Sun, Aug 17, 2014 at 3:40 PM, Oleg Moskalenko <[email-masked]>
wrote:

> Alan, I checked the new edition. The message-integrity wording is accurate
> and it is similar to how i understand this issue. So i agree with the new
> edition.
>
> Thanks!
> Oleg
>
> Sent from my iPhone
>
>> On Mon, Aug 11, 2014 at 9:22 AM, Alan Johnston <[email-masked]
>> > wrote:
>>
>>> Justin & Oleg,
>>>
>>> To mitigate any potential concerns arising from the unprotected
>>> attribute in the initial message, servers MUST verify that the ORIGIN
>>> attribute(s) present in the authenticated STUN requests match those that
>>> were received in the initial, unauthenticated requests.
>>>