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

2. The problem URP should solve in 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.htmlhttp://www.isaac.cs.berkeley.edu/isaac/wep-faq.html

3. The problem URP should solve in 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 solve in 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 problems in 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 problems in 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) AR/RA 1) Obtain WEP key via 802.1X with any user account (guest/null/actual) Local Web Server DHCP Server 2) Obtain IP address 3) Install URP client JAVA script (not necessary if UT already has any URP client program) 4) Run URP with actual user account (via web browser or any method) AAA via RADIUS/ Diameter External Network 5) Access to external network Free access Charged/restricted access UT: User Terminal AP: Access Point AR: Access Router RA: Registration Agent 802.11 AP UT AAA Server/ Proxy

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

10. Usage Scenario 3: URP (Interface Sharing in IPv6) External Network AR/RA Bluetooth/ 802.11 AP AAA Server/ Proxy DSL IP devices 1) Run URP 1) A /64 IPv6 prefix is assigned by AAA Server and inclueded in AAA reply message sent to AR/RA 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

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

12. The problem URP should solve w.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 problems w.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!