Liaison statement
Information about PANA as an applicable protocol for subscriber authentication in DSL networks
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
State | Posted |
---|---|
Submitted Date | 2007-12-12 |
From Group | pana |
From Contact | Alper E. Yegin |
To Group | DSL-FORUM |
To Contacts | gyoung@dslforum.org |
Cc | pana@ietf.org basavaraj.patil@nsn.com jari.arkko@piuha.net townsley@cisco.com |
Response Contact | alper.yegin@yegin.org basavaraj.patil@nsn.com |
Technical Contact | alper.yegin@yegin.org basavaraj.patil@nsn.com |
Purpose | For information |
Attachments | (None) |
Body |
IETF PANA working Group liaison to: Gavin Young, DSL Forum Technical Committee Chair gyoung@dslforum.org From: Alper Yegin, IETF PANA WG co-chair, alper.yegin@yegin.org Basavaraj Patil, ITEF PANA WG co-chair, basavaraj.patil@nsn.com Date: December 12, 2007 Subject: Information about PANA as an applicable protocol for subscriber authentication in DSL networks Dear Gavin, The PANA (Protocol for carrying Authentication for Network Access) Working Group in the IETF is chartered to work on defining a link-layer type independent network access authentication protocol. WG has completed its work on specifying the PANA protocol and the specification is now in the RFC editors queue for publication as a proposed standard (http://ietf.org/internet-drafts/draft-ietf-pana-pana-18.txt). Earlier this year, the DSL Forum had sent a liaison statement to the IETF requesting information about a protocol or work in the IETF which would meet the DSL Forum’s requirements for subscriber authentication in the context of the evolution of the DSL architecture. DSL Forum’s migration away from PPP has been identified as one of the candidate deployments for PANA from the early days of the WG as documented in RFC 4058 (http://ietf.org/rfc/rfc4058.txt). Additionally, the specific DSLF requirements were discussed at the PANA WG meeting at IETF70 in Vancouver (Dec 5, 2007) and on the PANA WG mailing list afterwards. WG believes that PANA is applicable to the current requirements presented by DSLF. The PANA WG’s analysis is presented below. We would like to request the DSL Forum’s technical committee to review the suitability of PANA for addressing your requirements especially in view of the fact that the protocol is now lined up to be published as a proposed standard RFC by the IETF. If you have further questions or need clarifications, please do not hesitate to contact the PANA WG. Sincerely, Alper Yegin (PANA WG co-chair) Basavaraj Patil (PANA WG co-chair) IPAuth-1: Authentication must not depend on the use of any given application, eg web browser. Compliance: Yes Explanation: PANA implementation does not rely on other applications. IPAuth-2: Must re-use existing SP Authentication infrastructure (use Radius Database) and allow mixed mode operation (eg PPP and IP) on the same L3 edge device Compliance: Yes Explanation: PANA does not require any changes on the AAA database. It can be used over IP networks that co-exist with PPP networks. IPAuth-3: Must offer L3 edge device (BRAS) subscriber policy enforcement via pull and push methods, ie L3 edge must be aware of authentication status and any subscriber credentials Compliance: Yes Explanation: PANA Authentication Agent (PAA) can be implemented on the BRAS, or elsewhere. IPAuth-4: Must allow for authorization purposes the use of any additional identifiers that may be available, eg MAC address, Option82 circuit-id. Compliance: Yes Explanation: MAC address is already available on the IP messages that carry PANA. PANA does not prevent use of Option 82 with DHCP. IPAuth-5: Should allow for subscriber nomadicity and support tracking of changes to location. Compliance: Yes Explanation: PANA allows establishing a new session or maintaining the same session upon mobility/nomadicity. IPAuth-6: Must fit into TR-101 operational model Compliance: Explanation: Although we do not see any issues there, IETF does not have the expertise to fully evaluate this requirement. IPAuth-7: Must support revoking authentication Compliance: Yes Explanation: PANA Termination message is explicitly designed for that purpose. IPAuth-8: Must handle L3 CPE device authentication and end-device (PC) user based authentication (likely with L2 CPEs in the latter case) Compliance: Yes Explanation: PANA Client (PaC) can be implemented on both CPEs and end-devices. IPAuth-9: Should be simple to implement on client (PC or CPE) Copliance: Yes Explanation: Implementation does not require changes to the operating system. Open source implementation available. IPAuth-10: Must be independent of medium type (eg Fixed Ethernet, Legacy ATM, PON, WiFi, WiMax, etc) Compliance: Yes Explanation: This is the original design goal of PANA. IPAuth-11: Must not require major re-work for IPv6. None ideally. Compliance: Yes Explanation: Same protocol can be used for both IPv4 and IPv6. IPAuth-12: Must be resilient to attacks on the subscriber, eg against brute-force challenge attacks, or spoofing of an authenticator edge device Compliance: Yes Explanation: Rate limiting, message validation, message authentication are used against such threats. IPAuth-13: Must offer authenticator edge device resiliency, eg not be prone to DOS authentication attacks Compliance: Yes Explanation: Stateless handshake and rate limiting are used against such threats. IPAuth-14: Must allow for authentication and download of subscriber service profile before service IP address is assigned Compliance: Yes Explanation: PANA requires an IP address be configured prior to authentication (a IPv4/IPv6 link-local, or a short-lease DHCP address), but allows the “service IP address� be assigned after authentication. IPAuth-15: Must offer an option to re-authenticate periodically or on demand. Compliance: Yes Explanation: Both the client-side and network-side are capable of initiating re-authentication. IPAuth-16: At an absolute minimum, must provide equivalent or better security than PPP CHAP/MD5 does today. Must include the ability to move to more secure authentication methods over time. Compliance: Yes Explanation: Supports any EAP method (including CHAP/MD5 equivalent of EAP-MD5). IPAuth-17: Should offer authentication fail/success reason message to subscriber from authenticator . Compliance: Yes Explanation: Supports explicit authentication and authorization result codes (extensible). IPAuth-18: Must allow for multiple authenticated subscribers on same physical or logical interface. Compliance: Yes Explanation: PANA Session-ID can demultiplex multiple authenticated sessions over the same physical/logical interface. IPAuth-19: Must offer scalable subscriber management, eg not rely on subscriber credentials configured on the authenticator Edge Compliance: Yes Explanation: PANA is independent of any backend protocol (RADIUS, Diameter, LDAP, etc.) that may or may not be used by the authenticator edge. IPAuth-20: Must have a logical path towards standardization Compliance: Yes Explanation: PANA specification is already approved by IESG and currently in IETF RFC queue. IPAuth-21: Must scale to 10000s of subscribers per L3 edge device (ie must be conservative in use of resources) Compliance: Yes Explanation: See PANA Session Attributes in the spec. |