Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?

[Tirumaleswar Reddy (tireddy)]

In this use case RS and AS could be implemented and operated by different 
providers, MTI solves the interop issue.

-Tiru

From: Bill Mills [mailto:wmills_92...@yahoo.com]
Sent: Monday, March 09, 2015 11:10 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?

Explain to me why there should be one other than the desire to over-specify?  
Why is one so clearly superior to any of the various possibilities that it 
should be mandated?

I do not think that there is any clearly superior mechanism and so making any 
particular one MTI is pointless and just likely to cause perfectly good 
implementations to be out of spec.

On Sunday, March 8, 2015 10:24 PM, Tirumaleswar Reddy (tireddy) 
mailto:tire...@cisco.com>> wrote:

Hi Bill,

Can you please provide more details why mandating specific key distribution 
mechanism is not appropriate especially in case of loosely coupled systems ?

-Tiru

From: Bill Mills [mailto:wmills_92...@yahoo.com]
Sent: Monday, March 09, 2015 10:27 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?

I do not believe making any specific key distribution MTI is aproprpiate.

On Sunday, March 8, 2015 8:06 PM, Tirumaleswar Reddy (tireddy) 
mailto:tire...@cisco.com>> wrote:

Hi Hannes,

http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01#section-5.3 
discusses long-term secret shared by the authorization server with the resource 
server but does not mention the out-of-band mechanism.

In 
http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13#section-4.1.1
 we had provided three mechanisms for long-term key establishment. In this use 
case RS and AS could be offered by the same provider (tightly-coupled) or by 
different providers (loosely-coupled).

Thoughts on which one should be mandatory to implement ?
(This question came up in ISEG review and probably would be a question for 
proof-of-possession work as well)

Thanks and Regards,
-Tiru

> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
> Behalf Of Hannes Tschofenig
> Sent: Saturday, March 07, 2015 12:30 AM
> To: oauth@ietf.org<mailto:oauth@ietf.org>
> Subject: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?
>
> Hi all,
>
> does anyone have free cycles to review
> draft-ietf-tram-turn-third-party-authz, which happens to use OAuth 2.0 in a 
> way
> that is similar to the proof-of-possession work with a new access token 
> format.
>
> Ciao
> Hannes
>
>  Forwarded Message 
> Subject: [saag] tram draft - anyone willing to help out?
> Date: Fri, 06 Mar 2015 15:43:57 +
> From: Stephen Farrell 
> mailto:stephen.farr...@cs.tcd.ie>>
> To: s...@ietf.org<mailto:s...@ietf.org> mailto:s...@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]
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/
>
> ___
> saag mailing list
> s...@ietf.org<mailto:s...@ietf.org>
> https://www.ietf.org/mailman/listinfo/saag
>
>

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?

[Tirumaleswar Reddy (tireddy)]

Hi Bill,

Can you please provide more details why mandating specific key distribution 
mechanism is not appropriate especially in case of loosely coupled systems ?

-Tiru

From: Bill Mills [mailto:wmills_92...@yahoo.com]
Sent: Monday, March 09, 2015 10:27 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?

I do not believe making any specific key distribution MTI is aproprpiate.

On Sunday, March 8, 2015 8:06 PM, Tirumaleswar Reddy (tireddy) 
 wrote:

Hi Hannes,

http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01#section-5.3 
discusses long-term secret shared by the authorization server with the resource 
server but does not mention the out-of-band mechanism.

In 
http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13#section-4.1.1
 we had provided three mechanisms for long-term key establishment. In this use 
case RS and AS could be offered by the same provider (tightly-coupled) or by 
different providers (loosely-coupled).

Thoughts on which one should be mandatory to implement ?
(This question came up in ISEG review and probably would be a question for 
proof-of-possession work as well)

Thanks and Regards,
-Tiru

> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
> Behalf Of Hannes Tschofenig
> Sent: Saturday, March 07, 2015 12:30 AM
> To: oauth@ietf.org<mailto:oauth@ietf.org>
> Subject: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?
>
> Hi all,
>
> does anyone have free cycles to review
> draft-ietf-tram-turn-third-party-authz, which happens to use OAuth 2.0 in a 
> way
> that is similar to the proof-of-possession work with a new access token 
> format.
>
> Ciao
> Hannes
>
>  Forwarded Message 
> Subject: [saag] tram draft - anyone willing to help out?
> Date: Fri, 06 Mar 2015 15:43:57 +
> From: Stephen Farrell 
> mailto:stephen.farr...@cs.tcd.ie>>
> To: s...@ietf.org<mailto:s...@ietf.org> mailto:s...@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]
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/
>
> ___
> saag mailing list
> s...@ietf.org<mailto:s...@ietf.org>
> https://www.ietf.org/mailman/listinfo/saag
>
>

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?

