Subject: Re: [pcp] PANA implementatinos to consider

From: Alper Yegin <[email-masked]>
Date: Fri, 14 Sep 2012 09:52:19 +0300

Hi Sam,

> 
> 
> hi.
> So, as I mentioned  earlier I'm either in the camp of strongly
> preferring PCP-specific authentication or in the camp of not caring much
> at all.
> 
> I'd kind of like to find out which camp I'm in by the 21st.
> 
> My nervousness is about implementation complexity.

Is that the only one? Or do you have other concerns as well? 

As for the implementation complexity, I don't quite understand why PANA (which is basically EAP over UDP) would ever be more complicated then to-be-designed "EAP over UDP within PCP framework". While I don't see a reason for former being more complicated, I see reasons for seeing the latter being more complicated, as the whole thing now needs to live within another protocol framework (read: format, flow, state machine harmonization between the two).

> I would like to see
> PCP authentication be something that can easily be implemented with
> open-source libraries. I know how to do that if we use an EAP library
> directly.

Would there be any difference between PANA and EAPoverUDP/PCP when it comes to using EAP libraries? I don't think so.

Alper

> I've managed projects doing something quite similar and I
> understand the implementation complexity.
> 
> Would people familiar with PANA implementation be willing to suggest
> which implementation I should look at? I'd prefer to look at one, but if
> there's disagreement I'd be happy to look at two.
> I'm sure you've done your analysis on this point but I'll feel more
> comfortable if I do my own.
> 
> I'll be happy to share my conclusions as I suspect that there are other
> WG participants who care about implementation complexity.
> 
> If there are open-source PCP servers I'd be happy to glance at those
> just to see how things like memory management, event loop and state
> management line up.
> 
> --Sam
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 14 Sep 2012 05:50:07 -0400

Hi Alper,

> As for the implementation complexity, I don't quite understand why PANA (which is basically EAP over UDP) would ever be more complicated then to-be-designed "EAP over UDP within PCP framework". Whi…

I don't understand how you get away from coupling PANA and PCP, even in the demultiplexing case where they run side-by-side on the same port.  I think a number of details are being glossed over in your latest document when you refer to a need for an "API" between PANA and PCP...

Let's start with a simple case where the PCP Client wants to initiate and authenticated PCP request...

The Client needs to ask the PANA Client to initiate authentication.  How?  Will that request include any details about the mapping request that is being made?  i.e. will the PANA Client be asking for authentication _and authorization_ to perform a particular action?  Or do we assume that a PCP client is authenticated via PANA, and that authorization for a particular action is a separate step that is performed as part of PCP?  If they are separate, do we need a new set of PCP error codes for the situation where an authenticated PCP client performs an unauthorized action, or is that already covered in the PCP spec?

When the PCP Client asks the PANA Client to perform authentication, what are the possible results that can be returned from that request, and how are they communicated back to the PCP Client?  You have only described the success case in your document.

How does this work in the case where the PCP Server is not running a PANA Server?  I _think_ that if a PCP Client asks its PANA Client to perform authentication, and the PCP Server does support authentication, some sort of "unsupported version" error code will be returned to the _PCP Client_ (due to the details of your proposed demultiplexing scheme), and that nothing will be returned to the PANA Client, at all.  We would need to make sure that secure PCP clients are specified to handle an "unsupported version" error differently when the PANA Client is in this particular state, but how does the PCP Client know that this is why that error was returned?  If this does happen, how does the PCP client inform the PANA Client that it should stop trying to perform authentication with that particular PCP Server?  

Also, how does the PCP Client know when the _PCP Server_ is ready to receive its request?  Are we assuming that the PANA Server will not return an indication to the PANA Client that the client has been authenticated until _after_ it has provisioned the necessary SA on the PANA Server?  

What if an additional application on the same PCP Client system wants to perform an authenticated request with the same PCP Server in the meantime?  Will that second request result in a second (interleaved) PANA negotiation, or will the PCP Client be told that a PANA negotiation is already pending?  If the latter, how will the second PCP Client thread by informed when the PANA negotiation has completed?  (Note:  The right answer here depends heavily on whether the PANA authentication depends, in any way, on the contents of a specific PCP request -- the authentication vs. authentication/authorization question above).

All of these questions will need to be answered, IMO, in a full specification of the PCP/PANA demultiplexing mechanism, precisely _because_ PCP and PANA are running separately.  The "API" is where this coupling is provided between the two "state machines", as you refer to them.  Why is this any simpler if PANA and PCP are running side-by side than if we run PANA encapsulated in PCP?  (or, if we run PCP directly over EAP, for that matter)

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 14 Sep 2012 05:54:45 -0400

I made one important typo here that I should fix:

On Sep 14, 2012, at 5:50 AM, Margaret Wasserman wrote:
> 
> How does this work in the case where the PCP Server is not running a PANA Server?  I _think_ that if a PCP Client asks its PANA Client to perform authentication, and the PCP Server does support authentication, some sort of "unsupported version" error code will be returned to the _PCP Client_ (due to the details of your proposed

s/PCP Server does support authentication/PCP Server _doesn't_ support authentication

> demultiplexing scheme), and that nothing will be returned to the PANA Client, at all.  We would need to make sure that secure PCP clients are specified to handle an "unsupported version" error differently when the PANA Client is in this particular state, but how does the PCP Client know that this is why that error was returned?  If this does happen, how does the PCP client inform the PANA Client that it should stop trying to perform authentication with that particular PCP Server?  

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 14 Sep 2012 05:58:13 -0400

