DSLF Subscriber Auth Requirements and IETF PANA Protocol PANA WG Chairs IETF 70 Dec 7, 2007 – Vancouver, Canada

IETF 70 – PANA WG2 DSLF “In 2006 the DSL Forum initiated a work item on "IP Sessions" with the intention of bringing some of the attributes of PPP to purely IP access scenarios. In particular IP over Ethernet over DSL in the context of our technical report TR-101. In the course of this work we have developed and agreed upon a set of requirements for subscriber authentication (summarized on the following page). We are not currently aware of a solution specified in the industry that meets our requirements. Can you advise us if you have a specified solution or whether a suitable solution is under your consideration. “

IETF 70 – PANA WG3 IETF PANA WG RFC 4508 Appendix A. Problem Statement DSL networks are a specific example where PANA has the potential for addressing some of the deployment scenarios. Some DSL deployments do not use PPP [RFC1661] as the access link- layer (IP is carried over ATM and the subscriber device is either statically or DHCP- configured). The operators of these networks are left either using an application-layer web-based login (captive portal) scheme for subscriber authentication, or providing a best-effort service only as they cannot perform subscriber authentication required for the differentiated services. The captive portal scheme is a non-standard solution that has various limitations and security flaws.

IETF 70 – PANA WG4 Analysis DSLF Req # DSLF Requirement DescriptionComplianceExplanation IPAuth-1Authentication must not depend on the use of any given application, eg web browser. Yes PANA implementation does not rely on other applications. IPAuth-2Must re-use existing SP Authentication infrastructure (use Radius Database) and allow mixed mode operation (eg PPP and IP) on the same L3 edge device Yes PANA does not require any changes on the AAA database. It can be used over IP networks that co-exist with PPP networks. IPAuth-3Must 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 Yes PANA Authentication Agent (PAA) can be implemented on the BRAS, or elsewhere. IPAuth-4Must allow for authorization purposes the use of any additional identifiers that may be available, eg MAC address, Option82 circuit-id. Yes MAC address is already available on the IP messages that carry PANA. PANA does not prevent use of Option 82 with DHCP. IPAuth-5Should allow for subscriber nomadicity and support tracking of changes to location. Yes PANA allows establishing a new session or maintaining the same session upon mobility/nomadicity. IPAuth-6Must fit into TR-101 operational model 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 Yes PANA Termination message is explicitly designed for that purpose.

IETF 70 – PANA WG5 Analysis DSLF Req # DSLF Requirement DescriptionComplianceExplanation IPAuth-8Must handle L3 CPE device authentication and end-device (PC) user based authentication (likely with L2 CPEs in the latter case) Yes PANA Client (PaC) can be implemented on both CPEs and end-devices. IPAuth-9Should be simple to implement on client (PC or CPE) Yes Implementation does not require changes to the operating system. Open source implementation available. IPAuth-10Must be independent of medium type (eg Fixed Ethernet, Legacy ATM, PON, WiFi, WiMax, etc) Yes This is the original design goal of PANA. IPAuth-11Must not require major re-work for IPv6. None ideally. Yes Same protocol can be used for both IPv4 and IPv6. IPAuth-12Must be resilient to attacks on the subscriber, eg against brute-force challenge attacks, or spoofing of an authenticator edge device Yes Rate limiting, message validation, message authentication are used against such threats. IPAuth-13Must offer authenticator edge device resiliency, eg not be prone to DOS authentication attacks Yes Stateless handshake and rate limiting are used against such threats. IPAuth-14Must allow for authentication and download of subscriber service profile before service IP address is assigned Yes 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.

IETF 70 – PANA WG6 Analysis DSLF Req # DSLF Requirement DescriptionComplianceExplanation IPAuth-15Must offer an option to re-authenticate periodically or on demand. Yes Both the client-side and network-side are capable of initiating re-authentication. IPAuth-16At 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. Yes Supports any EAP method (including CHAP/MD5 equivalent of EAP-MD5). IPAuth-17Should offer authentication fail/success reason message to subscriber from authenticator. Yes Supports explicit authentication and authorization result codes (extensible). IPAuth-18Must allow for multiple authenticated subscribers on same physical or logical interface. Yes PANA Session-ID can demultiplex multiple authenticated sessions over the same physical/logical interface. IPAuth-19Must offer scalable subscriber management, eg not rely on subscriber credentials configured on the authenticator Edge Yes PANA is independent of any backend protocol (RADIUS, Diameter, LDAP, etc.) that may or may not be used by the authenticator edge. IPAuth-20Must have a logical path towards standardization Yes PANA specification is already approved by IESG and currently in IETF RFC queue. IPAuth-21Must scale to 10000s of subscribers per L3 edge device (ie must be conservative in use of resources) Yes See PANA Session Attributes in the spec.

IETF 70 – PANA WG7 Conclusion IETF PANA protocol is specifically designed for the problem presented by the DSLF IETF PANA protocol satisfies the DSFL Subscriber Authentication Requirements as presented in their May 25, 2007 liaison. IETF should notify DSLF about PANA WG’s conclusion in response to DSLF’s May 25, 2007 liaison letter DSLF can contact IETF PANA WG for more details