[Tirumaleswar Reddy (tireddy)]

Hi Hannes,

http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01#section-5.3 
discusses long-term secret shared by the authorization server with the resource 
server but does not mention the out-of-band mechanism.

In 
http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13#section-4.1.1
 we had provided three mechanisms for long-term key establishment. In this use 
case RS and AS could be offered by the same provider (tightly-coupled) or by 
different providers (loosely-coupled).

Thoughts on which one should be mandatory to implement ?
(This question came up in ISEG review and probably would be a question for 
proof-of-possession work as well)

Thanks and Regards,
-Tiru

> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Saturday, March 07, 2015 12:30 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?
> 
> Hi all,
> 
> does anyone have free cycles to review
> draft-ietf-tram-turn-third-party-authz, which happens to use OAuth 2.0 in a 
> way
> that is similar to the proof-of-possession work with a new access token 
> format.
> 
> Ciao
> Hannes
> 
>  Forwarded Message 
> Subject: [saag] tram draft - anyone willing to help out?
> Date: Fri, 06 Mar 2015 15:43:57 +
> From: Stephen Farrell 
> To: s...@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]
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/
> 
> ___
> saag mailing list
> s...@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
> 
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC on "OAuth 2.0 Proof-of-Possession (PoP) Security Architecture"

[Tirumaleswar Reddy (tireddy)]

Please address the comments given in 
http://www.ietf.org/mail-archive/web/oauth/current/msg13352.html

-Tiru

> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes
> Tschofenig
> Sent: Saturday, November 29, 2014 2:30 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] WGLC on "OAuth 2.0 Proof-of-Possession (PoP)
> Security Architecture"
> 
> Hi all,
> 
> as discussed at the last IETF meeting we are processing with the proof-of-
> possession work. We are therefore starting a working group last call for the
> "OAuth 2.0 Proof-of-Possession (PoP) Security Architecture".
> 
> Here is the document:
> http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-00
> 
> Since the document covers scenarios, use cases, requirements, and
> architecture it should actually be easy to read for everyone.
> 
> Please send you comments to the OAuth mailing list by December 13, 2014.
> 
> Ciao
> Hannes & Derek

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth & Authentication: What can go wrong?

[Tirumaleswar Reddy (tireddy)]

And me.

-Tiru

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Antonio Sanso
Sent: Friday, September 12, 2014 12:20 PM
To: Gil Kirkpatrick
Cc: Derek Atkins; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong?

I would like to attend as well ...

regards

antonio

On Sep 12, 2014, at 3:00 AM, Gil Kirkpatrick 
mailto:gil.kirkpatr...@viewds.com>> wrote:


+1 for me.

-- Original Message --
From: "John Bradley" mailto:ve7...@ve7jtb.com>>
To: "Nat Sakimura" mailto:sakim...@gmail.com>>
Cc: "Derek Atkins" mailto:de...@ihtfp.com>>; 
"oauth@ietf.org" mailto:oauth@ietf.org>>
Sent: 12/09/2014 9:30:50 AM
Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong?

And me

Sent from my iPhone

On Sep 11, 2014, at 7:49 PM, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:
Add me, too.

2014-09-12 7:32 GMT+09:00 Anthony Nadalin 
mailto:tony...@microsoft.com>>:
Add me

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On 
Behalf Of Hannes Tschofenig
Sent: Thursday, September 11, 2014 3:30 PM
To: oauth@ietf.org
Cc: Derek Atkins
Subject: [OAUTH-WG] OAuth & Authentication: What can go wrong?

Hi all,

at the last IETF meeting Mike gave a presentation about the 
draft-hunt-oauth-v2-user-a4c and the conclusion following the discussion was to 
discuss the problems that happen when OAuth gets used for authentication.

The goal of this effort is to document the problems in an informational 
document.

Conference calls could start in about 2 weeks and we would like to know who 
would be interested to participate in such a discussion.

Please drop us a private mail so that we can find suitable dates/times.