And another typo that I should clarify (sorry, it's early here...  :-)):

> Also, how does the PCP Client know when the _PCP Server_ is ready to receive its request?  Are we assuming that the PANA Server will not return an indication to the PANA Client that the client has…

s/SA on the PANA Server/SA on the PCP Server

Margaret

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 14 Sep 2012 22:22:35 +0900

Hi Margaret,

I agree that there is a room to specify more details in the pana-pcp
draft to address your comments.  In general some interactions are
needed between an "AKM (Authentication and Key Management) function"
and the base PCP funtion.

On the other hand, if my understanding is correct, the needed set of
interactions between an AKM function and the base PCP functions are
not much different regardless of whether the AKM function is PANA or
PCP-specific, and therefore I think the interactions do not have to be
considered as a disadvantage of PANA-based approaches.

Please correct me if my understanding is wrong.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 14 Sep 2012 16:38:17 +0300

Hi Margaret,

Your below questions are implementation specific. 
Let me answer them to describe how this can be implemented in one way. Certainly there are other ways to implement them.

> I don't understand how you get away from coupling PANA and PCP, even in the demultiplexing case where they run side-by-side on the same port.  I think a number of details are being glossed over in your latest document when you refer to a need for an "API" between PANA and PCP…
> 

Association or binding of state between PANA and PCP is common on both.
But there are different degrees of "coupling". Or where you couple them. Are we coupling the state generated/maintained between the two, or are we coupling the protocols themselves.

You could say, a host configures a care-of address using DHCP, and uses that IP address with Mobile IP, hence DHCP and Mobile IP are coupled.
Or, you could invent carrying DHCP over Mobile IP, and call that coupling too.

Another more relevant example: Running IKE for IPsec, or running IKE over IPsec (however you do it).

> The Client needs to ask the PANA Client to initiate authentication.  How?  

PCP software triggers the PaC to perform authentication. 
Like how IKE gets triggered when IPsec SA needs to be setup.

> Will that request include any details about the mapping request that is being made?  i.e. will the PANA Client be asking for authentication _and authorization_ to perform a particular action?  Or do we assume that a PCP client is authenticated via PANA, and that authorization for a particular action is a separate step that is performed as part of PCP?  If they are separate, do we need a new set of PCP error codes for the situation where an authenticated PCP client performs an unauthorized action, or is that already covered in the PCP spec?

That trigger I mentioned above will include two pieces of information: 1. Indication that this is an auth/authz for PCP, 2. IP address of the PAA (which is same as the PCP server).

> When the PCP Client asks the PANA Client to perform authentication, what are the possible results that can be returned from that request, and how are they communicated back to the PCP Client?  You…

PANA already generates success and failure results. This result will be conveyed to the PCP client via the API.
If the result is success, also the PCP_AUTH_KEY and PANA Session ID and PANA Key ID need to be passed via that interface. 

> How does this work in the case where the PCP Server is not running a PANA Server?  I _think_ that if a PCP Client asks its PANA Client to perform authentication, and the PCP Server does support aut…

I'd like to first understand how the client-side decides when to use authentication, and when not to?
Can you, or someone, explain that? Once I understand the scenarios we are trying to cover, I can come back and answer your question.

> Also, how does the PCP Client know when the _PCP Server_ is ready to receive its request?  Are we assuming that the PANA Server will not return an indication to the PANA Client that the client has…

The order of events is:

1. PANA is executed
2. PaC provides the results to the PCP client
3. PCP client contacts PCP server, using  authentication tag generated with the SA from step 2.
4. Upon encountering new SA, PCP server contacts the PAA to obtain the matching parameters (or, the PAA had already pushed those params to PCP server after 1. These are different implementation choices…..)

> What if an additional application on the same PCP Client system wants to perform an authenticated request with the same PCP Server in the meantime?  Will that second request result in a second (int…

Second API call can be told that there is already an ongoing authentication and wait for the result.
Or, maybe it says "OK" but does not generate a second PANA session because the same PANA session (or, more specifically the security association generated by it) can be used with both PCP requests.

> All of these questions will need to be answered, IMO, in a full specification of the PCP/PANA demultiplexing mechanism, precisely _because_ PCP and PANA are running separately.  

Errr, I don't think so. None of these are impacting the over-the-wire behavior (i.e., the "protocol"), but they are all about implementation -- not something we need to put in the protocol specs. 

If we were to use EAP over PCP, do you think we need to define how EAP methods interface with EAP which interfaces with PCP. How one triggers the other and gets the results back. I don't think so. 

> The "API" is where this coupling is provided between the two "state machines", as you refer to them.  Why is this any simpler if PANA and PCP are running side-by side than if we run PANA encapsulated in PCP?  (or, if we run PCP directly over EAP, for that matter)
> 

Please see the top part about my "coupling" response. 

If you run two protocols side by side, you point how one can trigger the other. And ideally, triggers target meaningful states. E.g., one protocol triggers other to run, and at the end of execution the result is returned (PCP triggers PANA to execute).
If you run one protocol inside another, then you have to nest their state machines, and unless you are purely lucky, that cannot work automatically w/o aligning their state machines. (Like I said, PANA state machine is designed the way it is in accordance with the EAP state machine.)

Alper

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 14 Sep 2012 13:54:48 +0000

I've been following this discussion and my preference would be to avoid
having a design that requires a 'control protocol' between PCP and
something else. We should reuse other IETF standards whenever possible but
I would prefer everything to be part of a single protocol. Having a
separate protocol would mean significant more test and effort for
productization due to interactions, new CLIs, unforeseen state machine
issues, etc. 

We will certainly even face all kinds of backward/forward compatibility
issues between PCP, PANA (as an example) and whatever control protocol
will run between them due to different features and evolution timeline.

Although one can argue that PCP and PANA will run together as one entity
the next step would be somebody asking for them to be decoupled and able
to run anywhere. This train is never late.

-----Original Message-----
From: Alper Yegin <[email-masked]>
Date: Fri, 14 Sep 2012 16:38:17 +0300
To: Margaret Wasserman <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [pcp] PANA implementatinos to consider

>Let me answer them to describe how this can be implemented in one way.
>Certainly there are other ways to implement them.
>
>> 
>>> As for the implementation complexity, I don't quite understand why
>>>PANA (which is basically EAP over UDP) would ever be more complicated
>>>then to-be-designed "EAP over UDP within PCP framework". While I don't
>>>see a reason for former being more complicated, I see reasons for
>>>seeing the latter being more complicated, as the whole thing now needs
>>>to live within another protocol framework (read: format, flow, state
>>>machine harmonization between the two).
>> 
>> I don't understand how you get away from coupling PANA and PCP, even in
>>the demultiplexing case where they run side-by-side on the same port.  I
>>think a number of details are being glossed over in your latest document
>>when you refer to a need for an "API" between PANA and PCPŠ
>> 
>
>But there are different degrees of "coupling". Or where you couple them.
>Are we coupling the state generated/maintained between the two, or are we
>coupling the protocols themselves.
>
>You could say, a host configures a care-of address using DHCP, and uses
>that IP address with Mobile IP, hence DHCP and Mobile IP are coupled.
>> Will that request include any details about the mapping request that is
>>being made?  i.e. will the PANA Client be asking for authentication _and
>>authorization_ to perform a particular action?  Or do we assume that a
>>PCP client is authenticated via PANA, and that authorization for a
>>particular action is a separate step that is performed as part of PCP?
>>If they are separate, do we need a new set of PCP error codes for the
>>situation where an authenticated PCP client performs an unauthorized
>>action, or is that already covered in the PCP spec?
>
>
>That trigger I mentioned above will include two pieces of information: 1.
>Indication that this is an auth/authz for PCP, 2. IP address of the PAA
>(which is same as the PCP server).
>
>
>> When the PCP Client asks the PANA Client to perform authentication,
>>what are the possible results that can be returned from that request,
>>and how are they communicated back to the PCP Client?  You have only
>>described the success case in your document.
>
>If the result is success, also the PCP_AUTH_KEY and PANA Session ID and
>PANA Key ID need to be passed via that interface.
>
>
>
>> 
>> How does this work in the case where the PCP Server is not running a
>>PANA Server?  I _think_ that if a PCP Client asks its PANA Client to
>>perform authentication, and the PCP Server does support authentication,
>>some sort of "unsupported version" error code will be returned to the
>>_PCP Client_ (due to the details of your proposed demultiplexing
>>scheme), and that nothing will be returned to the PANA Client, at all.
>>We would need to make sure that secure PCP clients are specified to
>>handle an "unsupported version" error differently when the PANA Client
>>is in this particular state, but how does the PCP Client know that this
>>is why that error was returned?  If this does happen, how does the PCP
>>client inform the PANA Client that it should stop trying to perform
>>authentication with that particular PCP Server?
>> 
>
>Can you, or someone, explain that? Once I understand the scenarios we are
>trying to cover, I can come back and answer your question.
>
>
>> Also, how does the PCP Client know when the _PCP Server_ is ready to
>>receive its request?  Are we assuming that the PANA Server will not
>>return an indication to the PANA Client that the client has been
>>authenticated until _after_ it has provisioned the necessary SA on the
>>PANA Server?  
>> 
>
>The order of events is:
>
>1. PANA is executed
>4. Upon encountering new SA, PCP server contacts the PAA to obtain the
>matching parameters (or, the PAA had already pushed those params to PCP
>server after 1. These are different implementation choicesŠ..)
>
>
>
>> What if an additional application on the same PCP Client system wants
>>to perform an authenticated request with the same PCP Server in the
>>meantime?  Will that second request result in a second (interleaved)
>>PANA negotiation, or will the PCP Client be told that a PANA negotiation
>>is already pending?  If the latter, how will the second PCP Client
>>thread by informed when the PANA negotiation has completed?  (Note:  The
>>right answer here depends heavily on whether the PANA authentication
>>depends, in any way, on the contents of a specific PCP request -- the
>>authentication vs. authentication/authorization question above).
>> 
>
>Or, maybe it says "OK" but does not generate a second PANA session
>because the same PANA session (or, more specifically the security
>association generated by it) can be used with both PCP requests.
>
>
>> All of these questions will need to be answered, IMO, in a full
>>specification of the PCP/PANA demultiplexing mechanism, precisely
>>_because_ PCP and PANA are running separately.
>
>Errr, I don't think so. None of these are impacting the over-the-wire
>behavior (i.e., the "protocol"), but they are all about implementation --
>not something we need to put in the protocol specs.
>
>
>If we were to use EAP over PCP, do you think we need to define how EAP
>methods interface with EAP which interfaces with PCP. How one triggers
>the other and gets the results back. I don't think so.
>
>
>
>> The "API" is where this coupling is provided between the two "state
>>machines", as you refer to them.  Why is this any simpler if PANA and
>>PCP are running side-by side than if we run PANA encapsulated in PCP?
>>(or, if we run PCP directly over EAP, for that matter)
>> 
>
>
>If you run two protocols side by side, you point how one can trigger the
>other. And ideally, triggers target meaningful states. E.g., one protocol
>triggers other to run, and at the end of execution the result is returned
>(PCP triggers PANA to execute).
>If you run one protocol inside another, then you have to nest their state
>machines, and unless you are purely lucky, that cannot work automatically
>w/o aligning their state machines. (Like I said, PANA state machine is
>designed the way it is in accordance with the EAP state machine.)
>
>Alper
>
>
>
>
>
>
>
>
>
>
>> Margaret
>> 
>> 
>

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 14 Sep 2012 09:58:02 -0400

Hi Yoshi,

> considered as a disadvantage of PANA-based approaches.

I agree with you -- the need for integration of the authentication and PCP functions is effectively the same in all of the approaches we've considered.  I was responding to Alper's assertion that this sort of integration was not needed in the side-by-side (or demux) approach.

There are some things (like how we handle authentication requests to PCP Servers that don't implement PANA) that will work better in either encapsulation approach than in the demux approach.  There are other things (like the need to check that the fields in the PCP header match corresponding fields in the PANA packet that are specific to the PANA encapsulation approach).  And there are other issues (like the need to respecify and re-implement some functions already included in PANA) that will be specific to a PCP-Specific approach.  These are the things that the WG needs to understand and decide between, IMO.  To understand these things, we need to understand each of the PANA-based approaches in more detail than is currently documented.

Margaret

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 14 Sep 2012 15:59:27 +0200

+1 all I have seen so far is very complex for simple authentication of pcp. Let's embed it into pcp.

Cheers,
Wim
_________________
sent from blackberry

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 14 Sep 2012 23:19:23 +0900

Hi Margaret,

We can work out in details on the needed interactions, but my point is
that this does not mean that we cannot decide on one approach until
the interactions are fully defined, especially because they are common
to all approaches.  We can work out details after we agree on one
approach.

Yoshihiro Ohba

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 14 Sep 2012 10:26:34 -0400

Hi Yoshi,

> to all approaches.  We can work out details after we agree on one

I agree.  We only really need to fully understand what the key differences are between the different approaches, right now, so we can make an informed choice.

I continue to believe, as I said in Vancouver, that _all_ of the approaches we are discussing are reasonable approaches that _will work_.  They all use the same underlying security mechanism (EAP), and they are far more alike than different because of that.  We just have to decide which way of using EAP is best for our needs, and fully specify it.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 14 Sep 2012 10:54:15 -0400

> Can you, or someone, explain that? Once I understand the scenarios we are trying to cover, I can come back and answer your question.

There are two cases we have considered where PCP clients may send authenticated PCP requests:

(1) Cases where the client sends an unauthenticated request and is told that authentication is required, so it retries with an authenticated request.  

(2) Cases where the client initially attempts to send an authenticated request.

In the first case, the PCP Server will (we hope :-)) not return the "authentication required" error if it doesn't actually support authentication.  But, in the second case, a client may try to send an authenticated request to a PCP Server that does not support authentication.  Obviously, an error will result, be we want to be certain that the error can be properly detected and returned to the user, so that the user can understand what went wrong.

Margaret

---

From: Alper Yegin <[email-masked]>
Date: Mon, 17 Sep 2012 11:02:26 +0300

> In the first case, the PCP Server will (we hope :-)) not return the "authentication required" error if it doesn't actually support authentication.  But, in the second case, a client may try to send…

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".

Thanks.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 17 Sep 2012 11:31:46 +0300

> +1 all I have seen so far is very complex for simple authentication of pcp. Let's embed it into pcp.

It does not get simplified because you put one inside the other. In fact, it gets more complicated. Please see below.

> I would prefer everything to be part of a single protocol.

This is so un-IETF to me. Here we have two distinct pieces of work (PCP and key management), that can be satisfied using two protocols, we are talking about cobbling them together. 
Like that was done in the PPP-era, and like it's done in GTP (of 3GPP). Lot of pain with both...
I'd understand how other SDOs would think that way, but their priorities are different. But for IETF, we design protocols, and cobbling up protocols unnecessarily gets in the way of modularity, which is very essential to IETF. Right?

More on this below...

> Having a

Just the opposite. 
Inventing new EAP-over-UDP as part of PCP is a brand-new design with brand-new code. PANA is a standard with multiple interoperating implementations. 
It's obviously more stable then the to-be-designed EAP-over-UDP/PCP. 

State machines is one of the issues with cobbling up protocols. Two separate protocols, living side by side, the state machines have nothing to conflict.

If you put on inside the other, then problems arise.

Specifically in this case: The direction of PCP flow and EAP flow are just the opposite. PCP is host-side driven req/rsp. EAP is network-side driven req/rsp. So, now PCP state machine has to change to support that too. And, EAP can generate asynchronous requests at any time from the network side (re-authentication). Exact same issue that we had with the EAP-over-DHCP (in fact this whole discussion has the same pattern….)

And I have yet to hear someone saying yes EAP-over-PCP satisfies the EAP lower layer requirements. I had raised this issue 3 times, and don't see anyone doing the work. It's not as simple as defining a container to ship EAP payloads back and forth. 

> will run between them due to different features and evolution timeline.

Again, situation is the opposite. 
Having them separate will allow them to evolve independently. 
Adding new features to a revision or extension of PANA is better than adding it to N different protocols which chose to embed equivalent of PANA.

> to run anywhere. This train is never late.

They are running separately. They are de-coupled as "protocols". What we are coupling is the "state" generated/used by PANA and PCP.
This decoupling is a feature for "protocols", not a bug. Using state generated from one protocol in another is a "architecture design" or "implementation".

Alper

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 17 Sep 2012 12:05:53 +0200

I have a different perspective and the pains you listed in PPP/GTP from an implementation are very straightfwd and implemented by many people so far. I don't see the difficulties you highlight. Can you please indicate what is the issue with them as I am not getting it?

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: maandag 17 september 2012 10:32
To: Henderickx, Wim (Wim)
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: Side-by-side or nested protocols (was Re: [pcp] PANA implementatinos to consider)

More on this below...

Just the opposite. 

Specifically in this case: The direction of PCP flow and EAP flow are just the opposite. PCP is host-side driven req/rsp. EAP is network-side driven req/rsp. So, now PCP state machine has to change to support that too. And, EAP can generate asynchronous requests at any time from the network side (re-authentication). Exact same issue that we had with the EAP-over-DHCP (in fact this whole discussion has the same pattern..)

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 17 Sep 2012 08:55:49 -0400

Hi Alper,

> - 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

---

From: Alper Yegin <[email-masked]>
Date: Mon, 17 Sep 2012 17:16:30 +0300

Hi Wim,

> I have a different perspective and the pains you listed in PPP/GTP from an implementation are very straightfwd and implemented by many people so far. I don't see the difficulties you highlight. Can…

Both PPP and GTP, even though each is called a "protocol", are in fact more like "a collection of protocols that are bundled up inside another protocol".
One mother protocol, whose main or ancillary role is to encapsulate multiple protocols for multiple tasks.
PPP/GTP perform things like encapsulation, data-path setup, mobility management, QoS, configuration management, authentication, so on and so forth.
Single "protocol" doing all, sounds mind boggling, right?
In fact, each of these tasks call for a dedicated protocol. And in fact each is handled by a child protocol inside the mother protocol.

PPP is a legacy protocol from dial-up era. It also made its way into 3GPP2 due to lack of alternatives at that time.
In both cases, over the time limitation of this "all in one" design got in the way in different ways, and both architectures moved/moving away from PPP. 
Instead, each essential need is now being performed by a dedicated "protocol" in the latest specs. 

GTP, on the other hand, seems to be firmly lodged in the 3GPP architecture. Not only because of its technical merits, but other business reasons.
In fact, many attempts were made by folks, backed by IETF work, to replace GTP with separate standalone protocols, but that didn't work so far.

So, the direction and pressure is to move away from such bundling approaches (for the very reasons I've been writing about). 

There was even an attempt to go back in that "PPP" way when people proposed to bundled up EAP with DHCP, that didn't fly in IETF. (It'd have flew in other SDOs if they had the power -- again, it's a different ball game here and there).

Alper

---

From: Sam Hartman <[email-masked]>
Date: Mon, 17 Sep 2012 10:51:11 -0400

>> +1 all I have seen so far is very complex for simple
    >> authentication of pcp. Let's embed it into pcp.
    >> 

    >> 
    >> I've been following this discussion and my preference would be to
    >> avoid having a design that requires a 'control protocol' between
    >> PCP and something else. We should reuse other IETF standards
    >> whenever possible but I would prefer everything to be part of a
    >> single protocol.

    Alper> This is so un-IETF to me. Here we have two distinct pieces of
    Alper> work (PCP and key management), that can be satisfied using
    Alper> two protocols, we are talking about cobbling them together.
    Alper> Like that was done in the PPP-era, and like it's done in GTP
    Alper> (of 3GPP). Lot of pain with both...  I'd understand how other
    Alper> SDOs would think that way, but their priorities are
    Alper> different. But for IETF, we design protocols, and cobbling up
    Alper> protocols unnecessarily gets in the way of modularity, which
    Alper> is very essential to IETF. Right?

Hi.
I haven't been working in the internet area that long, but I have been
working in the security area of the IETF and following the apps area's
security for a while.
I think  I have some experience with what's ietf and un-ietf in those
contexts.

There are two related questions here:

1) To what extent should security frameworks be re-used.

2) Whether key management should run in-band with the managed protocol.

Both of these issues have been hotly discussed.  There was actually an
IAB document--I think draft-iab-authmech or similar--that tried to rule
out any stacking of frameworks.  For example you could not use GSS-API
within SASL or EAP within PANA in a context where both were appropriate.
This generated rather a lot of comment, and it doesn't look like that
document was ever published as an RFC in part because the IAB was having
trouble getting consensus around the strong negative statements against
frameworks.

While I think that document went too far, the general concerns about
protocol layering it raised are real.  Additional protocol layers does
add all the forms of complexity that Wim discusses.  If you get re-use
of code or re-use of platform infrastructure then it can be worth that
additional complexity.  If you get re-use of security analysis then it
can be worth the complexity.

The question of in-band vs out-of-band has also been a hot question in
the security area. The most recent huge instance of that discussion I'm
aware of was the KARP working group.
Many security participants were arguing that tight integration of key
management into routing protocols would ease security analysis and make
it much more likely that we got things right.
In that instance, the  implementor community for the routing protocols
said that tight integration (in-bind) was an unacceptable implementation
strategy for reasons specific to the routing protocols.

Really, there are a lot of factors to consider; let me give you a few
examples.

Many applications have decided that authentication needs to be tightly
integrated but that confidentiality and integrity should be re-used from
TLS at arms length. These include IMAP, SMTP, LDAP, POP, XMPP and
HTTP. Several of these have a seldom-used but sometimes important
facility to more tightly integrate confidentiality and integrity. All
protocols are run in-band with encapsulation.

Ssh designed ssh-specific protocols for everything and runs everything
in-band.

IPsec uses an out-of-band separate key-management protocol.

Network access uses EAP often as a out-of-band key management protocol
with a separate security association protocol.

    >> Having a separate protocol would mean significant more test and
    >> effort for productization due to interactions, new CLIs,
    >> unforeseen state machine issues, etc.

    Alper> Just the opposite.  Inventing new EAP-over-UDP as part of PCP
    Alper> is a brand-new design with brand-new code. PANA is a standard
    Alper> with multiple interoperating implementations.  It's obviously
    Alper> more stable then the to-be-designed EAP-over-UDP/PCP.

I actually agree with Wim.
I've seen a lot of complexity gluing protocols together.
Even given that I do tend to be a fan of security frameworks, but I have
to admit that there are huge costs.
If there is not a strong value proposition in terms of new capabilities
users get, it may not be worth it.

    Alper> State machines is one of the issues with cobbling up
    Alper> protocols. Two separate protocols, living side by side, the
    Alper> state machines have nothing to conflict.

    Alper> If you put on inside the other, then problems arise.

Actually,  state machine alignment simply gets messy.
As you point out you need to deal with the fact that the direction is
different for PCP and EAP.

However, in the demultiplexing case, we also have state machine issues.
On the client, the state machine now needs to wait while authentication
is happening.
That is we're introducing a waiting-for-PANA state into the PCP client.

Also, I've seen complex interactions between protocol state machines in
distributed systems.  The first time I ran into state machine issues was
a distributed filesystem protocol called AFS. There were two very
modular protocols, one for metadata access and one for accessing files.
Unfortunately, they could interact with each other and delays in the
metadata protocol could cause ever-increasing delays in the file service
protocol.

That was far more painful to debug than a single integrated protocol
would have been.

    Alper> And I have yet to hear someone saying yes EAP-over-PCP
    Alper> satisfies the EAP lower layer requirements. I had raised this
    Alper> issue 3 times, and don't see anyone doing the work. It's not
    Alper> as simple as defining a container to ship EAP payloads back
    Alper> and forth.

We've made a specific proposal that we believe satisfies the
requirements of an EAP lower layer.  We'd certainly appreciate your
technical comments on that proposal.  If we missed something please let
us know.

---

From: Alper Yegin <[email-masked]>
Date: Mon, 17 Sep 2012 18:01:35 +0300

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

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 17 Sep 2012 15:09:59 +0000

