Subject: [pcp] Comparison of PCP authentication

From: Alper Yegin <[email-masked]>
Date: Fri, 3 Aug 2012 00:30:56 +0300

http://www.ietf.org/proceedings/84/slides/slides-84-pcp-10.pdf

Ah, isn't it odd that this beauty contest is run by one of the contestants? This material should have been prepared and presented by a neutral party. 

One important question: With this proposal, are the authors advocating each protocol should come with their own in-band key management, more specifically embedding an EAP transport?

> what's the big deal of using the same port vs different port? Is jamming all in the same port is a benefit?

> "TLS is in-band"

- There's standalone use of TLS as "a separate" KMP. RFC 5705 is driven by the fact that some other protocols need to use TLS as a "separate KMP". 
- TLS is basically "transport layer security", something that sits below the protocol one would be trying to secure. We are not doing that.  

> are the EAP and PCP state machines compatible? If marrying two protocols, one needs to pay attention to this. This was one of the reasons why EAPoDHCP did not work.

> Does the EAP-over-PCP satisfy the "EAP lower layer requirements" as stated in RFC 3848? I had asked this question but don't remember seeing any response.

> "Possible in-band optimization". Is this documented anywhere? It's not easy to understand how it works by looking at this slide.

> PANA RFC 5191 was published in 2008, not 2011. It's adopted by Zigbee IP, ETSI TISPAN, and also ETSI M2M. Aside from two open-source implementations, multiple commercial implementations have successfully passed interop events in Zigbee Alliance. 

Need to specify the portions of PANA that don’t need to be implemented

in a PCP PANA Client and Server (such as IP Address reconfiguration)

>> this is just a single bit flag. We don't use it, and that's all we need to do about it.
Need to specify/describe interface between PANA and PCP elements

>> this is an implementation issue, like how the other spec implementors would need to define the interface between the EAP and PCP for passing keys, etc.

Need to specify how the PANA client finds the correct PANA Server for PCP Authentication (may be passed from PCP client?)

>> PCP server the the PAA are the same node.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 2 Aug 2012 18:34:48 -0400

Hi Alper,

I am not entirely clear on what parts of these messages came from you or what parts you are replying to...  If I miss something you would like me to answer,
please let me know.

> Ah, isn't it odd that this beauty contest is run by one of the contestants? This material should have been prepared and presented by a neutral party. 

There was a meeting between the available authors of both drafts this morning, and we worked together to make the slides reflect a fair comparison of the two approaches.

> One important question: With this proposal, are the authors advocating each protocol should come with their own in-band key management, more specifically embedding an EAP transport?

With which proposal?

I do, personally, think it is valid that there would be several different protocols that use EAP directly for authentication.  I think there already are...

> > what's the big deal of using the same port vs different port? Is jamming all in the same port is a benefit?

Having a protocol that relies on two ports (like the PCP Port and a PANA port) is more complex, operationally, because it requires that any intermediate firewalls or middleboxes be configured to pass both protocols in order for authenticated PCP to function properly.  

No one has indicated that this is a big deal, as far as I know.  It is one specific difference between two proposals that are, in many ways, quite similar.  There are other differences, as well, such as the fact that PANA has running code and the non-EAP portions of the in-band approach do not.

> >> this is just a single bit flag. We don't use it, and that's all we need to do about it.
One of the questions I have is:

What happens if a PANA Client that is trying to get authentication for PCP talks to a PANA Server that does Network Access authentication but _not_ PCP authentication...  The newest proposal (draft-ohba) does not indicate that any flag or value will be included in the PANA authentication request that indicates that the request is for Network Access authentication or PCP Authentication, so how will the PANA server know which to authenticate, and how will the client know what it has been authenticated _for_?
> >> this is an implementation issue, like how the other spec implementors would need to define the interface between the EAP and PCP for passing keys, etc.
Even in the case (as described in draft-ohba) where these elements run on a single system, it is necessary to specify what information is passed between these elements and what portion of it is passed in the PCP authentication options.  This is necessary, in order to ensure that the PANA authentication is properly bound to a PCP request.  Without specifying that information, it isn't possible to know that a particular PCP request/response has been properly bound to a particular PANA authentication.
> >> PCP server the the PAA are the same node.

You have suggested that a huge advantage of using PANA for this application is that there could be code reuse with existing PANA implementations.  Existing PANA implementations don't find their PAA by looking at their PCP Server address...  They also don't have any notion (as far as I can tell) of a "client" that is invoking them to initiate authentication, or of a client and server to whom they should communicate the security association information after they negotiate it.   If the PCP client does not _tell_ PANA the address of the PCP Server to which it intends to send a request, how will the PANA client know?

Margaret

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 6 Aug 2012 11:01:11 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alper Yegin
> Sent: Thursday, August 02, 2012 2:31 PM
> To: [email-masked]
> Subject: [pcp] Comparison of PCP authentication
> 
> Ah, isn't it odd that this beauty contest is run by one of the
> contestants? This material should have been prepared and presented by a
> neutral party.
> 
> One important question: With this proposal, are the authors advocating
> each protocol should come with their own in-band key management, more
> specifically embedding an EAP transport?
> 
> 
> > what's the big deal of using the same port vs different port? Is
> jamming all in the same port is a benefit?
> 
> > "TLS is in-band"
> 
> - There's standalone use of TLS as "a separate" KMP. RFC 5705 is driven
> by the fact that some other protocols need to use TLS as a "separate
> KMP".
> - TLS is basically "transport layer security", something that sits
> below the protocol one would be trying to secure. We are not doing
> that.

To throw another TLS thing into the mix:

DTLS-SRTP [RFC5764] uses the (D)TLS handshake to encrypt SRTP and is
pretty well aligned with what we want for PCP -- we want a key
exchange and then run the PCP protocol natively.  DTLS-SRTP has a 
normal DTLS handshake, followed by SRTP packets that appear normal 
on the wire (that is, the packets are RFC3711 packets which have
their RTP headers in the clear).  It does this over the same socket,
because the first byte indicates if the packet is DTLS, SRTP, or
STUN (ICE), http://tools.ietf.org/html/rfc5764#section-5.1.2.

At the meeting, I suggested we consider if PANA and PCP could
be similarly demux'd.  Stuart suggested using some sort of GRE-
like header if they cannot be demux'd.  Either approach would 
eliminate one of the objections of PANA, specifically its use 
of a separate port.

-d

> > are the EAP and PCP state machines compatible? If marrying two
> protocols, one needs to pay attention to this. This was one of the
> reasons why EAPoDHCP did not work.
> 
> > Does the EAP-over-PCP satisfy the "EAP lower layer requirements" as
> stated in RFC 3848? I had asked this question but don't remember seeing
> any response.
> 
> > "Possible in-band optimization". Is this documented anywhere? It's
> not easy to understand how it works by looking at this slide.
> 
> > PANA RFC 5191 was published in 2008, not 2011. It's adopted by Zigbee
> IP, ETSI TISPAN, and also ETSI M2M. Aside from two open-source
> implementations, multiple commercial implementations have successfully
> passed interop events in Zigbee Alliance.
> 
> >
> 
> *	Need to specify the portions of PANA that don't need to be
> implemented
> 
> *	Need to specify/describe interface between PANA and PCP elements
> 
> 	>> this is an implementation issue, like how the other spec
> implementors would need to define the interface between the EAP and PCP
> for passing keys, etc.
> 
> *	Need to specify how the PANA client finds the correct PANA Server
> for PCP Authentication (may be passed from PCP client?)
>

---

From: Alper Yegin <[email-masked]>
Date: Mon, 6 Aug 2012 22:43:35 +0300

PANA:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Flags             |         Message Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Session Identifier                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  AVPs ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Reserved

      This 16-bit field is reserved for future use.  It MUST be set to
      zero and ignored by the receiver.

PCP:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Version = 2  |R|   Opcode    |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Requested Lifetime (32 bits)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |            PCP Client's IP Address (128 bits)                 |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) Opcode-specific information            :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) PCP Options                            :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

First octet can be used for demux'ing.

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 6 Aug 2012 16:02:53 -0400

Hi Alper,

Thanks for your help with this!  While it would work to demultiplex on the first byte, as you indicate, there is a bit more to defining a demultiplexing solution than this...

Since this is UDP, there is nothing that inherently binds the PANA authentication to a particular (set of) PCP request(s).  So, we will need to make sure that the information passed in the authentication option is sufficient for the sever to securely determine that the client sending a the PCP request is the same client that initiated the PANA exchange and vice versa, just as we would need to do if PANA and PCP were run on separate ports.  I don't think this will be difficult, we just need to make sure that we achieve it.

Do you know what existing PANA implementations will do if the "Reserved" field at the start of the packet is non-zero? 

We should also consider the trade-offs between a demultiplexing approach (which allows us to run PANA and PCP separately over a single port), and an encapsulation approach (PANA encapsulated in PCP).  A demultiplexing approach is somewhat cleaner, in that we can process the whole message as a PANA or PCP message.  But, the encapsulation approach would allow us to gain some optimization by piggy-backing the first (and possibly the final?) messages of the PANA exchange in the original PCP request (and response?) to cut down on the number of messages needed to create a secure mapping.  Since the PCP exchange may happen as part of client connection set-up (while a user is waiting), cutting down on the number of messages exchanged could be valuable.

As discussed at the PCP meeting in Vancouver, we will be writing up both of these approaches soon, for further discussion on an interim phone call.

Margaret

On Aug 6, 2012, at 3:43 PM, Alper Yegin wrote:

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 6 Aug 2012 14:19:00 -0700

> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Monday, August 06, 2012 1:03 PM
> To: Alper Yegin
> Cc: Dan Wing; [email-masked]
> Subject: Re: [pcp] Comparison of PCP authentication
> 
> 
> Hi Alper,
> 
> Thanks for your help with this!  While it would work to demultiplex on
> the first byte, as you indicate, there is a bit more to defining a
> demultiplexing solution than this...
> 
> Since this is UDP, there is nothing that inherently binds the PANA
> authentication to a particular (set of) PCP request(s).  So, we will
> need to make sure that the information passed in the authentication
> option is sufficient for the sever to securely determine that the
> client sending a the PCP request is the same client that initiated the
> PANA exchange and vice versa, just as we would need to do if PANA and
> PCP were run on separate ports.  I don't think this will be difficult,
> we just need to make sure that we achieve it.
> 
> Do you know what existing PANA implementations will do if the
> "Reserved" field at the start of the packet is non-zero?

Also, if an update to PANA allows 0b00000010 in that first octet, we will
have a problem.  It would be safer if we assign the last two bits in that
first octet of PANA to must-be-zero.  Perhaps via an Errata against the PANA
spec, if we decide this is the best solution.

> We should also consider the trade-offs between a demultiplexing
> approach (which allows us to run PANA and PCP separately over a single
> port), and an encapsulation approach (PANA encapsulated in PCP).  A
> demultiplexing approach is somewhat cleaner, in that we can process the
> whole message as a PANA or PCP message.  But, the encapsulation
> approach would allow us to gain some optimization by piggy-backing the
> first (and possibly the final?) messages of the PANA exchange in the
> original PCP request (and response?) to cut down on the number of
> messages needed to create a secure mapping. 

How many messages are we talking about (5?), and how much reduction 
could we see (reduction from 5 to 3??).

> Since the PCP exchange may
> happen as part of client connection set-up (while a user is waiting),
> cutting down on the number of messages exchanged could be valuable.
> 
> As discussed at the PCP meeting in Vancouver, we will be writing up
> both of these approaches soon, for further discussion on an interim
> phone call.

Looking forward to that.

-d

> 	   |             Flags             |         Message Type
> |
> 	   |                      Session Identifier
> |
> 	   |                        Sequence Number
> |
> 	      0                   1                   2
> 3
> 	     |
> |
> 	     |
> |
> 	     |
> |
> 	     :
> :
> 	     :
> :
> 	     :
> :
> 	     :
> :
> 				what's the big deal of using the same port
vs
> different port? Is
> 			by the fact that some other protocols need to use
TLS
> as a "separate
> 				are the EAP and PCP state machines
compatible?
> If marrying two
> 				PANA RFC 5191 was published in 2008, not
2011.
> It's adopted by Zigbee
> 			in a PCP PANA Client and Server (such as IP Address
> 
> 
> 			reconfiguration)
> 
> 
> 
> 
> 			>> this is just a single bit flag. We don't use it,
> and that's
> 
> 
> 			all we need to do about it.
> 
> 
> 			* Need to specify/describe interface between PANA
and
> PCP elements

---

From: james woodyatt <[email-masked]>
Date: Mon, 06 Aug 2012 16:03:15 -0700

> Do you know what existing PANA implementations will do if the "Reserved" field at the start of the packet is non-zero? 

A related question might be what existing NAT-PMP implementations will do if they receive a message containing a PANA packet.  Assuming they comply with I-D.cheshire-nat-pmp-03, they will interpret the first two octets of a PANA message as an announcement request, and they will reply with the announcement response message shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers = 0      | OP = 128 + 0  | Result Code                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Seconds Since Start of Epoch                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | External IP Address (a.b.c.d)                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If a PCP server needs to implement NAT-PMP too, then it can easily distinguish a NAT-PMP announcement request from a PANA message, but one wonders if a PANA client expecting to authenticate to such a server can deal with replies from a NAT-PMP server that knows nothing about either PCP or NAT-PMP.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 6 Aug 2012 19:07:54 -0400

> spec, if we decide this is the best solution.

Good point Dan.  We will mention this in the updated draft (the one with the three choices), just so we don't lose track of it.

>>   But, the encapsulation

I think we are talking about ~7 messages, cut down to 5 or 6...  I realize that is a fairly small optimization, as a percentage, but security folks do go to fairly significant ends to cut out round trips, when possible, to make people less averse to adopting security solutions.  I don't know how many of those steps are lock-step... This is something I will try to look into and provide more information about for the interim meeting.  I'm hoping we'll have more time to go over the trade-offs in detail on a call than we did in the meeting (when we only had ~25 minutes).

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 6 Aug 2012 19:09:11 -0400

Another important point to consider, James.  Thanks!

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Mon, 06 Aug 2012 19:46:38 -0400

I actually don't think you can gain much value from encapsulation.
The issue is that you'll need to resend the PCP request once you have a
key available.

At least in the case where the client wants authentication, you cannot
save a half round trip through encapsulation.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 07 Aug 2012 09:59:59 +0900

RFC5191-conformant PANA implementations will ignore the "Reserved"
field.

If we specify a new use of PANA "Reserved" field, it cannot be an
Errata because it is not a specification error.  It needs to be a new
RFC that updates RFC 5191.

On the other hand, if we update RFC 5191 (in which WG?), then we
probably need to think more generally so that the update is beneficial
not only for PCP but also other protocols (such as STUN?) that can
potentially benefit from PANA-based in-band key management.

Yoshihiro Ohba

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Tue, 7 Aug 2012 03:50:24 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam
> Hartman
> Sent: Tuesday, August 07, 2012 7:47 AM
> To: Margaret Wasserman
> Cc: [email-masked]

I think in the same way. We used to mention this in the authentication draft. There is a concern of this approach. If a server have to maintain addition information before the success of authentication, the server may be more vulnerable to DOS attack. Attackers can send fake authentication requests appending PCP requests in order to consume the server's memory resources.

---

From: Alper Yegin <[email-masked]>
Date: Tue, 7 Aug 2012 10:48:58 +0300

Hi Margaret,

> Since this is UDP, there is nothing that inherently binds the PANA authentication to a particular (set of) PCP request(s).  So, we will need to make sure that the information passed in the authenti…

That's right.
PANA session will generate a Session-Id, Key-Id, and a PCP key. We should use the two identifiers along with the MIC generated using the PCP key in Authentication Tag Option. That's how PANA session and PCP messages get crypto-bound to each other.

> Do you know what existing PANA implementations will do if the "Reserved" field at the start of the packet is non-zero? 

According to the RFC 5191, receiver MUST ignore the Reserved bits.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 7 Aug 2012 11:10:38 +0300

> RFC that updates RFC 5191.

Those bits are reserved for "future." 
And because of this demux design, "now" we want to make sure no one will ever set bit#7.
What we need is to allocate that bit and state it's always set to 0. I don't think we need a separate RFC for this, this'd be the RFC that defines how PANA and PCP are used together.

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 7 Aug 2012 06:07:23 -0400

> PANA session will generate a Session-Id, Key-Id, and a PCP key. We should use the two identifiers along with the MIC generated using the PCP key in Authentication Tag Option. That's how PANA sessio…

We should also do something (a hash, or whatever) to bind those keys to the contents of a specific request, so that we can be sure that the contents of the request haven't been modified/replaced.  If we include a time and/or the transaction ID in the hash, I think we can guard against replay attacks that way.  I think that would do it.

Much of this is the same, whether we use a demultiplexing approach or an encapsulation approach, and much of it would apply to a PCP-specific mechanism as well.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 7 Aug 2012 06:14:10 -0400

> What we need is to allocate that bit and state it's always set to 0. I don't think we need a separate RFC for this, this'd be the RFC that defines how PANA and PCP are used together.

Right.  If we choose the demultiplexing option, the RFC that defines how to run PANA and PCP together will Update the PANA RFC to allocate certain bits in the first octet.  We might or might not choose to update PANA in other ways, depending on whether we decide to include a TLV indicating that the request is for PCP authentication vs. network access authentication.

Margaret

---

From: Alper Yegin <[email-masked]>
Date: Tue, 7 Aug 2012 13:55:13 +0300

On Aug 7, 2012, at 1:07 PM, Margaret Wasserman wrote:

> We should also do something (a hash, or whatever) to bind those keys to the contents of a specific request,

Authentication Data field of the Authentication Tag Option in your I-D does that.

> so that we can be sure that the contents of the request haven't been modified/replaced.  If we include a time and/or the transaction ID in the hash, I think we can guard against replay attacks that way.  I think that would do it.
> 

Yes.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 07 Aug 2012 23:24:22 +0900

Alper,

> And because of this demux design, "now" we want to make sure no one will ever set bit#7.

I think "no one will ever set bit#7" is too much restricted.

Because of in-band key management, a bit in the PANA "Reserved" field
to be used for demultiplexing "over PCP port" can be meaningful only
when PANA message is carried "over the PCP port".   The bit could also
be used for demultiplexing other application carried over another port
if the other application allows to use the bit for demultiplexing
purpose as well.

>From PANA perspective, we can now allocate the whole 16-bit "Reserved"
PANA field for "in-band key management usage", and let each
application including PCP define how to demultiplex using the 16-bit.
 I think this is a cleaner and extensible approach.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Tue, 7 Aug 2012 19:16:07 +0300

Hi Yoshi,

> if the other application allows to use the bit for demultiplexing

We can either say:

Bit#7 is reserved for use with PCP. (And it's always set to 0).

Or,

When used over PCP port, Bit#7 is always set to 0.
When used over other ports, its reserved for future use (as it currently is).

Latter one is more conservative about bit usage, but a bit more cumbersome. Not sure which way to go.

> I think this is a cleaner and extensible approach.

We may not want to give up on the 16-bit space for encoding one type of usage (in-band). Let's think about this…..

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 7 Aug 2012 13:30:28 -0400

> Latter one is more conservative about bit usage, but a bit more cumbersome. Not sure which way to go.

The problem comes in when/if PCP wants to allocate another version number.

Could we use the top nibble (4 bits) for demultiplexing, and leave PCP with a 4-bit version number, and PANA with 4 bits for future use?

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Aug 2012 14:01:14 -0400

If you are concerned about server DOS issues, the general solution is to
have the server send the client an encrypted cookie so the server
maintains no state.
See for example RFc 6113  section 5.2.
That's a Kerberos mechanism but it has similar properties.

EAP protocols have generally not done that, but it's certainly possibly
to do with EAP-like things. We designed draft-ietf-abfab-gss-eap to
permit extending to this use in the future if needed. The Moonshot
implementation of draft-ietf-abfab-gss-eap supports the necessary
mechanisms for no server state, demonstrating that it is possible.

Everything I say here can be applied to PANA with a bit of creativity.

---

From: Alper Yegin <[email-masked]>
Date: Tue, 7 Aug 2012 23:57:51 +0300

> Everything I say here can be applied to PANA with a bit of creativity.

PANA itself already has that property.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 7 Aug 2012 17:10:16 -0400

Hi Alper,

> PANA itself already has that property.

The specific discussion was about whether we can piggyback authentication messages in the PCP request/response packets when PANA is used in an encapsulated mode.  So, while PANA itself may not require server state, it can't (alone) prevent the PCP Server from needing to maintain server state in this case.  While we probably could achieve this using encapsulated PANA, we would also need to do something to retain the PCP Server state as part of the session.

Margaret

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 08 Aug 2012 08:39:40 +0900

Alper,

> Bit#7 is reserved for use with PCP. (And it's always set to 0).

This is over-specified as I explained above.

> Latter one is more conservative about bit usage, but a bit more cumbersome. Not sure which way to go.

The latter one does not work.  Once we define some PANA bits for
in-band key management (for whatever application protocol), the same
bits cannot be used for future new PANA extensions commonly applicable
to both plain PANA and in-band PANA.  Therefore, the bits won't be
able to be marked as reserved any more once we give out.

This is what I think:

- Decide on how many bits (4 bits?) are needed from the 16-bit PANA
"Reserved" field for in-band key management.

- Write a new PANA I-D to allocate the in-band bits that are not bound
to any specific application protocol in the I-D.  Perhaps you and I
can work on this.

- Describe PCP-specific usage of the in-band bits in
draft-ietf-pcp-authentication.

> We may not want to give up on the 16-bit space for encoding one type of usage (in-band). Let's think about this…..

I agree with you that we don't need to give up on the whole 16-bit
space.  I think the top 4 bits should be sufficient as Margaret
mentioned.

Yoshihiro Ohba

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Aug 2012 10:02:44 -0700

> james woodyatt
> Sent: Monday, August 06, 2012 4:03 PM
> To: [email-masked]
> A related question might be what existing NAT-PMP implementations will
> do if they receive a message containing a PANA packet. 

That is important to consider.  However, the message flows I have seen
show:

  PCP client                           PCP server
      |                                    |    
1.    |------PCP MAP request-------------->|
2.    |<---error, need authentication------|
      |                                    |
3.    |-(several authentication messages)->|
4.    |<-(several authentication messages)-|

If the PCP client is really communicating with a NAT-PMP server, it
would look like this,

  PCP client                           NAT-PMP server
      |                                    |    
1.    |------PCP MAP request-------------->|
2.    |<---error, wrong version------------|
      |                                    |    
3.    |------NAT-PMP request-------------->|
4.    |<---ok------------------------------|
      |                                    |    

So, I think we are okay -- assuming we keep the idea that the PCP 
client tries to first send a PCP request (and not to first send
a PANA request).  

However, I do worry that implementations may optimize themselves
to send a PANA request first, which would cause the problem you
describe if they send the PANA request to a NAT-PMP server.  That
is, this would be a problem:

  PCP client                           NAT-PMP server
      |                                    |    
1.    |-------(authentication message)---->|
2.    |<--NAT-PMP error--------------------|
      |                                    | 

But the PCP client doesn't speak NAT-PMP, so there isn't a way
for it to handle that case, anyway (no matter if we had PCP
authentication or not).

In summary, I think we can skate around problems with talking
to a NAT-PMP server.

-d

> Assuming they
> comply with I-D.cheshire-nat-pmp-03, they will interpret the first two
> octets of a PANA message as an announcement request, and they will
> reply with the announcement response message shown below.
> 
>     0                   1                   2                   3
> If a PCP server needs to implement NAT-PMP too, then it can easily
> distinguish a NAT-PMP announcement request from a PANA message, but one
> wonders if a PANA client expecting to authenticate to such a server can
> deal with replies from a NAT-PMP server that knows nothing about either
> PCP or NAT-PMP.
> 
> 
> --

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 8 Aug 2012 13:07:09 -0400

> client tries to first send a PCP request (and not to first send

Actually, we don't keep this, even now.  There is certainly a notion that a client could be configured to use authentication for all (or some) PCP exchanges, and that the authentication would come first.  

> In summary, I think we can skate around problems with talking

Makes sense.

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Aug 2012 13:47:04 -0400

It's not just that implementations may optimize sending an
authentication request.

An implementation MAY require authentication.
I.E. it is unwilling to send the request unless it has an authenticated
channel.
For firewall control this makes a lot of sense.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Aug 2012 10:57:17 -0700

> Sent: Wednesday, August 08, 2012 10:07 AM
> To: Dan Wing
> Cc: 'james woodyatt'; [email-masked]
> Actually, we don't keep this, even now.  There is certainly a notion
> that a client could be configured to use authentication for all (or
> some) PCP exchanges, and that the authentication would come first.

But slide 5 of your deck,
http://tools.ietf.org/agenda/84/slides/slides-84-pcp-10.pdf,
shows the PCP client doing an initial PCP request and getting an
AUTH_REQUIRED 
error.  That is the basis of my (lovely) ASCII artistry.

> For firewall control this makes a lot of sense.

I believe we are okay -- the PCP client trying to do authentication will 
have to expect it will occasionally see a NAT-PMP error message.  That
will occur if it is communicating with a NAT-PMP server (which shares the
same port as PCP).  If the PCP client receives a NAT-PMP error, it needs
to abort trying to do PCP and abort trying to do PANA (because neither
will work); in the (unlikely) event the PCP client also implements 
NAT-PMP, it can then downgrade to using NAT-PMP.

A sentence or three in draft-ietf-pcp-authentication will be needed 
to explain that a NAT-PMP error might be received.

-d

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Thu, 9 Aug 2012 01:56:34 +0000

Slide 5 only illustrates a scenario where the pcp server initiates the authentication procedure. But in our draft, it is also described that the client can initiate authentication proactively. In my opinion, this approach seems even more preferable.  ^_^

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
> Wing
> Sent: Thursday, August 09, 2012 1:57 AM
> To: 'Margaret Wasserman'; [email-masked]
> Cc: [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Aug 2012 19:29:15 -0700

> From: Zhangdacheng (Dacheng) [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2012 6:57 PM
> To: Dan Wing; 'Margaret Wasserman'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [pcp] Comparison of PCP authentication
> 
> Slide 5 only illustrates a scenario where the pcp server initiates the
> authentication procedure. But in our draft, it is also described that
> the client can initiate authentication proactively. In my opinion, this
> approach seems even more preferable.  ^_^

Depends on if we want to optimize for the case where PCP authentication
is necessary or is unnecessary.

Doing PANA first is a good optimization only if the PCP client knows 
that PCP authentication will be required by the PCP server on that 
particular network.  If PCP authentication is not needed on a particular 
network, requesting PCP authentication incurs an extra round trip.

If the PCP server doesn't want authentication, I believe we can always 
rely on a PCP error response if for PANA messages and for 
PCP-encapsulated (tunneled) PANA messages (which I believe are the two
proposals being considered) -- thus, we won't have timeouts due to
requesting authentication, which is good.

-d

> Dan

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Thu, 9 Aug 2012 06:07:01 +0000

If a client has been configured to support PANA, then it is more likely to stay in an environment where authentication is required, is it? ^_^ However, if this assumption is broken, then two approaches do not make big differences. 

> From: Dan Wing [mailto:[email-masked]]
> Sent: Thursday, August 09, 2012 10:29 AM
> To: Zhangdacheng (Dacheng); 'Margaret Wasserman';
> [email-masked]
> Cc: [email-masked]

---

From: Alper Yegin <[email-masked]>
Date: Thu, 9 Aug 2012 12:31:56 +0300

> proposals being considered) 

My understand is that there are two alternatives we are considering for using PANA for PCP authentication over the same PCP port:

1. Encapsulate PANA over PCP (e.g., define a dedicated PCP option that encapsulate PANA packet).
2. Define a way to demux PANA and PCP even when they operate over the same port (no encapsulation).

Right?

I might have lost track, just seeking confirmation…

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 9 Aug 2012 08:44:48 -0400

Hi Alper,

> 2. Define a way to demux PANA and PCP even when they operate over the same port (no encapsulation).

Yes, these are the two PANA-based approaches we are considering.

Someone asked, at the end of the meeting, that we also keep the PCP-Specific approach in the document, so that we could compare all three approaches at the interim conference call, so we will do that, too, since it doesn't require any significant work.

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Aug 2012 09:25:22 -0400

>>>>> "Dan" == Dan Wing <[email-masked]> writes:

    Dan> Doing PANA first is a good optimization only if the PCP client
    Dan> knows that PCP authentication will be required by the PCP
    Dan> server on that particular network.  If PCP authentication is
    Dan> not needed on a particular network, requesting PCP
    Dan> authentication incurs an extra round trip.

Thinking about this as an optimization seems wrong to me.

consider the case where the client wants authentication but the server
does not require it.  For example, the client wants integrity protection
of the result of the request.
In this case it's about security requirements *not* optimization.
The client needs a way to force the server to require authentication.

Another case where this becomes important is where a server will accept
requests from unauthenticated clients but treat them differently. For
example an authenticated client is allowed to ask for longer lifetimes,
etc.

Especially since interacting with firewalls is in-scope for PCP,
supporting clients with higher security requirements seems and important
design goal for a PCP authentication mechanism.

So, I don't think we should be thinking of this purely in terms of
optimization.

---

From: Alper Yegin <[email-masked]>
Date: Thu, 9 Aug 2012 18:41:20 +0300

Hi Margaret,

> Someone asked, at the end of the meeting, that we also keep the PCP-Specific approach in the document, so that we could compare all three approaches at the interim conference call, so we will do th…

There was a clear decision at the meeting to go with a PANA-based solution, not with EAP-over-PCP solution. Given that the decision is already made, why do we need to keep other options still floating in the WG document?

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 9 Aug 2012 10:07:08 -0700

> Sent: Thursday, August 09, 2012 5:45 AM
> To: Alper Yegin
> Cc: Dan Wing; 'Zhangdacheng (Dacheng)'; [email-masked];
> [email-masked]
> Subject: Re: single port PANA+PCP
> 
> 
> Hi Alper,
> 
> > My understand is that there are two alternatives we are considering
> for using PANA for PCP authentication over the same PCP port:
> >
> Someone asked, at the end of the meeting, that we also keep the PCP-
> Specific approach in the document, so that we could compare all three
> approaches at the interim conference call, so we will do that, too,
> since it doesn't require any significant work.

That was me that asked.  We need all three with pro/con to understand
what value we get and what problems we solve.  

Thanks,
-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 9 Aug 2012 10:07:08 -0700

> Sent: Wednesday, August 08, 2012 11:07 PM
> If a client has been configured to support PANA, then it is more likely
> to stay in an environment where authentication is required, is it? ^_^

On the other hand, it would be annoying if configuring PCP authentication 
for one network (e.g., office network) added a round trip when on networks 
that don't need PCP authentication (e.g., home network, airport, hotel,
3G/LTE network).  Heuristics to decide "same network" or "different network"
are probably helpful for PCP to distinguish those networks (e.g., 
DNAv4 [RFC4436]).

> However, if this assumption is broken, then two approaches do not make
> big differences.

Two approaches force additional code and test cases.

-d

> > > > I believe we are okay -- the PCP client trying to do
> authentication
> > > will
> > > > will occur if it is communicating with a NAT-PMP server (which
> shares
> > > the
> > > > same port as PCP).  If the PCP client receives a NAT-PMP error,
> it
> > > needs

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 9 Aug 2012 10:07:08 -0700

> From: Alper Yegin [mailto:[email-masked]]
> Sent: Thursday, August 09, 2012 2:32 AM
> To: Dan Wing
> Cc: 'Zhangdacheng (Dacheng)'; 'Margaret Wasserman'; hartmans@painless-
> security.com; [email-masked]
> Subject: single port PANA+PCP
> 
> My understand is that there are two alternatives we are considering for
> using PANA for PCP authentication over the same PCP port:
> 
> I might have lost track, just seeking confirmation.

Yes, I believe those are the two approaches being considered.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 9 Aug 2012 10:55:52 -0700

> From: Sam Hartman [mailto:[email-masked]]
> Sent: Thursday, August 09, 2012 6:25 AM
> To: Dan Wing
> Cc: 'Zhangdacheng (Dacheng)'; 'Margaret Wasserman'; [email-masked]

I am struggling to imagine a PCP client that would refuse to do MAP
or PEER because its PCP server doesn't support authentication.

> example an authenticated client is allowed to ask for longer lifetimes,

That sounds reasonable.  But we could solve that differently than trying
authentication first all the time, such as for example including an 
"I WILL DO AUTHENTICATION IF I GET BETTER CHOCOLATE COOKIES" in the 
initial PCP request, which triggers a PCP authentication required error.

> supporting clients with higher security requirements seems and
> important design goal for a PCP authentication mechanism.
> 

-d

---

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

>>>>> "Dan" == Dan Wing <[email-masked]> writes:

    Dan> I am struggling to imagine a PCP client that would refuse to do
    Dan> MAP or PEER because its PCP server doesn't support
    Dan> authentication.

If I'm updating security policy on a firewall I want to be able to audit
whether that actually happened.
That requires authentication.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 9 Aug 2012 11:32:28 -0700

> Sent: Thursday, August 09, 2012 11:20 AM
> To: Dan Wing
> If I'm updating security policy on a firewall I want to be able to
> audit whether that actually happened.  That requires authentication.

You are saying a PCP client would only want to update firewall policies 
if the PCP server supports authentication, otherwise it would tell the
user that it cannot enable the webcam, Internet-connected NAS, 
Internet-connected printer, etc.?

-d

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 9 Aug 2012 15:12:05 -0400

Hi Alper,

> There was a clear decision at the meeting to go with a PANA-based solution, not with EAP-over-PCP solution. Given that the decision is already made, why do we need to keep other options still float…

I'm not a WG chair, so it is not my place to call consensus of the room.  However, I don't _think_ we actually had consensus at that point in the discussion...  IIRC (and you should feel free to refer to the minutes when available to check my memory), about 1/3 of the people who expressed an opinion preferred a PCP-specific approach and 2/3 preferred a PANA-based approach (either a PANA encapsulation or a PCP/PANA demultiplexing).

There was, IIRC, consensus that we wanted a single-port solution.

I'm hoping we will emerge from the interim conference call with consensus on a single approach to pursue, and I currently expect it will be one of the PANA-based approaches.  However, I don't think that has been completely nailed down yet.

We also have the open question from Dave Thaler about whether to consider at DTLS-based approach.  I would be interested in hearing from other members of the WG whether a DTLS-based approach is of enough interest that we should document what that would look like, and include it in the trade-off discussion at the interim, or not.

I'm not really looking for _more_ choices here, but I would like us to fairly considered all of the sensible options and make a solid, technical choice.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 9 Aug 2012 15:21:25 -0400

> Internet-connected printer, etc.?

I wont presume to guess what Sam is thinking...

However, I am thinking that there will be some clients  that are configured to perform authentication for every request.  For example, there is no reason for a PCP proxy, running in an environment where authentication is required to do a THIRD-PARTY request, to perform a useless round-trip for every THIRD-PARTY request it issues.  

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Aug 2012 15:22:53 -0400

>>>>> "Dan" == Dan Wing <[email-masked]> writes:

    Dan> You are saying a PCP client would only want to update firewall
    Dan> policies if the PCP server supports authentication, otherwise
    Dan> it would tell the user that it cannot enable the webcam,
    Dan> Internet-connected NAS, Internet-connected printer, etc.?

I'm saying that a PCP client poking a hole in an enterprise firewall for
an enterprise server almost certainly wants to log an auditable event if
it cannot confirm it updated the firewall policy.
On the same network a webcam might not care what server it talked to.

Note there are a lot of ways of meeting the security requirement for
auditability. For example we can have a PCP message that requests a
server send us back an authentication error if it can do that.

--Sam

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Thu, 16 Aug 2012 02:47:16 +0000

Have we got any conclusions on two approaches?  Or we can just support the two options in the draft for the moment and briefly compare their pros and cons, can we?

Cheers

Dcheng

From: [email-masked] [mailto:[email-masked]] On Behalf Of Margaret Wasserman
Sent: Friday, August 10, 2012 3:21 AM
To: Dan Wing
Cc: [email-masked]
Subject: Re: [pcp] Comparison of PCP authentication

Margaret

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 16 Aug 2012 12:41:36 +0900

Here is a brief comparison on both PANA-based schemes:

Encapsulation/tunneling approach:
- Pros: No impact on PANA specification
- Cons: Encapsulation overhead

Demultiplexing/port-sharing approach:
- Pros: No encapsulation overhead
- Cons: Impact on PANA specification (an Update of RFC 5191 is needed
on the use of "Reserved" field.)

Hope this helps,
Yoshihiro Ohba

(2012/08/16 11:47), Zhangdacheng (Dacheng) wrote:
> Have we got any conclusions on two approaches?  Or we can just support 
> the two options in the draft for the moment and briefly compare their 
> pros and cons, can we?
> 
> Cheers
> 
> Dcheng
> 
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Margaret Wasserman
> *Sent:* Friday, August 10, 2012 3:21 AM
> *To:* Dan Wing
> *Cc:* [email-masked]
> *Subject:* Re: [pcp] Comparison of PCP authentication
> 
> However, I am thinking that there will be some clients  that are 
> configured to perform authentication for every request.  For example, 
> there is no reason for a PCP proxy, running in an environment where 
> authentication is required to do a THIRD-PARTY request, to perform a 
> useless round-trip for every THIRD-PARTY request it issues.
> 
> Margaret
> 
> 
>

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Thu, 16 Aug 2012 08:52:03 +0000

> - Cons: Encapsulation overhead
About this Con. Maybe we can remove the redundant information in a pana packet and only transport the necessary part in a pcp packet. Therefore, after receiving the PCP packet, the receiver can re-construct the pana packet.

Dacheng

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 16 Aug 2012 18:24:04 +0900

Dacheng,

> About this Con. Maybe we can remove the redundant information in a pana packet and only transport the necessary part in a pcp packet. Therefore, after receiving the PCP packet, the receiver can re-…

If "remove the redundant information" means a change of the basic PANA
PDU format other than defining a new use of "Reserved" field, then it
is going towards "re-inventing the wheel" direction which we should
not go.

Yoshihiro Ohba

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 16 Aug 2012 07:38:30 -0400

Hi Dacheng,

The conclusion from the meeting was that we will document all three approaches in our document:

- PCP Specific
- PANA Encapsulated in PCP
- PANA Demultiplexed with PCP on the same port

Then, we will have an interim PCP conference call to discuss the trade-offs and hopefully decide between them.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 16 Aug 2012 07:41:01 -0400

Hi Yoshi,

> on the use of "Reserved" field.)

In both cases, I think there is an open question (raised by my regarding your draft) of whether we want to modify PANA so that the server will know that it is performing PCP authentication vs. network access authentication.  I think this could be important, if we want a single PANA server to be able to serve both purposes in a small network.  It is possible that the credentials/criteria used to authenticate a node for PCP will be different than for network access, isn't it?

Margaret

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 16 Aug 2012 21:45:33 +0900

Hi Margaret,

In my opinion, PANA should be dedicated to PCP authentication in both
cases where PANA runs over PCP port.

In other words, we can say that PANA is used for network access
authentication only when PANA operates over PANA port, regardless of
whether the same or different credentials are used for PCP
authentication and network access authentication.

Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Thu, 16 Aug 2012 08:46:17 -0400

I have a question.
As background reading I recommend taking a look at RFC 6677 section 5.1.

If we want to use EAP channel binding to bind an authentication to a
specific PCP server, how will we do that with PANA?

For all three approaches we need to define i1 or what attributes the client
sends in the EAP channel binding to give the identity of the PCP
server. We could for example use the IP address of the PCP server in the
nas-ip-address (or v6 address) AVP.

For the PCP specific approach the rest is easy. The PCP server knows it
is a PCP server, and includes those attributes in the AAA message
so that  the EAP server has i2.

