Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 15 Sep 2014 08:29:15 +0000

Offline, Dan and we were discussing the following attack possible with the current token format:

Known-plain text attack: Client knows all the fields in the encrypted_token (tries various values for timestamp which would be within fixed range - the time the client requested and received the token from Authorization server). The client has to just try various keys with the plain-text and derive the long-term key. One possible way to solve the problem is to add a variable length nonce in the encrypted block. The other recommendation that should be added to the security considerations section is that the AS and RS should periodically change the long-term key or use mechanisms like http://tools.ietf.org/html/rfc4226 to keep changing the negotiated long-term key whenever a new token is generated.
Any other attacks that should to be considered ?

-Tiru

From: Oleg Moskalenko [mailto:[email-masked]]
Sent: Sunday, September 14, 2014 11:51 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; [email-masked]
Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03

Hi Tiru
thanks for the explanation. I understand the reasoning.

Regards,
Oleg

On Sun, Sep 14, 2014 at 9:43 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Oleg,

IV was not added to the token because the Authorization server for every new token produced does not generate identical data.

-Tiru

From: tram [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Oleg Moskalenko
Sent: Saturday, September 13, 2014 1:34 PM
To: Simon Perreault
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03

While reading the token encryption / decryption process description, I failed to figure out how we handle the initialization vector (IV) of the symmetric encryption algorithm (like AES_256_CBC). If we do not know what was the IV used when we were encrypting the token, then we cannot decrypt it. I see no provision for the IV in the token structure.
We have three options:
1) Authorization server and TURN server are agreeing upon a static IV, out-of-band. A bad unsecure option.
2) The IV is always all zeros. Even a worse option than the first one.
3) Each encrypted message carries its own random IV.
The third option is the most secure, recommended option.
I would rewrote the token structure as:
struct {
  uint16_t iv_length;
  opaque iv[iv_length];
  opaque {
    uint16_t key_length;
    opaque mac_key[key_length];
    uint64_t timestamp;
    uint32_t lifetime;
  } encrypted_block;
  opaque mac[mac_length];
} token;
Thanks
Oleg

On Wed, Sep 10, 2014 at 5:18 AM, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:
TRAMsters,

This email initiates a two-week working-group last call on this draft:

http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-03

Please read it now. Substantial comments should be addressed to the group. Nits should be sent directly to the authors.

Thanks,
Simon & Gonzalo

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

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 15 Sep 2014 01:54:40 -0700

I am not sure that a variable-length nonce would solve that attack problem.

First, the "variable length" does not do much good - because the usual AES
algorithms preserve the length and knowing the plaintext length, the client
can deduce the nonce length (because the ciphertext length is either the
same length as the plaintext length, or 16 bytes more for AEAD).

Second, even with unknown nonce, knowing the exact nonce field positions,
the client still can try the same attack - the client will just ignore the
nonce positions, and the client will obtain the same attack result as
without the nonce (with very high degree of probability). If the client
finds a key that decrypts properly all positions except the nonce, then the
client can be almost sure that he found the real long-term key.

I see no easy way to counter that attack.

Oleg

On Mon, Sep 15, 2014 at 1:29 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> Known-plain text attack: Client knows all the fields in the
> encrypted_token (tries various values for timestamp which would be within
> fixed range - the time the client requested and received the token from
> Authorization server). The client has to just try various keys with the
> plain-text and derive the long-term key. One possible way to solve the
> problem is to add a variable length nonce in the encrypted block. The other
> recommendation that should be added to the security considerations section
> is that the AS and RS should periodically change the long-term key or use
> mechanisms like http://tools.ietf.org/html/rfc4226 to keep changing the
> negotiated long-term key whenever a new token is generated.
>
> *From:* Oleg Moskalenko [mailto:[email-masked]]
> *Sent:* Sunday, September 14, 2014 11:51 PM
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* Simon Perreault; [email-masked]
> *Subject:* Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03
>
>
>
> Hi Tiru
>
> On Sun, Sep 14, 2014 at 9:43 AM, Tirumaleswar Reddy (tireddy) <
> [email-masked]> wrote:
>
> Hi Oleg,
>
> IV was not added to the token because the Authorization server for every
> new token produced does not generate identical data.
>
> -Tiru
>
> From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
> Cc: [email-masked]
> While reading the token encryption / decryption process description, I
> failed to figure out how we handle the initialization vector (IV) of the
> symmetric encryption algorithm (like AES_256_CBC). If we do not know what
> was the IV used when we were encrypting the token, then we cannot decrypt
> it. I see no provision for the IV in the token structure.
> We have three options:
> On Wed, Sep 10, 2014 at 5:18 AM, Simon Perreault <[email-masked]>
> wrote:
> TRAMsters,
>
> Please read it now. Substantial comments should be addressed to the group.
> Nits should be sent directly to the authors.
>
> Thanks,
> Simon & Gonzalo
>
> [email-masked]

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 15 Sep 2014 10:34:42 +0000

Inline [TR]

From: Oleg Moskalenko [mailto:[email-masked]]
Sent: Monday, September 15, 2014 2:25 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; [email-masked]; Dan Wing (dwing)
Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03

