Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.txt

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Richard,

Resending our responses to discussion points, Please have a look.

Let's talk about Section 6.2 and custom crypto.

(1) You have tried to invent your own authenticated encryption, and fallen into the trap of Encrypt-Then-MAC [0]. 

[TR] No, the authenticated encryption algorithms are already covered in http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-5.1.

(EDIT: Actually, it's MAC-then-Encrypt that's bad.  See why you should just use AEAD?)  Please use a real AEAD mode, such as AES-GCM [1].  That will also remove the need for padding, which is fraught with peril as well [2].

[TR] Padding attack as discussed in [2] is prevented by appending HMAC to the cipher-text. The encrypted_block in the token is integrity protected using HMAC.

(2) It's a bad idea to hard-wire cryptographic algorithms into protocols, because they inevitably go bad [3].  

[TR] The cryptographic algorithms are not hard-coded, they can be negotiated b/w the STUN server and Authorization server using the mechanisms in 
Section 4.1.1; 4.1.2 allows Authorization server to convey any algorithm of choice; 4.1.3 allows any number of algorithms to be configured on the STUN server and authorization server, the algorithm picked by the authorization server is determined by the STUN server using the kid conveyed in the STUN request.

(STUN itself is an anti-pattern here.)  Please add an algorithm indicator to the top of your token structure.  You don't need to create a registry now, since you've only got one value.

That gives you something like the following, much simpler structure:

struct {
  uint8_t algorithm;
  uint16_t length;
  opaque encrypted_block[length];
}

struct {
  uint16_t key_length;
  opaque mac_key[key_length];
  uint64_t timestamp;
  uint32_t lifetime;
}

It also means that you can simplify the key management routines in Section 4.1, since you only need one key.

(3) Section 5 should be more clear about how this mechanism changes STUN processing.  Namely, it adds a third parallel method of computing the message integrity value, which the server MUST use if an ACCESS-TOKEN attribute is present.  

[TR] The client is unaware of the technique used to encrypt and integrity protect the self-contained token. It just uses the mac_key provided by the authorization server to compute the message integrity of the STUN request.

Cheers,
-Tiru

[0] https://eprint.iacr.org/2001/045
[1] http://tools.ietf.org/html/rfc5116
[2] http://en.wikipedia.org/wiki/Padding_oracle_attack
[3] https://tools.ietf.org/html/draft-housley-crypto-alg-agility-00

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[e-mail]]
> Sent: Friday, March 06, 2015 4:16 PM
> To: Tirumaleswar Reddy (tireddy); [e-mail]; [e-mail]; draft-
> [e-mail]; draft-ietf-tram-turn-third-party-
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: New Version Notification - draft-ietf-tram-turn-third-party-authz-
> 13.txt
> 
> Stephen, Richard,
> 
> you have discusses on this draft:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/
> 
> Could you please look at the new revision Tiru has put together and let him know
> if you are happy with it?
> 
> Thanks,
> 
> Gonzalo
> 
> On 28/02/2015 5:10 AM, Tirumaleswar Reddy (tireddy) wrote:
> > We have responded to comments from ISEG and published updated draft.
> >
> > -Tiru
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]]
> >> Sent: Thursday, February 26, 2015 10:26 AM
> >> To: [e-mail]; [e-mail];
> >> draft-ietf-tram-turn-third-party- [e-mail];
> >> [e-mail]; draft-ietf-tram-turn-third-
> >> [e-mail]; draft-ietf-tram-turn-third-party-
> >> [e-mail]; [e-mail]; [e-mail];
> >> [e-mail]
> >> Subject: New Version Notification -
> >> draft-ietf-tram-turn-third-party-authz-
> >> 13.txt
> >>
> >>
> >> A new version (-13) has been submitted for
> >> draft-ietf-tram-turn-third-party-
> >> authz:
> >> http://www.ietf.org/internet-drafts/draft-ietf-tram-turn-third-party-
> >> authz-
> >> 13.txt
> >>
> >> Sub state has been changed to AD Followup from Revised ID Needed
> >>
> >>
> >> The IETF datatracker page for this Internet-Draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-aut
> >> hz/
> >>
> >> Diff from previous version:
> >> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-aut
> >> hz-13
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> IETF Secretariat.
> >