Ciao
Hannes & Derek
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Review of draft-ietf-oauth-pop-key-distribution-00

[Tirumaleswar Reddy (tireddy)]

My comments

1)Is audience parameter mandatory when handle token used ?

2)The value included in the aud parameter may not always be an absolute URI. 
For example refer to Figure 2 in 
http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-02

3)What are the mitigations RS would use to handle a scenario where there is a 
DDOS attack from clients sending invalid self-contained or handle tokens ?
4)

  Step (2): When the client interacts with the token endpoint to
  obtain an access token it MUST populate the newly defined
  'audience' parameter with the information obtained in step (0).

Nit> Replace 'audience' with 'aud'

5)Figure 3
Comment> Please explain what kty, kid, and k mean ?

Cheers,
-Tiru
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Review of draft-ietf-oauth-pop-architecture-00

[Tirumaleswar Reddy (tireddy)]

My comments:

1) Figure 3: Resource server in the response could also generate Signature/MAC 
to prove the client that it is in possession of cryptographic keying material.

2) Section 3.2:
Will new HTTP headers be defined in one of the PoP drafts for the application 
layer to carry the TLS channel binding information ?

3)Section 3.3: It is covering various attack scenarios except active, 
man-in-middle attack.

4)Why only discuss TLS and not DTLS ?

5)Section 3.4: Enterprise networks, ISP etc. may also deploy HTTP(S) proxy.

6)Please explain scenarios in which using asymmetric cryptography is better 
suited for PoP than using symmetric cryptography.

7)I don't see any discussion on HMAC algorithm negotiation b/w the client and 
resource server.
   It may help to define mandatory to implement and default algorithms.

8)Protocols like Dynamic Symmetric Key Provisioning Protocol (DSKPP) (RFC6063) 
could be considered for long-term secret b/w the AS and RS.

9)Nit> Figure 4: Add arrows for (V) and (IV)


10)   AS-to-RS Relationship Anonymity:

  This MAC Token security does not provide AS-to-RS relationship
  anonymity since the client has to inform the resource server about
  the resource server it wants to talk to.

Nit> I think you meant "inform the authorization server about the resource 
server it wants to talk to"

Cheers,
-Tiru
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [tram] Review of draft-ietf-tram-turn-third-party-authz-01

[Tirumaleswar Reddy (tireddy)]

> -Original Message-
> From: Brandon Williams [mailto:brandon.willi...@akamai.com]
> Sent: Monday, August 25, 2014 8:29 PM
> To: Hannes Tschofenig; Tirumaleswar Reddy (tireddy); oauth@ietf.org
> Cc: sperrea...@jive.com; draft-ietf-tram-turn-third-party-
> au...@tools.ietf.org; gonzalo.camari...@ericsson.com >> Gonzalo
> Camarillo; t...@ietf.org
> Subject: Re: [tram] Review of draft-ietf-tram-turn-third-party-authz-01
> 
> The TURN server name value in the THIRD-PARTY-AUTHORIZATION attribute
> servers 2 purposes, although only one of them is clearly called out in the
> document. The first purpose is to allow the OAuth server to select from
> among multiple 3rd party TURN service providers so that the appropriate key
> material can be selected when generating the token. The second purpose,
> which isn't called out in the document, is to provide a unique identifier for
> the specific server within the deployment so that the generated ACCESS-
> TOKEN value will only be considered valid by that specific server (i.e. to
> prevent replay of the token to multiple TURN servers). So, you can consider
> "f...@turn.com" to mean "generate a token for the server named foo at
> service provider turn.com".

The second purpose is also discussed in section 6.2

HMAC is computed using the encrypted portion
of the token and TURN server name to ensure that the client does not
use the same token to gain illegal access to other TURN servers
provided by the same administrative domain.  This attack is possible
when multiple TURN servers in a single administrative domain share
the same symmetric key with the authorization server.


-Tiru

