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

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 06 Mar 2015 20:00:02 +0100

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 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked] <[email-masked]>

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
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 9 Mar 2015 03:06:07 +0000

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:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Saturday, March 07, 2015 12:30 AM
> To: [email-masked]
> Subject: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?
> 
> Hi all,
> 
> 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
> 
> 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]

---

From: Bill Mills <[email-masked]>
Date: Mon, 9 Mar 2015 04:56:42 +0000 (UTC)

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

     On Sunday, March 8, 2015 8:06 PM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:

 Hi Hannes,

Thanks and Regards,
-Tiru

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 9 Mar 2015 05:24:42 +0000

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:[email-masked]]
Sent: Monday, March 09, 2015 10:27 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; [email-masked]
Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?

Hi Hannes,

Thanks and Regards,
-Tiru

> From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Hannes Tschofenig
> To: [email-masked]<mailto:[email-masked]>
> From: Stephen Farrell <[email-masked]<mailto:[email-masked]>>
> To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
>
>
> Hiya,
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Bill Mills <[email-masked]>
Date: Mon, 9 Mar 2015 05:39:39 +0000 (UTC)

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) <[email-masked]> wrote:

 #yiv3556672566 #yiv3556672566 -- _filtered #yiv3556672566 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv3556672566 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv3556672566 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv3556672566 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv3556672566 #yiv3556672566 p.yiv3556672566MsoNormal, #yiv3556672566 li.yiv3556672566MsoNormal, #yiv3556672566 div.yiv3556672566MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv3556672566 a:link, #yiv3556672566 span.yiv3556672566MsoHyperlink {color:blue;text-decoration:underline;}#yiv3556672566 a:visited, #yiv3556672566 span.yiv3556672566MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv3556672566 span.yiv3556672566EmailStyle17 {color:#1F497D;}#yiv3556672566 .yiv3556672566MsoChpDefault {} _filtered #yiv3556672566 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv3556672566 div.yiv3556672566WordSection1 {}#yiv3556672566 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:[email-masked]]
Sent: Monday, March 09, 2015 10:27 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; [email-masked]
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) <[email-masked]> wrote:    Hi Hannes,

http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01#section-5.3discusses 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.1we 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).

Thanks and Regards,
-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 9 Mar 2015 05:48:48 +0000

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:[email-masked]]
Sent: Monday, March 09, 2015 11:10 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; [email-masked]
Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?

On Sunday, March 8, 2015 10:24 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Bill,

-Tiru

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

On Sunday, March 8, 2015 8:06 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Hannes,

Thanks and Regards,
-Tiru

---

From: Bill Mills <[email-masked]>
Date: Mon, 9 Mar 2015 16:31:57 +0000 (UTC)

If this spec is about providing a single option for doing this as an option that's fine.  If it becomes MTI for using POP tokens at all  think that's a mistake.    OAuth 2 provides a framework and one optional token type, Bearer, which is not MTI.  That's a reasonable thing and would work here. 

     On Sunday, March 8, 2015 10:48 PM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:

 #yiv6169713675 #yiv6169713675 -- _filtered #yiv6169713675 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv6169713675 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv6169713675 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv6169713675 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv6169713675 #yiv6169713675 p.yiv6169713675MsoNormal, #yiv6169713675 li.yiv6169713675MsoNormal, #yiv6169713675 div.yiv6169713675MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv6169713675 a:link, #yiv6169713675 span.yiv6169713675MsoHyperlink {color:blue;text-decoration:underline;}#yiv6169713675 a:visited, #yiv6169713675 span.yiv6169713675MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv6169713675 p.yiv6169713675MsoAcetate, #yiv6169713675 li.yiv6169713675MsoAcetate, #yiv6169713675 div.yiv6169713675MsoAcetate {margin:0in;margin-bottom:.0001pt;font-size:8.0pt;}#yiv6169713675 p.yiv6169713675msonormal, #yiv6169713675 li.yiv6169713675msonormal, #yiv6169713675 div.yiv6169713675msonormal {margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv6169713675 span.yiv6169713675msohyperlink {}#yiv6169713675 span.yiv6169713675msohyperlinkfollowed {}#yiv6169713675 span.yiv6169713675emailstyle17 {}#yiv6169713675 p.yiv6169713675msonormal1, #yiv6169713675 li.yiv6169713675msonormal1, #yiv6169713675 div.yiv6169713675msonormal1 {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv6169713675 span.yiv6169713675msohyperlink1 {color:blue;text-decoration:underline;}#yiv6169713675 span.yiv6169713675msohyperlinkfollowed1 {color:purple;text-decoration:underline;}#yiv6169713675 span.yiv6169713675emailstyle171 {color:#1F497D;}#yiv6169713675 span.yiv6169713675BalloonTextChar {}#yiv6169713675 span.yiv6169713675EmailStyle27 {color:#1F497D;}#yiv6169713675 .yiv6169713675MsoChpDefault {font-size:10.0pt;} _filtered #yiv6169713675 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv6169713675 div.yiv6169713675WordSection1 {}#yiv6169713675 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:[email-masked]]
Sent: Monday, March 09, 2015 11:10 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; [email-masked]
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) <[email-masked]> 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:[email-masked]]
Sent: Monday, March 09, 2015 10:27 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; [email-masked]
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) <[email-masked]> wrote:   Hi Hannes,

Thanks and Regards,
-Tiru