-----Original Message-----
From: Alper Yegin <[email-masked]>
Date: Mon, 17 Sep 2012 11:31:46 +0300
To: "Henderickx, Wim (Wim)" <[email-masked]>
Cc: Reinaldo Penno <[email-masked]>, "[email-masked]'"
<[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Side-by-side or nested protocols (was Re: [pcp] PANA
implementatinos to consider)

>It does not get simplified because you put one inside the other. In fact,
>it gets more complicated. Please see below.
>
>> 
>This is so un-IETF to me. Here we have two distinct pieces of work (PCP
>and key management), that can be satisfied using two protocols, we are
>talking about cobbling them together.
>I'd understand how other SDOs would think that way, but their priorities
>are different. But for IETF, we design protocols, and cobbling up
>protocols unnecessarily gets in the way of modularity, which is very
>essential to IETF. Right?
>
>More on this below...
>
>
>> Having a
>Inventing new EAP-over-UDP as part of PCP is a brand-new design with
>brand-new code. PANA is a standard with multiple interoperating
>implementations. 

I posit that the effort to productize PANA or a yet to be defined
EAP-over-UDP (or something else) is almost the same. Unless the vendor
that is implementing
PCP Server has PANA in production but I'm not aware of any.

> 
>
>State machines is one of the issues with cobbling up protocols. Two
>separate protocols, living side by side, the state machines have nothing
>to conflict.

Conflict is not the right word. You are low balling this issue. Synching
two state machines that depend on each other can be tricky.

>
>Specifically in this case: The direction of PCP flow and EAP flow are
>just the opposite. PCP is host-side driven req/rsp. EAP is network-side
>driven req/rsp. So, now PCP state machine has to change to support that
>too. And, EAP can generate asynchronous requests at any time from the
>network side (re-authentication). Exact same issue that we had with the
>EAP-over-DHCP (in fact this whole discussion has the same pattern....)

PCP is capable of sending unsolicited messages (both multicast and
unicast). So, we are good here.

>
>And I have yet to hear someone saying yes EAP-over-PCP satisfies the EAP
>lower layer requirements. I had raised this issue 3 times, and don't see
>anyone doing the work. It's not as simple as defining a container to ship
>EAP payloads back and forth.
>
>
>> 

If PANA (and PANA<->PCP) are not there then this is a non-issue. Moreover,
If PANA is an integral part of PCP 'feature' then if PANA evolves, that
means PCP feature needs to be fully tested, regressed, etc.

> 
>Adding new features to a revision or extension of PANA is better than
>adding it to N different protocols which chose to embed equivalent of
>PANA.
>

The final solution with a PCP specific method might look different than
PANA.

>They are running separately. They are de-coupled as "protocols". What we
>are coupling is the "state" generated/used by PANA and PCP.
>This decoupling is a feature for "protocols", not a bug. Using state
>generated from one protocol in another is a "architecture design" or
>"implementation".

You are missing the point here. The implementation complexity of your
proposal is considerable because you will have:

- PANA 
- PCP
- PANA <-> PCP protocol

But a case in point: I have experience with H.248Ia and Diameter-like to
do session control through NATs. Something similar to what we are trying
to achieve. Parallel to H.248 we had an authentication protocol. Dealing
with those two state machines was complex and can not be ignored.

>>> Or, you could invent carrying DHCP over Mobile IP, and call that
>>>coupling
>>> too.
>>> 
>>> Another more relevant example: Running IKE for IPsec, or running IKE
>>>over
>>> IPsec (however you do it).
>>> 
>>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 18 Sep 2012 08:14:58 +0900

Both PANA and PCP have well defined state machines, and those help 
defining interactions between PCP and PANA state machines in the same 
as interactions between EAP and PANA, and PCP and PANA can evolve 
independently as long as the interactions do not change.
Or am I missing something?

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Tue, 18 Sep 2012 09:58:03 +0300

> within SASL or EAP within PANA in a context where both were appropriate.

That's an odd thing. EAP needs a lower-layer to get transported, as defined in RFC 3748. It's not going to fly on its own.

> trouble getting consensus around the strong negative statements against

What's a "framework"? 

> add all the forms of complexity that Wim discusses.  

I'm confused. It is the EAP-over-PCP that's creating the additional layering, not PANA.
It's carrying equivalent of PANA over PCP (layering!) vs using PANA and PCP side-by-side.

> If you get re-use

Again, I'm confused. With PANA, you get re-use of spec, implementation, security analysis. 
Which one of these do you get with yet-to-be specified EAP-over-PCP?

> strategy for reasons specific to the routing protocols.

I'm not surprised at all. Embedding a protocol inside another is never a drag-and-drop activity.

> protocols are run in-band with encapsulation.

To have more clarity, we need to use more specific terms, such as end-point authentication, data origin authentication (integrity+replay protection), data confidentiality. 

With the mention of TLS, let me note that there are three distinct approaches:

1. Transport layer security (e.g., TLS)
TLS encapsulates the subject protocol
End-point auth, data origin auth, data confidentiality provided by TLS

2. Separate key management (e.g., IKE, EAP transports)
End-point authentication provided by the key management protocol
Data origin auth, data confidentiality provided by subject protocol using the keys from the key management protocol.

3. All-in-one (e.g., PPP, EAP-over-PCP)
End-point auth, data origin auth, data confidentiality provided by the subject protocol. 

> That is we're introducing a waiting-for-PANA state into the PCP client.

Is this an "issue"?

> technical comments on that proposal.  If we missed something please let

I'll spin off a separate thread for this one.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 18 Sep 2012 10:30:07 +0300

Hi Reinaldo,

> PCP Server has PANA in production but I'm not aware of any.

So, if I the vendor do not have the protocol implemented in front of me, it makes sense to go back to square one and design my own wheel, get it through IETF standardization (spend lot of engineering cycles), get  it interop'ed, get it open-source implemented. Does this make sense?

But more interestingly, you said you are not aware of any PANA implementations in production.
As we said before, PANA is adopted into Zigbee Smart Energy Profile 2.0
And it passed several interop events, with 10 implementations.
Are you sure you don't have it in Cisco platforms?

> two state machines that depend on each other can be tricky.

Yes, it could be tricky, if we had a funky relationship between the two protocols. But in this case, it's a clean separation. PCP needs keys to run, it triggers PANA to generate the keys, PANA does its job and gives back the keys, PCP runs with the keys. This is how separate "key management" works. Natural fit.

But, if we embed one protocol inside the other, then you have to combine the state machines. And that combining is not a simple jump back and forth like in the above case. More specifically, within the PCP state machine, now you have to account for server-side retransmissions, server-side asynchronous requests, etc.

> unicast). So, we are good here.

You are referring to "announcements" right?
They are one-way notifications.
What you need is a server-initiated, multi-round-trip req/rsp exchanges -- to have a working EAP lower-layer.

> means PCP feature needs to be fully tested, regressed, etc.

When an enhancement is identified to the "end-point authentication and key management" aspect, then PANA gets revised/extended.
PANA revision/extension gets tested, you be done with it. 

If you go with EAP-over-PCP approach, then you gotta test both the EAP-over-PCP and the whole PCP as well. Since they are well-integrated (not isolated like above), you have to make sure you didn't mess up PCP. (Depending on the type of change, we probably also need to revise/extend/test PANA for its other use as well.)

OK, this is simple modular design, protocol re-use, and their benefits.

> The final solution with a PCP specific method might look different than

How much? It's going to carry EAP, it's going to carry it over UDP, it's going to be a EAP lower-layer. Where's the delta?

> proposal is considerable because you will have:

The interaction between the PANA and PCP is not governed by a protocol, but an API. They are on the same stack.

With PANA, you need to deal with how two protocols implemented on the same stack interacts.
With EAP-over-PCP, you need to deal with how two separate parts of the same protocol interact with each other.
How you implement these depend on your implementation environment.
I personally don't see an issue here that'd justify the re-invention of the wheel for IETF and causing complexity for PCP design and implementation.

Cheers,

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 18 Sep 2012 11:40:54 +0300

I went back to reading your draft again.

I gotta tell you, it felt like reading PANA! 
Most of the design is direct adaptation of PANA design.
Earlier version of the I-D had softly acknowledged that:

   Some of the ideas in this document were adopted from PANA[RFC5191].

Interestingly, this statement disappeared in the latest doc.
"Some" is a major understatement btw.

The most striking difference between PANA and your design is in the terminology, and making it (look like) part of PCP.

But actually, on that last note, this does not look like PCP at all either.

PCP is a host-driven req/rsp protocol, plus server-side one-way notifications. That dictates its state machine.

Your design includes:
- client side one way message (PCC-Initiation)
- server-driven req/rsp
- one-way acks (PA-Ack) from client, wedged into req/rsp sequence

This is so different than PCP. Forcing the base PCP protocol to have a state machine to support both its native needs and this new "extension" is not trivial. 

If you folks revert the terminology back to PANA's, we can be done :-)

Alper

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Tue, 18 Sep 2012 09:35:11 +0000

Hi, Alper:

I am not surprised that you have  that feeling. If you could check the discussion during the IETF 83 in Paris, we have clarified the PCP based authentication mechanism adopted the idea of PANA (but only the useful part). Also, in that meeting, people started discussing whether we need an integrated or an separated authentication mechanism. I think the most important problem we are discussing now is whether we need to use PCP or PANA to transport EAP, right?

Please refer to the following link for more information: http://www.ietf.org/mail-archive/web/pcp/current/msg01930.html

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: Tuesday, September 18, 2012 4:41 PM
To: Sam Hartman
Cc: [email-masked]'
Subject: [pcp] EAP-over-PCP

Your design includes:

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 18 Sep 2012 06:29:44 -0400

Hi Alper,

> Which one of these do you get with yet-to-be specified EAP-over-PCP?

Just to clarify -- you only get "implementation re-use" if you are able to use an existing PANA implementation on your platform.  That would require that the existing implementations:

- exist
- integrate well with your PCP implementation
- support the features that you require

People should read the long message that Sam Hartman sent to the list about existing PANA implementations, and make their own determination about whether one of the existing PANA implementations would work for them.  Two issues that are important here, IMO, are: 

- whether PANA brings in more complexity than is needed in the PCP case, because it is designed for the (more complex) network access case.
- whether the limitations of the existing PANA implementations (i.e. limited EAP methods support) are acceptable for PCP

If you won't be able to reuse an existing PANA implementation, then the "implementation re-use" benefit doesn't exist.

I don't understand how we can re-use the security analysis, since the PCP case is very different from a network access case.  In fact, the security requirements for PCP are very unusual, and quite specific to PCP.

Code reuse is also very desirable.  In any of our proposed cases, we could get code-reuse for the EAP portion on systems that use 802.11 security mechanisms or use EAP for other reasons. It is potentially possible that you could get additional code-reuse in the PANA case, if systems end up using PANA for more than one purpose.  Right now, though, there isn't much overlap between the types of systems that use PANA and the types of systems that are likely to use PCP.

None of this reuse is valuable at all, though (again, IMO), if it presents the user with an unintegrated experience and/or results in a hard-to-support or hard-to-maintain product.  Running two different protocols side-by-side and trying to present them as a single function to end-users and administrators presents various system design challenges that need to be weighed against the complexity of performing in-band PCP key management.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 18 Sep 2012 06:50:25 -0400

Hi Alper,

> And it passed several interop events, with 10 implementations.

Do you actually think that any nodes that implement SEP 2.0 will implement PCP?

[For those unfamiliar with Zigbee SEP 2.0, it is one of the standards (the only IP-based one, I think) proposed for use in the Smart Grid, specifically for appliances, sensors and other embedded devices to integrate with a home energy management system (EMS) and/or electric meter (Smart Meter) on the in-home side of the Smart Energy universe.  Implementations of SEP 2.0 are most often provided in ASICs, for integration into embedded devices with very limited system requirements.  These devices run on a dedicated Zigbee networks within the home, and do not generally communicate outside the home, at all.]

> Yes, it could be tricky, if we had a funky relationship between the two protocols. But in this case, it's a clean separation. PCP needs keys to run, it triggers PANA to generate the keys, PANA does…

The success case in the side-by-side approach appears to work very smoothly, it is the error cases that I am more concerned about.  Also, you haven't explained how you would deal with all of the things you list below...  If PCP has a simple request/response API with PANA, how are things like "asynchronous requests" handled in that model?  What is an "asynchronous request" in this context and when/why would it happen, BTW?  I understand that, in PANA, it is possible for network access to be renegotiated, or for Ip addresses to be reallocated.  There is no equivalent notion in PCP, though.

> But, if we embed one protocol inside the other, then you have to combine the state machines. And that combining is not a simple jump back and forth like in the above case. More specifically, within…

You keep claiming that there will be problems with "combining the state machines" of PCP and PANA in the encapsulation case that aren't there in the side-by-side case, but I'm still not sure what you mean by this.  Could you give a concrete example?

> What you need is a server-initiated, multi-round-trip req/rsp exchanges -- to have a working EAP lower-layer.

How do we get this in a model that you have described as:  "PCP needs keys to run, it triggers PANA to generate the keys, PANA does its job and gives back the keys, PCP runs with the keys. "  Won't this notion (of server-initiated messages) need to be integrated into the API between PCP and PANA somehow?  When would these messages ever happen in the PCP context?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 18 Sep 2012 07:12:22 -0400

On Sep 18, 2012, at 4:40 AM, Alper Yegin wrote:
> Interestingly, this statement disappeared in the latest doc

Um, the latest doc describes two solutions, one of which _is_ PANA (encapsulated in PCP), so it would seem a bit strange to claim the ideas were "adapted from" PANA...

> If you folks revert the terminology back to PANA's, we can be done :-)

Both mechanisms described in the current draft are encapsulation mechanisms, and I was under the impression that you were arguing that a demultiplexing (side-by-side) mechanism was substantially preferable...  Am I missing something?

The PCP-Specific mechanism is very similar to an encapsulated PANA mechanism with certain specific differences:

- It is a simplified protocol, because it doesn't need to handle things like address reallocation that are specific to the Network Access case.
- It is fully integrated with the PCP header, so there are no overlapping fields that need to be check for consistency, etc.

So, if we re-titled our initial PCP-Specific proposal to be called "Simplified PANA Authentication for PCP", would that resolve all of your concerns?

I don't have a strong personal preference between these two approaches, because they aren't very different.  If we do end-up defining an encapsulated PANA mechanism, our draft will need to describe what subset of PANA needs to be implemented/supported for use with PCP, and it will need to explain how to consistency-check the PANA packet against fields in the PCP header.  So, we'll end up with a protocol that uses (a subset of) PANA and requires a bit more run-time processing and a few more error cases than a PCP-Specific solution (for the consistency checking), but one that is otherwise very similar.

As I have said over and over, all of these solutions have far more in common (conceptually, functionally and even in the bits they will send on the wire) than their differences.

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Sep 2012 09:05:05 -0400

Hi, Alper.
Thanks for your review.
We're glad that we were able in your eyes to successfully re-use a lot
of the work that went into PANA design.
We really appreciated being able to look at previous lower-layer work
including PANA and draft-ietf-abfab-gss-eap to make our job easier.

If the WG believes terminology realignment would be beneficial here,
then we can work towards that goal.

I'd appreciate comments from PCP implementors on the state machine
integration issue that Alper brings up.

Depending on what's easy for PCP implementations we have a number of
options.

In RFC 3748  the conversation is conceptually server driven.
However, there is typically a client (lower layer) indication to get
things started.

However, the only reason that the conversation is server-driven iss
retransmissions. If you take a look at section 2 of RFC 3748 you note
that the protocol is lockstep. The server cannot send a new request
until the client has responded to the previous one.  If you take a look
at section 4.3, a lower layer may sent the retransmission timeout to
infinite. In this mode, the server will never generate an unsolicited
request.
So, it's entirely possible to  view things as a client-server protocol
with client-driven retransmissions if that makes things easier for PCP
implementations.

That's the approach we took in draft-ietf-abfab-gss-eap. That spec is an
approved EAP lower layer in the RFC editor queue. That spec treats EAP
as a simple lock-step client-server protocol. We lose a half round trip
because we ask the server to get started and it then asks us for our
identity. We came up with mechanisms for including our identity in the
first request, trimming a half round trip. The decision of that working
group was that the complexity was not worth it, but that optimization is
available if it helps with PCP.

so, feedback from people with PCP state machines would be really helpful
about which of these issues matter to you.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 19 Sep 2012 00:21:15 +0900

Margaret,

> Do you actually think that any nodes that implement SEP 2.0 will
implement PCP?

Yes.  A home EMS that is part of SEP2.0 may implement PCP client for
its external broadband connections.  Since a home EMS is a typically a
constrained device, it would be a burden to implement two different
protocols both carrying EAP over UDP.  By using PANA over PCP, such a
device can significantly benefit from code-sharing to carry EAP over
UDP for network access authentication inside 802.15.4 HAN and for
doing PCP for broadband connections.  This also shows why re-inventing
the wheel is a bad idea.

Regards,
Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 19 Sep 2012 10:30:18 +0300

Margaret,

> Um, the latest doc describes two solutions, one of which _is_ PANA (encapsulated in PCP), so it would seem a bit strange to claim the ideas were "adapted from" PANA...

The above statement, which existed in the previous version of the doc, is referring to EAP-over-PCP design. It's that design that's adopted from PANA, and that's still in the document.

> Both mechanisms described in the current draft are encapsulation mechanisms, and I was under the impression that you were arguing that a demultiplexing (side-by-side) mechanism was substantially pr…

Yes, that's what I'm arguing.

> - It is a simplified protocol, because it doesn't need to handle things like address reallocation that are specific to the Network Access case.

Address reallocation as supported by PANA base spec is nothing more than the PAA conveying a configuration parameter using a single bit. 
If that bit is not needed for PCP, then we just say it's not used for PCP. 

> - It is fully integrated with the PCP header, so there are no overlapping fields that need to be check for consistency, etc.

Yes, using the PCP header. But that's all when it comes to "integration into PCP" (plus the common terminology, which is editorial). Otherwise, pcp-auth is a totally different protocol with its new messages, flow, state machine.

PANA-based solution is allocating three bits out of its reserved bits for PCP use for the sake using operating on the same port.
(Honestly, I don't know why PANA and PCP must operate on the same port. If someone can explain, I'd appreciate. Is it for saving ports? For firewall traversal? For some misconception about "binding"? At any rate, current solution is trivial, but I'm curious why people chose the "same port".)

> So, if we re-titled our initial PCP-Specific proposal to be called "Simplified PANA Authentication for PCP", would that resolve all of your concerns?

My point is, 
- EAP-over-PCP design is not fundamentally PCP-based (using the same terminology and header, but anything else is different -- more essential things like the messages, flows, state machine). So, it's a cosmetic similarity.
- in it's essence, it's PANA. 
- So, why re-invent the wheel.

If you can identify the parts of PANA that appears to be extra, we can discuss if they are really not needed, and how we can go about not using them.
So far, this "IP address reconfig" is mentioned and it's a trivial feature that's easy not to use.   

> I don't have a strong personal preference between these two approaches, because they aren't very different.  If we do end-up defining an encapsulated PANA mechanism, our draft will need to describe what subset of PANA needs to be implemented/supported for use with PCP, and it will need to explain how to consistency-check the PANA packet against fields in the PCP header.  

We already described the use of those now-assigned three bits in the I-D.

> So, we'll end up with a protocol that uses (a subset of) PANA and requires a bit more run-time processing and a few more error cases than a PCP-Specific solution (for the consistency checking), but one that is otherwise very similar.
> 

Because EAP-over-PCP is re-invented PANA. Not in the vacuum, but specifically importing the design from PANA. As much as we are humbled about this, we are still wondering why not use PANA instead of creating a cosmetically-changed clone.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Wed, 19 Sep 2012 10:39:40 +0300

Hi Sam,

> with client-driven retransmissions if that makes things easier for PCP

I don't understand how this works.
EAP authenticator performs rexmits. 
So, if it does not get a response, it'll keep rexmitting. So, how can you achieve "server will never generate an unsolicited request"?

And, furthermore, there'd be EAP re-authentication which can be initiated by the client or server. This is another reason for having to support server-side requests.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Wed, 19 Sep 2012 10:57:37 +0300

Hi Margaret,
> Do you actually think that any nodes that implement SEP 2.0 will implement PCP?

First, let's recognize different types of "re-use":
- spec re-use
- source code re-use
- binary re-use

Your question is specifically about the last one.  I think the answer to the first two are clear, and that by itself goes a long way.

Even binary re-use is a possibility, like Yoshi explained, and also considering the possibility of integrated gateways.

> The success case in the side-by-side approach appears to work very smoothly, it is the error cases that I am more concerned about.  

Which specific error cases? You raised one about auth capability mismatch and I already responded to that.

> Also, you haven't explained how you would deal with all of the things you list below...  If PCP has a simple request/response API with PANA, how are things like "asynchronous requests" handled in that model?  What is an "asynchronous request" in this context and when/why would it happen, BTW?  I understand that, in PANA, it is possible for network access to be renegotiated, or for Ip addresses to be reallocated.  There is no equivalent notion in PCP, though.
> 

EAP re-authentication can be initiated by either party at any time. We need to support that.

> You keep claiming that there will be problems with "combining the state machines" of PCP and PANA in the encapsulation case that aren't there in the side-by-side case, but I'm still not sure what y…

Please see my email with EAP-over-PCP subject line. As you see, the state machines and flows of PCP and EAP-over-PCP are not compatible. If you try to fit the latter into the former, it won't work -- incompatible. Exact same issue with EAP-over-DHCP. I (naively?) assumed you'd not want to impact the PCP design hence this compatibility issue is a problem. 

> How do we get this in a model that you have described as:  "PCP needs keys to run, it triggers PANA to generate the keys, PANA does its job and gives back the keys, PCP runs with the keys. "  Won't…

Whether the client-side or the server-side initiated the re-auth, EAP/PANA is executed and new security association is generated. The new parameters are stored in the data structures where the PCP client picks them up next time it needs to send a request. 

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 19 Sep 2012 06:06:28 -0400

Hi Alper,

> So, if it does not get a response, it'll keep rexmitting. So, how can you achieve "server will never generate an unsolicited request"?

A retransmission is not an unsolicited request...  I'm not sure what you mean by this.

> And, furthermore, there'd be EAP re-authentication which can be initiated by the client or server. This is another reason for having to support server-side requests.

Why do you think that we need to support EAP re-authentication? 

Margaret

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 19 Sep 2012 12:03:18 +0000

-----Original Message-----
From: Alper Yegin <[email-masked]>
Date: Wed, 19 Sep 2012 10:57:37 +0300
To: Margaret Wasserman <[email-masked]>
Cc: Reinaldo Penno <[email-masked]>, "Henderickx, Wim (Wim)"
<[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Side-by-side or nested protocols (was Re: [pcp] PANA
implementatinos to consider)

>Your question is specifically about the last one.  I think the answer to
>the first two are clear, and that by itself goes a long way.

I do not think it is clear. The devices implementing PCP Server (routers,
FW, CGNs, CPEs, etc) will most likely not be able to reuse source code
from Zigbee. There are threading considerations, 64 vs. 32 bit, memory
management, configuration, events. The list goes on and on. My experience
with protocol code reuse between such different platforms is not very rosy.

>
>Even binary re-use is a possibility, like Yoshi explained, and also
>considering the possibility of integrated gateways.

Like getting PANA binary from Zigbee and running on a CGN, CPE/High end
Firewall running on a different NPU type without rewriting almost from
scratch, recompilation, integration with CLI, debug, etc ? Please excuse
my skepticism when I doubt this. But to be fair, please point me to your
best candidate for this reuse and I will see if we can look into it if WG
thinks it will help the process.

>
>
>> [For those unfamiliar with Zigbee SEP 2.0, it is one of the standards
>>(the only IP-based one, I think) proposed for use in the Smart Grid,
>>specifically for appliances, sensors and other embedded devices to
>>integrate with a home energy management system (EMS) and/or electric
>>meter (Smart Meter) on the in-home side of the Smart Energy universe.
>>Implementations of SEP 2.0 are most often provided in ASICs, for
>>integration into embedded devices with very limited system requirements.
>> These devices run on a dedicated Zigbee networks within the home, and
>>do not generally communicate outside the home, at all.]
>> 
>>> Yes, it could be tricky, if we had a funky relationship between the
>>>two protocols. But in this case, it's a clean separation. PCP needs
>>>keys to run, it triggers PANA to generate the keys, PANA does its job
>>>and gives back the keys, PCP runs with the keys. This is how separate
>>>"key management" works. Natural fit.
>> 
>> The success case in the side-by-side approach appears to work very
>>smoothly, it is the error cases that I am more concerned about.
>
>> Also, you haven't explained how you would deal with all of the things
>>you list below...  If PCP has a simple request/response API with PANA,
>>how are things like "asynchronous requests" handled in that model?  What
>>is an "asynchronous request" in this context and when/why would it
>>happen, BTW?  I understand that, in PANA, it is possible for network
>>access to be renegotiated, or for Ip addresses to be reallocated.  There
>>is no equivalent notion in PCP, though.
>> 
>
>>> But, if we embed one protocol inside the other, then you have to
>>>combine the state machines. And that combining is not a simple jump
>>>back and forth like in the above case. More specifically, within the
>>>PCP state machine, now you have to account for server-side
>>>retransmissions, server-side asynchronous requests, etc.
>> 
>> You keep claiming that there will be problems with "combining the state
>>machines" of PCP and PANA in the encapsulation case that aren't there in
>>the side-by-side case, but I'm still not sure what you mean by this.
>>Could you give a concrete example?
>
>Please see my email with EAP-over-PCP subject line. As you see, the state
>machines and flows of PCP and EAP-over-PCP are not compatible. If you try
>to fit the latter into the former, it won't work -- incompatible. Exact
>same issue with EAP-over-DHCP. I (naively?) assumed you'd not want to
>impact the PCP design hence this compatibility issue is a problem.
>
>
>> 
>>> What you need is a server-initiated, multi-round-trip req/rsp
>>>exchanges -- to have a working EAP lower-layer.
>> 
>> How do we get this in a model that you have described as:  "PCP needs
>>keys to run, it triggers PANA to generate the keys, PANA does its job
>>and gives back the keys, PCP runs with the keys. "  Won't this notion
>>(of server-initiated messages) need to be integrated into the API
>>between PCP and PANA somehow?  When would these messages ever happen in
>>the PCP context?
>> 
>
>Whether the client-side or the server-side initiated the re-auth,
>EAP/PANA is executed and new security association is generated. The new
>parameters are stored in the data structures where the PCP client picks
>them up next time it needs to send a request.
>
>Alper
>
>
>
>
>
>> Margaret
>> 
>> 
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 19 Sep 2012 09:53:55 -0400

>>>>> "Alper" == Alper Yegin <[email-masked]> writes:

    >> Depending on what's easy for PCP implementations we have a number
    >> of options.
    >> 
    >> However, there is typically a client (lower layer) indication to
    >> get things started.
    >> 
    >> However, the only reason that the conversation is server-driven
    >> iss retransmissions. If you take a look at section 2 of RFC 3748
    >> you note that the protocol is lockstep. The server cannot send a
    >> new request until the client has responded to the previous one.
    >> If you take a look at section 4.3, a lower layer may sent the
    >> retransmission timeout to infinite. In this mode, the server will
    >> never generate an unsolicited request.  So, it's entirely
    >> possible to view things as a client-server protocol with
    >> client-driven retransmissions if that makes things easier for PCP
    >> implementations.
    >> 

Alper>I don't understand how this works.
    Alper> EAP authenticator performs rexmits.  So, if it does not get a
    Alper> response, it'll keep rexmitting. So, how can you achieve
    Alper> "server will never generate an unsolicited request"?

There are three aspects to this: why does it work in practice, why does
it comply with the spec, and why do I think  it's been reviewed
adequately to suggest it?

For the first, EAP libraries tend to have a way to ignore  retransmits
or set the retransmission timeout to infinite.
Consider what happens in an AAA server. There, your EAP server cannot
(and is not supposed to) handle retransmits.
RADIUS at least is a lock-step protocol. Ignoring things like COA, a
RADIUS server cannot send an unsolicited response to a client.
So any EAP server library basically has to have a way to disable
retransmits.
I guess it's possible that you could have a passthrough authenticator
library that doesn't pull this off.
IN practice we've not run into this problem; see below for why.

Also, as I understand it (without close reading) the IKEv2 EAP support
works this way as well.

So, why does it comply with the spec?
Take a look at RFC 3748 section 4.3. That section points out a lower
layer can set the retransmit timeout to infinite if it is reliable
itself.

Why do I think the whole idea of assuming you'll never get an
unsolicited server request has been adequately reviewed? It's part of
draft-ietf-abfab-gss-eap, which has already been approved and is waiting
publication. I've personally walked through what we were doing with
Bernard; I know Joe is familiar with the work enough that he understands
our state machine constraints. Klaas is one of the chairs; he also has a
lot of EAP experience. Josh Howlett, my co-author has many more years of
EAP experience than I do.  So, I believe that this idea has received
adequate review that if I were somehow misreading the base EAP spec we
would have noticed it.

    Alper> And, furthermore, there'd be EAP re-authentication which can
    Alper> be initiated by the client or server. This is another reason
    Alper> for having to support server-side requests.

I'm not entirely sure what you're talking about when you say EAP
re-authentication.
Do you mean the EAP re-authentication protocol (the one done in HOKEY?)
The base EAP spec mentions re-authentication once or twice  but does not
define it.
My best reading of that text is that they simply mean there can be later
EAP conversations if you want to access a new resource or the like, or
the network wants to re-key, or prove fresh access to tokens or
whatever.

When you look at the peer state machine in RFC 4137, you note that the
success state is a final state.
It's going to require lower layer interactions to get out of that state.
If you look at the commen open-source supplicants (all I have access to)
you see that tends to be how people implement things.
You expect a disassociation or something else to trigger new
authentication.
And when that happens, yes, depending on who's doing the trigger and
what's going on, the first *EAP* message may be from the server.

In our proposal, PCP is the same way.  A server can throw away a session
and give a client an error that they must authenticate again if it wants
an EAP exchange.  This is intended to deal with wanting to expire
sessions or servers that lose state.  However it also deals with a
server wanting to confirm freshness, or getting a re-authentication
demand via some complex AAA infrastructure that seems unlikely to be
used with PCP in practice.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 19 Sep 2012 23:46:47 +0900

(2012/09/19 21:03), Reinaldo Penno (repenno) wrote:
(snip)
> thinks it will help the process.

I suggest taking a look at the open source implementations that I
pointed and Sam analyzed, and send comments to this list as Sam did.
You would have some points, and your comments will be valuable to
improve the quality of the open source implementations,

Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Wed, 19 Sep 2012 11:44:36 -0400

Yoshihiro> I suggest taking a look at the open source
    Yoshihiro> implementations that I pointed and Sam analyzed, and send
    Yoshihiro> comments to this list as Sam did.  You would have some
    Yoshihiro> points, and your comments will be valuable to improve the
    Yoshihiro> quality of the open source implementations,

I couldn't agree more.
We've had a lot of discussion, but ultimately  we need to hear more from
PCP implementors.

---

From: Alper Yegin <[email-masked]>
Date: Thu, 20 Sep 2012 11:48:45 +0300

Hi Reinaldo,

> with protocol code reuse between such different platforms is not very rosy.

There may be platforms that cannot share the same code. Yes, I acknowledge that.
But, that's not the norm, but an exception.

> thinks it will help the process.

I was referring to "integrated gateways". Broadband modem implementing Zigbee as well. 
They are on the same platform.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 20 Sep 2012 12:01:43 +0300

> A retransmission is not an unsolicited request...  I'm not sure what you mean by this.

If the EAP authenticator does not receive a response on time, it'd re-xmit the EAP request.
Which in turn will be transmitted by the PCP server to the PCP client.
That transmission is not "solicited by the PCP client".

> Why do you think that we need to support EAP re-authentication? 

EAP re-authentication is one of the EAP events, and any EAP lower-layer has to support that.
Otherwise, what? Your sessions have infinite lifetime? Authorization never changes? Never need to re-key? Never need to challenge the end-point again?
These are the things that call for "re-authenticaiton", and why EAP has that, and why EAP lower-layers need to support that.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 20 Sep 2012 12:38:50 +0300

> or set the retransmission timeout to infinite.

You mean the "EAP layer"? 

  When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as
   within [PIC]), the authenticator retransmission timer SHOULD be set
   to an infinite value, so that retransmissions do not occur at the EAP
   layer. 

Only when run over a reliable EAP lower layer, the EAP layer sets the timeout to infinity.
So, whether the rexmit is handled by the EAP layer, or the EAP lower layer, the PCP server will be sending retransmissions in your case.

> RADIUS at least is a lock-step protocol. Ignoring things like COA,

Ah, "ignoring CoA". CoA is the RADIUS' tool to generate an unsolicited message, more specifically for starting EAP re-authentication.
So, let's not ignore that.

> a

Rexmit is the responsibility of the "EAP passthru authenticator".

> layer can set the retransmit timeout to infinite if it is reliable

True. But see my explanations above.

> adequate review that if I were somehow misreading the base EAP spec we

Sam, you are claiming "it's entirely possible to view things as a client-server protocol with client-driven retransmissions if that makes things easier for PCP implementations."
I don't see how it works from your technical explanations here. 
You are referring to a past work, which I was not involved. Unless I go back and read that spec, and email archives, I cannot know why/how/what happened, and if it's applicable to here.

So, why don't you just explain us how it'd work, better yet show us on your document.

Bottom line is, 
EAP is server driven.
PCP is client driven. 
How do you stack them up against each other?

> Do you mean the EAP re-authentication protocol (the one done in HOKEY?)

No, not that. That's just an optimized re-authentication.
Re-authentication is executing EAP again.

> the network wants to re-key, or prove fresh access to tokens or

You got it.

> You expect a disassociation or something else to trigger new

You want service continuity. So, you don't use disassociation. EAP re-authentication is performed while the existing EAP session is still good and other layers are still using the unexpired security association.

> what's going on, the first *EAP* message may be from the server.

There you go.

> used with PCP in practice.

First of all, this is not in your document. 
Secondly, this is a bad design. As soon as the network side decides to re-auth, it's should be able to do so. It shouldn't have to wait for the client to make the next contact.

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 20 Sep 2012 06:28:21 -0400

Hi Alper,

> So, let's not ignore that.

Have you answered my question about why you think EAP re-authentication is needed for PCP, or even applies to PCP?  This is an optional part of EAP, and it's my understanding that it isn't widely used...  

Also if you do support re-authentication (after telling me what it would mean for PCP), how do you avoid exposing this paradigm to PCP, regardless of the which of the three you use?  It is no more aligned with a request-response protocol for an API to wake it up asynchronously and do re-authentication than it is for that to happen in a PCP message.

This _could_ be an argument for not using EAP, I suppose, but I don't think there has been much dissent about using an EAP-based mechanism.  I certainly don't see why we couldn't make the same simplifying assumptions in PCP that are made in GSS-EAP.  If using PANA will stand in the way of that, maybe that's a reason not to use PANA?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 20 Sep 2012 07:09:16 -0400

Hi Alper,

> These are the things that call for "re-authenticaiton", and why EAP has that, and why EAP lower-layers need to support that.

Sorry, I didn't see this response before I asked the question again...

EAP re-authentication is an optional extension to EAP -- it isn't part of the base EAP spec.  I understand why it is useful, in general, but it is not inherently part of EAP.  It has always been possible to start EAP over again from the beginning to do a new round of authentication, and that can be done periodically, as desired.  In other words, support for EAP re-authentication is not required to support re-keying or non-infinite lifetimes.

_Because_ PCP is a request/response protocol, it would be possible for either end to periodically throw away the existing authentication information for a peer, and perform/request a new round of authentication for the next request.  EAP re-authentication is not necessary for that purpose and, in fact, wouldn't be all that useful for that purpose with PCP -- we wouldn't want "sessions" to attempt to re-key repeatedly if there were no requests being sent back and forth, would we?  Please remember that PCP is a UDP request/response protocol, and the server may keep mappings open long after the client computers have gone home...  So, there is no hard concept of a PCP "session" that has a specific session lifetime.  Authentication may be required (in secure deployments) to create a mapping, but there is no notion that an authenticated session has to remain active for the mapping to remain in place for it's indicated lifetime.  In fact, it would be undesirable to create such a dependency, especially in the THIRD_PARTY/proxy case, because we would not want to create a situation where communication between two other nodes depends on the reliability/reachability of the PCP proxy.

You have asserted several times that EAP lower layers need to support retransmission and reauthentication, and Sam has asserted several times that they do not.  How do we resolve this disagreement?

Sam has pointed to an example of a recently approved EAP lower layer (more recent than PANA), gss-eap, that is simpler than PANA, supports a request/response model similar to PCP, and does not include those things.  So, it does not seem that the IETF (either the security area, or the IESG) currently enforces the rules that you are asserting.  Can you point to an RFC or some other reference that indicates that support for these things is required?  Or is it just your opinion that it is desirable to support these things for PCP?  If so, could you explain what benefits PCP would get from supporting them?

Could you perhaps look at gss-eap and consider whether a similar model could apply to PCP?  Would it be possible to achieve a similar model using PANA?  If so, what updates would be need to the PANA specification in order to do that?

Margaret

---

From: Alper Yegin <[email-masked]>
Date: Thu, 20 Sep 2012 15:44:47 +0300

> EAP re-authentication is an optional extension to EAP -- it isn't part of the base EAP spec.  

It's not an extension, it's not an option.
It's merely executing EAP again, whether initiated by the EAP peer or the EAP authenticator -- for the reasons Sam and I listed before (rekeying, reautz, etc).

What it means for the EAP lower layer is that it shall be able to transport unsolicited payloads from each side, including the server-side. Which you are lacking right now. And I suspect you are resisting that addition because EAP-o-PCP would look even less like PCP once you add that.

> I understand why it is useful, in general, but it is not inherently part of EAP.

Running EAP again, or n-times, is naturally part of EAP. 
EAP initiation on the server side is the "EAP standard".

>  It has always been possible to start EAP over again from the beginning to do a new round of authentication, and that can be done periodically, as desired.  

Yes, that's right. Also realize that this can be initiated by the client side or the network side. That's all I'm saying.

> In other words, support for EAP re-authentication is not required to support re-keying or non-infinite lifetimes.
> 

Confusing, what's that mean now? Once you perform re-auth, you get new keys and a new lifetime. Getting fresh keys and extending the lifetime are two of the reasons for performing re-auth.

> _Because_ PCP is a request/response protocol, it would be possible for either end to periodically throw away the existing authentication information for a peer, and perform/request a new round of authentication for the next request.  

How does the "server" side do that? That's the question. You need to define a message that can be transmitted from the server side to initiate re-auth.
It's not rocket science. It's doable. Just define it in EAP-o-PCP. I'm saying you are missing it. (but, I'm also saying your EAP-o-PCP is totally different than PCP).

> EAP re-authentication is not necessary for that purpose and, in fact, wouldn't be all that useful for that purpose with PCP -- we wouldn't want "sessions" to attempt to re-key repeatedly if there were no requests being sent back and forth, would we?  

EAP, and in fact any authenticated session, always comes with a finite lifetime. Even if you were sitting idle, you need to re-auth and extend the lifetime sometime before the current lifetime expires. Gotta do that.

> Please remember that PCP is a UDP request/response protocol, and the server may keep mappings open long after the client computers have gone home...  So, there is no hard concept of a PCP "session" that has a specific session lifetime.  

Really??? I hope not. If a client disappears, is your NAT/firewall going to keep the state "forever"? 

> Authentication may be required (in secure deployments) to create a mapping, but there is no notion that an authenticated session has to remain active for the mapping to remain in place for it's indicated lifetime.  

That's right. But next time a PCP message needs to be sent/received related to a session, there better be a live SA. If there is no live SA, then one needs to "re-auth!" to get a live one.

> In fact, it would be undesirable to create such a dependency, especially in the THIRD_PARTY/proxy case, because we would not want to create a situation where communication between two other nodes depends on the reliability/reachability of the PCP proxy.
> 

Umm, he didn't explain why reauth/rexmit is not needed. Technical explanation is a good starting point, or a EAP-clueful person looks at this and makes a comment. 

> Sam has pointed to an example of a recently approved EAP lower layer (more recent than PANA), gss-eap, that is simpler than PANA, supports a request/response model similar to PCP, and does not incl…

We did explain that already, right? Even Sam made references to re-keying, lifetime, authorization change, etc.

I mean, this is one of the most basic things with security design. 
If we were in a security-specific group, you'd be the one explaining how you can get away w/o ever supporting re-auth.

If you guys think you have a magic to turn a server-driven protocol (EAP) into a client-drive protocol, and a magic to totally eliminate re-auth and yet still be have a secure solution with unconstrained applicability, please explain how you do that to us. 

> Could you perhaps look at gss-eap and consider whether a similar model could apply to PCP?  

I could look at it. And I guess now I have to. A simple technical explanation from Sam could be better than I having to read and digest that spec.

> Would it be possible to achieve a similar model using PANA?  If so, what updates would be need to the PANA specification in order to do that?
> 

Confused. What updates to PANA for what purpose? PANA already supports re-auth. 

Alper

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Sep 2012 08:48:43 -0400

I wanted to give the WG some final thoughts on the conversation Alper
and I  have been having.
This will probably be my last message on the topic as I think we're
basically at the point of diminishing returns.

>>>>> "Alper" == Alper Yegin <[email-masked]
g> writes:

On the topic of retransmits, we agree that under section 4.3 of RFC
3748, you can set the transmit timer to infinite.
I think we agree that this moves retransmits from within the EAP layer
to the EAP lower layer.

    Alper>   When run over a reliable lower layer (e.g., EAP over
    Alper> ISAKMP/TCP, as within [PIC]), the authenticator
    Alper> retransmission timer SHOULD be set to an infinite value, so
    Alper> that retransmissions do not occur at the EAP layer.

    Alper> Only when run over a reliable EAP lower layer, the EAP layer
    Alper> sets the timeout to infinity.  So, whether the rexmit is
    Alper> handled by the EAP layer, or the EAP lower layer, the PCP
    Alper> server will be sending retransmissions in your case.

It's actually fairly easy to move which side generates the
retransmission once you move it into the lower layer.
Note that the PCP server still needs to maintain the state of what EAP
request to send, but whether to send that can be based on what the
client sends.
That is, if the PCP state machine works better with client-driven
retransmits,
we can achieve that.
We do need authentication-session state in the server, and part of that
state is the unacknowledged eap-request if there is one.

With regard to re-authentication:

