Last Modified: 2004-07-01
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.
| 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 |
|
Protocol for Carrying Authentication for Network Access WG (pana)
August 4th, Wednesday; 1300-1500 ================================= Thanks to Subir Das and Mohan Parthasarathy for volunteering to take the meeting minutes. --------------------------- 1. Preliminaries (bluesheets, minute takers, agenda bashing, document status) : 5 min, Chairs - Chairs mentioned that charter has been updated - Requirements and threats drafts are ready for last call - The usage scenarios I-D has been deprectaed. The scenarios are now included as an appendix in the Requirements I-D - Received Expert reviews for pana protocol, pana framework, pana Ipsec draft. - pana snmp needs more reviews. ********************************** 2. PANA protocol update and open issues: 30 min, Alper Yegin Discussion of recently closed and currently open issues on draft-ietf-pana-pana-05.txt. See "Change History" section of the draft for the list of issues closed in this revision. Additional issues may be discussed on the mailing list prior to the meeting. Detailed issue descriptions can be found at http://danforsberg.info:8080/pana-issues/ Alper presented the update and issues, Expert reviews have been received. Several issues are resolved and some are still open Issues resolved: - Issue 71, Post-PANA address AVP Resolution: No config, DHCP, RFC2462 etc - Issue 72: Capability discovery is not accomplished Resolution: PSR now includes PPAC and protection Capability AVP - Issue 73: What type of DI will be used on DSL networks? Resolution: Locally significant identifiers are ok DI does not have to be carried in an AVP. Mohan: Is DI carried by the packet Alper: Yes, it can be carried by the packet - Issue 74: Using PRAR and PRAA for mobility feature. We can use PBR and PBA instead Resolution: Use PBR/PBA instead Yoshihiro: May be it is related to other issue. For mobility, we can change the DI Alper: There is no text that conflicts your assertion Mohan: Is it optional? Alper: you can use as is. However the question is interface switching - Issue 78: EAP pass-through - Issue 79: Should PANA support the case where EAP authentication succeeds? Resolution: PBR results codes: PANA_SUCCESS - Issue 85: If PRPA is replaced by POPA, PAA needs to be notified Resolution: PaC sends PANA-Update-Request with IP-address AVP Sidefix: PANA-reauth MUST include MAC AVP only when PANA SA is available - Issue 98: PANA answers may be lsot. PaC/PAA should be ready to respond to retransmitted requests Resolution: PANA-auth-req responses are driven by EAP May respond to duplicate PANA-termination-req Section 4.7 and 4.11 are duplicates - Issue 100: Due to retransmissions and window of acceptable seq. numbers, ISN_* on PAA and PaC may differ. ISNs are used in PANA-MAC_key computation Resolution: Carry nonce values in PSR and PSA Use nonce values instead of nonce - Issue 107: Current seq no scheme does not accommodate rexmited rseq PaC drops msg 3 because "y" was already acknowledges Issue 75, 76, 77, 80,83, 84,91,92,93,96,97,99,103 are mostly editorial and clarification. Excpet 97 which are still open for further inputs. Next steps: Fix the open issues, Publish. Lionel: Is there any plan to have the distinction of different errors. Alper: Currently we have some messages. But I don't know whether they distinguish it or not Raj: Do you want to change the state machine behaviour depending upon the error message Lionel: Something like that but not to change the state machine Alper: It is hard to specifiy it Raj: He has a valid point since client may take some other steps depending upon partial information Alper: If PaC receives failure, PaC is out of PANA and it is an architectural decision Ra: It seems that issue 79 does not resolve the complete scenario and may be we should look it again. Resolution: Relax the expected rseq window to allow rexmot of seq ********************************** 3. PANA framework update and open issues: 5 min, Yoshihiro Ohba Discussion of recently closed and currently open issues on draft-ietf-pana-framework-01.txt. - Issue: AP hopping was needed when PAA and AP(EP) are separated Resolution: Text for AP hopping was removed A single solution for both co-located and separated PAA-EP cases Misc fix: Added explicit text that IEEE802.11i 4-Way handshake by AP - Issue: Simplifying DSL section: CPE acting as router (Router mode) CPE acting as a NATPT Resolution: Two modes can be combined - Issue: Revising Introduction section Missing info on overview and other documents Resolution: Introduction section will be revised and other document references will be added Next step: WG last call? ********************************** 4. SNMP usage for PAA-2-EP interface: 5 min, Yacine El Mghazli Discussion of recently closed and currently open issues on draft-ietf-pana-snmp-01.txt. Yacine: PANA Wg mandates SNMP for PAA-EP In last IETF this was accepted as WG item IPSec config MIP splitted into 3 separate modules: Reuse of existing IPSEc configuration MIBs IP level access control Rule/Filter/action policy structure MIB module ID-KEY_ID config IpSEc IKE config PANA-secific objects extends the SPD-MIB L2 filters L2 protection Changes in this draft: Terminology section updated PAA/EP separation context section Feedback on SNMPv3: -A MIB doctor to act as a technical advisor for the PANA WG? - Careful use of SNMP terminology Raj: Generally for new MIB, we use MIB doctor and that's the IETF practice Yacine: Yes I agree Security issue: New PaC notification could lead to DoS attacks on the PAA. Alper: With SNMPv3, PAA Attack not clear... Alper: Attack pretty common...might be a general Open issues: - link layer filters: Do we support everything ? 802, DSL, What more ? - L2 protection : Some additional objects needed ? Alper: No need for enumerate all link layers. Define generic container. Yacine: Use existing objects to configure EP. Some are lacking.. Security: Details the use of snmpv3 security. Depends on MIB objects definition. ********************************** 5. PANA-IPsec I-D update and open issues: 5 min, Mohan Parthasarathy Discussion of recently closed and currently open issues on draft-ietf-pana-ipsec-03.txt. Mohan: Version 03 updates Clarification of Key-ID in IKE pre-shared key derivation for reauthentication case Address Config has been simplified - Pre-PANA address can be link local Double IPsc section has been removed Dual stack operation section has been added How is IKE pre-shared key derived ahen there are multriple authentication schemes Raj: Is the document ready for last call? Mohan: Yes I think so. But is there are expert review pending? ********************************** 6. PANA state machine: 20 min, Victor Fajardo New I-D presentation for draft-ohba-pana-statemachine-00.txt. Victor: This is included in PANA base protocol documents Important in implementation - gives PANA internal details - insights of PANA PaC State Diagram overview has been presented. The intention is to show the difference with the previous presentation. The main differences is the introduction of EAP Interaction states. More details are available on the web site. In PAA state diagram the main difference are EAP interaction and result indication states. Also included issue 7 and 8. Details retransmissions descriptions are also available. Next Steps: Want to get the feedback from other implementers, verification of state machine Accommodate EP interface Raj: This document is a result from the protocol document. Because of the details, we decided to put it in a separate document and next steps should be to proceed with this since the State machine is very valuable. ********************************** 7. Context transfer for PANA: 20 min, Julien Bournelle New I-D presentation for draft-bournelle-pana-ctp-00.txt. Julien: Problem: Reauthentication from scratch ahen it moves to new PAA and that's hwy we need CTP (context transfer). The base PANA draft mentions that we need CTP for supporting mobility. Two cases were discussed: Reactive and predictive: Various uses were discussed: for example, CTP mentions use of CTAR message to trigger the transfer - seems necessary in predictive case Who enables the transfer? In CTP: MN and pAR shares a key. The pAR validate an authentication token -if PAA: can we still talk about CTP? ALper: Answering the 2nd question: it is the inclusion of session ID. Unless CTP does not mandate in CTAR format, it should be fine Raj: Session ID is not enough for CTP transfer Julien: Can we do that? Gerado: in CTP, CTAR is always required? Raj: We need to consider how do we do CTP? I agree that it may be necessary Gerado: CTP in Seamoby is not useful here. Vijay: Triggers should not be given by PANA Hannes: Mobility protocols should give the trigger Alper: If you know what to transfer, that's fine. Raj: CTP is protocol Raj: We should discuss in mailing list or offline. Issue: Do we need to introduce new state in state machine PAAs are not ARs (CTP mentions ARs) Should we handle inter-domain scenario? Vijay: If PAA is AR then 2nd point does not apply Alper: Regarding the state machine can we accommodate this? Yoshi: In case of mobility optimization, pAA is alwys stateful Hannes: Regarding the last bullet, for domain handover we need to consider something more and not beeen discussed in seamoby since multipartes are involved. Alper: Is it a protocol issue or operational issue Hannes: No it may be a protocol issue Raj: I don't know how important is to consider CTP here in context of PANA protocol and tight schedule ********************************** 8. Next steps: 5 min, Chairs We need to do the WG last call with requirements and threats with next few weeks Proceed to WG last call on Pana protocol, pana framework SNMP draft is not ready for WG last call. Chairs will find MIB doctor for this. |