Internet-Draft Yoshihiro Ohba
Expires: July, 2002 Subir Das
Henry Haverinen
Basavaraj Patil
Phil Roberts
Hesham Soliman
Barani Subbiah
January 28, 2002
PANA Usage Scenarios
<draft-ietf-pana-usage-scenarios-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents, valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Many commercial networks today require users to provide their
authentication information before being allowed access to network
resources. Resources could include basic access to the network or
could be more specific services in the network or a certain grade of
service, etc. Currently, the authentication process depends upon the
type of network that a user is attaching to and in most cases it is
specific to an access technology. Therefore, a common protocol for
performing user authentication (which is independent of access
technologies) at the network layer (IP) or above is deemed necessary.
This document attempts to capture various such scenarios where a
higher layer protocol, such as, PANA (Protocol for carrying
Authentication for Network Access) would be appropriate. The purpose
of this draft is to help in understanding the problem space clearly,
issues involved for different usage scenarios, and finally to
facilitate the discussion for PANA requirements and framework.
Expires July, 2002 [Page 1]
Internet-Draft PANA Usage Scenarios January 28, 2002
Table of Contents
1 Introduction ............................................ 2
1.1. Requirements Language ................................... 2
1.2. Acronyms ................................................ 3
1.3. Terminology ............................................. 3
2. Current Mechanisms ...................................... 4
3. Scenarios Where PANA is Applicable ...................... 5
3.1. NAS ..................................................... 5
3.1.1. Layer Two Specific Network Access Mechanisms ............ 5
3.1.2. Multiple Access Routers ................................. 6
3.1.3. Multiple Interfaces on a Single Device .................. 8
3.1.3.1. Interface Switching ..................................... 8
3.1.3.2. Multi-homing ............................................ 9
3.1.3.3. Interface Sharing ....................................... 9
3.2. WLAN ................................................... 10
3.3. GPRS ................................................... 11
3.4. Intra-domain, Inter-technology Handoff ................. 11
4. LSA Usages ............................................. 12
4.1. Using LSA for Re-authentication ........................ 12
4.2. Using LSA for IKE ...................................... 12
5. Conclusion ............................................. 13
6. Acknowledgments ........................................ 13
7. References ............................................. 13
8. Authors' Information ................................... 14
1 Introduction
Many commercial networks today require users to provide their
authentication information before being allowed access to network
resources. Resources could include basic access to the network or
could be more specific services in the network or a certain grade of
service (e.g., free vs. paid services), etc. Although authentication
process varies from network to network, current best practices are to
perform the authentication at the link layer. Since existing
solutions are specific to access technologies, network providers need
either a new transport mechanism or an extension to existing
mechanism to authenticate users each time a new access technology is
being standardized. A common protocol designed at the network layer
(IP) or above could solve this problem.
This document attempts to capture various scenarios where a higher
layer protocol, such as, PANA (Protocol for carrying Authentication
for Network Access) would be appropriate. The purpose of this draft
is to help in understanding the problem space clearly, issues
involved for different usage scenarios, and finally to facilitate the
discussion for PANA requirements and framework.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [Keywords].
Expires July, 2002 [Page 2]
Internet-Draft PANA Usage Scenarios January 28, 2002
1.2. Acronyms
AAA: Authentication, Authorization and Accounting
AP: Access Point
AR: Access Router
DSL: Digital Subscriber Line
GPRS: General Packet Radio Service
ISP: Internet Service Provider
NAS: Network Access Server
PPP: Point-to-Point Protocol
RADIUS: Remote Authentication Dial In User Service
SA: Security Association
WISP: Wireless ISP
WLAN: Wireless Local Area Network
1.3. Terminology
Following terminologies are defined for this document.
Device
A user's equipment (namely notebook computers, PDAs, etc.) that
requires access to a provider's network.
Local Network
The immediate network(s) that is available to the device/user for
Connecting. The network that the device is connecting to may be
operated by anyone (not necessarily the users home network
operator).
PAA (PANA Authentication Agent)
The functional element in the access network that a user device
communicates with and provides it with the credentials used for
authentication. PAA MAY also have an interface to AAA backend
infrastructures for authenticating the device/user or may use any
other authentication mechanism.
PANA (Protocol for carrying Authentication for Network Access)
A protocol which is used for carrying authentication information
Expires July, 2002 [Page 3]
Internet-Draft PANA Usage Scenarios January 28, 2002
between a device (acting on behalf of a user) and a PAA in order
for the device to be allowed to access the network.
Credentials
Information that is transferred or presented to establish either
a claimed identity or the authorizations of a system entity
[RFC2828]. Credentials include things such as, private keys,
trusted roots, tickets, or the private part of a Personal
Security Environment (PSE) [RFC3157,RFC2510].
Initial Authentication
Authentication performed by PAA when a device needs to be
authenticated and authorized for network access.
Re-authentication
Authentication performed after successful initial authentication
when a device needs to be authenticated again in order to extend
the authorization lifetime for the network access.
LSA (Local Security Association)
A temporary security association between a device and a PAA,
which is derived from a credential that is provided by the device
on behalf of a user during initial authentication.
2. Current Mechanisms
Today's technologies mostly rely on access specific mechanisms. For
example, dial-up networks have relied on PPP's [RFC1661] capability
to do user authentication in conjunction with AAA (RADIUS) [RFC2865]
as a means to initial authentication. However, PPP may not be
appropriate for most new type of networks. Moreover, node
configuration through PPP is not always necessary. Today's wireless
networks, especially cellular networks, also have relied on specific
layer 2 identifiers and layer 3 messaging (NOT IP) to accomplish user
authentication. Access control in most current technologies is
performed on layer 2 based on device identification combined with
layer 2 security. As new type of networks (including wireless LANs)
are deployed in hotspot areas the legacy mechanisms may not be
appropriate in such scenarios. Different kinds of service models are
also emerging in today's Internet. For example, while basic
connectivity may be user-agnostic, enhanced services will be
available only to authorized users (since charging is involved for
such services).
The following scenarios are described in the next section:
Expires July, 2002 [Page 4]
Internet-Draft PANA Usage Scenarios January 28, 2002
- NAS
- WLAN
- GPRS
- Intra-domain, inter-technology handoff
3. Scenarios Where PANA is Applicable
3.1. NAS
Basic NAS functionality includes authentication of users with an
authentication server. It has also hooks for access control.
Although PPP offers these functionalities, it assumes few network
characteristics:
i) PPP always assumes a link layer disconnect indication.
-- This feature is not available in networks such as Wireless LANs
and others. So there has to be some mechanism to detect when
the client disconnects. This might mean that there is also a
need to re-authenticate client X to appear just after client A
left, spoof the MAC and IP addresses of the client A, and
basically continue to use client A's authenticated access.
ii) Since PPP works in scenarios where dedicated links exist, it
normally assumes a single access router in that link.
-- However, this is not true in multi-access links, such as WLANs.
Multiple ARs are required for efficient control and robustness.
The multi-AR scenario is discussed in section 3.3.
iii) PPP does address configuration to the client.
-- Address configuration should be decoupled from AAA
functionalities since in many cases devices may use other
address configuration mechanisms such as DHCP, stateless
address autoconfiguration, etc.
In view of the above, we need a flexible NAS type of functionality.
There are definitely architectural tradeoffs relating to the
relationship between the PAA and the access control enforcement point
in terms of their relative location (same box, or different box) as
well as how close or far away from the client. Also there may be a
need for defining some rules or policies on how this will interwork
with L2 authentication and access control mechanisms, such as 802.1X
and cellular systems.
3.1.1. Layer Two Specific Network Access Mechanisms
WISPs are becoming prevalent and they are also starting Internet
access services in public areas such as airports and hotel lobbies.
The access control technologies they are currently considering would
Expires July, 2002 [Page 5]
Internet-Draft PANA Usage Scenarios January 28, 2002
be (i) web-based access control or (ii) L2 access control such as
802.1X. The web-based access control is performed at a higher layer
after obtaining an IP address, whereas the L2 access control is
performed before obtaining an IP address. There are pros and cons as
to which layer access control is performed. However, a higher layer
access control would be suitable for realizing user-agnostic network
access services in which a user can access local information such as
local-area map and flight information for free of charge, while
access to specific external web-sites is subject to charge.
The web-based access control could provide such a service, but there
is no standard protocol or method which could help WISPs to support
roaming users. While web-based access control can support devices
with web browsers, there are number of other applications such as
FTP, VoIP require a standard client application or protocol at the
client. The client will use this protocol to initiate the network
access for any non browser based applications. In addition to charge
a user for external web access, a local WISP can also provide charge-
based information delivery services such as music download, VoIP,
etc. These services are provided by the local network and external
connectivity is supported by gateways. It is also envisioned that
NAS can be triggered either by the device or PAA, based on provider
business model. PANA could provide a standardized way of
L2-independent user-agnostic network access with roaming enabled.
3.1.2. Multiple Access Routers
In multi-access environments such as Ethernet and 802.11a/b, it is
possible for multiple ARs to exist on the same subnet. This is a
fundamental difference from PPP in which a single AR is always
associated with a PPP tunnel and the association never changes
throughout the lifetime of the PPP connection.
It would be desirable to use multiple ARs in such a way that traffic
coming from and going to a specific device always goes through a
single AR for ease of access control, but traffic among different
devices diverges for the purpose of load balancing and redundancy.
Although many NAS-based networks support multiple ARs for inbound
traffic, however, for outbound traffic (originated from user devices
connected via PPP tunnels to a single NAS) a single AR is always
used. In an 802.11a/b network, it is possible to support multiple
ARs if all first hop routers reside behind the layer-2 access points.
On the other hand, if WLAN access points act as first hop access
routers then it boils down to the same NAS type of model as described
earlier.
Thus in order to achieve load balancing and redundancy in a more
flexible way we may need a different type of solution and in which
case PANA seems to be appropriate. Consider the following scenario
(see Fig.1 for IPv4 example):
o Unlike the existing PPP-based NAS model, the device randomly (or
by using some other criteria) selects one of the ARs as the
Expires July, 2002 [Page 6]
Internet-Draft PANA Usage Scenarios January 28, 2002
default router and always uses the selected AR as the next hop for
the outgoing traffic. The network is also configured in such a
way that ICMP Redirect would not occur in the edge subnet to avoid
divergence of traffic coming from the user terminal.
o Like the existing PPP-based NAS model, each AR has at least two
interfaces, one (Ie) is attached to the edge subnet and the other
(Ic) is attached to the core network. The subnet prefix assigned
to Interface Ic covers that is assigned to Interface Ie. When an
AR receives an address resolution request (ARP REQUEST or Neighbor
Solicitation) from R (who is searching for the device on Interface
Ic) the AR that is selected by the device replies to the address
resolution request on behalf of the device and thereby guarantees
that all incoming traffic going to the device passes through the
AR. This part is the same as the existing PPP-based NAS scenario.
For example, assume that devices D1 and D3 perform initial
authentication with AR1 and that devices D2 and D4 perform initial
authentication with AR2. If initial authentication is successful,
AR1 and AR2 will open firewall and create proxy ARP (or ND) entries
for D1/D3 and D2/D4, respectively. Packets originated from D1 or D3
are forwarded to AR1. Packets originated from D2 or D4 are forwarded
to AR2. On the other hand, in terms of the reverse direction, when
core router R receives a packet destined for either D1 or D2, it is
delivered to the final destination through AR1 in the following way.
If R does not yet have an ARP/Neighbor cache of the destination, it
performs address resolution since it thinks that the destination is
on-link according to the prefix assignment. Only AR1 makes a
response to the address resolution request with specifying the MAC
address of Ic1. Then, R forwards the packet to AR1 which delivers it
to the final destination device. In the same way, when R receives a
packet destined for either D3 or D4, it is delivered to the final
destination through AR2.
Expires July, 2002 [Page 7]
Internet-Draft PANA Usage Scenarios January 28, 2002
[D1] ----+
| Ie1 Ic1
[D2] ----+---[AR1]---+
| Ie2 Ic2|
[D3] ----+---[AR2]---+
| |
[D4] ----+ |
+---[R]----
[D5] ----+ |
| Ie3 Ic3|
[D6] ----+---[AR3]---+
| Ie4 Ic4|
[D7] ----+---[AR4]---+
|
[D8] ----+
D1..D8: Devices
AR1..AR4: Access Routers
R: Core Router
Ie1 = x.y.1.1/24, Ic1 = x.y.0.1/16
Ie2 = x.y.1.2/24, Ic2 = x.y.0.2/16
Ie3 = x.y.2.1/24, Ic3 = x.y.0.3/16
Ie4 = x.y.2.2/24, Ic4 = x.y.0.4/16
Fig.1: A possible multi-AR environment
In the above case, since both the incoming and outgoing traffic with
regard to a specific device are controlled to pass though a single
AR, it would be easier to perform authentication via the same AR.
However, this would change if the topology is different or if traffic
coming from and going to a specific device diverges among different
ARs as a result of ICMP Redirect or the use of "Default Router
Preferences and More-Specific Routes" [Draves] in IPv6. Detailed
architecture tradeoffs will be discussed in framework document.
3.1.3. Multiple Interfaces on a Single Device
PANA would be useful when a host has multiple interfaces of
homogeneous or heterogeneous technologies. A typical example is a
device with a Bluetooth interface and and an 802.11 interface or with
multiple Bluetooth interfaces. There are three possible scenarios:
interface switching, multi-homing, and interface sharing.
3.1.3.1. Interface Switching
If multiple interfaces are connectable to the same local network,
only one of those interfaces may be activated at a time for the
purpose of battery saving, and perform interface switching when other
interface is to be activated, with or without changing IP address. In
such an environment, the device may have to perform initial
authentication each time interface switching occurs, as well as
periodical re-authentication for the activated interface. This would
not be desired if initial authentication or re-authentication
involves communication with the AAA infrastructure which would
Expires July, 2002 [Page 8]
Internet-Draft PANA Usage Scenarios January 28, 2002
increase AAA signaling traffic in the core network unless the user's
credential is stored in the L2 network access point.
The LSA established by using PANA as a result of successful initial
authentication with an interface can be used for local re-
authentication which would be performed periodically or at every
interface switching event. See section "Using LSA for details.
Note that this kind of optimization by PANA would not be possible if
(i) multiple interfaces are connected to different local networks
each managed by an independent PAA and (ii) re-authentication is not
required.
3.1.3.2. Multi-homing
If multiple interfaces are connectable to the same local network,
those interfaces may be activated at the same time for the purpose of
bandwidth increase and/or load balancing.
In such an environment, the device may have to perform initial
authentication multiple times, one for each interface, and periodical
re-authentication for each interface. This would not be desired for
the same reason described in section "Interface Switching".
The LSA established by using PANA as a result of successful initial
authentication with an interface can be can be shared among all the
interfaces and used for local re-authentication which would be
performed periodically or when an additional interface comes up. See
section "Using LSA for Re-authentication" for details.
Note that this kind of optimization by PANA would not be possible if
(i) multiple interfaces are connected to different local networks
each managed by an independent PAA and (ii) re-authentication is not
required.
3.1.3.3. Interface Sharing
There may be cases in which a device (i.e., a gateway device) has one
provider interface and multiple private interfaces, where only the
provider interface is connected to the ISP's local network and other
interfaces are connected to other devices (child devices) under
administration of the user (i.e., both the gateway device and child
devices are owned by the same user). Traffic coming from the private
interfaces would be bridged or routed to the provider interface and
vice versa. Such a scenario would be more realistic in IPv6 where a
/64 prefix could be allocated to the user, enabling a distinct IP
address within the allocated prefix to be assigned to each of the
devices of the same user. In terms of both access control overhead
and AAA signaling overhead, it would be desirable to perform access
control per prefix rather than per child device. PANA would be very
suitable for such a prefix-based access control, especially in DSL or
cable modem environment (see Fig.2).
Expires July, 2002 [Page 9]
Internet-Draft PANA Usage Scenarios January 28, 2002
[D1a] ----+ /64 prefix +--------+
| <-- | |
[D1b] ----+---[GD1]--(DSL)-+ | |
| | | |
[D1c] ----+ | | |
. +--+ AR +----
[D2a] ----+ . | | |
| | | |
[D2b] ----+---[GD2]--(DSL)-+ | |
| | |
[D2c] ----+ +--------+
GD1: Gateway Device of User 1
GD2: Gateway Device of User 2
D1a,D1b,D1c: Other Devices of User 1
D2a,D2b,D2c: Other Devices of User 2
AR: Access Router
Fig.2: PANA usage in DSL
In this usage scenario, it would be required to prevent other users
from using the advertised prefix especially when the AR uses a single
Ethernet interface for multiple gateway devices (i.e., multiple
gateway devices of different users are on the same shared media, as
shown in Fig.2). Details will be discussed in framework document.
Note that if the gateway device and child devices are owned by
different users, access control would be performed per-device instead
of per-prefix. Then it boils down to one of the models as described
earlier in which each device performs PANA with PAA.
3.2. WLAN
WLAN is a one of the many scenarios where PANA could be useful. While
802.1X specification is being deployed by WISPs today, it would not
meet the future needs such as inter-technology hand-offs,
differentiation between free and paid access and others.
While interworking with 802.1X needs to be taken into consideration,
a solution at the higher layer is clearly another option, especially
where only legacy 802.11a/b interface cards and APs are available.
An alternative is that L2 authentication could be used to get free
local access, and PANA could then later be used to access specific
paid services or access to global Internet.
PANA and 802.1X-based authentication together may not be required for
all situations rather it would be preferable to use them in different
places - 802.1X authentication is preferred in public operator
networks where there are no free local services (or if all services
are charged at a flat rate), and PANA is preferred in hotels and
other places with free intranets. However, both mechanisms can
coexist in a service provider's network since they belong to two
different layers.
Expires July, 2002 [Page 10]
Internet-Draft PANA Usage Scenarios January 28, 2002
3.3. GPRS
In GPRS there are only two methods of authenticating/acquiring an
address from networks other than the GPRS access network (corporate
or ISP). In one mode PPP is terminated by the GGSN which then
authenticates the user (using the RADIUS client) to the "other"
network, being the ISP the user connects to or the "home" corporate
network depending on the requested APN. In the second mode, PPP is
terminated in the MT, ONLY the Challenge Response is piggybacked on
PDP context requests. The RADIUS client in the GGSN then relays this
info to the RADIUS server wherever that maybe (Based on the APN).
As yet another example, there is no mechanism for exchanging a
second level of authentication and addressing information, only the
interaction with the cellular systems' authentication and address
assignment mechanism is possible (although Mobile IP could be used).
A protocol that decouples the authentication and addressing from PPP
(and Mobile IP) could allow an operator to provide remote
authentication and authorization of home network services and address
assignment within such a domain using one of the available IP layer
tunneling mechanisms to deliver packets.
3.4. Intra-domain, Inter-technology Handoff
Although the PANA WG will not directly work on solutions relating to
mobility of the device. However, it is noted in the PANA WG charter
that the ability to re-authenticate locally with the PAA, can be an
important element in allowing efficient handling of mobile devices.
This section describe possible situations where an LSA established by
using PANA would be useful for mobile nodes.
Different radio technologies will have different characteristics in
terms of BW, cost, resilience and speed. Different applications may
prefer to use access technologies that are most suited to their
needs. It is foreseen that network operators will overlay different
access technologies on top of their existing IP backbones to satisfy
users' needs, hot spot coverages, etc. For an operator to have
control over the access to their networks some mechanism for user
authentication and access control is required. Currently these
mechanisms are access dependent (e.g.,. HLR in GPRS and 802.1X
specific mechanisms). Such access dependence requires an access
dependent identity for the user. Hence while connected to a Cellular
network, a user is identified by an IMSI, on a WLAN or Bluetooth
network a user will have a different identity.
For users to be able to roam seamlessly within an operator's domain
between different access technologies they need to avoid re-
authentication all the way back to their home AAA servers each time
the move. Context Transfer (CT) may help, however if the identity of
a user is different in each access technology, CT will not help and
re-authentication will become necessary. Hence an access independent
mechanism that uses a standard access independent identity is need to
identify the user regardless of which access technology he/she is
connected to. The LSA established by using PANA can be used for
minimize the re-authentication overhead so that re-authentication is
Expires July, 2002 [Page 11]
Internet-Draft PANA Usage Scenarios January 28, 2002
performed only locally in a similar way that is described in section
"Interface Switching". CT and MIP can solve the rest of the problem
for seamless mobility.
Another possible scenario in Mobile IPv6 is described in [Soliman].
4. LSA Usages
Establishing an LSA between a device and a PAA is equivalent to
having a shared secret between them. The shared secret for the LSA
can be derived from credentials of a user. The credentials could be
a symmetric cryptographic key (i.e., shared key) or an asymmetric
cryptographic key (i.e., public key). A typical example of symmetric
cryptographic key is a password stored in the database of the user's
home ISP. A typical example of asymmetric cryptographic key is a PKI
digital certificate issued by a trusted 3rd party.
4.1. Using LSA for Re-authentication
Once initial authentication is successful, re-authentication would be
necessary in the following situations:
o When there is a change in attributes of either the device or PAA.
For example, re-authentication would be necessary when the
device's IP address changes due to e.g., interface switching or
handoff.
o If the underlying access network does not have a capability to
detect physical disconnection of devices, periodical re-
authentication is necessary for (i) preventing connection
hijacking from malicious users which would possibly occur when the
device is shutdown or the user leaves the local network with the
device without performing explicit log-off from the local network
or (ii) improve the accuracy of accounting.
On the other hand, it is desired that periodical re-authentication is
performed locally between the device and PAA in order to minimize the
signaling traffic.
Once the LSA is established, re-authentication could be performed
locally based on the shared secret for the established LSA.
4.2. Using LSA for IKE
The shared key for the LSA or other shared key derived from the LSA
can also be used as an IKE credential with which an IPsec SA between
the device and PAA is established via IKE[RFC2409]. This would be
useful especially in roaming environment where it is difficult to
share the IKE credential a priori between the device and an IPsec
entity in the local network.
The established IPsec SA can be used for protecting PANA message
exchange, which would be useful for quick re-authentication and/or
Expires July, 2002 [Page 12]
Internet-Draft PANA Usage Scenarios January 28, 2002
secure explicit log-off.
It is also possible to utilize the LSA to establish an IPsec tunnel
between a device and an IPsec gateway. The established IPsec tunnel
can be used for protecting user data packets in the access network at
the IP layer. This would provide access network security without
relying on L2 security mechanisms, which is important considering the
recent exposure of WEP vulnerabilities.
5. Conclusion
The scenarios described above show a clear need for a common edge
protocol that would provide network or service providers a vehicle
for user authentication irrespective of what access technology they
are using. It is anticipated that a higher layer solution like PANA
can support future flexible service models. However, there are
several issues that need to be resolved before we deploy this
solution. We hope this draft will help the WG to understand
different usage scenarios either existing or upcoming and the
rationale behind this approach.
6. Acknowledgments
The authors would like to thank James Kempf, David Spence, and the
rest of the PANA Working Group for the ideas and support they have
given to this document.
7. References
[DIAMETER] P. Calhoun, et al., "Diameter Base Protocol", Work in
progress, November 2001.
[Draves] R. Draves, "Default Router Preferences and More-Specific
Routes", Work in Progress, May 2001.
[Keywords] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661
(STD 51), July 1994.
[RFC2409] D. Harkins, et. al., "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[RFC2510] C. Adams, et al., "Internet X.509 Public Key Infrastructure
Certificate Management Protocols", RFC 2510, March 1999.
[RFC2828] R. Shirey, "Internet Security Glossary", RFC 2828, May 2000.
[RFC2865] C. Rigney, "Remote Authentication Dial In User Service
(RADIUS)", RFC 2865, June 2000.
Expires July, 2002 [Page 13]
Internet-Draft PANA Usage Scenarios January 28, 2002
[RFC3157] A. Arsenault, et. al, "Securely Available Credentials -
Requirements", RFC 3157, August 2001.
[Soliman] H. Soliman, et al., "Security Association establishment for
Mobile IPv6 Route Optimisation using AAA", Internet-Draft, Work in
progress, July 2001.
8. Authors' Information
Yoshihiro Ohba
Toshiba America Research, Inc.
P.O. Box 136
Convent Station, NJ 07961-0136
USA
Phone: +1 973 829 5174
Fax: +1 973 829 5601
Email: yohba@tari.toshiba.com
Subir Das
MCC 1D210R, Telcordia Technologies
445 South Street, Morristown, NJ 07960
Phone: +1 973 829 4959
email: subir@research.telcordia.com
Henry Haverinen
Nokia Mobile Phones
P.O. Box 88
FIN-33721 Tampere
Finland
E-mail: henry.haverinen@nokia.com
Phone: +358 50 594 4899
Fax: +358 3 318 3690
Basavaraj Patil
Nokia
6000 Connection Dr.
Irving, TX. 75039
USA
Phone: +1 972-894-6709
Email: Basavaraj.Patil@nokia.com
Phil Roberts
Megisto Corp.
Suite 120
20251 Century Blvd
Germantown MD 20874
USA
Phone: +1 847-202-9314
Email: PRoberts@MEGISTO.com
Hesham Soliman
Ericsson Radio Systems AB
Torshamnsgatan 29,
Kista, Stockholm 16480
Sweden
Expires July, 2002 [Page 14]
Internet-Draft PANA Usage Scenarios January 28, 2002
Phone: +46 8 7578162
Fax: +46 8 4043630
E-mail: Hesham.Soliman@era.ericsson.se
Barani Subbiah
3Com Corporation
5400 Bayfront Plaza
Santa Clara CA 95052
Email: barani_subbiah@3com.com
Expires July, 2002 [Page 15]
