2.3.17 Protocol for carrying Authentication for Network Access (pana)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional PANA Web Page

Last Modified: 2004-10-14

Chair(s):

Basavaraj Patil <basavaraj.patil@nokia.com>
Alper Yegin <alper.yegin@samsung.com>

Internet Area Director(s):

Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Thomas Narten <narten@us.ibm.com>

Mailing Lists:

General Discussion: pana@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/pana
In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/pana/index.html

Description of Working Group:

In some scenarios, an IP-based device is required to authenticate
itself to the network prior to being authorized to use it. This
authentication usually requires a protocol that can support various
authentication methods, dynamic service provider selection, and
roaming clients. In the absence of such an authentication protocol on
most of the link-layers, architectures have resorted to filling the gap
by using a number of inadequate methods. For example, inserting an
additional layer between link-layer and network-layer mostly for client
authentication purpose (e.g., PPPoE), overloading another network-layer
protocol to achieve this goal (e.g., Mobile IPv4 with Registration-
required flag), and even defining application-layer ad-hoc
authentication mechanisms (e.g., http redirects with web-based login).
In these and other cases, a network-layer authentication protocol may
provide a cleaner solution to the authentication problem.

The goal of PANA is to define a protocol that allows clients to
authenticate themselves to the access network using IP protocols. Such
a protocol would allow a client to interact with a site's back-end AAA
infrastructure to gain access without needing to understand the
particular AAA infrastructure protocols that are in use at the
site. It would also allow such interactions to take place without a
link-layer specific mechanism. PANA would be applicable to both
multi-access and point-to-point links. It would provide support for
various authentication methods, dynamic service provider selection,
and roaming clients.

Mobile IPv4 developed its own protocols for performing PANA-like
functions (e.g., MN-FA interaction). Mobile IPv6 does not have the
equivalent of a Foreign Agent (FA) that would allow the access/visited
network to authenticate the MN before allowing access. The PANA
authentication agent (PAA) can perform the authentication function
attributed to the FA in Mobile IPv4, in Mobile IPv6 networks.

The WG will work with the assumption that a PANA client (PaC) is
already configured with an IP address before using PANA. This IP address
will provide limited reachability to the PaC until it is authenticated
with the PAA. Upon successful authentication, PaC is granted broader
network access possibly by either a new IP address assignment, or by
enforcement points changing filtering rules for the same IP address.

PANA will neither define any new authentication protocol nor define key
distribution, key agreement or key derivation protocols. It is believed
that PANA will be able to meet its goals if it is able to carry EAP
payloads. Note, however, that EAP may need to be extended in order for
PANA to meet the need for all of its intended usages. Such extensions
are outside the scope of the PANA WG.

PANA will develop an IP-based protocol that allows a device to
authenticate itself with the network (and to a PAA in particular) in
order to be granted network access. For simplicity, it is assumed that
the PAA is attached to the same link as the device (i.e., no
intermediary IP routers). The PAA itself may interface with other AAA
backend infrastructures for authenticating and authorizing the service
being requested by the host, but such interactions are transparent to
the PaC.

Network access authentication enables the client to be authorized for
packet data service. However it is possible that the underlying link
itself is insecure, i.e the packets being sent to and received on the
link between the client (PaC) and the 1st hop access router (EP) in the
network are not protected by any physical or cryptographic
means. In such cases, PANA will enable the establishment of an IPsec
SA between the client and the 1st hop access router to secure the
packets on the link. In networks that have physical security or
ciphering as a link-layer feature, no such SA is required. Hence the
establishment of the IPsec SA is optional. The WG will deliver a
document that explains how such an IPsec SA is established by using
IKE after successful PANA authentication. No enhancements to either
IKE or IPsec are expected.

The PAA does not necessarily act as an enforcement point (EP) to
prevent unauthorized access or usage of the network. When a PaC
succesfully authenticates itself to the PAA, EP(s) (e.g., access
routers) will need to be suitably notified. SNMP will be used
by the PAA to deliver the authorization information to one or
more EPs when the PAA is separated from EPs. The WG will document
the solution based on SNMP for carrying the authorization information
between the PAA and the EP.

The WG will also propose a solution of how the PaC discovers
the IP address of PAA for sending the authentication request.

The PANA WG will deliver

- A mechanism for the PAC to discover the PAA on the link.

- The PANA protocol itself, capable of carrying multiple authentication
methods (e.g. using EAP)

- A document that describes how SNMP is used to deliver authorization
information from the PAA to the EP in the scenarios where the PAA
and EP are separated.

- A document that explains the establishment of an IPsec SA between
the client and the 1st hop access router subsequent to
authentication for securing the data packets on the link.

Goals and Milestones:

Done  Submit usage scenarios and applicability statement to the IESG
Done  Submit security threat analysis to the IESG
Done  Submit protocol requirements to the IESG
Aug 04  Submit PANA framework to the IESG
Aug 04  Submit PANA protocol specification to the IESG
Aug 04  Submit IPsec-based access control to the IESG
Aug 04  Submit SNMP-based PAA-to-EP protocol specification to the IESG
Dec 04  Submit MIB for PANA to the IESG

