2.3.13 User Registration Protocol (urp) BOF

Current Meeting Report

Minutes from the User Registration Protocol (URP) BOF
----------------------------------------------------------
Thanks to Anthony J. Mcauley and Jarno Rajahalme for capturing the notes

Wednesday, August 08 at 0900-1130, London
===============================

1.Problem Statement:

Basavaraj Patil introduced the problem scope by saying that although we had a strong consensus from the first BOF at Minneapolis that this work is needed, IESG and ADs feel that problem scope needs to be better defined and understood boundaries properly. Chairs dropped the letter "B" from "BURP" although there is enough scope to discuss about the terminology and an appropriate name for this proposed WG. Raj then described the objective of the URP as follows: "To demonstrate/determine clearly the need for an edge protocol that allows a user to interact with an agent in the network for AAA. The agent in turn may interact with network AAA protocols, such as, Diameter/RADIUS." He also mentioned several important features of URP, such as,

-- Perform URP only when required
-- Interacts with an URP agent in the network
-- URP agent interacts with the network AAA if required
-- Setup Security Association (SA) with the network
-- Support multiple authentication schemes

Questions like: is there any link layer registration before URP?, are we assume User has IP address before it sends URP message? , what things are going to be accomplished when URP is in place? etc. were raised and it was told that a clear boundary must be defined to prevent "boiling the ocean".

2.Discussion of applicability (usage scenarios) in various environments
[draft-ohba-urp-usage-scenarios-00.txt]

i) Yoshihiro Ohba described the NAS/WLAN scenario stating that PPPoE is not desirable and periodic re-authentication is needed for disconnection detection. He emphasized the need for a user to use multiple interfaces/terminals with a single interaction to Home AAA Server (AAAH) for initial authentication/authorization. He then described how URP can solve the problem in NAS area with few requirements, for example, URP must be independent of layer-2 technologies, URP must establish an LSA between User Terminal and RA as a result of successful URP registration, the established LSA should be used for periodical and local re-authentication, etc.

ii) James Kempf described the applicability of URP from a mobility perspective. He defined the problem from service authorization and authentication challenge perspective. He thinks initial URP registration should provide a Mobile Node with something like a lightweight encrypted capabilities token, the possession of which is sufficient to identify the Mobile Node as authorized for a collection of network level services. On the other hand, the network requires some means to issue a lightweight challenge to the Mobile Node to authenticate, for example, after handover. Similarly, the Mobile Node requires some means to challenge the network. Some other drafts talks about using an identity token, e.g. SUCV, BAKE, etc. but he thinks those are somewhat half baked and URP can provide the vehicle for setting up initial conditions such as, keying, etc. Finally he concluded with some requirements

iii) Phil Roberts described a mode of GPRS where URP can be applicable. In one GPRS mode, when IP runs over GTP and SNDCP (no PPP) between MN and GGSN there is no way one can carry external ID & credentials. GSM authentication is used to identify and authenticate the user locally. He thinks URP (running over IP) could be used to enable this.

iv) Hesham Soliman presented usage of URP in heterogeneous networks scenarios.

He explained that since current cellular networks use access dependant user identifiers, movement between two different access technologies within the same administrative domain requires re-authentication and authorization. On the other hand, seamless mobility requires avoiding re-authentication/authorization at the new AR. He thinks an access independent user identifier will allow the transfer of user credentials to the new AR seamlessly and URP may play a key role on that.

This draft raised lot of interesting debate relating to applicability or usage of URP. However, experts in the field of security feel that some ideas look promising while many are very difficult to achieve and too diverse. The WG must focus the charter carefully and should not boil down to an attractive protocol with multiple features that will create potential security holes and also be difficult to solve.

3. AAA Local Security Association (LSA): The Temporary Shared Key (TSK)
(draft-le-aaa-lsa-tsk-00.txt)

Franck Lee presented his draft on AAA Local Security Association (LSA): The Temporary Shared Key (TSK). He described this as a secure mechanism to setup LSA between user and visited domain Temporary shared key (TSK). It also allows subsequent user/network authentication with the home domain. He thinks URP is good candidate for setting up the LSA.

General comments were: WG should use the terminology carefully, one can't just split key generation from distribution, can't separate crypto-info from transport etc... Therefore additional thought is needed when handling these issues.

4. AAAv6: (draft-perkins-aaav6-04.txt)

Charlie Perkins presented his AAA Mobile IPv6 draft. He thinks URP can play a key role in this space since there is no such protocol in AAA-MobileIPv6 space. However, this draft is specific to only MobileIPv6 and may move to AAA or IPv6 WG.


5. Related Issues:

Subir Das discussed several issues, such as, discovery of Registration Agent, when to perform URP, how to identify user, etc. which were partly discussed in the URP mailing list. Chairs thought that these issues are relevant and need to be discussed further when looking at requirements.

6. New Charter:

Chairs proposed the new charter stating the need for a generic registration protocol that allows: i) a user to register in the local network by providing identity and authentication information and ii) the network to validate the user using AAA infrastructure. Salient features include flexible authentication, disconnect indication, user-to-network AAA functions, create local security association between user and the registration agent after successful registration.

7. Next Steps:

Area Directors will talk to Chairs offline to decide the future course of action and them result will be posted in the mailing list shortly .

Slides

Agenda
URP Usage Scenarios for NAS & Key Distribution
*A* GPRS scenario
Related Issues
Heterogenous networks scenarios
URP Usage Scenarios for Mobility
URP Usage Scenarios for NAS
Local Security Association
AAAv6