AAA for IPv6 Network Access

AAA for IPv6 Network Access

FASTER workshop, Tampere University of Technology, January 11, 2001

N. Asokan Nokia Research Center [email protected] 1

© NOKIA

aaav6.PPT, v1.0/ 10.1.2001/ N.Asokan (NRC/COM)

Outline • Introduction • AAA for Mobile IPv4 • AAA for IPv6 • Some open issues

2

© NOKIA


What is it? • Authentication, Authorization, and Accounting • Authorization • checking of eligibility to access service or resource, e.g.,

• • •

• • •

passport at border control movie ticket to the gatekeeper driver's license to the attendant with an authorized visitor list

•

network access, auxiliary services (e.g., QoS), other services (e.g., mobile commerce)

sometimes, but not always, based on authentication based on some type of credential basis for collecting money from users

• Authorization infrastructure • framework necessary to support authorization, servers, contracts,... • for mobile users, issuer and verifier are in different administrative domains

3

© NOKIA


AAA Basics • Support for authorization seen as a critical missing piece in IETF • General model • •

AAA server responsible for authorization decisions (one per domain) may distribute cryptographic keys to be used between, e.g., attendant and client

• SA3 implies the need for a large scale authorization infrastructure Local domain

Home domain

SA3

AAAL

AAAH

SA2

Attendant

SA1 Security associations

client 4

© NOKIA


Access protocol flows AAA Protocol flows

Mobile IP Basics • Mobile host has a permanent home address, and a home agent (HA) in the home network • On entering a visited network, it acquires a care-of address (CoA) and conveys this information to the HA in a binding update. •

binding update is protected using the MN-HA security association

• In IPv4, the access router may act as a foreign agent (FA): an address of the FA may be used as the CoA Local domain

Home domain

Router

HA SA1

client/host 5

© NOKIA


Security association Mobile IP protocol flows

Mobile IPv4/AAA • AAA and Mobile IP working groups are developing protocols for AAA • AAA credential sent as payload in Registration Request (RR) • FA extracts relevant information from RR, includes in request to AAAL •

also, includes entire RR (in order to meet the "single round-trip" requirement) Local domain

Home domain SA3

AAAL

AAAH

SA2

SA4

FA

SA1

HA Security associations

client/host See "Mobile IP Joins Forces with AAA", IEEE Personal Communications magazine, August 2000 6

© NOKIA


Mobile IP protocol flows AAA Protocol flows

AAA for IPv6 • Objectives • general framework for AAA support for IPv6 network access • support many different scenarios: stateless and stateful address autoconfiguration, Mobile IPv6, ... • anticipate use in other contexts as well • Proposed approach • described in IETF personal draft: draft-ietf-perkins-aaav6 • joint work with Patrik Flykt, Charlie Perkins, Thomas Eklund • current version available at http://people.nokia.net/~charliep/txt/aaav6/aaav6.txt

7

© NOKIA


General Framework Router System

Client/Host

Attendant

Packet filter

AAAL

Local Challenge (LC) AAA Req: LC, RPI, CID, Cred.

AHR: LC, RPI, CID, Cred AHA: code, RPI, KR, ...

AAA Rep: code, RPI, KR • CID - client identifier • LC - Local challenge • RPI - Replay protection indicator (between AAAH and host)

8

© NOKIA


Update config

• Cred. - AAA Credential (from host to AAAH) • KR - Key reply • AHA, AHR - AAA protocol messages

AHR AHA

AAAH

General Framework, cont. • Client Identifier: NAI or an IPv6 address • Replay protection: • between AAAL and AAAH, AAAL and Attendant: AAA protocol • host and AAAH: timestamps or random challenges (similar to Mobile IPv4) • AAA Credential: based on • security association between the client and AAAH • client identifier • local AAA challenge • replay protection indicator • Key Reply: encoded session key(s) for use between host & local domain • e.g., used in IPSec AH tunnel for upstream traffic • used for subsequent authorization within the same domain (e.g., for regional registration requests) 9

© NOKIA


Stateless Address Autoconfiguration • Router Advertisement containing local AAA challenge option • ICMPv6 messages (alt. IPv6 destination options) for transporting AAA data between host and attendant • AAA Request, AAA Reply • AAA Home Challenge Request • AAA Teardown Request? AAA Teardown? • one or more AAA options • • • • • • •

Client Identifier (subtypes: NAI, IPV6 address) Challenge (subtypes: local challenge, AAAH challenge) Generalized Key Reply Timestamp IPv6 address (acquired IPv6 address) Lifetime Embedded data (to carry additional data)

• AAA protocol (DIAMETER) between • • 10

© NOKIA

attendant and AAAL ,and AAAL and AAAH


Mobile IPv6 • If HA and AAAH belong to the same domain • bundle Binding Update in AAA Request using Embedded Data option • AAAH extracts Binding Update and sends it to HA • Binding Acknowledgement sent back via AAAH • Otherwise, AAA processing and binding updates can be done seperately • Which is the common case? • "single home" is the traditional telecom notion (e.g., HLR) • IETF heading in this direction, too • but "authorization home" and "routing home" may be different •

•

"single roundtrip" may not be a critical factor for IPv6 •

•

11

© NOKIA

needed when existing authorization infrastructures are used: e.g., payment with credit card, or authorization using SIM card (see next slide) binding updates to correspondent nodes/previous router are more time critical

provisional conclusion: both models need to be supported


Bootstrapping MIP/AAA: GSMSIM case GSM authorization infrastructure

• Use GSM auth. infrastructure as AAAH • Use existing SIM cards • Local access network operators need contracts with local GSM operators

AAAH

HLR

Gateway/MSC SA3

Local domain AAAL

Home domain SA1'

SA4

Attendant

HA Derived security associations

See IETF draft draft-haverinen-gsmsim-01.txt (for Mobile IPv4) 12

© NOKIA


Bootstrapping MIP/AAA: Pros and cons • No new per-user setup necessary • users need to download necessary software • use existing SIM cards • charges show up in phone bill • Local access network operators trusted to generate correct charging information • alternatives • • •

13

© NOKIA

do GSM authentication periodically to authorize a fixed amount flat-rate billing use unforgeable digital signatures (based on public key mechanisms)


Other issues • ICMPv6 or destination options for the AAA Request and Reply messages? • ICMPv6: more explicit, allow longer options (16-bit length field) • destination options: possibly more optimal if AAA signaling is to be combined with data transfer • Support for micromobility? • usual authorization on entering a new domain • subsequent authorizations (with different access routers) within the same domain must be lightweight and fast • What about DHCPv6? • current approach: define new AAA extensions to DHCPv6 • alternative: use the same ICMPv6 messages, along with the embedded data option? • Additions to the AAA protocol? 14

© NOKIA