First, the "variable length" does not do much good - because the usual AES algorithms preserve the length and knowing the plaintext length, the client can deduce the nonce length (because the ciphertext length is either the same length as the plaintext length, or 16 bytes more for AEAD).

[TR] Agreed.

Second, even with unknown nonce, knowing the exact nonce field positions, the client still can try the same attack - the client will just ignore the nonce positions, and the client will obtain the same attack result as without the nonce (with very high degree of probability). If the client finds a key that decrypts properly all positions except the nonce, then the client can be almost sure that he found the real long-term key.

[TR] Yup, the client will have to try all possible key combinations (2 to the power 256 key combinations which takes very very long time) and check if the decrypted token matches the plain token. Looks like we don’t have to address this attack. http://en.wikipedia.org/wiki/Talk%3ASalt_%28cryptography%29 mentions that “modern ciphers such as Advanced Encryption Standard are not susceptible to known-plaintext attacks”.

Cheers,
-Tiru

Oleg

On Mon, Sep 15, 2014 at 1:29 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Offline, Dan and we were discussing the following attack possible with the current token format:

-Tiru

From: Oleg Moskalenko [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, September 14, 2014 11:51 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03

Hi Tiru

-Tiru

Thanks,
Simon & Gonzalo

---

From: Simon Perreault <[email-masked]>
Date: Mon, 15 Sep 2014 08:26:33 -0400

On Mon, Sep 15, 2014 at 6:34 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> [TR] Yup, the client will have to try all possible key combinations (2 to
> the power 256 key combinations which takes very very long time) and check
> if the decrypted token matches the plain token. Looks like we don’t have to
> address this attack.
> http://en.wikipedia.org/wiki/Talk%3ASalt_%28cryptography%29 mentions that
> “modern ciphers such as Advanced Encryption Standard are not susceptible to
> known-plaintext attacks”.
>

Whatever you decide, please mention it in the Security Considerations
section, and explain why you think your decision makes sense.

Thanks,
Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 16 Sep 2014 15:21:08 -0700

I'd also suggest to create an Appendix, with the content similar to RFC
5769, with ticket encoding/decoding sample examples. That would benefit
both client and server implementations, to avoid ambiguity and
misunderstandings.

Thanks
Oleg

On Mon, Sep 15, 2014 at 5:26 AM, Simon Perreault <[email-masked]>
wrote:

>> http://en.wikipedia.org/wiki/Talk%3ASalt_%28cryptography%29 mentions
>> that “modern ciphers such as Advanced Encryption Standard are not
>> susceptible to known-plaintext attacks”.
>>
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 18 Sep 2014 02:36:03 +0000

[TR2]

From: Simon Perreault [mailto:[email-masked]]
Sent: Monday, September 15, 2014 5:57 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Oleg Moskalenko; [email-masked]; Dan Wing (dwing)
Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03

On Mon, Sep 15, 2014 at 6:34 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Second, even with unknown nonce, knowing the exact nonce field positions, the client still can try the same attack - the client will just ignore the nonce positions, and the client will obtain the same attack result as without the nonce (with very high degree of probability). If the client finds a key that decrypts properly all positions except the nonce, then the client can be almost sure that he found the real long-term key.

Whatever you decide, please mention it in the Security Considerations section, and explain why you think your decision makes sense.

[TR2] Yup, We will update the security considerations section accordingly.

-Tiru

Thanks,
Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 18 Sep 2014 23:08:50 -0700

I have another comment, on Section 6.2.

I do not think that the ACCESS-TOKEN must be a comprehension-optional
attribute. The optional attributes are used when the message recipient may
be of a limited functionality (like in backward compatibility cases or
minimal clients or minimal servers). There are two reasons why the optional
attribute does not fit well here in the dialog:

1) When the client sends the request with ACCESS-TOKEN, the server already
made a commitment that the server understands the oAuth credentials (by
sending the THIRD-PARTY-AUTHORIZATION attribute). So the server may not be
a legacy server.
2) The message cannot be handled properly if the server does not
understands the ACCESS-TOKEN - because the KID is not a valid username,
anyway, and the server does not know the mac even if somehow miraculously
the server had a username with KID as the value.

If there are valid reasons why the ACCESS-TOKEN is a comprehension-optional
attribute, I'd like to hear them.

Thanks !
Oleg

On Tue, Sep 16, 2014 at 3:21 PM, Oleg Moskalenko <[email-masked]>
wrote:

>>> Second, even with unknown nonce, knowing the exact nonce field
>>> positions, the client still can try the same attack - the client will just
>>> ignore the nonce positions, and the client will obtain the same attack
>>> result as without the nonce (with very high degree of probability). If the
>>> client finds a key that decrypts properly all positions except the nonce,
>>> then the client can be almost sure that he found the real long-term key.
>>>
>>>
>>>
>>> [TR] Yup, the client will have to try all possible key combinations (2
>>> to the power 256 key combinations which takes very very long time) and
>>> check if the decrypted token matches the plain token. Looks like we don’t
>>> have to address this attack.

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 18 Sep 2014 23:40:19 -0700

