Transcript URP Usage Scenarios for NAS and Key Distribution

URP Usage Scenarios for NAS
Yoshihiro Ohba
August 2001
Toshiba America Research, Inc.
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.html
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
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
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
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
•
Prefix-based access control 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)
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
Usage Scenario 1:
URP+802.1X (Registraion)
UT
Free
1) Obtain WEP key via 802.1X
with any user account
802.11
(guest/null/actual)
AP
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)
access
Charged/restricted access
DHCP
Server
Local
Web
Server
AR/RA
5) Access to external network
UT: User Terminal
AP: Access Point
AR: Access Router
RA: Registration Agent
AAA via
RADIUS/
Diameter
AAA
Server/
Proxy
External
Network
Usage Scenario 2:
URP (Multi-interface)
802.11 AP
Free access
Charged/restricted access
1) Obtain IP address for
802.11 interface
UT
2a) Obtain IP address for BT interface, OR
2b) Use the same IP address
for both interfaces
2a)
DHCP
Server
UT: User Terminal
AP: Access Point
AR: Access Router
RA: Registration Agent
Bluetooth AP
AAA via
RADIUS/
Diameter
3) Run URP with its IP address(es)
AR/RA
4) Access to external network
AAA
Server/
Proxy
External
Network
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
1) Run URP
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
AAA
Server/
Proxy
External
Network
URP Usage Scenarios for
Key Distribution
Yoshihiro Ohba
August 2001
Toshiba America Research, Inc.
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
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
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
Thank you!