> 
> I think the client would perform the required DNS lookups first to get the
> address of a specific server, after which it would attempt to establish the
> tunnel in order to get the error with the server name back. Alternatively,
> based on the service provider's naming conventions and use of IP addresses,
> it might be possible to avoid the initial exchange with the TURN server by
> allowing the client to construct the server name without having to ask (at
> least that's what I hope to do).
> 
> --Brandon
> 
> On 08/22/2014 04:35 AM, Hannes Tschofenig wrote:
> >>> Minor aspects:
> >>> >>
> >>> >>  * Would the TURN server name really be an email alike address
> >>> >>rather than a URI ?
> >> >
> >> >Yes, for more information please refer
> >> >tohttp://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-0
> >> >0
> >> >
> > Thanks. Why do you need the username part for the discovery of the
> > TURN server capabilities? I couldn't find the answer to that question
> > by quickly looking at the TURN server discovery document. Do you
> > expect that the configuration is different from user to user?
> >
> > The procedure seems to be:
> >
> > Client -> TURN server: Establish Tunnel Client <- TURN server: error -
> > here is my "email" alike address
> > (f...@turn.com)
> > Client -> DNS: DNS Lookup (turn.com)
> > Client <- DNS: something domain name back Client -> DNS: NAPTR Client
> > <- DNS: IP address back
> >
> > Is this correct?
> >
> 
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Review of draft-ietf-tram-turn-third-party-authz-01

[Tirumaleswar Reddy (tireddy)]

Hi Hannes,

Please see inline

> -Original Message-
> From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
> Sent: Friday, August 22, 2014 2:06 PM
> To: Tirumaleswar Reddy (tireddy); oauth@ietf.org
> Cc: draft-ietf-tram-turn-third-party-au...@tools.ietf.org;
> gonzalo.camari...@ericsson.com >> Gonzalo Camarillo;
> sperrea...@jive.com; t...@ietf.org
> Subject: Re: Review of draft-ietf-tram-turn-third-party-authz-01
> 
> Hi Tiru,
> 
> ~snip~
> >> * The Design
> >>
> >> I would have used OAuth as is (or maybe selected a specific grant
> >> type) to obtain an access token. Then, I would have defined how the
> >> access token is carried in the TURN protocol. This is a bit similar
> >> what we have already done with the OAuth SASL draft where we defined
> >> a new way to convey the access token from the SASL client to the SASL
> server.
> >>
> >> How did the authors solve that problem? They pretty much did what I
> >> just explained. Since TURN does not use DTLS (or TLS) the
> >> proof-of-possession security work we are doing becomes relevant
> >> (namely the symmetric key- based part).
> >
> > Yes, the communication b/w TURN client and server may or may not use
> > (D)TLS, hence proof-of-possession security work is used.
> 
> I know saw in one of the references that there is a proposal for DTLS.
> In that case you might already want to consider re-using the channel binding
> work as well.

TURN request/response will always be integrity protected independent of whether 
(D)TLS is used or not and the media traffic relayed through the TURN server is 
encrypted (e.g. using DTLS-SRTP) for end-to-end security. Is there need to 
support channel binding ?

> 
> 
> >
> >>
> >> Putting discovery information in-band into the exchange is also find
> >> (which is what we did in the SASL document).
> >>
> >> Instead of using the JWT access token format the authors have defined
> >> a new, binary encoding to keep the size smaller. The OAuth framework
> >> allows other token formats to be used - so that's fine as well.
> >> (As a minor remark, I would use AEAD ciphers here since that's what
> >> everyone is doing noways.)
> >
> > Good point, will update the draft to use AEAD.
> 
> Ok
> 
> >
> >>
> >> Two things surprised me:
> >>
> >> a) The spec leaves the way to obtain the access token pretty much open.
> >> A big benefit from using OAuth is that there is a protocol mechanism
> >> defined for getting the access token. You could, for example,
> >> recommend using authorization code flow. This concerns the text written
> in Section 4.
> >
> > Using authorization code flow is discussed in Section 4 of the draft.
> >
> > 
> >OAuth in [RFC6749] defines four grant types.  This specification uses
> >the OAuth grant type "Implicit" explained in section 1.3.2 of
> >[RFC6749] where the WebRTC client is issued an access token directly.
> > 
> >
> > Are you suggesting that we add more details ?
> 
> I missed that. That's fine.
> 
> >
> >>
> >> b) You describe a key establishment scheme to be used between the
> >> resource server and the authorization server. What assumption do you
> >> make about the relationship between the authorization server and the
> >> resource server? Are they supposed to have a business relationship or
> >> some other relationship with each other ?
> >
> > Authorization and Resource servers could have a business relationship
> > (loosely coupled, for example Enterprise network using TURN server
> > provided by third party provider like Akamai) or could be deployed in
> > the same administrative domain (tightly coupled, for example Google
> > providing both WebRTC and TURN servers)
> 
> I guess you assume that there is some long-term secret (such as asymmetric
> credential) in place and you then derive the symmetric keys from it (by using
> DSKPP). 