One more comment, about the section 3.

1) It would be better to say in the text (or show it on the Figure 1),
explicitly, that the error code of the "Allocate error response" is 401. We
are including the THIRD-PARTY-AUTHORIZATION attrbute only in the "challenge
response", not in any error responses.
2) In the challenge response, we have to mention that we are still
including the NONCE and REALM parameters, in the case if the client does
not supports oAuth. And we have to mention that if the client does support
oAuth, then the client has to ignore those attributes.

Thanks
Oleg

On Thu, Sep 18, 2014 at 11:08 PM, Oleg Moskalenko <[email-masked]>
wrote:

> If there are valid reasons why the ACCESS-TOKEN is a
> comprehension-optional attribute, I'd like to hear them.
>
> Thanks !
> Oleg
>
>
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 19 Sep 2014 00:21:33 -0700

Actually, my comments about NONCE and REALM are invalid, those attributes
must be used in oAuth in the same way as in usual long-term credentials.
Scratch that.

Thanks
Oleg

On Thu, Sep 18, 2014 at 11:40 PM, Oleg Moskalenko <[email-masked]>
wrote:

>> 1) When the client sends the request with ACCESS-TOKEN, the server
>> already made a commitment that the server understands the oAuth credentials
>> (by sending the THIRD-PARTY-AUTHORIZATION attribute). So the server may not
>> be a legacy server.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 19 Sep 2014 09:00:18 +0000

Hi Oleg,

Regarding your second comment, though Application provided TURN server may only support third party authorization. But Enterprise provided TURN server could support both first and third party authorization. This way client can use third party authorization when it uses WebRTC/SIP servers that have business relationship with the Enterprise network and use first party authorization for non-business related calls.

TURN server in the challenge will include NONCE, REALM and THIRD_PARTY_AUTHORIZATION attributes, client uses the TURN server name to determine if third party authorization will work or not by cross-checking with the Authorization sever. If it works then client will proceed with third party authorization or else continue with first party authentication.

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Friday, September 19, 2014 12:52 PM
To: Simon Perreault
Cc: Dan Wing (dwing); [email-masked]; Tirumaleswar Reddy (tireddy)
Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03

Actually, my comments about NONCE and REALM are invalid, those attributes must be used in oAuth in the same way as in usual long-term credentials. Scratch that.

Thanks
Oleg

On Thu, Sep 18, 2014 at 11:40 PM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:
One more comment, about the section 3.
1) It would be better to say in the text (or show it on the Figure 1), explicitly, that the error code of the "Allocate error response" is 401. We are including the THIRD-PARTY-AUTHORIZATION attrbute only in the "challenge response", not in any error responses.
2) In the challenge response, we have to mention that we are still including the NONCE and REALM parameters, in the case if the client does not supports oAuth. And we have to mention that if the client does support oAuth, then the client has to ignore those attributes.
Thanks
Oleg

On Thu, Sep 18, 2014 at 11:08 PM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:
I have another comment, on Section 6.2.
I do not think that the ACCESS-TOKEN must be a comprehension-optional attribute. The optional attributes are used when the message recipient may be of a limited functionality (like in backward compatibility cases or minimal clients or minimal servers). There are two reasons why the optional attribute does not fit well here in the dialog:

1) When the client sends the request with ACCESS-TOKEN, the server already made a commitment that the server understands the oAuth credentials (by sending the THIRD-PARTY-AUTHORIZATION attribute). So the server may not be a legacy server.
2) The message cannot be handled properly if the server does not understands the ACCESS-TOKEN - because the KID is not a valid username, anyway, and the server does not know the mac even if somehow miraculously the server had a username with KID as the value.
If there are valid reasons why the ACCESS-TOKEN is a comprehension-optional attribute, I'd like to hear them.
Thanks !
Oleg

On Tue, Sep 16, 2014 at 3:21 PM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:
I'd also suggest to create an Appendix, with the content similar to RFC 5769, with ticket encoding/decoding sample examples. That would benefit both client and server implementations, to avoid ambiguity and misunderstandings.
Thanks
Oleg

On Mon, Sep 15, 2014 at 5:26 AM, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 19 Sep 2014 08:28:03 -0700

OK, thanks !

Oleg

Sent from my iPhone

> On Sep 19, 2014, at 2:00 AM, "Tirumaleswar Reddy (tireddy)" <[email-masked]> wrote:
> 
> Hi Oleg,
>  
> On Thu, Sep 18, 2014 at 11:40 PM, Oleg Moskalenko <[email-masked]> wrote:
> On Thu, Sep 18, 2014 at 11:08 PM, Oleg Moskalenko <[email-masked]> wrote:
> On Tue, Sep 16, 2014 at 3:21 PM, Oleg Moskalenko <[email-masked]> wrote:
> On Mon, Sep 15, 2014 at 5:26 AM, Simon Perreault <[email-masked]> wrote:
>  
> On Mon, Sep 15, 2014 at 6:34 AM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote: