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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 13 Apr 2015 14:03:19 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
> Sent: Monday, April 13, 2015 12:35 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [email-masked]
> Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-
> party-authz-13: (with DISCUSS and COMMENT)
> 
> I noticed that the encrypted token has odd number of bytes, because the
> nonce_length is just one byte. I'd suggest to make it two bytes.

Yes, fixed in my local copy.

Thanks and Regards,
-Tiru

> Saving a byte by making the data size odd usually does not work well.
> It is really not saving any space or CPU cycles.
> 
> 
> Thanks
> Oleg
> 
> 
> On Fri, Apr 10, 2015 at 8:07 PM, Tirumaleswar Reddy (tireddy)
> <[email-masked]> wrote:
> >> -----Original Message-----
> >> From: Stephen Farrell [mailto:[email-masked]]
> >> Sent: Saturday, April 11, 2015 1:08 AM
> >> To: The IESG
> >> Cc: [email-masked]; [email-masked];
> >> draft-ietf-tram-turn-third-party- [email-masked];
> >> [email-masked]; draft-ietf-tram-turn-third-
> >> [email-masked]; draft-ietf-tram-turn-third-party-
> >> [email-masked]
> >> 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tram
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 14 Apr 2015 05:38:40 +0000

> From: Oleg Moskalenko [mailto:[email-masked]]
> Sent: Monday, April 13, 2015 1:17 PM
> Cc: Stephen Farrell; [email-masked]; [email-masked]; draft-ietf-tram-turn-
> [email-masked]; [email-masked]; draft-ietf-tram-
> [email-masked]; draft-ietf-tram-turn-third-party-
> [email-masked]
> 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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 15 Apr 2015 16:10:03 +0000

> Sent: Wednesday, April 15, 2015 2:50 AM
> To: Martin Thomson
> Cc: Tirumaleswar Reddy (tireddy); [email-masked]; [email-masked];
> Brandon Williams; [email-masked]; Salz, Rich; Stephen Farrell
> ([email-masked])
> On Tue, Apr 14, 2015 at 1:18 PM, Martin Thomson
> <[email-masked]> wrote:
> > On 14 April 2015 at 12:53, Oleg Moskalenko <[email-masked]>
> wrote:
> >> You can set the server name to
> > "Martin Thomson" and it will be perfectly OK.
> >
> > OK, you still haven't explained why such a field needs to be defined
> > in an RFC.  Ideally, the draft should contain that explanation.
> 
> The draft fully explains why we need that field for the sake of
> encryption/authorization. I do not believe that it can be explained clearer.

Yes, it's explained in section 6.2

<snip>
   The associated data (A) MUST be the STUN server name.  This ensures
   that the client does not use the same token to gain illegal access to
   other STUN servers provided by the same administrative domain i.e.,
   when multiple STUN servers in a single administrative domain share
   the same symmetric key with an authorization server.
</snip>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 15 Apr 2015 16:10:32 +0000

> >
> > Also, I just noticed that this uses base64.  That's arbitrary.  Does
> > the client remove that encoding before including the token in the STUN
> > message?  There's no MUST there, but it seems like it's part of the
> > process somehow.
> 
> more clarifications in the text are always welcome.

The token is opaque to the client and it includes the token in the STUN message as provided by the authorization server. It's already discussed in section 6.2
<snip>
Note that the self-contained token is opaque to the client and the client MUST NOT examine the token.  
</snip>