datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Liaison Statement: Information about PANA as an applicable protocol for subscriber authentication in DSL networks

Submission Date: 2007-12-12
From: IETF PANA WG (Alper Yegin)
To: DSL Forum (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.