>>     Consider what happens in an AAA server. There, your EAP
>> server cannot (and is not supposed to) handle retransmits.
>> RADIUS at least is a lock-step protocol. Ignoring things like
    Alper> COA,

    Alper> Ah, "ignoring CoA". CoA is the RADIUS' tool to generate an
    Alper> unsolicited message, more specifically for starting EAP
 
I'd like to draw the WG's attention to RFC 5176, which defines COA.
Section 4 explicitly mentions that COA cannot be used for starting
re-authentication.  Section 1.1 is an applicability statement explaining
why COA is not standards-track because of security and semantic
concerns.

As best I can tell only diameter has AAA support for re-authentication.
So, I'd like to draw our attention to RFC 4005, section 3.3 which
defines rules for diameter re-authentication.  That section explicitly
calls out re-authentication must be supported *if the underlying service
supports it*.  That is, re-authentication is OPTIONAL for a given
service like PCP, but if a given PCP server supports re-authentication
and diameter, then it needs to support re-authentication via diameter.
Section 3 of RFC 4072 (diameter over eap) confirms the guidelines of RFC
4005 apply.

Re-authentication being optional is definitely consistent with my
implementation experience.  I have no experience with diameter, but do
have a lot of experience with EAP implementations that consider
re-authentication optional.

This is all great news for the PCP community.  We can choose the
retransmission strategy that best meets the PCP implementations.  we can
choose to support re-authentication if it is useful, or decline to
support it if it is not.  If we don't choose to support
re-authentication then we can avoid the complexity.

---

From: Alper Yegin <[email-masked]>
Date: Thu, 20 Sep 2012 16:17:40 +0300

So, I looked at this spec.

This, too, is server-driven. Like EAP is, unlike PCP is. 
Retransmission do happen, not at the EAP layer but at the EAP-lower layer.

Yep, there's no re-auth. It's absence is confirmed! :-)

- What happens if server-side needs to re-key, extend lifetime, change authorization, re-challenge the client? 
Say, the acceptor receives a RADIUS CoA with EAP-Request, what's going to do with it?

Sorry folks, gss-eap as an EAP lower layer spec is incomplete. Whether you recognize and accept this today, or later when you start building complete architectures/systems with it. No worries, you can always add it.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 21 Sep 2012 00:27:32 +0900

I believe Alper and Sam are discussing EAP re-authentication in the
context of RFC 3748 and RFC 5247 and not specifically in the context
of RFC 5296 (ERP).  Let's not confuse ourselves.

EAP re-authentication in the context of RFC 3748 and RFC 5247 is
supported by most known lower-layers, including 802.1X and PANA, for
re-keying lower layer SA.

While I agree that ERP is definitely not needed for PCP, but I think
unsupporting EAP re-authentication in the context of RFC 3748 and RFC
5247 is NOT a good idea, because it enables smooth migration from old
SA to new SA.  Without supporting EAP re-authentication in the context
of RFC 3748 and RFC 5247, communications disruptions can happen during
rekey, i.e., communication quality of PCP and data traffic controlled
by PCP can affect in our case.

Also, it seems that there is some desire to change PCP-specific
authentication design to be based on client-initiated request so that
it fits the PCP-base design.  This just shows that this is an issue
with the current design of PCP-specific authentication.  Regarding
client-initiated request support for EAP lower layer, I also have the
same doubt as Alper has.  Whether it works with acceptable complexity
really depends on detailed characteristics of the targeted lower
layer.  Showing examples of EAP-GSS and IKEv2 does not help for PCP.
I can say that EAP over DHCP that was rejected by IETF, one major
reason was that is was considered to be difficult to fit EAP into
DHCP's client-initiated request model (I forgot why it is difficult, I
suggest to read the entire email discussion in DHC WG on this).
Having said that I cannot really judge until and unless a complete
solution for the design change is shown.

I suggest not to spend too much time for justifying or promoting
re-invented designs which can easily contain flaws and disadvantages
that were already taken care of in the original design that
successfully went through critical evaluation by a large community (IETF).

Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Sep 2012 11:32:48 -0400

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> While I agree that ERP is definitely not needed for PCP,
    Yoshihiro> but I think unsupporting EAP re-authentication in the
    Yoshihiro> context of RFC 3748 and RFC 5247 is NOT a good idea,
    Yoshihiro> because it enables smooth migration from old SA to new
    Yoshihiro> SA.  Without supporting EAP re-authentication in the
    Yoshihiro> context of RFC 3748 and RFC 5247, communications
    Yoshihiro> disruptions can happen during rekey, i.e., communication
    Yoshihiro> quality of PCP and data traffic controlled by PCP can
    Yoshihiro> affect in our case.

I'd like to hear from PCP implementors about whether smoothe SA
migration is even desirable.
My assumption would be that it would be entirely not worth the
complexity for PCP.

    Yoshihiro> Also, it seems that there is some desire to change
    Yoshihiro> PCP-specific authentication design to be based on
    Yoshihiro> client-

Actually, I didn't propose a change; I simply pointed out that you can
do it either way depending on what is easiest for PCP implementations;
we should pick, but what we pick should be based on the needs of the PCP
community.

It's my experience that security solutions are best when they provide a
good user experience and are easy to implement. I'm hoping to accomplish
that here.

--Sam

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 21 Sep 2012 01:12:39 +0900

Sam,

> My assumption would be that it would be entirely not worth the

I have to say that this matters for users of PCP.  PCP implementors
have to implement what PCP users want.  As a user of PCP, I don't want
my established WebEx session for the interim meeting to get disrupted
by rekey ;)

> we should pick, but what we pick should be based on the needs of the PCP

I would rather consider this as the major disadvantage of tight
coupling EAP and PCP.  It is much easier to run PANA and PCP
side-by-side which achieves loose coupling of EAP and PCP.

> good user experience and are easy to implement. I'm hoping to accomplish

Then EAP re-authentication needs to be supported.

Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Sep 2012 12:22:09 -0400

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> I have to say that this matters for users of PCP.  PCP
    Yoshihiro> implementors have to implement what PCP users want.  As a
    Yoshihiro> user of PCP, I don't want my established WebEx session
    Yoshihiro> for the interim meeting to get disrupted by rekey ;)

We're agreed on that.
However as Margaret has pointed out 
you don't need seemless SA migration to get that in PCP.
Session expire does not mean mapping expire.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 20 Sep 2012 12:45:01 -0400

On Sep 20, 2012, at 12:12 PM, Yoshihiro Ohba wrote:
> side-by-side which achieves loose coupling of EAP and PCP.=

The problem is that running PCP and PANA side-by-side doesn't really change anything...

Either we change PCP to have a notion of a "session" that is associated with every mapping, and to understand to understand that external events can cause an asynchronous event of some sort that invalidates all of those mappings, or we don't...

I greatly prefer a model where the a client is authenticated and authorized to create a mapping, at the time that the mapping is created, and there is no presumption that the mapping is tied to any sort of ongoing client authentication/authorization.

Otherwise, I suppose we could _claim_ to support re-authentication, but what does it mean if PANA performs re-authentication and there is no meaningful way to communicate a re-authentication success, or more importantly perhaps, a re-authentication failure to PCP.

How are you imagining this would work in the side-by-side case -- re-authentication occurs, and then what?

Margaret

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 21 Sep 2012 02:24:01 +0900

Margaret,

> I greatly prefer a model where the a client is authenticated and authorized to create a mapping, at the time that the mapping is created, and there is no presumption that the mapping is tied to any…

I disagree.  Loose coupling of authentication/authorization and states
associated with authorization creates a security issue.  Loose
coupling makes it difficult for service providers to strictly enforce
their services based on the authentication/authorization.

> How are you imagining this would work in the side-by-side case -- re-authentication occurs, and then what?

I suggest you to take a look at RFC 5609 on how it can work.
Completion of initial authentication and re-authentication calls
Authorize() upon success and Disconnect() upon failure which are
typically implemented as a callback.

"
   void Disconnect()

      A procedure to delete the PANA session as well as the
      corresponding EAP session and authorization state.

   boolean Authorize()

      A procedure to create or modify authorization state.  It returns
      TRUE if authorization is successful.  Otherwise, it returns FALSE.
      It is assumed that Authorize() procedure of PaC state machine
      always returns TRUE.  In the case that a non-key-generating EAP
      method is used but a PANA SA is required after successful
      authentication (generate_pana_sa() returns TRUE), Authorize()
      procedure must return FALSE.
"

If you find some issue, we can work on revising RFC 5609 if something
is missing for PCP needs, which would be more productive IMO.

Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Sep 2012 13:33:07 -0400

One thing to consider is that in many cases, PCP users will not be using
authentication; they will be using unauthenticated PCP.  So, especially
for PCP, it seems undesirable to tie authorization to authentication.

If an authorization revocation event happens--that is, a service
provider wants to stop providing service to a customer--they will
typically want to drop both unauthenticated and authenticated mappings.
The sort of things that might trigger this are  administrative action
(customer account suspended for immediate cause), address renumbering,
or lease expire.

For PCP it seems much more likely that these events will be tied to a
provisioning/authorization system than any event in an authentication
system.

Tieing this to authentication seems like it will miss important PCP use
cases.
Duplicating the same logic both for authentication and authorization
seems to introduce complexity that PCP does not need.

--Sam

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 21 Sep 2012 03:18:23 +0900

Sam,

Since PCP authentication is not part of base specification,
authentication is already optional, which is fine.  But when
authentication is used it needs to be tied with authorization.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 21 Sep 2012 14:04:57 +0300

Sam,

This whole trying to decouple authentication from authorization couldn't more more wrong.

Non-PCP-specific background:
Authentication is done for the sake of authorization. The server (whether it's the PCP server, or Foo server) does not really care if you are really "Bob". They care what you are authorized to access. It's the backend policy server (e.g., RADIUS server) that knows Bob --> authorization parameters mapping. 

So, when PCP Client is authenticated as "Bob's PC", PCP server also learns the authorization parameters "allow him to use X ports for Y minutes". In AAA systems, authorization always has finite lifetime (for better resource management). Bob needs to "re-authenticate" before Y minutes passes, otherwise his authorization is yanked. Ports are closed. Whatever state PCP server has created/allocated for "Bob's PC" are freed. That's it.

As soon as authorized lifetime expires, PCP server stops serving the client. That's the meaning of "lifetime" in AAA systems.

You have to re-authenticate before that happens.

This is how it's for any EAP-based system, this is how it's for any AAA (RADIUS/Diameter)-based system. 

How can you think PCP does not need re-authentication? 

Alper