Subject: [pcp] FW: New Version Notification for draft-wing-pcp-third-party-authz-00.txt

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 27 May 2013 05:25:27 +0000

Hi all,

This document describes a third party authorization mechanism to address the REQ-14 in "PCP Auth Requirements" draft. It describes a cryptographic technique for an application server to permit a flow across a firewall.  This technique uses OAuth and a new PCP option.

comments and suggestions are welcome.

Best Regards,
--Authors.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, May 25, 2013 7:58 AM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing (dwing)
Subject: New Version Notification for draft-wing-pcp-third-party-authz-00.txt

A new version of I-D, draft-wing-pcp-third-party-authz-00.txt
has been successfully submitted by Dan Wing and posted to the
IETF repository.

Filename:	 draft-wing-pcp-third-party-authz
Revision:	 00
Title:		 PCP Extension for Third Party Authorization
Creation date:	 2013-05-25
Group:		 Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-00.txt
Status:          http://datatracker.ietf.org/doc/draft-wing-pcp-third-party-authz
Htmlized:        http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-00

Abstract:
   It is often desirable for an application server to permit a flow
   across a firewall, as happens today when a firewall includes an
   Application Layer Gateway (ALG) function.  However, an ALG has
   several weaknesses.

   This document describes a cryptographic technique for an application
   server to permit a flow across a firewall.  This technique uses OAuth
   and a new PCP option.

The IETF Secretariat

---

From: Alper Yegin <[email-masked]>
Date: Tue, 28 May 2013 13:16:54 +0300

Hello Tiru,

Judging from the Figure 3 in the document, if the main objective is to get PCP client and PCP server authenticate each other with the help of a Authorization Server (a trusted third party), let me point out that this is already achieved with both of the EAP-based solutions.

I didn't get under that impression, but in case OAuth is also essential to the solution, then it can be defined as an EAP method and carried over EAP.

Alper

On May 27, 2013, at 8:25 AM, Tirumaleswar Reddy (tireddy) wrote:

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 28 May 2013 11:06:21 +0000

Hi Alper,

Thanks for the comments. Please see inline

> From: Alper Yegin [mailto:[email-masked]]
> Sent: Tuesday, May 28, 2013 3:47 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [email-masked]
> Subject: Re: [pcp] FW: New Version Notification for draft-wing-pcp-third-
> party-authz-00.txt
> 
> Hello Tiru,
> 
> Judging from the Figure 3 in the document, if the main objective is to get PCP
> client and PCP server authenticate each other with the help of a Authorization
> Server (a trusted third party), let me point out that this is already achieved
> with both of the EAP-based solutions.

In addition to Third-party authorization, PCP server needs a mechanism to validate that the PCP client is only requesting the resources permitted to be used by Authorization Server. Various validations that are performed by the PCP server for this use case are mentioned in http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-00#section-5.2

>
> I didn't get under that impression, but in case OAuth is also essential to the
> solution, then it can be defined as an EAP method and carried over EAP.

For the use-case mentioned in the draft, PCP Authentication is optional. The OAuth Handle token provided by the Authorization server is carried in a new PCP ACCESS_TOKEN option in the PCP request.

--Tiru.

> > This document describes a third party authorization mechanism to address the
> REQ-14 in "PCP Auth Requirements" draft. It describes a cryptographic
> technique for an application server to permit a flow across a firewall.  This
> technique uses OAuth and a new PCP option.
> >

---

From: Alper Yegin <[email-masked]>
Date: Tue, 28 May 2013 19:10:40 +0300

Hi Tiru,

> In addition to Third-party authorization, PCP server needs a mechanism to validate that the PCP client is only requesting the resources permitted to be used by Authorization Server. Various validat…

Yes, this is indeed part of what I'm describing.

Typically, EAP is carried over Foo between the xClint and xServer, and over a AAA (Authentication, Authortization, and Accounting) protocol [such as RADIUS, Diameter] between the xServer and the Authorization Server (a AAA server). The AAA protocol takes care of the "authorization", making sure the authenticated Client is only getting the services that it is authorized to use.

> For the use-case mentioned in the draft, PCP Authentication is optional. The OAuth Handle token provided by the Authorization server is carried in a new PCP ACCESS_TOKEN option in the PCP request.

That Token is providing "Client authentication", ensuring that the Token indeed is sent by the claimed identity,
But it'd not be providing data-origin authentication and integrity protection for the rest of the PCP message.
And in the absence of that, any part of the message aside from the Token can be spoofed/modified.

Alper

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 29 May 2013 13:10:37 +0000

> Sent: Tuesday, May 28, 2013 9:41 PM
> Subject: Re: [pcp] New Version Notification for draft-wing-pcp-third-party-
> authz-00.txt
> 
> Hi Tiru,
> 
> > In addition to Third-party authorization, PCP server needs a mechanism to
> validate that the PCP client is only requesting the resources permitted to be
> used by Authorization Server. Various validations that are performed by the
> PCP server for this use case are mentioned in
> http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-00#section-5.2
> >
> 
> Typically, EAP is carried over Foo between the xClint and xServer, and over a
> AAA (Authentication, Authortization, and Accounting) protocol [such as RADIUS,
> Diameter] between the xServer and the Authorization Server (a AAA server). The
> AAA protocol takes care of the "authorization", making sure the authenticated
> Client is only getting the services that it is authorized to use.

In this case PCP server (Resource server) communicates with the Authorization Server (WebRTC Server) to identify if the OAuth Handle token is valid and also identify the resources permitted with the Handle token. In this case the token is provided by the WebRTC server (Application Server) and not AAA. The WebRTC server could may located in a different administrative domain and the resources authorized by it for a specific purpose only.

> > For the use-case mentioned in the draft, PCP Authentication is optional. The
> OAuth Handle token provided by the Authorization server is carried in a new
> PCP ACCESS_TOKEN option in the PCP request.
> >
> 

In the Security Considerations it's already mentioned that PCP authentication needs to be taken into account but is not mandatory. The token is designed such that it is applicable to the user it is assigned to and cannot be used by another party.

Best Regards,
--Tiru.
> >>> To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Reinaldo
> Penno
> >> (repenno); Dan Wing (dwing)
> >>> Status:          http://datatracker.ietf.org/doc/draft-wing-pcp-third-
> party-
> >> authz