URP Usage Scenarios for NAS

1. URP Usage Scenarios for NAS Yoshihiro Ohba August 2001 Toshiba America Research, Inc.

2. The problem URP should solvein NAS area • Providing authentication method in multi-access network • PPP(oE) is not desired because of encapsulation overhead • Periodic reauthentication mechanism is needed for disconnection detection • Used for usage-based accounting and protection against connection hijacking • Local reauthentication is preferable (frequency of contacting the Home AAA Server should be minimized) • 802.1X supports reauthentication, but not locally performed • 802.11 provides WEP based local reauthentication, but WEP is known to be weak • See http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html

3. The problem URP should solvein NAS area (cont'd) • Enabling an enterprise to control access to visitors, employees, and partners at different levels • That would be possible by using 802.1X-capable AP with AR functionality, but • Not economical if there are many AP's within an administrative domain

4. The problem URP should solvein NAS area (cont'd) • Allowing a user to use multiple interfaces/terminals with a single interaction to Home AAA Server (AAAH) for initial authentication/authorization • Interface switching • Multi-homing (using multi-interfaces simultaneously) • Interface sharing among multiple user terminals of a single user with a /64 IPv6 prefix assignment

5. How URP can solve the problemsin NAS area • Defining a new access independent (L2) edge protocol : URP • Runs between User Terminal and Registration Agent (RA) • Front-end protocol for RADIUS/Diameter • Establishing an LSA (Local Security Association) between User Terminal and RA as a result of URP registration • LSA can be derived from pre-established SA between user and AAAH • The established LSA can be used for periodical and local reauthentication • Providing lightweight reauthentication

6. How URP can solve the problemsin NAS area (cont'd) • URP can be independent of L2 technologies • Expected to work with any L2 technology (802, GPRS, etc.) • Expected to work with or w/o L2 access control (802.1X, etc.) • Registration with multiple L2 addresses is possible • Changing L2 address after registration is possible • URP can be flexible in having association with L3 addresses • Registration with multiple L3 addresses is possible • Changing L3 address after registration is possible • Flexible access control per user is possible (but supporting multiple users per interface is out of scope) • Prefix-based access control is possible

7. URP requirements for NAS • URP must support establishing an LSA as a result of successful initial registration with mutual authentication • URP must support periodical and local reauthentication by using LSA with mutual authentication • URP must work with any L2 technologies • Needs consideration for the location of RA • URP must work with or without L2 access control • Needs consideration for detailed usage scenario • URP must allow flexible association with L2/L3 addresses

8. Usage Scenario 1:URP+802.1X (Registraion) Free access Charged/restricted access 1) Obtain WEP key via 802.1X with any user account (guest/null/actual) UT 802.11 AP UT: User Terminal AP: Access Point AR: Access Router RA: Registration Agent DHCP Server 2) Obtain IP address 3) Install URP client JAVA script (not necessary if UT already has any URP client program) Local Web Server AAA via RADIUS/ Diameter AAA Server/ Proxy 4) Run URP with actual user account (via web browser or any method) AR/RA 5) Access to external network External Network

9. Usage Scenario 2:URP (Multi-interface) 802.11 AP Free access Charged/restricted access 1) Obtain IP address for 802.11 interface UT: User Terminal AP: Access Point AR: Access Router RA: Registration Agent DHCP Server UT 2a) Obtain IP address for BT interface, OR 2b) Use the same IP address for both interfaces 2a) Bluetooth AP AAA via RADIUS/ Diameter AAA Server/ Proxy 3) Run URP with its IP address(es) AR/RA 4) Access to external network External Network

10. Usage Scenario 3:URP (Interface Sharing in IPv6) IP devices 1) A /64 IPv6 prefix is assigned by AAA Server and inclueded in AAA reply message sent to AR/RA Bluetooth/ 802.11 AP DSL AR/RA AAA Server/ Proxy 1) Run URP 2) The /64 prefix is advertised by AR/RA via ICMPv6 Router Advertisement 3) Each device is able to configure an IP address within the advertised prefix and start external network access External Network

11. URP Usage Scenarios for Key Distribution Yoshihiro Ohba August 2001 Toshiba America Research, Inc.

12. The problem URP should solvew.r.t. key distribution • There are a number of "agents” in the network • Mobile IP FA/HA • SIP Proxy/Redirect/Registrar • DMHA (aka IP Paging) agents (PA/DMA/TA) • IPSEC Remote Access Gateway? • Secured message exchange is required for communication between User Terminal and agents • Need to establish SA between them which are previously unknown each other • Global PKI-based approach: problematic • AAA-based approach: suitable for networks running AAA

13. How URP can solve the problemsw.r.t. key distribution • User Terminal registers to RA by using URP • LSA is established between User Terminal and RA as a result of URP registration • When User Terminal requires to have an SA with some agent of a protocol, it sends a URP key request message to RA • RA will generate keying information (key, random number, etc.) needed for establishing the SA, and deliver it to User Terminal (via URP message) in a secure manner • The key is also delivered to the agent (via other protocol such as COPS, SNMP etc.) -- out of scope of URP

14. URP requirement w.r.t. key distribtion • URP must support for delivery of keying information to User terminal • The keying information is needed for establishing an SA between User Terminal and an agent of other protocol • The information delivery must be secured by using LSA

15. Thank you!