Internet-Drafts:

  • draft-ietf-pana-requirements-09.txt
  • draft-ietf-pana-threats-eval-07.txt
  • draft-ietf-pana-pana-06.txt
  • draft-ietf-pana-ipsec-04.txt
  • draft-ietf-pana-snmp-02.txt
  • draft-ietf-pana-framework-02.txt

    No Request For Comments

    Current Meeting Report

    PANA Minutes, IETF-61, DC

    Protocol for Carrying Authentication for Network Access WG (pana)

    TUESDAY, November 9 at 1415-1515
    ================================

    CHAIRS: Basavaraj Patil <basavaraj.patil@nokia.com>
    Alper Yegin <alper.yegin@samsung.com>

    AGENDA:

    1. Preliminaries (bluesheets, minute takers, agenda bashing, document status) : 5 min, Chairs

    Agenda bashing by Alper.
    If time permits one more document will be covered.

    Document status:

    - PANA Requirements, and Threat Analysis and security requirements in RFC editor.
    - Other three documents (PANA spec, PANA framework and PANA-IPsec) in WGLC with numerous issues.

    2. PANA framework: 10 min, Yoshihiro Ohba
    Discussion of WG last call issues on draft-ietf-pana-framework-
    02.txt

    Presented by Yoshihiro Ohba. Yoshi presented the framework issues But only technical ones.

    Issue: How PMK for each AP is obtained by Pac?
    Proposed Solution:
    - Add text mentioning that PMK is derived from AAA-key
    (No comment form the WG)

    Issue: How can PAA install filtering rules for Pac to EP before receiving PBA with device-ID AVP?
    It has been discussed in the mailing list and the resolution is to add text that explains this behavior
    (No comment from the WG)

    Issue: in Section 10.1, DSLAM is missing in figures 7 and 8
    Resolution: Add DSLAM in figures and add text on future DSL model

    Issue: Why do we have multiple DHCP servers in some diagrams?
    Resolution: In the diagram use single DHCP server and put some text why we need multiple servers separately?
    (no Comments from the WG)



    3. PANA protocol: 20 min, Yoshihiro Ohba
    Discussion of WG last call issues on draft-ietf-pana-pana-06.txt

    Received many comments and generated 39 new issues Yoshi categorized two issues : A. Editorial and technical issues
    B: More technical issues that require protocol changes. Yoshi only described category A technical issues

    Issue 112: “M” clarification: This is borrowed from diameter
    Resolution: Is an AVP with the M bit set and not recognized, pl.
    ignore
    Q: Lionel: The text does not specify whether unrecognized AVP will be discarded silently or generated some message to the source.
    Ans: Yes, some additional text is required that will explain that

    Issue: 114: Can a PANA exchange other than PANA-Ping message used for liveliness text?
    Discussion Yes
    Resolution: Some text will be added
    (no comment)

    Issue 115: Raised by Mohan: Why the session cannot be shared across multiple network interfaces?
    Resolution: Rephrase the session definition using the term “device identifier” instead of “interfaces”

    Issue 116, 134: device ID, Protection-Cap and PPAC AVps handling in PBR: Rules as to when to or not to include Device-ID AVP in PBR should be more specific
    Solution: Device-ID AVP is carried in PBR if Prot.-cap AVp is carried
    - Dev-id AVP may be carried in PBR if Prot.-cap AVP is required
    - If PBA does not contain dev-id AVP when expected, the PAA initiates PER/PEA exchange to terminate the session
    -Other change: When PBR does not carry PANA-SUCCESS result code, Prot.-cap AVP and PPAC AVP is not carried in PBR
    (No specific comments)

    Issue 117: DI with IPSec Clarification (raised by Mohan): Which is the DI of Pac, IPSec-TOA or IPSec-TIA ?
    Discussion is going on and will continue in the emailing list

    Issue127: Retransmission Acknowledgement: What will happen if PANA-Auth-answer(p) is lost? Could PANA-Auth-Request(q+1) be used to confirm PANA-Auth-Request(p)?
    Resolution: No Optimization. Let the protocol run as it should work
    Q: Alper: Just to recap the issue in a different way: when the 2nd message is lost, 3rd message can be used as a hint. Without the optimization even, the protocol should work. NO problem with the flow except some unnecessary retransmission or flow but that’s fine.
    Yoshi: In the current spec, 3rd message will be processed and it will be passed to EAP. Just queueing the new message should be sufficient to run the protocol.

    Issue 136: network selection in PANA and EAP methods PANA and EAP also define this. What is the relationship between this?
    Discussion: The selection can conflict when EAP-based selection is used for ISP selection
    Proposed resolution?
    Q: Jari: There are multiple parts: One important part is roaming part and the proposed text is sufficient. The other part is conflict resolution. I don’t think there is any conflict. We should have both. It may be good if this information is available at lower layers. The discovery and selection can also be done via multicast. If a user gets 10 different information what should it do? This kind of things should be discussed.
    Yoshi: Issue with multicast: periodic multicast may consume bandwidth. Solicited Multicast may be good.
    Jari: Yes, this is a complicated issue.
    Greg Daley: There can be interaction also between PANA and Router Discovery (DNA) depending on the deployment scenario.
    Raj: I don’t think PANA has any impact in RA.
    Greg: There are several discovery mechanisms. In some situation, may be DNA is helpful, I don’t know..

    Issue: 137:
    (no comment)

    Issue 144: Mobility handling: PAA update in the AAA infrastructure:
    a mechanism is needed for the old and/or new PAA to inform the PAA server of the movement of Pac
    Resolution: This is not a PANA issue and no additional text is required

    Issue 145: Failed-AVP AVP is not always needed for PANA-Error-
    Request. OTOH, more than one Failed-AVP AVPs can be carried in PER,
    one per erroneous AVP.
    Proposed Resolution: allow zero or more Failed-AVP AVPs for PER
    No comments

    Issue 148: ABNF spec into the doc
    PANA is trying to resue Diamter ABNF
    Resolution: Add PANA ABNF grammar

    Issue 149: General purpose notification
    PANA currently does not have general purpose notification mechanism What about defining notification exchange in PANA?
    PAA-to-PaC notification only? Or both PAA-to-PaC and PaC-to-PAA notification?
    PANA does not have general purpose notification mechanism. It would be useful.
    No comments

    Issue 150: PAA mandating separate authentication
    Can PAA refuse to authenticate if the Pac sets S-flag to 0 in PANA-START-Answer message in discovery and handshake phase? Resolution?
    Q: Does anyone thinks this is useful?
    Raj: If we don’t think this is useful no point of asking this question, just drop it.
    Yoshi: ok.


    4. PANA-IPsec: 5 min, Mohan Parthasarathy
    Discussion of WG last call issues on draft-ietf-pana-ipsec-04

    Mohan has presented this draft. This is WG last call. There are few comments. Open issue is about lifetimes: AAA key, IKE SA key, IPSec SA
    Answer: None of these lifetimes can be greater than PANA Sa
    lifetime. This is more or less text clarifications in the document rather than any technical issue here which will be fixed in future version.
    Q: Hannes: There is no yes or no answer here. This is discussed in EAP keying framework.

    5. SNMP usage for PAA-2-EP interface: 5 min, Julien Bournelle
    Presentation of updates and open issues on
    draft-ietf-pana-snmp-02.txt

    Presented by Julien. This is an update of previous presentation. It extends the MIBs. Added security section, Made some editorial corrections.

    Next steps:
    Link Layer protection
    Might reuse existing

    Q: ALper: Have you announced it MIB WG?
    Dave: MIB defines notifications. Will this work if notifications are not delivered? If some notifications are lost.
    Julien: I don’t know
    Alper: Can you bring this issue up on the PANA ML?
    Wais Herker: Can’t you use SNMPv3?
    Thomas: Dave is asking a more fundamental question: SNMP is using UDP and is there any problem in sending it reliably.
    Thomas: From SNMP perspective, this is different.
    Alper: This sounds a fundamental question of SNMP-based configuration
    Dave: Notifications are not used for configuration. If you do not send this notifications that are not reached what will happen?
    Although I didn’t read the draft., I thought authors have thought this issue and they can answer my question.
    Thomas: We do have some follow-up work here.


    6. Context transfer for PANA: 5 min, Julien Bournelle
    Presentation of updates and open issues on draft-bournelle-
    pana-ctp-01.txt

    Julien presented this. Two major issues: PAA is not AR: modify CTP?
    Hesham: In some cases, PAA may be ARs. Is there any association with PAA and other elements? Depending upon the location, can you eliminate some options?
    James: This is an experimental draft. If it turns out that something is needed, CTP can be changed.
    Hesham: You might be raising an architecture question which does not exist today.
    James: Are you saying that Host can do some CTP to router, and PAA and router are not co-located? This is a real concern. However, PAA is a logical entity.
    Hesham: That’s exactly true.
    Raj: PAA may not be at the access router.
    Hesham: If it makes life easier, PAA should be co-located to router.
    Alper: What is the status of CTP?
    James: It is an experimental RFC. If there are some interests, it can be discussed in mobopts. If you talk to crypto people, they are very nervous.
    Vijay: It should be handled in mobopts. You can not send signaling message to anyone. Signaling should come from host.
    Jari: I am wondering is there any synchronization with EAP keying framework. Are you following that?
    Julien: This is not the same as EAP keying framework
    Hannes: The problem is that EAP keying framework is changing time to time and this is a valid and effectively these keys are same and may be termed differently.
    Jari: You don’t have to change this document and may be EAP document needs to be changed. May be the issue is with the authorization issue. Is it important here?


    7. Next steps: 5 min, Chairs

    Raj: PANA protocol issue will be addressed and we will send to AD review. Hopefully we will be able to send this to IESG by next IETF. State machine id will also be published an informational.

    Hannes: I will send the slides (draft-tschofenig-pana-bootstrap-kerberos-00.txt) to the mailing list.

    Slides

    Protocol for carrying Authentication for Network Access[PANA]
    PANA Framework Last Call Issues
    PANA Specification Last Call Issues
    PANA enabling IPsec based Access control
    SNMP for the PAA-EP protocol
    CTP for PANA