Subject: [pcp] Margaret's PPT

From: Alper Yegin <[email-masked]>
Date: Wed, 17 Oct 2012 16:22:22 +0300

Folks,

Margaret's PPT on the interim web is out-of date. It's from last meeting and not reflecting the latest updates.
So, I'm not sure if it'll be used in today's meeting. Nevertheless, let me share my comments on it.

- Decision tree starts with an "Architectural Model Discussion". IMO, the starting and even determining point is whether we "re-use an existing protocol, or re-invent it". 

- Loosely coupled authentication and authorization

They cannot be decoupled.
Authentication is done for authorization.
The authorized service, and the crypto keys used during that authorization, shall have the same lifetime. This is how it is in EAP and AAA-based systems.

- Need for re-authentication

If the authorized lifetime expires, the authorized service (mappings) needs to expire as well.
They are bound to each other. 

- Asking if a client needs to remain reachable in order to defend/retain its mapping.

It's a PCP design and policy question.
Whatever it's, PANA can support that.
PANA-Ping is not a mandatory-to-use feature.

- "EAP-PCP has no unsolicited messages that require a response"

Not true for any EAP lower layer (EAP-o-PCP being one). 
EAP is network driven, requests are sent from the network, and they expect a response.

- "Mappings survive key expiration"

They shall not. Mapping lifetime and key lifetime are dictated by the AAA server and the same. This is how it's in EAP and AAA unless you want to do some unusual thing. 
Possession of keys by the PCP client is the proof of authorization of the PCP client. 

- "Simplified PANA-link mechanism"

Yes, ~20 lines of PANA-Ping and IP Reconfig is omitted in EAP-o-PCP. Negligible amount of savings.

- Bit overloading with port-sharing PANA.

Not sure why it's called "overloading".
To the PANA implementation, that one bit indicates the protocol is executed over PCP port.
To the PCP implementation (or a piece of demux code handling the PCP port) , that one bit indicates the incoming packet is not PCP, it's something else running over PCP port.

With the new discovery solution we make sure PCP server does not find itself having to process a request with unsupported version.

Cheers,

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 17 Oct 2012 09:51:08 -0400

Hi Alper,

> So, I'm not sure if it'll be used in today's meeting. Nevertheless, let me share my comments on it.

I have sent any updated version to the chairs, and I think it will be posted soon.  However, it is very similar, as discussions have not progressed much since the last call.
> - Decision tree starts with an "Architectural Model Discussion". IMO, the starting and even determining point is whether we "re-use an existing protocol, or re-invent it". 

You and Yoshi covered this topic in your slides, which you presented at length in the last meeting.  I don't think it would be useful to present them again.

> They are bound to each other. 

These are your opinions.  Other opinions were expressed during discussions on the mailing list.  I don't think we can know what the WG thinks in this area without asking...

> It's a PCP design and policy question.

Exactly.  That is why I am raising the question.

> PANA-Ping is not a mandatory-to-use feature.

Correct.  We can, if we choose, define a subset of PANA that removes the need for nodes to remain reachable to defend their mapping.  This would involve dropping support for PANA "liveness checks" (which is what I think you mean by "PANA-Ping"), and removing server-initiated reauthentication.

> EAP is network driven, requests are sent from the network, and they expect a response.

Have you read the GSS-EAP draft that Sam Hartman referenced in his e-mail?  It is not true that all EAP lower layers need to support server-initiated re-authentication.  PANA does, but PCP could define an EAP lower layer that doesn't, like GSS-EAP.  This is something the WG needs to discuss and consider.

> Possession of keys by the PCP client is the proof of authorization of the PCP client. 

Again, this is your opinion.  We do not yet know if the WG agrees with you.
> Yes, ~20 lines of PANA-Ping and IP Reconfig is omitted in EAP-o-PCP. Negligible amount of savings.

The entire Enforcement Point concept, session termination, server-initiated re-authentication, and details specific to controlling network access are also omitted in the PCP-Specific approach. If we go with a PANA-based approach, we will need to decide what to do about each of these things, and write a detailed description of what portions of PANA are and are not used for PCP authentication.

> To the PCP implementation (or a piece of demux code handling the PCP port) , that one bit indicates the incoming packet is not PCP, it's something else running over PCP port.

When a bit is used for more than one purpose, that is called "overloading".  In this case, the bit is part of the PCP version number, and is also used for demultiplexing.  That is what "overloading" means...

> With the new discovery solution we make sure PCP server does not find itself having to process a request with unsupported version.

This is possible, yes, at some cost in terms of complexity.  Assuming the WG reaches consensus to proceed with a PANA-based approach, the WG needs to compare the complexity of a discovery solution against the overhead of encapsulation, in order to make an informed choice between those two approaches.

Margaret

---

From: Dave Thaler <[email-masked]>
Date: Wed, 17 Oct 2012 13:51:20 +0000

She sent an updated copy which I just uploaded.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Alper Yegin [[email-masked]]
Sent: Wednesday, October 17, 2012 6:22 AM
To: [email-masked]
Subject: [pcp] Margaret's PPT

Folks,

Cheers,

Alper

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

---

From: Alper Yegin <[email-masked]>
Date: Thu, 18 Oct 2012 09:22:55 +0300

Hi Margaret,

> You and Yoshi covered this topic in your slides, which you presented at length in the last meeting.  I don't think it would be useful to present them again.

Honestly, "architectural model discussion" is good for the PCP authentication design, but won't be helpful for the PANA vs EAP-o-PCP discussion. The reason is, since EAP-o-PCP is re-invention of PANA, unsurprisingly the features will be the same. Then it'll simply boil down to my question: re-use or re-invent. 

> Enforcement Point concept: 

This is the entity that performs access control on per-packet basis. 
This is a concept. It's not a PANA protocol entity, there's no code in PANA implementation for this.
Application of that concept to PCP is the "piece of PCP code that verifies the auth option of the incoming PCP packet before acting on the rest of the payload".

So, one thing performs "end-point authentication" (like authenticating joe@domain), and generates crypto keys. EAP + EAP-lower-layer does that.
Those crypto keys are used with per-packet security (putting a signed hash on each packet) to perform data-origin authentication. The things that does this check is called Enforcement Point. 

Again, no code, no extra in PANA.

> Session termination

If the client decides to sign-off,
or the network decides to terminate the session (e.g,  when the NAS receives a AAA Disconnect message), then you need an explicit termination message.
This is needed.

> Server-initiated re-auth

(will have a separate thread for that..)

PANA-Ping and IP Reconfig we agreed. 

What else??

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 18 Oct 2012 07:36:43 -0400

Hi Alper,

Expressing my own opinion, not trying to represent the opinion of the WG or any other group...

On Oct 18, 2012, at 2:22 AM, Alper Yegin wrote:

> Honestly, "architectural model discussion" is good for the PCP authentication design, but won't be helpful for the PANA vs EAP-o-PCP discussion.

I think it will be, because it helps us understand what the different solutions will really look like...

> The reason is, since EAP-o-PCP is re-invention of PANA, unsurprisingly the features will be the same. Then it'll simply boil down to my question: re-use or re-invent. 

The PCP-specific approach is not simply a "re-invention" of PANA.  Although it was originally conceived by looking at how PANA works, there are difference that are intended to make it more suitable for use with PCP.  These include:

- Integration with PCP messages (no need to demultiplex or fully encapsulate another protocol, clean logging and error handling).
- No server-generated requests (i.e. no equivalent to liveness tests or server-initiated re-authentication)
- Retransmissions are handled at the PCP level, not by the EAP upper layer (avoiding server-generated retransmissions)

In my opinion, saying something like "use PANA", and then providing a long list of the parts of PANA that you shouldn't use ("liveness tests", server-initiated re-authentication, EAP-layer retransmissions, IP address reconfiguration, session termination, etc.), or that need to be modified to work with PCP (i.e. meaning of the flag bits, role of the enforcement point) would be a re-invention of PANA.  

If PANA is meant to be a general purpose UDP-over-EAP authentication mechanism, as you seem to indicate, then why doesn't the PANA document say that?  Why isn't there a mechanism in PANA to make it usable by more than one application at the same time?  Why is all of this network access-specific stuff (IP address reconfig, "liveness tests", etc.) mixed together with the authentication mechanism?

In fact, the whole notion that we would invent a PCP-specific way to use PANA is confusing to me, because PANA is _not_ a general-purpose EAP-over-UDP authentication protocol -- it is a network access authentication protocol like IEEE 802.1x...  You are actually proposing that we re-use _some parts_ of PANA for PCP, and that we re-invent the parts of PANA that aren't suitable for use with PCP.  Yes, it would be possible to do those things, but why would that be better than using a PCP-Specific mechanism?  

You seem to have given up (in your proposals) on the notion that PCP and the network access authentication portions of PANA could share a single instance of a PAA, since you have not included a way to indicate whether the request for authentication is coming from PCP or from a PANA network access application.  Do you actually think that by the time we are done subsetting PANA to only include the authentication bits that are appropriate to PCP that it will be possible to use the same code for a PCP PAA and a PANA PAA? ...I don't.

> or the network decides to terminate the session (e.g,  when the NAS receives a AAA Disconnect message), then you need an explicit termination message.

There is no notion in PCP that a client would "sign off".  PCP is a UDP-based request/response protocol.  There isn't anything to "sign-off" from...

> PANA-Ping and IP Reconfig we agreed. 

If you can't eliminate server-initiated re-authentication, then there is not benefit to eliminating PANA-Ping (called "liveness tests" in the PANA document).

Margaret

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 19 Oct 2012 01:01:08 +0900

Hi Margaret,

> - Retransmissions are handled at the PCP level, not by the EAP upper layer (avoiding server-generated retransmissions)

To me these things are not attractive enough to define a new EAP 
transport specific to PCP compared to
the benefit of reuse of a well-defined and interoperable protocol (i.e., 
PANA).  If we decide to use
either of the two PANA-based I-Ds for which some people already 
mentioned that they are short and workable, then I believe we can 
quickly get our work done.

> In my opinion, saying something like "use PANA", and then providing a long list of the parts of PANA that you shouldn't use ("liveness tests", server-initiated re-authentication, EAP-layer retransm…

I disagree.  It is re-use of PANA with a specific profile of not using 
some optional features.

(BTW, I never mentioned that server-iniated re-authentication, EAP-layer 
retransmision and session termination should not be used.)

> If PANA is meant to be a general purpose UDP-over-EAP authentication mechanism, as you seem to indicate, then why doesn't the PANA document say that?  Why isn't there a mechanism in PANA to make it…

PANA is already used as a general purpose UDP-over-EAP authentication mechanism in ETSI MSM.

> You seem to have given up (in your proposals) on the notion that PCP and the network access authentication portions of PANA could share a single instance of a PAA, since you have not included a way…

Why not?  Both PANA-based approaches use port number to distinguish PCP 
authentication and
network access authentication.

Yoshihiro Ohba

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 20 Oct 2012 15:58:25 -0400

On Oct 18, 2012, at 12:01 PM, Yoshihiro Ohba wrote:
> 
> To me these things are not attractive enough to define a new EAP transport specific to PCP compared to
> the benefit of reuse of a well-defined and interoperable protocol (i.e., PANA).  If we decide to use
> either of the two PANA-based I-Ds for which some people already mentioned that they are short and workable, then I believe we can quickly get our work done.

Unfortunately, I believe that the two PANA drafts are as short as they are because they are incomplete.  We will need to resolve the open questions about what parts of PANA are and are not included when PANA is used with PCP.

I continue to believe that any of the three approaches could work.  We just need to decide, as a WG, which one is best for PCP.

> I disagree.  It is re-use of PANA with a specific profile of not using some optional features.
> 
> (BTW, I never mentioned that server-iniated re-authentication, EAP-layer retransmision and session termination should not be used.)

Whether to use server-initiated re-authentication or retransmission is one of our open architectural/design issues.

I don't understand when/if session termination would ever be used with PCP.  Where do you picture it being used and why?

> PANA is already used as a general purpose UDP-over-EAP authentication mechanism in ETSI MSM.

What is ETSI MSM?  Could you send a pointer to a document describing it?

> Why not?  Both PANA-based approaches use port number to distinguish PCP authentication and

We talked about the PANA server needing to be co-resident with the PCP Server (no proxies).  The PCP port gets the message to the PCP Server, not to the PANA Server.  Current PANA implementations don't have any way to receive PANA messages except on the PANA port, do they?  So, either you need to modify existing implementations or send them messages on the PANA port...

Margaret

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 21 Oct 2012 19:15:39 +0900

