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

[Oleg Moskalenko <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> wrote:
>
>>
>> On Mon, Sep 15, 2014 at 6:34 AM, Tirumaleswar Reddy (tireddy) <
>> [e-mail]> 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
>>
>
>