DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents
draft-ietf-dhc-paa-option-05

IANA additional Comments:

IANA received author's reply from Lionel.

Please consider that both DHCPv4 and DHCPv6 PANA options
defined in draft-ietf-dhc-paa-option have the same name i.e. "PANA_AGENT_OPTION". Moreover, I think that we can clarify
that only addresses are provided with this option.

Therefore, as a result of the first action, we should have
in the "BOOTP AND DHCP PARAMETERS" registry:

Tag NAME Length Meaning Ref
TBD1 OPTION_PANA_AGENT N N/4 Pana Autentication Agent
addresses [RFC-dhc-paa-option-05]

[Ballot comment]
As far as I can tell, the issues that were raised about PANA in Last
  Call have not been fully sorted out.  I do not think we should be
  assigning DHCP options to locate a PANA Authentication Agent until
  we are sure that the PANA protocol itself is going to be approved.

IANA Last Call Comments:

First action:


Upon approval of this document, the IANA will make
the following assignments in the "BOOTP AND DHCP
PARAMETERS" registry located at

http://www.iana.org/assignments/bootp-dhcp-parameters
sub-registry "BOOTP Vendor Extensions and DHCP Options"

Tag NAME Length Meaning Ref
TBD1 PANA_AGENT N N/4 Pana Autentication Agents
[RFC-dhc-paa-option-05]


Second Action:
Upon approval of this document, the IANA will make
the following assignments in the "DHCPv6 and DHCPv6
options" registry located at

http://www.iana.org/assignments/dhcpv6-parameters
in sub-registry "DHCP Option Codes"

Value Description Reference
----- ---------------------- ---------
TBD2 OPTION_PAA_AGENT [RFC-dhc-paa-option-05]



We understand the above to be the only IANA Actions
for this document.

[Ballot comment]
>      PANA Authentication Agent (PAA):
>
>          The protocol entity in the access network whose responsibility
>          is to verify the credentials provided by a PANA client (PaC)
>          and authorize network access to the device associated with the
>          client and identified by a Device Identifier (DI).

The latest version of draft-ietf-pana-pana removed "Device Identifier"
from the protocol. The definition of PAA should be updated accordingly. Perhaps a cut and paste from draft-ietf-pana-pana-13.txt

>
> 7.  Security Considerations
>
>    The security considerations in [RFC2131], [RFC2132] and [RFC3315]
>    apply.  If an adversary manages to modify the response from a DHCP
>    server or insert its own response, a PANA Client could be led to
>    contact a rogue PANA Authentication Agent, possibly one that then
>    intercepts call requests or denies service.

"Call requests"?? I don't think this is a PANA, EAP or DHCP term.

>
>    In most of the networks, the DHCP exchange that delivers the options

s/the networks/networks

>    thank also Jari Arkko, Thomas Norten, Bernard Aboba that provided

s/Norten/Narten

AD Review results:

I reviewed this spec and also got reviews from
Thomas Narten and Bernard Aboba. All
review input is collected below.

The following issues need attention in the
document before I can take it forward:

1. Clarify the role of this option in the decision
    of the PANA client to start using PANA, and
    the relationship of PANA usage in the network
    to the DHCP server's decision to send this option.

    Currently, the document is silent on these points.

    When I first read the document, I assumed that
    the option is used as a dynamic mechanism to
    tell the client when PANA is required in the
    network.  However, the document does not say
    that PANA-capable clients must always
    request this option, and as a result, it is
    not clear how clients find out. Similarly,
    does the server send this if and
    only if PANA is required to gain
    access from this network? This seems
    obvious, but the document says nothing.

    Even if we add the explanations,
    it is not clear that the result is what
    was expected. PANA usage makes
    sense when there is no underlying
    security. As a result, the DHCP exchange
    that delivers this option is not secured from
    a L2 point of view. This would allow a bidding
    down attack where the client chooses
    to use a lower-grade security mechanism or
    perhaps no security at all.

    One model where there are no bidding
    down attacks is that the client is
    configured to always run PANA,
    and the DHCP option is used merely
    to find the PAA, not negotiate the
    use of PANA. But it was not clear if
    this is what the WG wants.

2. The security considerations section
    needs to explain what the implications
    of spoofed PAA addresses are. The
    implications are also dependent on
    the answers to issue 1; if the option
    is used in a negotiation process the
    security impacts need to be explained.

3. In the abstract, s/many//

Given that the above issues are more about the
PANA functionality than the DHCP encapsulation,
I would suggest continuing this thread on the PANA
mailing list.

AD review results:

1) In the abstract, s/many//

2) Clarify the use of this option and when it needs to
    be requested. I had a discussion with Ralph about
    this -- this option is different from other options in
    the sense that it is absolutely needed if the network
    requires PANA authentication. For instance, we could
    use something along the following lines (Ralph's
    text, slightly edited):

      The DHCP client MUST send a request for the option
      if it is capable of participating in the PANA protocol.
      The DHCP server will respond with the option if
      the client will be expected to use PANA for network
      access and the client has requested the option. If
      the client has not requested the option or if PANA
      is not required in the network, no option will be sent.

Proto writeup:

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



It has been reviewed by several key WG members in both dhc and pana

WGs.  No concerns.

 

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

 

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.



No



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?



Majority of the group is silent.  Several have supported this document,

none have spoken against it.  The document is also supported by people

in the pana WG.  WGLC of rev 03 was performed in both dhc and pana WGs.

The document passed the WGLCs.  The responses received were positive, but

some minor changes were requested.  These are incorporated in rev 04.



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, no nits found.

 

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

  announcement includes a writeup section with the following

  sections:



  - Technical Summary



The document specifies a DHCPv4 option and a DHCPv6 option that

allow a PANA client to learn addresses of PANA Authentication

Agents.



  - Working Group Summary



There was consensus for adopting this draft at the wg meeting at

IETF 63.  Consensus was verified on the mailing list, and got

adopted in September 2005.  After that it has been discussed in

both dhc and pana WGs and rev 03 went to a joint WGLC in dhc and

pana WGs in August 2006.  Based on comments received during last

call rev 04 was produced.



  - Protocol Quality



The protocol specified in this document specifies new DHCPv4 and

DHCPv6 options and as there are no special requirements on option

encodings or usage, this should be trivial to implement.

This is a work item at the DHC WG, but the real customer is the PANA WG. A simultanous WGLC has been run in both WGs.