draft-ietf-pana-requirements-08.txt   draft-ietf-pana-requirements-09.txt 
Network Working Group A. Yegin, Ed. Network Working Group A. Yegin, Ed.
Internet-Draft Samsung AIT Internet-Draft Samsung AIT
Expires: December 9, 2004 Y. Ohba Expires: February 28, 2005 Y. Ohba
Toshiba Toshiba
R. Penno R. Penno
Nortel Networks Nortel Networks
G. Tsirtsis G. Tsirtsis
Flarion Flarion
C. Wang C. Wang
ARO/NCSU ARO/NCSU
June 10, 2004 August 30, 2004
Protocol for Carrying Authentication for Network Access (PANA) Protocol for Carrying Authentication for Network Access (PANA)
Requirements Requirements
draft-ietf-pana-requirements-08.txt draft-ietf-pana-requirements-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 42 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 9, 2004. This Internet-Draft will expire on February 28, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
It is expected that future IP devices will have a variety of access It is expected that future IP devices will have a variety of access
technologies to gain network connectivity. Currently there are technologies to gain network connectivity. Currently there are
access-specific mechanisms for providing client information to the access-specific mechanisms for providing client information to the
skipping to change at page 2, line 45 skipping to change at page 2, line 49
4.6 Interaction with Other Protocols . . . . . . . . . . . . . 11 4.6 Interaction with Other Protocols . . . . . . . . . . . . . 11
4.7 Performance . . . . . . . . . . . . . . . . . . . . . . . 11 4.7 Performance . . . . . . . . . . . . . . . . . . . . . . . 11
4.8 Congestion Control . . . . . . . . . . . . . . . . . . . . 11 4.8 Congestion Control . . . . . . . . . . . . . . . . . . . . 11
4.9 IP Version Independence . . . . . . . . . . . . . . . . . 12 4.9 IP Version Independence . . . . . . . . . . . . . . . . . 12
4.10 Denial of Service Attacks . . . . . . . . . . . . . . . . 12 4.10 Denial of Service Attacks . . . . . . . . . . . . . . . . 12
4.11 Client Identity Privacy . . . . . . . . . . . . . . . . . 12 4.11 Client Identity Privacy . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 16
8.2 Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
A. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 19 A. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 19
B. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 21 B. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . 24
1. Introduction 1. Introduction
Secure network access service requires access control based on the Secure network access service requires access control based on the
authentication and authorization of the clients and the access authentication and authorization of the clients and the access
networks. Initial and subsequent client-to-network authentication networks. Initial and subsequent client-to-network authentication
skipping to change at page 9, line 37 skipping to change at page 9, line 37
client provisioning. This transport is needed to create access client provisioning. This transport is needed to create access
control lists to allow authenticated and authorized clients' traffic control lists to allow authenticated and authorized clients' traffic
through the EPs. PANA Working Group will preferably identify an through the EPs. PANA Working Group will preferably identify an
existing protocol solution that allows the PAA to deliver the existing protocol solution that allows the PAA to deliver the
authorization information to one or more EPs when the PAA is authorization information to one or more EPs when the PAA is
separated from EPs. Possible candidates include but are not limited separated from EPs. Possible candidates include but are not limited
to COPS, SNMP, Diameter, etc. This task is similar to what the to COPS, SNMP, Diameter, etc. This task is similar to what the
MIDCOM Working Group is trying to achieve, therefore some of that MIDCOM Working Group is trying to achieve, therefore some of that
working group's output might be useful here. working group's output might be useful here.
It is assumed that the communication between PAA and EP(s) is secure. The communication between PAA and EP(s) MUST be secure. The
The objective of using a PAA-to-EP protocol is to provide filtering objective of using a PAA-to-EP protocol is to provide filtering rules
rules to EP(s) for allowing network access of a recently to EP(s) for allowing network access of a recently authenticated and
authenticated and authorized PaC. The chosen protocol MUST be authorized PaC. The chosen protocol MUST be capable of carrying DI
capable of carrying DI and cryptographic keys for a given PaC from and cryptographic keys for a given PaC from PAA to EP. Depending on
PAA to EP. Depending on the PANA protocol design, support for either the PANA protocol design, support for either of the pull model (i.e.,
of the pull model (i.e., EP initiating the PAA-to-EP protocol EP initiating the PAA-to-EP protocol exchange per PaC) or the push
exchange per PaC) or the push model (i.e., PAA initiating the model (i.e., PAA initiating the PAA-to-EP protocol exchange per PaC),
PAA-to-EP protocol exchange per PaC), or both may be required. For or both may be required. For example, if the design is such that the
example, if the design is such that the EP allows the PANA traffic to EP allows the PANA traffic to pass through even for unauthenticated
pass through even for unauthenticated PaCs, the EP should also allow PaCs, the EP should also allow and expect the PAA to send the
and expect the PAA to send the filtering information at the end of a filtering information at the end of a successful PANA exchange
successful PANA exchange without the EP ever sending a request. without the EP ever sending a request.
4.5 Network 4.5 Network
4.5.1 Multi-access 4.5.1 Multi-access
PANA MUST support PaCs with multiple interfaces, and networks with PANA MUST support PaCs with multiple interfaces, and networks with
multiple routers on multi-access links. In other words, PANA MUST multiple routers on multi-access links. In other words, PANA MUST
NOT assume the PaC has only one network interface, or the access NOT assume the PaC has only one network interface, or the access
network has only one first hop router, or the PaC is using a network has only one first hop router, or the PaC is using a
point-to-point link. point-to-point link.
skipping to change at page 10, line 40 skipping to change at page 10, line 40
network systems going down, or a change in the access policy. network systems going down, or a change in the access policy.
In case the clients cannot send explicit disconnect messages to the In case the clients cannot send explicit disconnect messages to the
PAA, PAA can still detect their departure by relying on periodic PAA, PAA can still detect their departure by relying on periodic
authentication requests. authentication requests.
4.5.3 Location of PAA 4.5.3 Location of PAA
The PAA and PaC MUST be exactly one IP hop away from each other. The PAA and PaC MUST be exactly one IP hop away from each other.
That is, there must be no IP routers between the two. Note that this That is, there must be no IP routers between the two. Note that this
does not mean they are on the same physical link. Bridging does not mean they are on the same physical link. Bridging and
techniques can place two nodes just exactly one IP hop away from each tunneling (e.g., IP-in-IP, GRE, L2TP, etc.) techniques can place two
other although they might be connected to separate physical links. A nodes just exactly one IP hop away from each other although they
PAA can be on the NAS (network access server) or WLAN access point or might be connected to separate physical links. A PAA can be on the
first hop router. The use of PANA when the PAA is multiple IP hops NAS (network access server) or WLAN access point or first hop router.
away from the PaC is outside the scope of PANA. The use of PANA when the PAA is multiple IP hops away from the PaC is
outside the scope of PANA.
A PaC may or may not be pre-configured with the IP address of PAA. A PaC may or may not be pre-configured with the IP address of PAA.
Therefore the PANA protocol MUST define a dynamic discovery method. Therefore the PANA protocol MUST define a dynamic discovery method.
Given that the PAA is one hop away from the PaC, there are a number Given that the PAA is one hop away from the PaC, there are a number
of discovery techniques that could be used (e.g., multicast or of discovery techniques that could be used (e.g., multicast or
anycast) by the PaC to find out the address of the PAA. anycast) by the PaC to find out the address of the PAA.
4.5.4 Secure Channel 4.5.4 Secure Channel
PANA MUST NOT assume presence of a secure channel between the PaC and PANA MUST NOT assume presence of a secure channel between the PaC and
skipping to change at page 11, line 33 skipping to change at page 11, line 33
client and network authentication. client and network authentication.
4.6 Interaction with Other Protocols 4.6 Interaction with Other Protocols
Mobility management is outside the scope of PANA. However, PANA MUST Mobility management is outside the scope of PANA. However, PANA MUST
be able to co-exist and MUST NOT unintentionally interfere with be able to co-exist and MUST NOT unintentionally interfere with
various mobility management protocols, such as Mobile IPv4 [RFC3344], various mobility management protocols, such as Mobile IPv4 [RFC3344],
Mobile IPv6 [I-D.ietf-mobileip-ipv6], fast handover protocols Mobile IPv6 [I-D.ietf-mobileip-ipv6], fast handover protocols
[I-D.ietf-mipshop-fast-mipv6][I-D.ietf-mobileip-lowlatency-handoff], [I-D.ietf-mipshop-fast-mipv6][I-D.ietf-mobileip-lowlatency-handoff],
and other standard protocols like IPv6 stateless address and other standard protocols like IPv6 stateless address
auto-configuration [RFC2461] (including privacy extensions auto-configuration [RFC2461] (including privacy extensions [RFC3041]),
[RFC3041]), and DHCP [RFC2131][RFC3315]. It MUST NOT make any and DHCP [RFC2131][RFC3315]. It MUST NOT make any assumptions on the
assumptions on the protocols or mechanisms used for IP address protocols or mechanisms used for IP address configuration of the PaC.
configuration of the PaC.
4.7 Performance 4.7 Performance
PANA design SHOULD give consideration to efficient handling of the PANA design SHOULD give consideration to efficient handling of the
authentication process. This is important for gaining network access authentication process. This is important for gaining network access
with minimum latency. As an example, a method like minimizing the with minimum latency. As an example, a method like minimizing the
protocol signaling by creating local security associations can be protocol signaling by creating local security associations can be
used for this purpose. used for this purpose.
4.8 Congestion Control 4.8 Congestion Control
skipping to change at page 15, line 7 skipping to change at page 15, line 7
Due to the nature of this protocol most of the requirements are Due to the nature of this protocol most of the requirements are
security related. The actual protocol design is not specified in security related. The actual protocol design is not specified in
this document. A thorough discussion on PANA security threats can be this document. A thorough discussion on PANA security threats can be
found in PANA Threat Analysis and Security Requirements document found in PANA Threat Analysis and Security Requirements document
[I-D.ietf-pana-threats-eval]. Security threats identified in that [I-D.ietf-pana-threats-eval]. Security threats identified in that
document are already included in this general PANA requirements document are already included in this general PANA requirements
document. document.
7. Acknowledgements 7. Acknowledgements
Authors would like to thank Bernard Aboba, Derek Atkins, Julien Authors would like to thank Bernard Aboba, Derek Atkins, Steven
Bournelle, Subir Das, Francis Dupont, Dan Forsberg, Pete McCann, Bellovin, Julien Bournelle, Subir Das, Francis Dupont, Dan Forsberg,
Lionel Morand, Thomas Narten, Mohan Parthasarathy, Basavaraj Patil, Pete McCann, Lionel Morand, Thomas Narten, Mohan Parthasarathy,
Hesham Soliman, and the PANA Working Group members for their valuable Basavaraj Patil, Hesham Soliman, and the PANA Working Group members
contributions to the discussions and preparation of this document. for their valuable contributions to the discussions and preparation
of this document.
8. References 8. References
8.1 Normative References 8.1 Normative References
[I-D.ietf-pana-threats-eval] [I-D.ietf-pana-threats-eval]
Parthasarathy, M., "PANA Threat Analysis and security Parthasarathy, M., "Protocol for Carrying Authentication
requirements", draft-ietf-pana-threats-eval-04 (work in and Network Access Threat Analysis and Security
progress), May 2003. Requirements", draft-ietf-pana-threats-eval-07 (work in
progress), August 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
Authentication Protocol (EAP)", RFC 2284, March 1998. Authentication Protocol (EAP)", RFC 2284, March 1998.
8.2 Informative References 8.2 Informative References
[I-D.ietf-eap-rfc2284bis] [I-D.ietf-eap-rfc2284bis]
Blunk, L., "Extensible Authentication Protocol (EAP)", Blunk, L., "Extensible Authentication Protocol (EAP)",
draft-ietf-eap-rfc2284bis-09 (work in progress), February draft-ietf-eap-rfc2284bis-09 (work in progress), February
2004. 2004.
[I-D.ietf-mipshop-fast-mipv6] [I-D.ietf-mipshop-fast-mipv6]
Koodli, R., "Fast Handovers for Mobile IPv6", Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fast-mipv6-01 (work in progress), draft-ietf-mipshop-fast-mipv6-02 (work in progress), July
February 2004. 2004.
[I-D.ietf-mobileip-ipv6] [I-D.ietf-mobileip-ipv6]
Johnson, D., Perkins, C. and J. Arkko, "Mobility Support Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress),
July 2003. July 2003.
[I-D.ietf-mobileip-lowlatency-handoff] [I-D.ietf-mobileip-lowlatency-handoff]
Malki, K., "Low latency Handoffs in Mobile IPv4", Malki, K., "Low latency Handoffs in Mobile IPv4",
draft-ietf-mobileip-lowlatency-handoffs-v4-09 (work in draft-ietf-mobileip-lowlatency-handoffs-v4-09 (work in
progress), June 2004. progress), June 2004.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/