Subject: [tram] draft-ietf-tram-stunbis-02

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 25 Mar 2015 20:37:47 -0500

Hi,

I was reading section 9.2 Long-Term Credential Mechanism of the
draft-ietf-tram-stunbis-02 document, and I came a cross the following
statement:

  "Note that the long-term credential mechanism cannot be used to
   protect indications, since indications cannot be challenged.  Usages
   utilizing indications must either use a short-term credential or omit
   authentication and message integrity for them."

I am not sure that I understand the reason for this statement.

After the client is able to authenticate to the server and get the realm,
nonce, and maybe the salt from the server, the client should be able to
create the key that will be used with the HMAC function.

At this stage either side should be able to create an HMAC for any request,
including Indication. In the case that the receiving side failed to
validate the HMAC for an Indication it should just drop it on the floor.

Regards,
 Rifaat

---

From: Justin Uberti <[email-masked]>
Date: Wed, 25 Mar 2015 22:43:30 -0500

True, but that nonce may have expired by the time the indication is sent.

On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef <[email-masked]>
wrote:

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

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 25 Mar 2015 21:57:37 -0700

Another reason is that indications can be used for high-volume traffic
(like data traffic) and we may not want to associate extra CPU load
with each indication packet.

The indications are usually used either over secure channel (TLS or
DTLS) or contain secured payload (like SRTP).

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 26 Mar 2015 06:47:33 -0500

Why is the nonce needed in this case? you cannot challenge the request
anyway.
Maybe a client nonce is needed here instead?

Regards,
 Rifaat

On Wed, Mar 25, 2015 at 10:43 PM, Justin Uberti <[email-masked]> wrote:

> On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef <[email-masked]
> > wrote:
>
>> Hi,
>>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 26 Mar 2015 06:59:06 -0500

Inline...

> with each indication packet.
If you want a secure solution you better be ready to pay the cost for that.
Did you quantify that "extra CPU load"?.

> DTLS) or contain secured payload (like SRTP).
I thought that the draft was talking about using STUN over non-secured
channels too; right?
Securing the payload would not protect you against replay attacks.

Regards,
 Rifaat

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 26 Mar 2015 12:16:25 +0000

SRTP can handle replay attacks. Active attacker can consume the indication message so integrity protection is of no help; Passive attacker sniffing packets on the wire can replay the indications with or without message integrity and remote peer will discard SRTP packets with old sequence number.

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, March 26, 2015 5:29 PM
To: Oleg Moskalenko
Cc: [email-masked]; Justin Uberti
Subject: Re: [tram] draft-ietf-tram-stunbis-02

Inline...

On Wed, Mar 25, 2015 at 11:57 PM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:
Another reason is that indications can be used for high-volume traffic
(like data traffic) and we may not want to associate extra CPU load
with each indication packet.

I thought that the draft was talking about using STUN over non-secured channels too; right?
Securing the payload would not protect you against replay attacks.

Regards,
 Rifaat

On Wed, Mar 25, 2015 at 8:43 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
> On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>
> wrote:
>>
>> Hi,
>>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 26 Mar 2015 08:00:36 -0500

I have not read the whole document, so I do not know how indication is
being used.
All I am trying to say is that the current statement in the document is not
accurate, as there is a way to protect the integrity of the indication. The
text should be either removed or clearly state that indication protection
is not needed and explain why it is not needed.

Regards,
 Rifaat

On Thu, Mar 26, 2015 at 7:16 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

>  SRTP can handle replay attacks. Active attacker can consume the
> indication message so integrity protection is of no help; Passive attacker
> sniffing packets on the wire can replay the indications with or without
> message integrity and remote peer will discard SRTP packets with old
> sequence number.
>
>
>
> -Tiru
>
>
>
> *From:* tram [mailto:[email-masked]] *On Behalf Of *Rifaat
> Shekh-Yusef
> *Sent:* Thursday, March 26, 2015 5:29 PM
> *To:* Oleg Moskalenko
> *Cc:* [email-masked]; Justin Uberti
> *Subject:* Re: [tram] draft-ietf-tram-stunbis-02
>
>
>
> Inline...
>
>
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 26 Mar 2015 08:25:06 -0500

> is not needed and explain why it is not needed.

What we can do is change the text by saying that authentication of indication is possible, but if the NONCE expires then indication MUST be dropped.  This way the client or server makes a conscious decision of getting a chance of having the packets dropped without knowing why (the client should in this case periodically send a dummy transaction just for the purpose of giving a chance to the server to renew the NONCE).

But note that when moving up the stack to the TURN layer, indications are just a poor man's TURN channel, TURN channels that again are not authenticated, and do not even have a simple way to be authenticated.

>>>> validate the HMAC for an Indication it should just drop it on the floor.

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

---

From: Brandon Williams <[email-masked]>
Date: Thu, 26 Mar 2015 11:17:44 -0400

I don't think the possible but improbable use of MI for indications 
deserves too much text. I suggest the following. My edits are in brackets.

---
Note that the long-term credential mechanism [SHOULD NOT] be used to 
protect indications, since indications cannot be challenged [to notify 
the client of authentication errors (e.g. expired NONCE)]. Usages 
utilizing indications [SHOULD] use a short-term credential or omit 
authentication and message integrity for them.
---

I would be supportive of using MUST here instead of SHOULD, and I would 
also support removal or modification of this proposed description of why 
lack of challenge is a problem.