Yes

> Maybe you want to say that (in addition to the assumed relationship
> between the two entities). If there is no relationship between the two parties
> then they will certainly be a challenge to get this done securely.

Agreed, will update the draft.

> 
> 
> >
> >>
> >> Minor aspects:
> >>
> >>  * Would the TURN server name really be an email alike address rather
> >> than a URI ?
> >
> > Yes, for more information please refer to
> > http://tools.ietf.org/html/draft-ietf-tram-turn-server-d

Re: [OAUTH-WG] Review of draft-ietf-tram-turn-third-party-authz-01

[Tirumaleswar Reddy (tireddy)]

Hi Hannes,

Thanks for the review. Please see inline

> -Original Message-
> From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
> Sent: Friday, August 22, 2014 12:21 AM
> To: oauth@ietf.org
> Cc: draft-ietf-tram-turn-third-party-au...@tools.ietf.org;
> gonzalo.camari...@ericsson.com >> Gonzalo Camarillo;
> sperrea...@jive.com
> Subject: Review of draft-ietf-tram-turn-third-party-authz-01
> 
> Hi all,
> 
> Simon asked us (Derek and myself) to do a quick review of this document
> developed within another working group that happens to use OAuth.
> 
> * Background
> 
> TURN is a special tunnelling gateway (very much like an IPsec gateway would
> be) but designed specifically to relay voice/video traffic. To prevent 
> attacks a
> TURN client (such as a VoIP phone) uses a shared secret (username &
> password) with the TURN server (=gateway).
> 
> So, if Alice calls Bob and uses a TURN server then her VoIP client uses SIP or
> WebRTC (as a signaling protocol) to establish the necessary communication
> so that voice packets can be exchanged between the two VoIP clients with
> the help of the TURN server.
> 
> The main idea of this document is to re-use OAuth to authorize the use of
> this TURN server.
> 
> * The Design
> 
> I would have used OAuth as is (or maybe selected a specific grant type) to
> obtain an access token. Then, I would have defined how the access token is
> carried in the TURN protocol. This is a bit similar what we have already done
> with the OAuth SASL draft where we defined a new way to convey the access
> token from the SASL client to the SASL server.
> 
> How did the authors solve that problem? They pretty much did what I just
> explained. Since TURN does not use DTLS (or TLS) the proof-of-possession
> security work we are doing becomes relevant (namely the symmetric key-
> based part).

Yes, the communication b/w TURN client and server may or may not use (D)TLS, 
hence 
proof-of-possession security work is used.

> 
> Putting discovery information in-band into the exchange is also find (which is
> what we did in the SASL document).
> 
> Instead of using the JWT access token format the authors have defined a
> new, binary encoding to keep the size smaller. The OAuth framework allows
> other token formats to be used - so that's fine as well.
> (As a minor remark, I would use AEAD ciphers here since that's what
> everyone is doing noways.)

Good point, will update the draft to use AEAD.

> 
> Two things surprised me:
> 
> a) The spec leaves the way to obtain the access token pretty much open.
> A big benefit from using OAuth is that there is a protocol mechanism defined
> for getting the access token. You could, for example, recommend using
> authorization code flow. This concerns the text written in Section 4.

Using authorization code flow is discussed in Section 4 of the draft.


   OAuth in [RFC6749] defines four grant types.  This specification uses
   the OAuth grant type "Implicit" explained in section 1.3.2 of
   [RFC6749] where the WebRTC client is issued an access token directly.


Are you suggesting that we add more details ?

> 
> b) You describe a key establishment scheme to be used between the
> resource server and the authorization server. What assumption do you make
> about the relationship between the authorization server and the resource
> server? Are they supposed to have a business relationship or some other
> relationship with each other ?

Authorization and Resource servers could have a business relationship (loosely 
coupled, for example Enterprise network using TURN server provided by third 
party provider like Akamai) or could be deployed in the same administrative 
domain (tightly coupled, for example Google providing both WebRTC and TURN 
servers)

> 
> Minor aspects:
> 
>  * Would the TURN server name really be an email alike address rather than
> a URI ?

Yes, for more information please refer to 
http://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00

