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: tram [mailto:[e-mail]] On Behalf Of Oleg Moskalenko
> Sent: Monday, April 13, 2015 12:35 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [e-mail]
> 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)
> <[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
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram