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

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 6 Mar 2015 12:46:29 +0200

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: [email-masked] [mailto:[email-masked]]
>> Sent: Thursday, February 26, 2015 10:26 AM
>> To: [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]; [email-masked]; [email-masked];
>> [email-masked]
>> 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-authz/
>>
>> Diff from previous version:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-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.
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Mar 2015 15:46:39 +0000

Hey,

#1 - nope, that version doesn't address things that I can see
(and I've not seen a direct response to my discuss points that
I recall)

#2 - I sent an ask to the saag list just now, (attached) will
let you know if I get offers. Please also ping me if you get
any direct, just so's we don't cross streams.

S.

>>> until the htmlized version and diff are available at tools.ietf.org.

Subject: [saag] tram draft - anyone willing to help out?
From: Stephen Farrell <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 06 Mar 2015 15:43:57 +0000
List-Id: Security Area Advisory Group <saag.ietf.org>

Hiya,

There's a draft in IESG eval that attracted a bunch of perhaps
fundamental discusses and comments [1] about its security
properties. I think this may be one where the authors could
do with a bit more help from the security mafia^H^H^H^H^Hcommunity.
(I looked at their wg list and only see a v. thin smattering of
names I'd recognise from this list.) So if you're willing and
have a little time, please let me know and/or get in touch
with the authors.

And btw - this might not seem so important but I'd worry it may
end up being a major source of system level vulnerabilities for
WebRTC deployments if we get it wrong and many sites don't deploy
usefully good security for this bit of the WebRTC story.

Thanks in advance,
S.

[1]

_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 6 Mar 2015 18:14:41 +0200

Hey Stephen,

thanks for the status update. Sure, let's keep in sync regarding the
request to get a dedicated reviewer for this draft.

Cheers,

Gonzalo

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Fri, 6 Mar 2015 20:13:26 +0000

Hi Stephen,
We did respond to your discussion points. In any case, responses pasted
below:

(1) Making none of 4.1.x mandatory to implement will
result in a lack of interop. What is the developer
supposed to implement? Why is it ok to not say?  (For
example, defining 4.1.1 and 4.1.2 simply so as to appear
"more secure" whilst really expecting 4.1.3 to be used,
but not saying so, would seem like a bad plan to me.)

Response> Sections 4.1.x are only meant to be examples of mechanisms that
could be potentially used. The authors don¹t have a preference of one over
the others, 4.1.2 (REST) could be something that can be recommended to be
implemented (easy to develop and provides algorithm agility).

(2) What is the status of Appendix B? Am I supposed to
implement that? What does "Client could..." mean?

Response> Appendix B is only meant to be provide an illustration of
interaction between the WebRTC client and authorization server (WebRTC
server). Please note that the communication between the two is
proprietary, WebRTC does not mandate any signaling protocol.

(3) In the secdir review [1] discussion, I see the authors
mention adding ECC, but I see nothing in the draft. I
don't believe that that discussion has really ended and
would like to continue it. Why is the WebRTC server not
simply signing something for the STUN server to verify?
https://www.ietf.org/mail-archive/web/secdir/current/msg05425.html

Response> We did have an offline discussion with Yaron Sheffer (who had
suggested ECC). ECDH-ES can be used to agree upon a symmetric key for
encrypting/decrypting the token and ECDSA to generate digital signature
for the token. But this would result in a symmetric key, just like the
approaches described in 4.1.1 and 4.1.2. We¹ve hence decided not to
include any details pertaining to ECC.

Intro: "impossible in web applications" isn't really
true in principle, but impossible in WebRTC as it uses JS
is true. 

Response> Yes. It is not possible for WebRTC as it uses JS. We¹ll correct
it.
 
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."

- 4.1.2 - which "two servers"? WebRTC can have more
servers than that.

Response> 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.

- 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?

Response> 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?

Response> No. The ŒNote:¹ at the end of the section is probably
misleading, will update it.
 
NEW:
"Note : The mechanism specified in Section 4.1.3 lacks encryption and HMAC
algorithm agility."

- 9: Figure 2 should be way up at the top of the document
and not here

Response> 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?

Response> STUN messages can be sent over UDP, 5 seconds is to accommodate
packet loss and RTO interval.

- 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?

Response> 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.

-Prashanth

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Mar 2015 20:59:05 +0000

On 06/03/15 20:13, Prashanth Patil (praspati) wrote:
> Hi Stephen,
> We did respond to your discussion points. 

Ah sorry - you omitted the IESG I guess, as with this and that was
where I looked. Can you respond cc'ing all? That way any other ADs
who may be interested also see the discussion.

Ta,
S.

In any case, responses pasted

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 7 Mar 2015 12:05:02 +0200

Hi,

I am adding the IESG list to the cc: so that everyone can follow these
discussions.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 7 Mar 2015 12:05:18 +0200

Hi Stephen,

I just added the IESG list, as you suggested.

Thanks,

Gonzalo

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 07 Mar 2015 19:54:32 +0000

> I am adding the IESG list to the cc: so that everyone can follow these

Thanks. And sorry for missing this and not responding before.

>> the others, 

That's not going to get us interop though is it? And interop is
needed here - we have the browser, the web-site and the TURN/STUN
server all involved. I think you need one mechanism that is MTI
and that is RECOMMENDED to use for this to be useful.

>> 4.1.2 (REST) could be something that can be recommended to be
>> server). 