> 
>  * Would you use Dynamic Client Registration to provision the client with the
> necessary parameter? Is there the expectation that random clients would
> work with random authorization servers ?

No, client must authenticate with the authorization server (SIP/WebRTC server) 
to make a call.

> 
>  * Wouldn't you want to define a scope value for use with the TURN service
> so that the authorization server is able to restrict the access token for use
> with TURN only?

The scope value for use with the TURN service is defined in section 4


   The scope of the access token explained in section 3.3 of [RFC6749]
   MUST be TURN.


> 
>  * Crypto algorithm negotiation: would you expect the authorization server to
> tell the client what crypto algorithms to use (since the authorization server
> not only needs to share a key with the resource server but also needs to have
> knowledge about the supported cryptographic algorithms) ?

Currently STUN only uses HMAC-SHA1, hence details about au

Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

[Tirumaleswar Reddy (tireddy)]

Token revocation will require unsolicited update from AS to RS that the token 
is no longer valid, it will be useful to add this communication mechanism in 
this draft.

-Tiru

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, July 30, 2014 6:21 AM
To: Mike Jones; Thomas Broyer
Cc: 
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token 
Introspection" as an OAuth Working Group Item

Not true if I revoke the token after it's been issued but before it expires.

On 7/29/2014 8:49 PM, Mike Jones wrote:
Yes, but that’s the simplest thing to determine – try the token and see whether 
it works or not.

From: Thomas Broyer [mailto:t.bro...@gmail.com]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: ; George Fletcher; Phil Hunt
Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token 
Introspection" as an OAuth Working Group Item


Decoding a token with a specific format wouldn't tell you whether the token is 
still live: it could have been revoked before its expiration.
Le 30 juil. 2014 02:16, "Mike Jones" 
mailto:michael.jo...@microsoft.com>> a écrit :
Did you consider standardizing the access token format within that deployment 
so all the parties that needed to could understand it, rather requiring an 
extra round trip to an introspection endpoint so as to be able to understand 
things about it?

I realize that might or might not be practical in some cases, but I haven’t 
heard that alternative discussed, so I thought I’d bring it up.

I also second Phil’s comment that it would be good to understand the use cases 
that this is intended to solve before embarking on a particular solution path.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On 
Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token 
Introspection" as an OAuth Working Group Item

We also have a use case where the AS is provided by a partner and the RS is 
provided by AOL. Being able to have a standardized way of validating and 
getting data about the token from the AS would make our implementation much 
simpler as we can use the same mechanism for all Authorization Servers and not 
have to implement one off solutions for each AS.

Thanks,
George
On 7/28/14, 8:11 PM, Phil Hunt wrote:
Could we have some discussion on the interop cases?

Is it driven by scenarios where AS and resource are separate domains? Or may 
this be only of interest to specific protocols like UMA?

From a technique principle, the draft is important and sound. I am just not 
there yet on the reasons for an interoperable standard.

Phil

On Jul 28, 2014, at 17:00, Thomas Broyer 
mailto:t.bro...@gmail.com>> wrote:
Yes. This spec is of special interest to the platform we're building for 
http://www.oasis-eu.org/

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
Thomas Broyer
/tɔ.ma.bʁwa.je/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





___

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

[Tirumaleswar Reddy (tireddy)]

+1 support for adoption. This draft is useful for PCP third party authorization 
http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-03, where PCP 
server in the Enterprise network (Resource server) and WebRTC server 
(Authorization server) are in different administrative domains. PCP third party 
authorization is using handle token and need a standard communication mechanism 
b/w RS and AS to validate token. RS and AS are provided by different vendors 
and need interoperability.

-Tiru

> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Monday, July 28, 2014 11:03 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token
> Introspection" as an OAuth Working Group Item
> 
> Hi all,
> 
> during the IETF #90 OAuth WG meeting, there was strong consensus in adopting
> the "OAuth Token Introspection"
> (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG work
> item.
> 
> We would now like to verify the outcome of this call for adoption on the OAuth
> WG mailing list. Here is the link to the document:
> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/
> 
> If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion as to
> the suitability of adopting this document as a WG work item, please send mail 
> to
> the OAuth WG list indicating your opinion (Yes/No).
> 
> The confirmation call for adoption will last until August 10, 2014.  If you 
> have
> issues/edits/comments on the document, please send these comments along to
> the list in your response to this Call for Adoption.
> 
> Ciao
> Hannes & Derek

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth