Protocol for Carrying Authentication for Network Access (PANA) Framework
draft-ietf-pana-framework-10

[Ballot comment]
Great work, guys. This is much simpler than what we had
in the initial version.

Nit: In -framework, Section 2:

  When cryptographic access control is used, a secure association
  protocol (e.g., [RFC2409], [RFC4306], [802.11i]) needs to run
  between the PaC and EP.

I would suggest deleting the references or replacing them with
a reference to RFC 3748 or an informational reference to eap-keying.
The reason is to avoid any possibility of misunderstanding
whether PANA works out-of-the-box with, say 802.11i SAP.

[Ballot comment]
In -framework, Section 2:

  When cryptographic access control is used, a secure association
  protocol (e.g., [RFC2409], [RFC4306], [802.11i]) needs to run
  between the PaC and EP.

I would suggest deleting the references or replacing them with
a reference to RFC 3748 or an informational reference to eap-keying.
The reason is to avoid any possibility of misunderstanding
whether PANA works out-of-the-box with, say 802.11i SAP.

[Ballot comment]
The PANA protocol document says that the derivation of keys for use in
setting up or binding to link or layer 3 security is out of scope.
That's fine and probably even a good idea.  however there needs to be
a single document that specifies this derivation that all the uses of
the PANA SA end up referring to.  IT would be inappropriate for the
PANA IPsec document to use one method and say a method to set up
preshared secrets for 802.11I to use another mechanism that might
interact badly with the ipsec mechanism.

[Ballot discuss]
First, I'd like to compliment Mark and the PANA working group on the
excellent work they have done over the last year.  I fully expected to
be unable to support publication of PANA when it came to the IESG.
While I do have some blocking comments, I think they are easy to
resolve and expect to be able to remove my discuss when that happens.
What an excellent job making PANA easier to understand and removing
complexity.


What must a receiver do if it receives a PANA message with unknown
version?  How is the version field actually useful?  (How do you get
backward compatibility if you discard packets with unknown version?)

The framework document says that sometimes a PAC is expected to
reconfigure its address after PANA.  The PANA protocol has no
normative discussion of this.  In order to get interoperable
implementations, you need to clearly indicate when address
configuration is required.  Perhaps you are deferring this to future
documents.  If so, then the framework should indicate that unless a
PAC implements a protocol extension that mandates address
reconfiguration and that protocol extension is used, then the PAC need
not do address configuration.  Or, if address reconfig is supported in
the base protocol, you need to have normative language describing it.


The framework document talked about a lot of options having to do with
the underlying link and security.  It seems that the mandatory to
implement behavior from the protocol document is support for integrity
of PANA messages using EAP methods that produce MSKs but no mandatory
to implement support for link security either at layer 2 or 3.  If so,
please make this clear in the framework document.  If not, explain
what I'm missing.

Section 5.5 of the protocol document should include a rule that
messages expected to have an auth attribute but which do not do so
MUST be discarded.  You need to specify which messages are expected to
have auth attributes (presumably all of them after a completed
authentication with an EAP method that generates an MSK).

Please describe how PANA will migrate to a new hash.  You need a
negotiation mechanism so that one side can determine the capabilities
of the other and so that you can maintain backward compatibility when
deploynig a new hash or PRF.
I am not sure the algorithm AVP quite gives you this.
Also, you SHOULD protect your negotiation after the fact so that  if an attacker modifies the unprotected negotiation then the modification will be detected.
I'm particularly concerned that even if the  algorithm AVP is sufficient, you recommend against using it unless the link is secured.  That seems highly problematic; protected negotiation is a better solution.

I am uncomfortable with the claim in the protocol document's security
consideration section that physical security provides protection of
confidentiality and spoofing.  I'm not really sure that is true in any
reasonable sense for DSL lines.  I think a better way to state this is
that the environment provides adequate protection against spoofing and
confidentiality based on the operational needs of the environment.
Similarly, I'm concerned that the blanket claim that if a link does
not provide security then security is required at a higher layer.  I
agree that PANA integrity protection is required, but for example I
don't see why data origin authentication or connectionless integrity
is required for most Internet traffic.  I think the security
considerations section could be reworked to talk a lot more about
tradeoffs and a lot less about hard requirements.
Some hard requirements are probably still necessary.

I am uncomfortable with the recommendation of eap methods like md5
even when link security is available.  Can you please work with the
EAP and EMU working groups and see if they support this recommendation
in the framework document?

[Ballot discuss]
What language is used to provide the declarations present in section 7.2 to 7.7? A reference to the defintion of this language is required.

Section 9.

There is unclarity on if IRT is absolute time value or an amount of time. Based on the formulas the later, but that is not clear in the text definitions. Also the definition of RT is a bit of. RT is the amount of time from the previous transmission, while the intitial defintion may mislead one to think it is an absolute time.

[Ballot comment]
Section 4.1., paragraph 12:
>    It is possible that both the PAA and the PaC initiate the PANA
>    session at the same time, i.e., the PAA unsolicitedly sends the
>    initial PANA-Auth-Request message while the PaC sends a
>    PANA-Client-Initiation message.  To resolve the race condition, the
>    PAA MUST silently discard the PANA-Client-Initiation message received
>    from the PaC after it has sent the initial PANA-Auth-Request message.

  And what must the PaC do when it receives the PANA-Auth-Request from
  the PAA that it didn't expect to get in response to its
  PANA-Client-Initiation message?


Section 6.1., paragraph 2:

>    For any PANA message sent from the peer that has initiated the PANA
>    session, the UDP source port is set to any number and the destination
>    port is set to the assigned PANA port number (to be assigned by
>    IANA).


  "source port is set to any number" - it'd probably be good if the node
  were able to receive packets sent to that port.

  Also, to make this work, you need to also require that all peers
  listen on the PANA port.


Section 7., paragraph 7:
>    message-name    = PANA-name

  ABNF warning: rule message-name previously referred to as Message-Name

PROTO Questionairre



Hello,



The following PANA WG I-D has completed WG last call and is ready for

AD/IESG review.

I-D title: PANA Framework

I-D: draft-ietf-pana-framework-04.txt

Track: Informational



Below are details about the last call and quality of document.



-Basavaraj



=============================================================



1) Have the chairs personally reviewed this version of the ID and do

  they believe this ID is sufficiently baked to forward to the IESG

  for publication?



Yes.





2) Has the document had adequate review from both key WG members and

  key non-WG members? Do you have any concerns about the depth or

  breadth of the reviews that have been performed?



Yes, the document has been reviewed by WG and non WG members. We are

satisfied with depth and breadth of the reviews done on this document.



3) Do you have concerns that the document needs more review from a

  particular (broader) perspective (e.g., security, operational

  complexity, someone familiar with AAA, etc.)?



No concerns here. 



4) Do you have any specific concerns/issues with this document that

  you believe the ADs and/or IESG should be aware of? For example,

  perhaps you are uncomfortable with certain parts of the document,

  or whether there really is a need for it, etc., but at the same

  time these issues have been discussed in the WG and the WG has

  indicated it wishes to advance the document anyway.



None.

 

5) How solid is the WG consensus behind this document?  Does it

  represent the strong concurrence of a few individuals, with others

  being silent, or does the WG as a whole understand and agree with

  it?



There is no dissent in the WG w.r.t this document. There is a good

amount of consensus on publishing it as an Informational RFC as it

provides a clear understanding of PANA in the larger scope.



6) Has anyone threatened an appeal or otherwise indicated extreme

  discontent?  If so, please summarize what are they upset about.



No.

 

7) Have the chairs verified that the document adheres to _all_ of the

  ID nits?  (see http://www.ietf.org/ID-nits.html).



Yes.

 

8) Does the document a) split references into normative/informative,

  and b) are there normative references to IDs, where the IDs are not

  also ready for advancement or are otherwise in an unclear state?



Yes. The references are split in normative and informative

sections. The reference to the I-D :

draft-ietf-zeroconf-ipv4-linklocal-17 in the normative section may be

an issue.



9) For Standards Track and BCP documents, the IESG approval

  announcement includes a writeup section with the following

  sections:



  - Technical Summary

  - Working Group Summary

  - Protocol Quality



This I-D is on an Informational RFC track.



-Chairs

Basavaraj/Alper

AD REVIEW RESPONSE

-------- Original Message --------
Subject: AD-review: pana-fwk (Section 10.1)
Date: Tue, 25 Oct 2005 00:02:38 +0300
From: Alper Yegin
To: 'Mark Townsley'
CC:


>In that case, the client can be assigned a
>  temporary IP address (PRPA) prior to PANA authentication.  This IP
>  address might be obtained via DHCP with a lease reasonably long to
>  complete PANA authentication, or via the zeroconf technique
>  [I-D.ietf-zeroconf-ipv4-linklocal].  In either case, successful PANA
>  authentication signalling prompts the client to obtain a new (long
>  term) IP address via DHCP.  This new IP address (POPA) replaces the
>  previously allocated temporary IP address.
>
>

So, two full DHCP cycles.

Alper: One DHCP cycle can be replaced by a zeroconf operation as the
text stated.


Most "ISP selection" deployments today are based on handoff of L2TP
tunnels (many forced to this model by government regulation). It seems
that this section is incomplete without covering PPP renegotiation of
IPCP (and potentially LCP/AUTH), focusing instead on DHCP only.

Alper: The reason it only talks about DHCP case is that, it does not
make much sense to use PANA when PPP is used. We shall add some text to
state why PPP is not discussed in this section.

Alper

AD REVIEW RESPONSE

-------- Original Message --------
Subject: AD-review: pana-fwk (Section 4)
Date: Mon, 24 Oct 2005 14:26:49 +0300
From: Alper Yegin
To: 'Mark Townsley'
CC:


Mark,

This is for your comments/questions on Section 4 of the pana-fwk
document.

>    The presence of a secure channel before PANA exchange eliminates
>    the need for executing a secure association protocol after PANA.
>    The PANA session can be bound to the communication channel it was
>    carried over.
>
What do you mean by "bound to the communication channel" - do you really

mean that the security requirements of PANA are different depending on
the assumptions implied by underlying link layer?

Alper: If you are saying this in reference to whether or not to run a
secure association protocol, let me note that the secure association
protocol is not part of PANA. Examples are 802.11i 4-way handshake,
802.16e 3-way handshake, IKE. So, it is up-to the architecture to
determine the underlying link-layer capabilities and use the appropriate
protocols (PANA+EAP+secure_assoc+...).

This is different than
"bound" to me (in general, "bindings" between layers are a red flag for
bad design, so I'm not sure you want to suggest this).

Alper: The term "binding" in the context of EAP (RFC3748) and PANA is
used for relating the EAP "session" to a "communication channel". So
that, once the EAP authentication is successful, the network elements
(e.g., EP) know which traffic is allowed. [of course, representation of
a channel depends on the lower-layers...]

============================

Here's where you might suggest EAP Methods to NOT use, and it would be
nice to even venture to suggest ones that SHOULD be used. Even better if

you can name one that MUST be implemented, so that there is at least one

method that is available on all PANA implementations.

Alper: It is better if we stay away from "concrete" EAP method
suggestions. This issue was discussed in EAP WG, as it was already part
of RFC2284. Also, the architectures using EAP decide on this by taking a
multitude of parameters into account. Whether PANA or another EAP
lower-layer is used has not impact on that decision.

Thanks.

Alper

AD REVIEW RESPONSE

-------- Original Message --------
Subject: AD-review: pana-fwk (Section 3)
Date: Mon, 24 Oct 2005 14:04:59 +0300
From: Alper Yegin
To: 'Mark Townsley'
CC:


Hi Mark,



We partitioned the pana-fwk document among the authors in order to handle your review feedback. Let us tackle it section-by-section.



In this message I’ll only include responses to your questions and issues that may require discussion. All the other straight-forward editing is omitted.



Please see below and let us know if you have further comments.





==========================



>  Authentication Server (AS):

>

>    The server implementation that is in charge of verifying the

>

>

Is this another PANA Server?



Alper: No, this corresponds to the RADIUS server. This term is coming from RFC 3748 (EAP). We can clarify this.



==========================



>    The EP uses non-cryptographic or cryptographic filters to

>    selectively allow and discard data packets.  These filters may be

>    applied at the link-layer or the IP-layer.

>

Are the details of how one identifies a packet for a given client is

detailed somewhere? This is very link-specific for the link-layer, but

for IP you should be able to suggest something - is it source IP address?



Alper: We can give a reference to pana-ipsec document here.



===========================



>  Use of IKE or IEEE 802.11i 4-way handshake protocols for secure

> association is only required in the absence of any lower-layer

> security prior to running PANA.  Physically secured networks (e.g.,

>  DSL) or the networks that are already cryptographically secured on

> the link-layer prior to PANA run (e.g., cdma2000) do not require

> additional secure association and per-packet ciphering.  These

> networks can bind the PANA authentication and authorization to the

> lower-layer secure channel that is already available.

>

>

Which begs that question as to, if you already have a cryptographically

secure connection below, why you need another layer of authentication

above. Perhaps the answer to this is that the keys for the lower-layer

crypto may not be owned by the users running PANA. Thus, there is not a

1:1 association, however, the suggestion that you may bind between

layers diminishes this claim.



Alper: The other layer of authentication is needed for “accessing the IP service.� The lower-layer may be already authenticated, authorized, and crypto-secured for another service (e.g., voice in 3GPP2). Or, think of the physical security present in DSL networks. I know there is physical security, but I don’t know who is at the other end of the wire. As soon as I know the identity of that party, I can relate this wire to that user. That’d be the binding.



===========================



>              PaC            EP              PAA              AS

>              |              |                |                |

>  IP address ->|              |                |                |

>  config.      |      PANA    |                |      AAA      |

>              |<------------------------------>|<-------------->|

>              |              |    SNMP      |                |

>  (Optional)  |              |<-------------->|                |

>  IP address ->|              |                |                |

>  reconfig.    |  Sec.Assoc.  |                |                |

>              |<------------->|                |                |

>              |              |                |                |

>              |  Data traffic |                |                |

>              |<----------------->            |                |

>              |              |                |                |

>

>                      Figure 2: PANA Signaling Flow

>

>  The EP on the access network allows general data traffic from any

> authorized PaC, whereas it allows only limited type of traffic (e.g.,

> PANA, DHCP, router discovery, etc.) for the unauthorized PaCs.  This

> ensures that the newly attached clients have the minimum access

> service to engage in PANA and get authorized for the unlimited

> service.

>

>



What level of review has this received from the SNMP community?



Alper: pana-snmp has been reviewed by David Perkins and Robert Story.



Also, is it possible to need a NAT between the EP and PAA?



Alper: Yes. We analyzed this and found no issues. There was a presentation on that during IETF 62.



===========================





>  The PaC MUST configure an IP address prior to running PANA.

>

The PaC cannot use DHCP to get an IP address? When I see "configure" I

immediately think "statically configure."



Alper: Unless stated otherwise, “configured� stands for “either dynamically or statically configured.� So, DHCP is a valid option. That issue is expanded in Section 5.



===========================





>After

>  the successful PANA authentication, depending on the deployment

>  scenario the PaC MAY need to re-configure its IP address or configure

>  additional IP address(es).  The additional address configuration MAY

>  be executed as part of the secure association protocol run (e.g., via

>  IKE).

>

>

I think you need to warn the reader what this really means. Changing an

IP address is not something that is always seamless for a host or set of

applications.



Alper: Yes, we’ll add some text for that.



This is really verging onto the territory of multi-homing

in general, particularly when you suggest multiple IP addresses. This

paragraph is really leaving open a lot of possibilities, is it possible

to constrain this?



Alper: When IPsec tunnels are used, there’d be at least two IP addresses. One used inside the tunnel, the other outside. IPsec tunnel-mode implementations already deal with this.



===========================





>  If the PaC is authorized to gain the access to the network, the PAA

> also sends the PaC-specific attributes (e.g., IP address,

> cryptographic keys, etc.) to the EP by using SNMP.  The EP uses this

>

>

So, SNMP is now a peer to peer key negotiation protocol ;-)



Alper: No, it is still used for managing and configuring devices. One of the configuration parameters is a key.



===========================



>  In case cryptographic access control needs to be enabled after the

> PANA authentication, a secure association protocol runs between the

> PaC and the EP.

>

If you have already exchanged keys, I wonder why you need to exchange

them again.



Alper: PaC and EP sharing a master key is not sufficient to enable, say, IPsec. They need to use this key with a secure association protocol, such as IKE, and produce IPsec SAs (which include more keys and other attributes). Please see figure 4 in http://ietf.org/internet-drafts/draft-ietf-eap-keying-07.txt.



===========================





Regards,



Alper