How does the PANA server find out i2?

RFC 6677 strongly recommends that an eap-lower-layer attribute be
included.  There's a value defined for PANA.  However, that wouldn't
really be a good choice here because it would not allow an EAP server to
distinguish PCP authentications from uses of PANA for network access.
how does the PANA server know which eap-lower-layer to include?

--Sam

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 16 Aug 2012 08:53:37 -0400

Hi Yoshi,

I thought the point of running PANA over/beside PCP, instead of using a PCP-specific mechanism, was that the PCP Server could hand the PANA request to a separate PANA server for processing, just like a PANA Relay would hand-off a PANA request to a PANA Server.  

How will that PANA Server (the one that receives the PANA request from the PCP Server, presumably on the PANA port) know that the request is coming from a PCP Server and concerns PCP access, and that it isn't a network access request from a regular PANA PaC or Relay?  I think it is pretty important that we not set-up a situation where a PANA server could think that it is authorizing network access while it is actually authorizing PCP requests, don't you?

Margaret

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 16 Aug 2012 22:41:04 +0900

Hi Margaret,

I understand your point.

I think the challenging case is that the same node is acting as PANA
relay for both network access authentication and PCP authentication
where the both types of authentication goes to the same PAA.  In this
case, probably PANA needs to be extended to carry additional
information (a new flag or AVP) for distinguishing the two types of
authentication.  Once the additional information is defined, then the
information may also be used for channel binding purpose.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Aug 2012 11:09:03 +0300

> The conclusion from the meeting was that we will document all three approaches in our document:

Could the chairs please declare what the meeting conclusions and next steps are.

Thanks.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Aug 2012 11:14:59 +0300

EAP Authenticator is on the PCP server.
Hence, PAA (PANA Authentication Agent) and PCP server are on the same node.
Therefore, the PAA can tell whether it's authenticating the PaC for PCP or for network access by looking at the destination port.
That's sufficient.

(I don't know why you folks are digressing to another model where EAP authenticator resides on a different node than the PCP server --  in which case we need to engage PANA relay (OK, fine) ; and EAPoPCP folks need to come up with yet another solution to relay the EAP from PCP server to the EAP authenticator).

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Aug 2012 11:22:21 +0300

(spinning off a new thread for easier tracking)

What value are you thinking of using for i1 and i2? IP address of the PCP server?
If so, you can do that in any of those solutions. 
Is there a problem?

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Aug 2012 11:36:28 +0300

> on the use of "Reserved" field.)

I prefer the latter approach as this seems to be most straightforward.

Yoshi and I exchanged some emails to figure out what needs to be done, and here's the finding:

We have 16 Reserved bits in PANA header.
Bits 5-6-7 will be used for demux'ing between PANA and PCP when the two are run over the PCP port.
PCP version 2 sets the values to 0-1-0 and future versions would be 0-1-1, 1-0-0, … 1-1-1 -- should be enough.

PCP-spec would state the following:
- When PANA is executed over the PCP port, sender shall set the Bits 5-6-7 to 0-0-0 and the receiver shall ignore them.
(Other reserved bits and Bits 5-6-7 when used over ports other than PCP port are still governed by RC 5191).

RFC 5191 will include an "Updated by RFC(PCP-spec)".

Alper

---

From: Sam Hartman <[email-masked]>
Date: Fri, 17 Aug 2012 09:07:47 -0400

Alper> EAP Authenticator is on the PCP server.  Hence, PAA (PANA
    Alper> Authentication Agent) and PCP server are on the same node.
    Alper> Therefore, the PAA can tell whether it's authenticating the
    Alper> PaC for PCP or for network access by looking at the
    Alper> destination port.  That's sufficient.

So you are happy to decide PCP authentication doesn't need a PANA relay?
If so, I propose we explicitly decide that.

It makes my channel binding question easier.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 17 Aug 2012 09:06:28 -0400

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

    Alper> (spinning off a new thread for easier tracking)

    Alper> What value are you thinking of using for i1 and i2? IP
    Alper> address of the PCP server?  If so, you can do that in any of
    Alper> those solutions.  Is there a problem?
I'm not entirely sure what we need for i1 and i2.
I think it definitely needs to include:

* an indication that it is PCP
* IP address.

Possibly this is easy.
Can you give a clear algorithm for determining what ip address to use in
i2?

--Sam

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Aug 2012 23:53:27 +0900

I am ok without supporting PANA relay for PCP authentication.

It also makes key management easier because remote transport of PCP
key from PAA to PCP server is needed if PANA relay is supported for
PCP authentication.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Aug 2012 18:50:35 +0300

> Can you give a clear algorithm for determining what ip address to use in

For i2, we need new RADIUS attribute(s)/Diameter AVP(s) to carry an indication that this is for PCP authentication, and the IP address facing the PCP client/PANA Client.
These would constitute i2.
Note that the IP address used by the node implementing PAA and PCP server may be different than the IP address used by the same node with its AAA client. That's why I said "facing…"

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Aug 2012 18:54:46 +0300

> So you are happy to decide PCP authentication doesn't need a PANA relay?

I really didn't understand when this "split EAP authenticator from PCP server" case came into the picture.
Unless someone has a real use case behind it, we can ignore that case.

> key from PAA to PCP server is needed if PANA relay is supported for

Well, such a thing would have been needed irrespective of what carried EAP (PCP itself or PANA) if we were to deal with the split case.

Alper

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Mon, 20 Aug 2012 07:07:51 +0000

+1

> Sent: Friday, August 17, 2012 10:53 PM
> To: Sam Hartman
> Cc: [email-masked]

---

From: Subir Das <[email-masked]>
Date: Wed, 29 Aug 2012 09:26:54 -0400

Margaret,
I realized that I didn't copy my  mail to the mailing list.

Thanks,
-Subir

---------- Forwarded message ----------
From: Subir Das <[email-masked]>
Date: Fri, Aug 17, 2012 at 8:29 AM
Subject: Re: [pcp] Comparison of PCP authentication
To: Margaret Wasserman <[email-masked]>

Hi Margaret,
My recollection regarding conclusion was little different:

We will discuss  the following two PANA-based approaches and then decide:

The consensus in the room  was that PANA-based approach is preferrable over
PCP specific approach. I need to look at the meeting minutes and recording
though.

regards,
_Subir

On Thu, Aug 16, 2012 at 7:38 AM, Margaret Wasserman
<[email-masked]>wrote:

> Then, we will have an interim PCP conference call to discuss the
> trade-offs and hopefully decide between them.
>
> Margaret
>
>
>
> Have we got any conclusions on two approaches?  Or we can just support the
> two options in the draft for the moment and briefly compare their pros and
> cons, can we?****
> ** **
> Cheers****
> ** **
> Dcheng****
> ** **
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Margaret
> Wasserman
> *Subject:* Re: [pcp] Comparison of PCP authentication****
> ** **
> ** **
> On Aug 9, 2012, at 2:32 PM, Dan Wing wrote:****
>
> ** **
>
> If I'm updating security policy on a firewall I want to be able to****
>
> audit whether that actually happened.  That requires authentication.****
>
>
> Internet-connected printer, etc.?****
>
> ** **
> I wont presume to guess what Sam is thinking...****
> ** **
> configured to perform authentication for every request.  For example, there
> is no reason for a PCP proxy, running in an environment where
> useless round-trip for every THIRD-PARTY request it issues.  ****
> ** **
> Margaret****
> ** **
> ** **
>
>
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 29 Aug 2012 08:59:11 -0700

I went to the audio, to try to understand this resistance to analyzing
everything.

The discussion of the three options started at about 77 minutes into the
audio, which is at
http://www.ietf.org/audio/ietf84/ietf84-regencya-20120802-1510-pm2.mp3.  The
audio quality is pretty poor.

I heard:
 1.  separate PCP-dedicated function:  4 hands
 2.  PANA 'tunnel': ? hands (I could not hear)
 3.  PCP/PANA demux: 5 hands
 4.  don't care:  ? hands (I could not hear)

then, after a little more hand-raising, PANA had twice the votes of a
separate PCP-dedicated function.  Alain said the direction is PANA on a
single port.  I then heard myself asking at the microphone that I answered
"don't care" because I lack enough information to decide.  I couldn't hear
Margaret's reply in the audio.

In any event, I am struggling to understand the resistance to analyzing all
three in detail.  Worried a non-PANA solution will win, or the analysis will
take an additional 15 minutes, or what?

-d

> Subir Das
> Sent: Wednesday, August 29, 2012 6:27 AM
> To: Margaret Wasserman
> Cc: [email-masked]
> Subject: [pcp] Fwd: Comparison of PCP authentication
> 
> Margaret,
> The consensus in the room  was that PANA-based approach is preferrable
> over PCP specific approach. I need to look at the meeting minutes and
> recording though.
> 
> regards,
> _Subir
> 
> <[email-masked]> wrote:
> 
> 
> 
> 
> 	Hi Dacheng,
> 
> 		Have we got any conclusions on two approaches?  Or we can
> just support the two options in the draft for the moment and briefly
> compare their pros and cons, can we?
> 
> 		Cheers
> 
> 		Dcheng
> 
> 				If I'm updating security policy on a
firewall I
> want to be able to
> 			You are saying a PCP client would only want to
update
> firewall policies
> 		However, I am thinking that there will be some clients
> that are configured to perform authentication for every request.  For
> example, there is no reason for a PCP proxy, running in an environment
> where authentication is required to do a THIRD-PARTY request, to
> perform a useless round-trip for every THIRD-PARTY request it issues.
> 
> 		Margaret
> 
> 
> 
> 
>

---

From: Subir Das <[email-masked]>
Date: Wed, 29 Aug 2012 13:19:29 -0400

I also tried the audio and it was very poor. You have summarized it nicely
though. I am not resisting anything, I was merely stating my takeway on
Chair's statement.

-Subir

On Wed, Aug 29, 2012 at 11:59 AM, Dan Wing <[email-masked]> wrote:

> >               From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Margaret Wasserman
> >                       if the PCP server supports authentication,
> otherwise
> > it would tell the

---

From: Sam Hartman <[email-masked]>
Date: Wed, 29 Aug 2012 14:20:47 -0400

I was not at the meeting.
I'll note a couple of IETF process points though; RFC 2418 is a good
read on issues like this:

1) This decision would need to be confirmed on the list anyway; a
consensus of the room does not make a decision.

2) Let's say that there were 8 hands in favor of PANA onsame port and 4
hands in favor of PCP-specific.  That's kind of questionable as a rough
consensus.  It's certainly sufficient to say that the room was moving
towards PANA on same port, but 2/3 is kind of iffy for calling rough
consensus depending on the issue and on level of discussion.  Certainly,
if additional discussion doesn't make things more clear, and if we
confirm that the WG is more interested in progress on this issue than
blocking (which I suspect strongly it is), then you might eventually
make a decision at 2/3.
You might make a decision at 2/3 much earlier if no one in the 1/3 cared
much.

I was not counted in the room, so I'll need to be counted when
confirming on the list.  I prefer a PCP-specific solution.  However, I
need more information before I'll be able to say whether I strongly
prefer the PCP-specific solution, or whether it's a weak preference
among similar technical approaches.

I know there are others who have expressed opinions who were not in the
room.  For example I think Alper has indicated he prefers a PANA-based
solution and I believe I recall he could not make the meeting.

I definitely would prefer understanding all the options.

--Sam