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

[Oleg Moskalenko <[e-mail]>]

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.

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.

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-authz/
>>
>>
>>
>> ----------------------------------------------------------------------
>> 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