MIPv6 authentication

1 © NOKIA Nokia_TIA-835D_MIPv6_authentication / 18AUG03 / ETacsik

MIPv6 authentication

MIPv6 authentication – AAAv6

MIPv6 authentication – PANA

MIPv6 authentication – PPP

MIPv6 authentication - comparison

Appendix A: IEEE 802.1x authentication



AAAv6


AAAv6 Introduction

• Proposes a way for IPv6 nodes (clients) to offer credentials to a local AAA server in order to be granted access to the local network

• The client solicits access to the network in conjunction with some protocol. Protocols considered in this document include:

• Stateless Address Autoconfiguration (RFC 2462)• Mobile IPv6• DHCPv6

• Controlled and uncontrolled access: Each network interface of the router can be configured to provide AAA services. When an interface is so configured, all transiting packets are subject to controlled access. If a packet does not pass access control, but is an AAA message addressed to the router, it is given to the Attendant in the uncontrolled access part.


Conformance to IPv4 model

• Basic RADIUS/DIAMETER doesn’t require changes

• AAA servers in home and local domain

• Attendant at local point of attachment (as in FA for MIPv4)

• Node desiring authorization supplies identification and credentials to attendant

AAAL AAAH

Local AttendantHome Agent

[email protected]


AAAv6 Router System (PDSN)

• The router is the node that provides network access to the client. In addition to the usual packet forwarding functionality, the router system consists of functional blocks like the attendant and the packet filter.

