Subject: 51st IETF - User Registration Protocol BOF (urp)

From: [email-masked]
Date: Wed, 18 Jul 2001 12:40:42 -0400

User Registration Protocol BOF (urp)

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

CHAIRS: Basavaraj Patil <[email-masked]>
        Subir Das <[email-masked]>

AGENDA:

- Discussion of applicability (usage scenarios) in various
  environments (45 Mins)[draft-urp-usage-scenarios-00.txt]
- What should be the scope of URP and what can be used from
  other WGs (15 Mins)
- Issues such as   (15 Mins)
    * What layer
    * Auto Config
    * Others?
- What are the minimum features that should be targeted (15 Mins)
- Charter review (15 Mins)

Proposed Charter:
-----------------

Universal Registration Protocol (URP)
=====================================

The recent developments in wireless technologies are ushering in the era
of pervasive computing, enabling 'anytime, anywhere' Internet access.
The technology is being deployed to allow  users to access public, home,
or office networks even from public places such as, airports,
railway  stations,  hotels, malls, and sports  complexes,  etc.  In such
scenarios,  networks  typically  require  a user  to  register  and
provide
authentication information before being allowed to use their network or
authorized to use certain specific resources.

The Universal Registration  Protocol (URP) working group's primary task
is
to define a generic registration  protocol that allows:  i) a user  to
register  in the  local  network  by  providing  identity  and
authentication  information  to the local  network,  ii) the  network to
validate the user using network AAA  infrastructure  and  authorize/deny
access to authorized/unauthorized users. The URP would provide
user-to-network
AAA functions where legacy  mechanisms are not available or appropriate.

As with all IP protocols, however, URP would provide the advantage of a
service that can be offered across different access  technologies,
without
modifying or extending L2 protocols. It might provide features such as
disconnect indication. Moreover, it could provide flexible
authentication
and access control needed in some emerging  service  models.

Although PPP protocol provides similar functionalities it assumes:  i) a
link layer disconnect  indication is always available; ii) the existence
of a single  router in the  dedicated  link;  iii) nodes are not
roaming;
and iv) it must perform IP configuration. For most new link layer
technologies, however, PPP is inappropriate. Moreover, address
configuration
should be decoupled from AAA functionalities since in some cases it is
necessary to be able to assign address prefixes to the client.

The working group will create a local  security  model  between user and
network.  It will support sharing of this local security among different
network  elements  and  applications  so that  application  data  can be
securely  shared  with  users  having  a  local  security  association.
However, it will not assume user and network  share  pre-established  or
public key  certificates.  Also it does not define how to  generate  the
keys to establish the LSA.

A working  group task will be to illustrate  how other  services such
as,
QoS, mobility, etc.,  and their associated  protocols, can make use of
this local security model.  This includes getting any requirements from
other WGs.

Milestones:
===========

Merge two earlier requirements documents

Framework for the protocol

Protocol specification

MIB definition

General use cases