Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-party-authz-13: (with DISCUSS and COMMENT)

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

> -----Original Message-----
> From: Oleg Moskalenko [mailto:[e-mail]]
> Sent: Monday, April 13, 2015 1:17 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Stephen Farrell; [e-mail]; [e-mail]; draft-ietf-tram-turn-
> [e-mail]; [e-mail]; draft-ietf-tram-
> [e-mail]; draft-ietf-tram-turn-third-party-
> [e-mail]
> Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-
> party-authz-13: (with DISCUSS and COMMENT)
> 
> I noticed another problem in the draft:
> 
> In the version 13, there was a formal explanation how the keys can be
> derived from the original K parameter (the keying material); due to that
> formal algorithm, both AS and STUN servers can perform the same actions
> over the K and obtain the same keys. That algorithm was based upon HKDF.
> In the version 14, that algorithm is omitted, and instead a reference to
> section 5.2.2.1 of [I-D.ietf-jose-json-web-algorithms] is added. But that
> section explains only how to derive AUTH and RS keys for the
> AES_CBC_HMAC_SHA algorithm. In the case if other algorithms are used, the
> derivation of keys from the K is not defined, and that makes AS and STUN
> server inter-operation problematic. The required STUN server authenticated
> encryption algorithm is A256GCMKW and it has no defined key derivation
> procedure in the version 14 of the draft.

GCM only takes input key K https://tools.ietf.org/html/rfc5116#section-2.1, key derivation procedure is not required for AEAD. 
Updated draft to be more clear.
NEW:
   If Authenticated Encryption
   with Associated Data (AEAD) algorithm defined in [RFC5116] is used
   then there is no need to generate the AUTH key and AS-RS key will
   have the same value as the symmetric key (K).

> 
> I propose to restore the HKDF-based universal key derivation procedure for
> GCM and other algorithms.
> 
> Overall, I see that sections 4.1 and 4.1.1 have lots of legacy from the previous
> draft version 13, and it creates a somewhat messy wording. I'd suggest to re-
> write those two sections from scratch, because just changing/replacing some
> words in the historical text eventually creates a cryptic text that different
> people may understand differently. For example, the new 4.1.1 text can be
> understood so that AUTH and RS keys must always be 256 bites both (and
> we know that this is not really the case). I think that closing the old text and
> writing the new one (with clear understanding in mind what we want) would
> do the trick.

Agreed, attached updated draft with changes to sections 4.1 and 4.1.1

Cheers,
-Tiru