• Attendant: The attendant is the entity that extracts identification and authorization data sent by the client and forwards them to AAAL for verification. It is also responsible for making the necessary configuration updates (e.g., to the packet filter, and the router's Neighbor Cache) so that only authorized clients can access the network.

• Packet filter: A packet filter/firewall/security gateway is the entity responsible for disallowing unauthorized datagram traffic. When a client is authorized, the access control list of the filter is updated with the corresponding client's IP address(es).


System Point of View

Router System

Filter

Client System

Attendant

AAAH

AAAL

AAA Server

Infrastructure

Client


AAAv6 Messages

• New ICMPv6 messages to transport AAA data between the client and the attendant. In addition, several options that can be embedded in a AAAv6 Protocol Message are defined

• AAAv6 Protocol Message types• From client to attendant:

• AAA Request: Request for client authorization.• AAA Home Challenge Request: Request for a new

challenge from AAAH.• From attendant to client:

• AAA Reply: Reply to AAA Request• AAA Teardown: Indication of termination of the

currently active AAA registration. This message is always sent unsolicited to the registered AAA client.


General AAAv6 protocol overview

• LC = Local AAA Challenge• RPI = Replay Protection Indicator used

between client and AAAH• CR = AAA Credential• ID = Client Identifier

• KR = Key Reply• UCP = Uncontrolled part• CP = Controlled part• ACR = AAA Client Request (using an AAA

protocol)• ACA = AAA Client Answer (using an AAA

protocol)

Challenge

MN UCP CP AAAL AAAH

ACRACR

ACAACA

ID,CR,RPI,Ch

Status,RPI,Key

update config

Router subsystem



PANA


Protocol for carrying Authentication for Network Access (PANA)

An IETF Protocol for Last-hop AAA

Alper Yegin, Basavaraj Patil

IETF PANA WG Chairs


Overview

• A network-layer (i.e., link-layer and IP Version agnostic) access authentication protocol, that can carry various authentication methods• Last-hop AAA (i.e., between host and access network)• AAA backend can be either RADIUS or Diameter

• Purpose: Enable authentication and

authorization of nodes and networks,

for gaining network access

EAP

PANA

IP

Authenticationmethod

UDP


PANA

• PANA is a standards-track solution that will allow any authentication method to be used on any link-layer• No need to rely on the underlying L2 for providing an

authentication mechanism • No need to resort to non-standard ad-hoc schemes (e.g.,

web-based login)• No need to stretch and overload existing protocols (e.g.,

using Mobile IPv4 for network access authentication)


Architecture

InternetInternetPaC (MT) PAA

(PDSN)AuthenticationServer

PANA DIAMETER/Radius


Signaling

• Before authentication, the MT is allowed to send and receive only PANA packets (and maybe DHCP, Router Discovery)

• PANA can be engaged before or after the MT has been assigned an IP address (i.e., can work with 0.0.0.0 address)

• After PANA is completed , MT is allowed any traffic allowed by its AAA profile• PDSN turns the gate open

PDSN(PAA) AAA

PANA Discovery

PANA EAP RADIUS/Diameter

MT(PaC)

PANA Termination


Supported Scenarios

• PANA over physically secured networks (e.g., DSL)

• PANA over already cipher-secured links (e.g., cdma2000 in 3GPP2)

• PANA without any lower layer security• It can enable L2 or L3 ciphering as a result of

authentication


Data Security

• PANA can be used for enabling per-packet authentication and encryption

• At L2 (e.g., bootstrap WEP)• At L3 (e.g., bootstrap IPsec. See draft-mohanp-

pana-ipsec-00.txt)

• Uses EAP keying framework


Useful PANA Features

• Unifying:• Can be used for any link-layer for any type of access

(simple IPv4/IPv6, Mobile IPv4/IPv6)

• Extensible:• Support for any authentication method via EAP• Standard and vendor-specific AVPs

• Ease to deploy: PANA can be implemented as a UDP-based application



• Provides deployment flexibility: • PAA can be placed on any device on the last hop.• PAA, access router, and access enforcement points

can be hosted on separate nodes.

• Well-integrated with “Internet AAA architecture”• EAP, RADIUS, Diameter, IPsec, IKE, provisioning

protocols

• Mobility optimizations• Re-use of ongoing PANA session even after PAA

(subnet) change



• Bootstraps a local security association• Useful for securing other protocols (e.g., draft-tschofenig-

pana-bootstrap-rfc3118-00.txt)

• Authentication sequencing• Example: separate ISP and NAP authentication

• Multiple parallel authenticated sessions

• “Limited free access” model: Forcing authentication only after client attempts to access beyond free zone.


Proposal

• Mobile IPv6 is intended for use in cdma2000 networks in Revision “D”

• PANA can be used as the authentication protocol for clients before allowing Mobile IPv6 access

• It can enable various levels of last-hop AAA unification, enhanced features


Status

• Informational drafts are being reviewed by IESG• Problem statement• Requirements• Security Threats

• PANA protocol: Mostly completed, being revised and reviewed• Expected to be completed before the end of ‘03


Pointers

• Working Group web site: www.ietf.org/html.charters/pana-charter.html

• Additional web site:• http://www.toshiba.com/tari/pana/pana.htm

• FAQ:• http://www.toshiba.com/tari/pana/pana-faq.txt



PPP


PPP/EAP

• Uses LCP Configuration Option for Authentication-Protocol (as in with Simple IP service) i.e. :

• Description On some links it may be desirable to require a peer to authenticate itself before allowing network-layer protocol packets to be exchanged.

• This Configuration Option provides a method to negotiate the use of a specific protocol for authentication.

• A summary of the Authentication-Protocol Configuration Option format is shown below. The fields are transmitted from left to right.

• 0 1 2 3

• 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

• +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• | Type | Length | Authentication-Protocol |

• +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• | Data ...

• +-+-+-+-+


Authentication Protocol

• Authentication-Protocol• The Authentication-Protocol field is two octets, and

indicates the authentication protocol desired. Values for this field are always the same as the PPP Protocol field values for that same authentication protocol.

• Value (in hex) Protocol

• C023 Password Authentication Protocol (PAP)• C223 Challenge Handshake Authentication Protocol

(CHAP)• C227 Extensible Authentication Protocol [RFC2284] (EAP)

• Within the EAP Request message, there is a Type field to indicate what authentication is being requested. Examples of Request Types include MD5-challenge, etc.



comparison


MIPv6 authentication in TIA-835D(i.e. rfc3012 for MIPv6)

AAAv6 PANA / EAP PPP / EAP

Message protocol Extend/re-use ICMPv6/DHCPv6/MIPv6 protocols

New Pana protocol Existing PPP protocol

New messages Yes - 4 new ICMPv6 Yes – several Pana protocol messages

no

Key distribution No Yes - Via EAP Yes - Via EAP

Authentication method Existing MS-AAA SA – EAP not supported

Via Pana payload, EAP or other authentication methods

Via PPP payload – EAP or other authentication methods

New functionality in ms Minimal – but low in stack/kernel

PaC (Pana Client) – UDP-based application

Minimal/None

New functionality in PDSN Yes – attendant function (can be separate from PDSN)

Yes - PAA (Pana Authentication Agent) – can be separate from PDSN

none

IETF status Limbo - awaiting wg status Tbd - Active in Pana wg – but behind schedule

Little to no required effort

Security Not scrutinized by ietf yet – bigger issue outside cellular

Threat analysis completed n/a

Layer network IP/UDP – link layer agnostic Link

Efficiency - Message piggybacking possible – but PANA PAA discovery needed

No message piggybacking possible

AAA (RADIUS vs. DIAMETER) dependency

None None None

Applicable to WLAN Yes Yes No – link layer specific


+/- analysisPlus minus

Aaav6 Evolutionary - similar functionality to RFC 3012

link layer agnostic

attendant location can be outside PDSN (WLAN)

Allows deprecation of PPP

IETF uncertain on necessity

New PDSN (e.g.) attendant functionality

IPv6 specific mechanism (3rd mechanism)

Security risks associated with all higher layer authentication protocols - n/a for cdma2000 access

Pana/EAP Link layer & IP version agnostic

Standard track work – dedicated IETF wg

Allows deprecation of ppp for authentication

harmonizes authentication across existing modes – I.e. Simple IPv4/v6, MobileIPv4/v6, “potential” use for WLAN, Bluetooth

New protocol

New PDSN PaA functionality

Security risks associated with all higher layer authentication protocols - n/a for cdma2000 access

PPP/EAP Existing protocol Link layer specific


Appendix A:MIPv6 authentication

802.1x


802.1x authentication

• The 3-year-old Wired Equivalent Privacy (WEP) protocol has been discredited so thoroughly that its authentication and encryption capabilities are not considered sufficient for use in enterprise networks.

• In response to the WEP fiasco, many wireless LAN vendors have latched onto IEEE 802.1x standard to help authenticate and secure both wireless and wired LANs. The wildcard with 802.1x protocol is interoperability.


802.1x authentication (cont)


802.1x authentication (cont)

1. Wireless client sends authentication request to either wireless access point or 802.1x-enabled switch.

2. Wireless access point or 802.1x-enabled switch repackages authentication request to send on to RADIUS server.

3. RADIUS server examines request and may proxy the request to another server or consult an authentication database directly.

4. If access is authenticated, RADIUS server informs wireless access point or 802.1x-enabled switch.

5. Wireless access point or 802.1x-enabled switch informs client of access.

MIPv6 authentication

Documents