--Brandon

On 03/26/2015 09:25 AM, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJVFAiyAAoJECnERZXWan7EQOwQAMlkSxcvLjOzyZQRCD4jOrTe
> y3qTmC0O/JV4wKrzDw0FFEigXKutNg9e1v0AlVI0g71c+MV6y7QN3zkM+Y4HGKSP
> +tz+E5DwE5lwiE4r57mlM780iRV0Y/cEbYKJPSQvzpcDpq8MnB3iE/6JE4WBZ6Q6
> DtoYLvTNnhj5Mf31Ervv43XAJJrv9XfrQvtvRYA0jpv4LMtpOKHFoUy5Ez7Z1yCu
> E1YF0kEL1sWDk+CqU/PJkiPxt4xx7U/JoqIwvJ7Xk5Jiw4vCVeYVaZTLm2uEeFO6
> 6fFEnby2zmYb1+5xHSCA/iopRzBr9f6Ze3XrGbnIrnFUi12ZSBGPD49GiitLemr0
> +4aPkSnQeyprRUcdtXccqTPrvekMxwuN7slMktHTJsvDuWjPU2FXJ5mDGF1qk8q4
> bDp22mcveAjFWvDTFp6djY41t61kJCOX3Otxnk17BavGfuFSMkEZrNbc66ezVWQ1
> BQHQ4sRZ8WDsVTCxAfo1uVGtO5dOq0hfe0lcApyitX7BSy+dnXncdRLI3Ts0RvJy
> xV14we3zZl9tzqSNH+8gNxTPQ3TWF4uJslALRrgrqDT0ZN2lfWur1ncFzDwcw/iy
> qdbMqemudVrKbFoU6epPrJ7VCY2fPxLcAT9YCZqyA1vP4bPHonGDb1Jf2xGLLf/T
> aNrDXOb5ChWgkRDWwem4
> =C/nZ
> -----END PGP SIGNATURE-----
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 26 Mar 2015 11:33:14 -0500

It's hard for me to imagine a scenario where MI for indications makes
sense. With no challenge, you have to accept that at some point, the remote
side could start silently eating the indications, which seems like a
particularly bad failure mode.

That said, your proposed SHOULDs seem like a good way to handle this.

On Thu, Mar 26, 2015 at 10:17 AM, Brandon Williams <
[email-masked]> wrote:

> protect indications, since indications cannot be challenged [to notify the
> client of authentication errors (e.g. expired NONCE)]. Usages utilizing
> indications [SHOULD] use a short-term credential or omit authentication and
> message integrity for them.
> ---
>
>> What we can do is change the text by saying that authentication of
>> indication is possible, but if the NONCE expires then indication MUST be
>> dropped.  This way the client or server makes a conscious decision of
>> getting a chance of having the packets dropped without knowing why (the
>> client should in this case periodically send a dummy transaction just for
>> the purpose of giving a chance to the server to renew the NONCE).
>>
>> But note that when moving up the stack to the TURN layer, indications are
>> just a poor man's TURN channel, TURN channels that again are not
>> authenticated, and do not even have a simple way to be authenticated.
>>
>>
>>> Regards,
>>>   Rifaat
>>>
>>>
>>>>> On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef <
>>>>>
>>>> [email-masked]>
>>>>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> After the client is able to authenticate to the server and get the
>>>>>>
>>>>> realm,
>>>>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 26 Mar 2015 16:36:14 +0000

I don’t think any attack is prevented by including MI for indications.

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Thursday, March 26, 2015 10:03 PM
To: Brandon Williams
Cc: [email-masked]
Subject: Re: [tram] draft-ietf-tram-stunbis-02

It's hard for me to imagine a scenario where MI for indications makes sense. With no challenge, you have to accept that at some point, the remote side could start silently eating the indications, which seems like a particularly bad failure mode.

On Thu, Mar 26, 2015 at 10:17 AM, Brandon Williams <[email-masked]<mailto:[email-masked]>> wrote:
I don't think the possible but improbable use of MI for indications deserves too much text. I suggest the following. My edits are in brackets.

---
Note that the long-term credential mechanism [SHOULD NOT] be used to protect indications, since indications cannot be challenged [to notify the client of authentication errors (e.g. expired NONCE)]. Usages utilizing indications [SHOULD] use a short-term credential or omit authentication and message integrity for them.
---

I would be supportive of using MUST here instead of SHOULD, and I would also support removal or modification of this proposed description of why lack of challenge is a problem.

--Brandon

Regards,
  Rifaat

[email-masked]<mailto:[email-masked]>> wrote:

-Tiru

*From:* tram [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of *Rifaat
Shekh-Yusef
*Sent:* Thursday, March 26, 2015 5:29 PM
*To:* Oleg Moskalenko
*Cc:* [email-masked]<mailto:[email-masked]>; Justin Uberti
*Subject:* Re: [tram] draft-ietf-tram-stunbis-02

Inline...

On Wed, Mar 25, 2015 at 11:57 PM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>>
wrote:

Regards,

  Rifaat

On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef <
[email-masked]<mailto:[email-masked]>>
wrote:

Hi,

At this stage either side should be able to create an HMAC for any
request,
including Indication. In the case that the receiving side failed to
validate the HMAC for an Indication it should just drop it on the floor.

Regards,
  Rifaat

- --
Marc Petit-Huguenin
Email: [email-masked]<mailto:[email-masked]>