> 
> Thanks
> Oleg
> 
> On Fri, Apr 10, 2015 at 8:07 PM, Tirumaleswar Reddy (tireddy)
> <[e-mail]> wrote:
> >> -----Original Message-----
> >> From: Stephen Farrell [mailto:[e-mail]]
> >> Sent: Saturday, April 11, 2015 1:08 AM
> >> To: The IESG
> >> Cc: [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]
> >> Subject: Stephen Farrell's Discuss on
> >> draft-ietf-tram-turn-third-party-authz-
> >> 13: (with DISCUSS and COMMENT)
> >>
> >> Stephen Farrell has entered the following ballot position for
> >> draft-ietf-tram-turn-third-party-authz-13: Discuss
> >>
> >> When responding, please keep the subject line intact and reply to all
> >> email addresses included in the To and CC lines. (Feel free to cut
> >> this introductory paragraph, however.)
> >>
> >>
> >> Please refer to
> >> http://www.ietf.org/iesg/statement/discuss-criteria.html
> >> for more information about IESG DISCUSS and COMMENT positions.
> >>
> >>
> >> The document, along with other ballot positions, can be found here:
> >> http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-auth
> >> z/
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> -
> >> DISCUSS:
> >> ---------------------------------------------------------------------
> >> -
> >>
> >>
> >> Edited discuss ballot after chats around Dallas.
> >>
> >> (1) Please fix the crypto as per Richard's discuss. (I think the plan
> >> here is for Rich Salz to help with that, which I'm confident will
> >> work out ok.)
> >
> > Yes, comments from Richard are addressed.
> >
> >>
> >> (2) Please consider whether a signature based scheme that does not
> >> require pre-shared keys between the TURN and (in particular) WebRTC
> >> server could be useful to support. (Either in this document or
> >> elsewhere.) There should be use cases where that offers sufficient
> >> accountability for use of TURN and it ought allow some deployments
> >> that are less easy with this kind of pre-shared keys approach. The
> >> DISCUSS here is to check if the WG want to take that approach, either
> now or later.
> >
> > Passive attacks could occur in TURN due to lack of integrity protection. For
> example, a passive attacker could monitor Allocate request/response
> between the client and TURN server and make a Refresh request with a
> requested lifetime of 0 to delete the allocation. Message integrity of TURN
> messages ensures that passive attacker cannot spoof subsequent TURN
> messages.
> >
> >>
> >> (3) I think the plan is to take out some of the options that are not
> >> needed so as make interop more likely.
> >> Please do so. (I think we discussed taking out the DKSPP stuff at
> >> least, but the more options we can get rid of, the better).
> >
> > Yes, DKSPP is removed from the draft.
> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> -
> >> COMMENT:
> >> ---------------------------------------------------------------------
> >> -
> >>
> >>
> >> - COMMENTS below are unchanged since before Dallas.
> >> We can look over then as we go.
> >>
> >> - I really think this would benefit from some wider review and I
> >> don't think it's ready as-is.
> >
> > This draft is also reviewed in OAuth WG.
> >
> >>
> >> - I agree with Richard's discuss points.
> >>
> >> - intro: "impossible in web applications" isn't really true in
> >> principle, but impossible in WebRTC as it uses JS is true.
> >
> > NEW:
> >    However, in web applications
> >    like WebRTC [I-D.ietf-rtcweb-overview] where JavaScript uses the
> >    browser functionality to make real-time audio and/or video calls, Web
> >    conferencing, and direct data transfer, ensuring this secrecy is
> >    typically not possible.
> >
> >>
> >> - Assuming the AS that can authorize the user shares a secret with
> >> the STUN server chosen by the WebRTC server seems very brittle. Why
> >> would that be true in general?
> >
> > The AS and WebRTC server are in the same administrative domain of the
> application provider. The user never sends the session key learned  from the
> AS to the STUN server it only uses the session key to compute  message
> integrity of STUN request and to validate the  message integrity of  the STUN
> response. The STUN server will only know the session key if it can decrypt
> the token.
> >
> >>
> >> - 4.1.1: Hmmm. How many people use KeyProv I wonder?
> >
> > Already removed DKSPP.
> >
> >>
> >> - 4.1.2 - which "two servers"? WebRTC can have more servers than that.
> >
> > The STUN server and the AS. As far as the STUN server is concerned, it only
> deals with the AS of interest for key establishment. The AS could be the
> application server itself or could be a Key management  function syncing the
> keying material to the WebRTC servers.
> >
> > NEW:
> >    The STUN and AS servers could choose to use REST API over HTTPS to
> >    establish a symmetric key.
> >
> >>
> >> - 4.1.2 - now we're using TLS mutual auth? And how does the TLS
> >> client know which CA to use that'll work with the TLS server here? I
> >> don't think that'll scale will it?
> >
> > We presume the two parties involved know what CA to consider when
> using the REST APIs ­ they would have to do this to trust each other. Please
> note that the AS is allocating symmetric keys meant exclusively for  that
> STUN Server, so some level of co-ordination is already involved.
> >
> >>
> >> - 4.1.3 - this looks like what the WG/authors really want, would that
> >> be a fair statement?
> >
> > As per our discussion we have changed the specification to recommend
> > REST
> >
> > NEW:
> >
> >    Note : The mechanism specified in Section 4.1.2 compared to REST
> >    lacks encryption and HMAC algorithm agility.  Hence a STUN server and
> >    authorization server implementation SHOULD support REST explained in
> >    Section 4.1.1.
> >
> >
> >>
> >> - 9: Figure 2 should be way up at the top of the document and not
> >> here
> >
> > In the previous versions it was in the top of the document but moved
> down after comments received from the WG that WebRTC is only an
> example usage of third party authorization.
> >
> >>
> >> - 9: Why 5 seconds ?
> >
> > STUN messages can be sent over UDP, 5 seconds is to accommodate packet
> loss and RTO interval.
> >
> > -Tiru
> >
> >>
> >
> > _______________________________________________
> > tram mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tram