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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 19 Sep 2014 08:46:44 +0000

Hi Oleg,

Good catch, changed ACESS_TOKEN to comprehension-required attribute.

Cheers,
-Tiru

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

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:

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.

[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: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 19 Sep 2014 08:48:03 +0000

Inline [TR]

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

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.

[TR] Updated figure 1

-Tiru

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:

Thanks,
Simon