Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-06.txt

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 21 Jan 2015 05:20:54 +0000

Hi Oleg,

Good point, Modified text in sections 4, 6.1 to be more clear when the client supports both methods

NEW (Section 4):
A STUN client should know the authentication capability of the STUN server before deciding to use third party authorization. A STUN client initially makes a request without any authorization. If the STUN server supports third party authorization, it will return an error message indicating that the client can authorize to the STUN server using OAuth access token. The STUN server includes an ERROR-CODE attribute with a value of 401 (Unauthorized), a nonce value in a NONCE attribute and a SOFTWARE attribute that gives information about the STUN server's software. The STUN servers also includes additional STUN attribute THIRD-PARTY-AUTHORIZATION signaling the STUN client that the STUN server supports third party authorization.

(Section 6.1)
If the client is able to comprehend THIRD-PARTY-AUTHORIZATION it MUST ensure that third party authorization takes precedence over first party authentication (explained in section 10 of RFC 5389). If the client does not support or is not capable of doing third party authorization then it defaults to first party authentication.

Cheers,
-Tiru

From: Oleg Moskalenko [mailto:[email-masked]]
Sent: Wednesday, January 21, 2015 1:03 AM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-06.txt

A new change that I noticed in this draft is that it is making impossible simultaneous support of the original 'legacy' long-term credentials and the new third party credentials in the same server. If the server includes the THIRD-PARTY-AUTHORIZATION attribute in the 401 response, then the client is REQUIRED to provide the new authorization scheme. So, we have a few problems here:
1) This is incompatible with the old clients.
2) If we really do want that change, then we have to make the THIRD-PARTY-AUTHORIZATION attribute comprehension-required. Currently, it is comprehension-optional. With the current scheme, there is a logical mistake: you are allowing the client to ignore the TPA attribute (by making it comprehension-optional) but in the same time you are NOT allowing the client to ignore it (because you are requiring that the third-party authorization to be used). It has to be resolved one way or another.
I'd recommend to rollback to the previous draft because the older draft did not have contradictions and the old draft allowed the server administrators to decide which combination of the authorization schemes they want to deploy.

On Tue, Jan 20, 2015 at 7:55 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Revision http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-06 addresses comments from Spencer.

-Tiru

> -----Original Message-----
> From: tram [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of internet-
> [email-masked]<mailto:[email-masked]>
> Sent: Tuesday, January 20, 2015 9:22 PM
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-06.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the TURN Revised and Modernized Working
> Group of the IETF.
>
>         Title           : Session Traversal Utilities for NAT (STUN) Extension for Third
> Party Authorization
>         Authors         : Tirumaleswar Reddy
>                           Prashanth Patil
>                           Ram Mohan Ravindranath
>                           Justin Uberti
>       Filename        : draft-ietf-tram-turn-third-party-authz-06.txt
>       Pages           : 20
>       Date            : 2015-01-20
>
> Abstract:
>    This document proposes the use of OAuth to obtain and validate
>    ephemeral tokens that can be used for Session Traversal Utilities for
>    NAT (STUN) authentication.  The usage of ephemeral tokens ensure that
>    access to a STUN server can be controlled even if the tokens are
>    compromised.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-06
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-06
>
>
> 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<http://tools.ietf.org>.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> tram mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tram

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

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 20 Jan 2015 22:15:41 -0800

That's great. I agree with the text.

Thanks !
Oleg

On Tue, Jan 20, 2015 at 9:20 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> A STUN client should know the authentication capability of the STUN server
> before deciding to use third party authorization. A STUN client initially
> makes a request without any authorization. If the STUN server supports
> third party authorization, it will return an error message indicating that
> the client can authorize to the STUN server using OAuth access token. The
> STUN server includes an ERROR-CODE attribute with a value of 401
> (Unauthorized), a nonce value in a NONCE attribute and a SOFTWARE attribute
> that gives information about the STUN server's software. The STUN servers
> also includes additional STUN attribute THIRD-PARTY-AUTHORIZATION signaling
> the STUN client that the STUN server supports third party authorization.
>
>
>
> (Section 6.1)
>
> If the client is able to comprehend THIRD-PARTY-AUTHORIZATION it MUST
> ensure that third party authorization takes precedence over first party
> authentication (explained in section 10 of RFC 5389). If the client does
> not support or is not capable of doing third party authorization then it
> defaults to first party authentication.
>
>
>
> Cheers,
>
> -Tiru
>
>
>
> *From:* Oleg Moskalenko [mailto:[email-masked]]
> *Sent:* Wednesday, January 21, 2015 1:03 AM
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* [email-masked]
> *Subject:* Re: [tram] I-D Action:
> draft-ietf-tram-turn-third-party-authz-06.txt
>
>
>
> A new change that I noticed in this draft is that it is making impossible
> simultaneous support of the original 'legacy' long-term credentials and the
> new third party credentials in the same server. If the server includes the
> THIRD-PARTY-AUTHORIZATION attribute in the 401 response, then the client is
> REQUIRED to provide the new authorization scheme. So, we have a few
> problems here:
>
> 2) If we really do want that change, then we have to make the
> THIRD-PARTY-AUTHORIZATION attribute comprehension-required. Currently, it
> is comprehension-optional. With the current scheme, there is a logical
> mistake: you are allowing the client to ignore the TPA attribute (by making
> it comprehension-optional) but in the same time you are NOT allowing the
> client to ignore it (because you are requiring that the third-party
> authorization to be used). It has to be resolved one way or another.
>
> I'd recommend to rollback to the previous draft because the older draft
> did not have contradictions and the old draft allowed the server
> administrators to decide which combination of the authorization schemes
> they want to deploy.
>
>
>
>
>
> On Tue, Jan 20, 2015 at 7:55 AM, Tirumaleswar Reddy (tireddy) <
> [email-masked]> wrote:
>
> Revision
> addresses comments from Spencer.
>
> -Tiru
>
>
> > From: tram [mailto:[email-masked]] On Behalf Of internet-
> > [email-masked]
> > To: [email-masked]
> > Cc: [email-masked]
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > [email-masked]
> [email-masked]