Re: [pcp] Authentication scenarios (was Re: PANA implementatinos to consider)

[Alper Yegin <[e-mail]>]

Hi Margaret,

The simplest solution is to discover security policy along with the IP address of the PCP server.
After that point on, the client-side knows whether to engage authentication or not.

Alper



On Sep 17, 2012, at 3:55 PM, Margaret Wasserman wrote:

> 
> Hi Alper,
> 
> On Sep 17, 2012, at 4:02 AM, Alper Yegin wrote:
>> Few questions:
>> 
>> - Why is there an unauthenticated case? Or, under what real-life scenarios would authentication be necessary? And under what real-life scenarios would authentication be unnecessary? 
>> 
>> - If authentication is optional, is it client's preference to use it, or network's? Would client ever attempt to use it w/o knowing network's preference? Would it bail out if network does not support/use it? 
>> 
>> - Are we talking about optional to use or optional to implement? You mentioned "PCP Server that does not support authentication".
> 
> The scenarios under which authentication is needed are described in the Security Considerations section of the PCP base spec, and are reiterated at the beginning of draft-ietf-pcp-authentiction.
> 
> This authentication mechanism will be both optional to use and optional to implement -- the only mandatory-to-implement security mechanism is the "simple security model" described in the base spec Security Considerations section. The PCP base spec is currently with the IESG, about to be approved as a standards track RFC.  There have been several PCP base spec implementations tested at interop events, and we expect that there will be many PCP implementations that support the base PCP spec and do not support this (optional) authentication mechanism.  
> 
> So, our PCP authentication spec needs to consider the case where a PCP client that implements (and attempts to use) the authentication mechanism is talking to a server that doesn't even implement it.  The client needs to get a clear error in that case, so that it can pass a useful error to the user and/or take appropriate action.
> 
> If we go with a demux approach, the PCP server will receive a packet on the PCP port that appears to contain a PCP version number that isn't implemented by the server.  It would be interesting to know what existing PCP servers do in this case...  If they return a "unsupported version" error to the client, will the error message that is returned contain the version number from the original header sent in the client's request?  Or will it contain the server's highest supported PCP version?  In the latter case, the error would not be returned to the PANA client, it would be returned to the PCP Client (due to the overloading nature of your proposed demux scheme), and we need to explain how the PCP client will distinguish between the PCP server not implementing PANA and a real PCP version mismatch.  It is also quite unfortunate that the PCP Server is likely to log a "version mismatch" error, when that isn't an accurate reflection of what happened.  This type of problem is typical of cases where we overload fields in existing protocols to perform additional functions.
> 
> Margaret
> 
> 
> 
> 
> 
> 
> 
>