(2012/10/21 4:58), Margaret Wasserman wrote:
>
>
>>> In my opinion, saying something like "use PANA", and then providing 
>>> a long list of the parts of PANA that you shouldn't use ("liveness 
>>> tests", server-initiated re-authentication, EAP-layer 
>>> retransmissions, IP address reconfiguration, session termination, 
>>> etc.), or that need to be modified to work with PCP (i.e. meaning of 
>>> the flag bits, role of the enforcement point) would be a 
>>> re-invention of PANA.
>>
>> (BTW, I never mentioned that server-iniated re-authentication, 
>> EAP-layer retransmision and session termination should not be used.)
>
> Whether to use server-initiated re-authentication or retransmission is 
> one of our open architectural/design issues.
>
> I don't understand when/if session termination would ever be used with 
> PCP.  Where do you picture it being used and why?

Session termination is to remove a PCP SA.  A PCP SA can be terminated 
any time when either end wants to delete it and having explicit 
indication of session termination is better.

>
>>> If PANA is meant to be a general purpose UDP-over-EAP authentication 
>>> mechanism, as you seem to indicate, then why doesn't the PANA 
>>> document say that?  Why isn't there a mechanism in PANA to make it 
>>> usable by more than one application at the same time?  Why is all of 
>>> this network access-specific stuff (IP address reconfig, "liveness 
>>> tests", etc.) mixed together with the authentication mechanism?
>>

Visit http://www.etsi.org/website/technologies/m2m.aspx and look for
ETSI M2M documents.

>
>> In fact, the whole notion that we would invent a PCP-specific way to 
>> use PANA is confusing to me, because PANA is _not_ a general-purpose 
>> EAP-over-UDP authentication protocol -- it is a network access 
>> authentication protocol like IEEE 802.1x...  You are actually 
>> proposing that we re-use _some parts_ of PANA for PCP, and that we 
>> re-invent the parts of PANA that aren't suitable for use with PCP. 
>>  Yes, it would be possible to do those things, but why would that be 
>> better than using a PCP-Specific mechanism?
>>>
>>> You seem to have given up (in your proposals) on the notion that PCP 
>>> and the network access authentication portions of PANA could share a 
>>> single instance of a PAA, since you have not included a way to 
>>> indicate whether the request for authentication is coming from PCP 
>>> or from a PANA network access application.  Do you actually think 
>>> that by the time we are done subsetting PANA to only include the 
>>> authentication bits that are appropriate to PCP that it will be 
>>> possible to use the same code for a PCP PAA and a PANA PAA? ...I don't.
>>
> We talked about the PANA server needing to be co-resident with the PCP 
> Server (no proxies).  The PCP port gets the message to the PCP Server, 
> not to the PANA Server.  Current PANA implementations don't have any 
> way to receive PANA messages except on the PANA port, do they?  So, 
> either you need to modify existing implementations or send them 
> messages on the PANA port...

Yes, existing PANA implementations need to be modified and that is why 
the status of the two PANA drafts
say "Updates: 5191 (if approved) ", and there is nothing wrong with it 
as long as it works.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 22 Oct 2012 13:27:37 +0300

Margaret,

Yoshi gave very good answers to your question. Btw, some of your questions are really repeat questions that are already answered. (Well, this is bound to happen when we are a very small group of people discussing w/o other (especially neutral) parties involved, and the chairs not helping summarize the discussion…. :-(

What we are proposing is protocol re-use. If you are too concerned about re-using a protocol that was originally designed for network access, you should not be using EAP at all :-) You know, it's designed for network access authentication with a whole lot more network access specific bits in it.

We gotta reset this discussion to what IETF should normally do:

> For the given problem space, let's look around and see what we can use out of our current IETF toolbox.

We say there's PANA.

You say it has extras.

1- PANA-Ping: OK, we don't need this. We can say it is not used with PCP. (BTW, FYI, this is not network ping. This is liveness check on the PANA SA. So, it's not a network thing, it's a security thing).
2- IP Reconfig: OK, we don't need this either.
3- Termination: This I claim is needed. If we are creating security association, we shall also define an explicit way to purge them on either end. This is again not network specific, this is simply part of a complete security association management. 
4- Re-auth: This is still under discussion.

1&2 are extremely small piece of PANA design that we can choose not to use for PCP.
3&4 are under debate.

Even in the case we decide not to use any of the 4 features above, how can this justify tossing PANA away and redesigning its subset from scratch? 

So, before we abandon all the effort that went into IETF's standard PANA, and embark the WG and beyond on designing PANA subset from scratch, you need to convince the WG that this is really essential. Otherwise this is just waste of IETF resources.

Alper