The use of the AS term in WebRTC is unusual. Sufficiently so as to
be a bad idea I think. (And one could wonder about who is the real
resource owner in WebRTC - I don't think it's the web site that sets
up the calls myself.)

>> Please note that the communication between the two is

Hmm. I'm not sure I see the benefit of including that, if you're
right above.

>> include any details pertaining to ECC.

ECDSA is a signature scheme. No symmetric key would be needed. So
I'm not following your logic there tbh. At least at a high level,
a signature scheme makes a lot of sense in this case.

Cheers,
S.

PS: We can cover the comments below later, when the discuss points
are sorted.

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 10 Mar 2015 20:00:43 +0000

Hi Stephen,

>and that is RECOMMENDED to use for this to be useful.

We can certainly RECOMMEND 4.1.2 (REST). However, the suggestion from
OAUTG WG is to not mandate one
http://www.ietf.org/mail-archive/web/oauth/current/msg14325.html.

Section 4 was originally meant to provide examples for key establishment.
TURN standardization has no dependency on the establishment procedure. In
would seem that a relay service provider will probably use whichever
method(s) for key exchange their customers are
willing to accept.

We could either remove this completely, or move this section to appendix,
if that helps.

>resource owner in WebRTC - I don't think it's the web site that sets

The resource server is the TURN server, owned by the WebRTC service (or
the TURN and WebRTC service providers could have a business relationship.)

>a signature scheme makes a lot of sense in this case.

The token needs to be encrypted and authenticated. ECDSA only generates
signature for the token. We need ECDH to agree upon a symmetric key for
encrypting/decryption. Symmetric keys would result in approaches very
similar to the ones described in 4.1.1 and 4.1.2.

-Prashanth

>>>>>https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-auth
>>>>>z/b
>>>>> allot/
>>>>>
>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-tram-turn-third-party
>>>>>>>-au
>>>>>>> thz-
>>>>>>> 13.txt
>>>>>>>
>>>>>>>https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-au
>>>>>>>thz
>>>>>>> /
>>>>>>>
>>>>>>>http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-au
>>>>>>>thz
>>>>>>> -13
>>>>>>>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Mar 2015 20:40:48 +0000

Hiya,

> http://www.ietf.org/mail-archive/web/oauth/current/msg14325.html.

Yes, I saw that. And it's a bogus suggestion. OAuth may be a framework
but WebRTC is not and nor is the STUN/TURN part of WebRTC.

I think you need to pick one (or more) MTI scheme. And one that
provides better security than we have today with STUN/TURN.

The only answer I can think of for that is a signature based
scheme to be honest.

> method(s) for key exchange their customers are

Sorry - are you assuming some particular business model? I'm not sure
that's a valid assumption for WebRTC, nor for STUN/TURN in general.

> The token needs to be encrypted and authenticated.

Why encrypted? What needs confidentiality?

Ta,
S.

> ECDSA only generates

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 10 Mar 2015 21:21:55 +0000

Hi Stephen,

>The only answer I can think of for that is a signature based

Sure, we’ll need WG feedback on this. The feedback from the WG was to not
mandate one as well.

>Why encrypted? What needs confidentiality?

The Token, which is self contained, is encrypted so as to make it opaque
to the client. All the information necessary to authenticate the validity
of the token is contained within the token itself.

-Prashanth

>>>>> Please note that the AS is allocating symmetric keys meant
>>>>>exclusively
>>>>> for
>>>>>>>th

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Mar 2015 21:29:30 +0000

Hiya,

> of the token is contained within the token itself.

Sorry I'm still not getting it. Exactly what information needs to be
confidential between which endpoints?

When I think of the STUN/TURN problem in WebRTC, it's a pure question
of permission and accountability.

Today, the web site hands out a username/secret for use of STURN or
TURN, which is bad,

But why not have the web site sign a token that says "web site
<foo> says it's ok for whoever presents this to get STUN/TURN service"
with whatever timestamps or other controls are needed. I don't see
anything that needs to be inside that token that's not immediately
obvious from just watching the (ciphertext) packets flow. So I
don't see anything that needs encrypting between the web site and
the STUN/TURN servers.

Cheers,
S.

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 11 Mar 2015 04:26:14 +0000

Hi Stephen,
The token carries the key used to generate message integrity for the STUN
message. It was designed to be inline with the proof-of-possesion security
mechanism discussed in
https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01. STUN
messages have to be signed to prove that it was indeed the TURN client
that was authorized to use the token, and similarly the TURN server needs
to prove to the TURN client that it was the server authorized by the
WebRTC server and not a rouge TURN server.

-Prashanth

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 11 Mar 2015 04:27:45 +0000

> >provides better security than we have today with STUN/TURN.

The STUN/TURN Server and WebRTC server could be operated by the same provider (tightly-coupled) and in this case it they can choose to pick whatever mechanism suites it for establishing the long-term key. Even in the scenario where STUN/TURN server and WebRTC server are operated by different providers (loosely-coupled), they need prior business tie-up to utilize the TURN/STUN resource for WebRTC calls and they can decide on any key establishment mechanism.

> >
> >The only answer I can think of for that is a signature based scheme to
> >be honest.

The token carries session key which is used for generating message integrity for STUN messages, hence the token needs both encryption and signature. There are multiple keys involved in this mechanism [1] Keys for encrypting and generating message integrity of the token [2] key for generating message integrity of the STUN message.

> Sure, we’ll need WG feedback on this. The feedback from the WG was to not

I think it was discussed in the WG and the decision was not to mandate any key establishment procedure, If there is no objection from the WG we will add recommendation to use mechanism specified in section 4.1.2.

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 11 Mar 2015 04:39:11 +0000

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

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Friday, March 06, 2015 4:16 PM
> To: Tirumaleswar Reddy (tireddy); [email-masked]; [email-masked]; draft-
> [email-masked]; draft-ietf-tram-turn-third-party-
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: New Version Notification - draft-ietf-tram-turn-third-party-authz-
> 13.txt
> 
> Stephen, Richard,
> 
> Could you please look at the new revision Tiru has put together and let him know
> if you are happy with it?
> 
> Thanks,
> 
> Gonzalo
> 
> >> To: [email-masked]; [email-masked];
> >> draft-ietf-tram-turn-third-party- [email-masked];
> >> [email-masked]; draft-ietf-tram-turn-third-
> >> 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.
> >

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Mar 2015 10:08:39 +0000

So I think someone needs to draw me a picture at a whiteboard, which
we can do in Dallas maybe, since I'm not getting the rationale behind
the design here.

S.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 13 Mar 2015 13:33:44 +0100

Hi Spencer,

could you please propose a timeslot that works for both you and Stephen
so that we can move this forward during the upcoming meeting in Dallas?

Thanks,

Gonzalo

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Mar 2015 19:57:51 +0000

On 20/03/15 19:54, Brandon Williams wrote:
> Hi all,
> 
> Has a timeslot been proposed for this discussion? Please CC me if/when
> it is. Rich Salz (a colleague of mine who focuses on security) and I
> would like join the discussion if we can.

I think we just got done agreeing on Friday 0850 @ noticeboard

S

> 
> Thanks,
> --Brandon
> 
> On 03/13/2015 08:33 AM, Gonzalo Camarillo wrote:
>> Hi Spencer,
>>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Dpop-2Darchitecture-2D01&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=nCIoBhgZ9Uqiw99NM5A0zgnl26IUiofXZMm0CxLDl3A&s=sqrlLUHPx0NZS-UmsqhWkTtXwzz_Zfa1Td0MYOlICPI&e=
>>>> . STUN
>> tram mailing list
>> [email-masked]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=nCIoBhgZ9Uqiw99NM5A0zgnl26IUiofXZMm0CxLDl3A&s=4n-Qc5o1pANLszaThuvMPkUsUFs8-8k7aK-ft6xMzn4&e=
>>
>>
>