draft-ietf-pana-requirements-03.txt   draft-ietf-pana-requirements-04.txt 
PANA Working Group Reinaldo Penno, Editor PANA Working Group Reinaldo Penno, Editor
INTERNET-DRAFT Alper E. Yegin INTERNET-DRAFT Alper E. Yegin
Date: June 2002 Yoshihiro Ohba Date: October 2002 Yoshihiro Ohba
Expires: December 2002 George Tsirtsis Expires: April 2003 George Tsirtsis
Cliff Wang Cliff Wang
Protocol for Carrying Authentication for Protocol for Carrying Authentication for
Network Access (PANA) Network Access (PANA)
Requirements and Terminology Requirements and Terminology
<draft-ietf-pana-requirements-03.txt> <draft-ietf-pana-requirements-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 31 skipping to change at page 2, line 31
4.2.2. Disconnect Indication......................................6 4.2.2. Disconnect Indication......................................6
4.2.3. Location of PAA............................................7 4.2.3. Location of PAA............................................7
4.2.4. Secure Channel.............................................7 4.2.4. Secure Channel.............................................7
4.3. Interaction with Other Protocols.............................7 4.3. Interaction with Other Protocols.............................7
4.4. Performance..................................................8 4.4. Performance..................................................8
4.5. Reliability and Congestion Control...........................8 4.5. Reliability and Congestion Control...........................8
4.6. Miscellaneous................................................8 4.6. Miscellaneous................................................8
4.6.1. IP Version Independence....................................8 4.6.1. IP Version Independence....................................8
4.6.2. Denial of Service Attacks..................................8 4.6.2. Denial of Service Attacks..................................8
4.6.3. Location Privacy...........................................8 4.6.3. Location Privacy...........................................8
4.7 Change Log....................................................8 4.7 Change Log....................................................9
Acknowledgements..................................................9 Acknowledgements..................................................9
References........................................................9 References........................................................9
Authors' Addresses................................................9 Authors' Addresses...............................................10
Full Copyright Statement.........................................10 Appendix (PANA Model)............................................11
Full Copyright Statement.........................................13
1. Introduction 1. Introduction
Network access technologies for wired and wireless media are Network access technologies for wired and wireless media are
evolving rapidly. With the rapid growth in the number and type of evolving rapidly. With the rapid growth in the number and type of
devices and terminals that support IP stacks and can access the devices and terminals that support IP stacks and can access the
Internet, users can potentially use a single device having the Internet, users can potentially use a single device having the
capability of attaching via different multiple access media and capability of attaching via different multiple access media and
technologies to interface to the network. technologies to interface to the network.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
its users can access the network is outside the scope of PANA. its users can access the network is outside the scope of PANA.
PANA MUST NOT define new security protocols or mechanisms. Instead PANA MUST NOT define new security protocols or mechanisms. Instead
it must be defined as a "carrier" for such protocols. PANA MUST it must be defined as a "carrier" for such protocols. PANA MUST
identify which specific security protocol(s) or mechanism(s) it can identify which specific security protocol(s) or mechanism(s) it can
carry (the "payload"). The current thinking is that a sufficient carry (the "payload"). The current thinking is that a sufficient
solution would be for PANA to carry EAP. If PANA WG decides that solution would be for PANA to carry EAP. If PANA WG decides that
extensions to EAP are needed, it will define requirements for an extensions to EAP are needed, it will define requirements for an
EAP WG instead of defining these extensions. EAP WG instead of defining these extensions.
Authentication and encryption of data traffic sent to and from an Authentication and encryption of data traffic except between
authenticated PaC is outside the scope of PANA. Providing a complete the Pac and PAA is outside the scope of PANA. Providing a complete
secure network access solution by also securing router discovery secure network access solution by also securing router discovery
[RDISC], neighbor discovery [NDISC], and address resolution [RDISC], neighbor discovery [NDISC], and address resolution
protocols [ARP] is outside the scope as well. protocols [ARP] is outside the scope as well.
Both the PaC and the PAA MUST be able to authenticate each other for Both the PaC and the PAA MUST be able to authenticate each other for
network access. Providing capability of only PAA authenticating the network access. Providing capability of only PAA authenticating the
PaC is not sufficient. PaC is not sufficient.
PANA MUST be capable of carrying out both periodic and on-demand re- PANA MUST be capable of carrying out both periodic and on-demand re-
authentication. Both the PaC and the PAA MUST be able to initiate authentication. Both the PaC and the PAA MUST be able to initiate
skipping to change at page 7, line 20 skipping to change at page 7, line 20
Several mechanisms can be used to provide disconnect indication, Several mechanisms can be used to provide disconnect indication,
e.g., frequent re-authentication; but the use of a heartbeat e.g., frequent re-authentication; but the use of a heartbeat
function is not recommended. function is not recommended.
4.2.3. Location of PAA 4.2.3. Location of PAA
The PAA must be on an IP capable network element on the same The PAA must be on an IP capable network element on the same
IP link as the PaC. Hence it can be on the NAS or WLAN AP or first IP link as the PaC. Hence it can be on the NAS or WLAN AP or first
hop router (most likely scenario). The use of PANA when the PAA is hop router (most likely scenario). The use of PANA when the PAA is
not on the same link as the PAA is outside the scope of PANA. not on the same link as the PaC is outside the scope of PANA.
Since a PaC may not be pre-configured with the IP address of PAA, Since a PaC may not be pre-configured with the IP address of PAA,
but may have to dynamically discover instead. Therefore PANA but may have to dynamically discover instead. Therefore PANA
protocol must define a dynamic discovery method. Given that protocol must define a dynamic discovery method. Given that
the PAA is on the same link as the PaC, there are number the PAA is on the same link as the PaC, there are 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.
PANA does not assumes the PAA is co-located with the enforcement PANA does not assumes the PAA is co-located with the enforcement
point. Network access enforcement can be provided by one or more point. Network access enforcement can be provided by one or more
skipping to change at page 9, line 7 skipping to change at page 9, line 7
masquerade attacks through IP spoofing that swamp the PAA in masquerade attacks through IP spoofing that swamp the PAA in
spending much resources and prevent legitimate clientsœ attempts of spending much resources and prevent legitimate clientsœ attempts of
network access. network access.
4.6.3. Location Privacy 4.6.3. Location Privacy
Location privacy is outside the scope of PANA. Location privacy is outside the scope of PANA.
4.7. Change Log 4.7. Change Log
Version 04
* Minor Editorial corrections
* Inserted the PANA model appendix
Version 03 Version 03
* In section 4.2.2 the requirement for a heartbeat mechanism to * In section 4.2.2 the requirement for a heartbeat mechanism to
provide disconnect indication was removed. Rewording of the provide disconnect indication was removed. Rewording of the
section was done section was done
* In section 4.2.3 and 4.1.2 rewording was done to account for * In section 4.2.3 and 4.1.2 rewording was done to account for
the separation of PAA and EP and the protocol between them. the separation of PAA and EP and the protocol between them.
* In section 4.2.4 new text was added to account for the possibility * In section 4.2.4 new text was added to account for the possibility
skipping to change at page 9, line 51 skipping to change at page 10, line 5
[MIPV4] C. Perkins (editor), "IP Mobility Support", RFC 2002, [MIPV4] C. Perkins (editor), "IP Mobility Support", RFC 2002,
October 1996. October 1996.
[MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-15.txt, July 2001. Work in progress. draft-ietf-mobileip-ipv6-15.txt, July 2001. Work in progress.
[MNAAA] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response [MNAAA] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response
Extensions", RFC3012, November 2000. Extensions", RFC3012, November 2000.
[RDISC] S. Deering, "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[NDISC] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery [NDISC] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)",RFC 2461, December 1998. for IP Version 6 (IPv6)",RFC 2461, December 1998.
[ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37, [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37,
RFC 826, November 1982. RFC 826, November 1982.
[FMIPV4] K. ElMalki (editor), et. al., "Low latency Handoffs in [FMIPV4] K. ElMalki (editor), et. al., "Low latency Handoffs in
Mobile IPv4", November 2001. Work in progress. Mobile IPv4", November 2001. Work in progress.
[FMIPV6] G. Dommety (editor), et. al., "Fast Handovers for Mobile [FMIPV6] G. Dommety (editor), et. al., "Fast Handovers for Mobile
skipping to change at line 496 skipping to change at page 11, line 11
USA USA
Phone : +44 20 88260073 Phone : +44 20 88260073
E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com
Cliff Wang Cliff Wang
Smart Pipes Smart Pipes
565 Metro Place South 565 Metro Place South
Dublin, OH, 43017 Dublin, OH, 43017
USA USA
Phone: +1 614 923 6241 Phone: +1 614 923 6241
Email: cwang@smartpipes.com Email: cwang@smartpipes.com
Appendix
A. PANA Model
Following sub-sections capture the PANA usage model in different
network architectures with reference to its placement of logical
elements such as, PANA Client (PaC) and PANA Authentication Agent
(PAA) w.r.t Enforcement Point (EP) and Access Router (AR). Four
different scenarios are described in following sub-sections. Note
that PAA may or may not use AAA infrastructure to verify the
credentials of PaC and grants or deny the device (belongs to that
particular PaC) to access the network resources.
A.1. PAA Co-located with EP but separated from AR
In this scenario (Figure 1), PAA is co-located with the enforcement
point on which access control is performed. PaCs communicate with
the PAA for network access on behalf of a device (D1, D2,... etc.).
PANA in this case provides a means to transport the authentication
parameters from the PaC to PAA securely. PAA understands how to
verify the credentials. After verification, PAA sends back the
success or failure to PaC. However, PANA does not play any explicit
role in performing access control except that it provides a hook to
access control mechanisms.
PaC -----EP/PAA-+
[D1] |
+- ----- AR ----- (AAA)
|
PaC -----EP/PAA-+
[D2]
Figure 1: An example of PANA Model
[PAA co-located with EP but separated from AR]
A.2. PAA Co-located with AR but separated from EP
Figure 2 describes this model. In this scenario, PAA is not co-
located with EPs but resides in the edge subnet. Although we have
shown only one AR here there could be multiple ARs with PAAs co-
located. PaC exchanges the same messages with PAA as discussed
earlier. The difference here is when initial authentication for the
PaC is successful, access control parameters are to be distributed to
respective enforcement points residing in the edge subnet so that the
corresponding device on which PaC is authenticated must get the
access to the network. Similar to earlier case, PANA does not play
any explicit role in performing access control except that it
provides a hook to access control mechanisms. However, a separate
protocol is needed between PAA and EP to carry access control
parameters.
PaC -------- EP --+
[D1] |
+--- router/PAA --- (AAA)
|
PaC -------- EP --+
[D2]
Figure 2: An example of PANA Model
[PAA co-located with AR but separated from EP]
A.3. PAA colocated with EP and router
In this scenario (Figure 3), PAA is co-located with the EP and AR on
which access control and routing are performed. PaC exchanges the
same messages with PAA and PAA performs similar functionalities as
above. PANA in this case also does not play any explicit role in
performing access control except that it provides a hook to access
control mechanisms.
PaC ---------- EP/PAA/router+
[D1] |
+ -------(AAA)
|
PaC ---------- EP/PAA/router+
[D2]
Figure 3: An example of PANA Model
[PAA co-located with EP and AR]
A.4. PAA Separated from EP and AR
Figure 4 represents this model. In this scenario, PAA is neither co-
located with EPs nor ARs but resides on the edge subnet. Although we
have shown only one PAA here there could be multiple PAAs in the edge
subnet. PaC does similar exchanges with PAA as discussed earlier.
Similar to model 5.2, after successful authentication, access control
parameters will be distributed to respective enforcement points via a
separate protocol and PANA does not play any explicit role to this.
PaC ----- EP -----+- router -----+
| |
PaC ----- EP --- -+ |
| |
PaC ----- EP -----+- router ---- + ----(AAA)
|
+- PAA
Figure 4: An example of PANA Model
[PAA separated from EP and AR]
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (2002). All Rights Reserved. "Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
 End of changes. 

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