Service theft allows the possibility of exploiting the weakness in
other authentication protocols that use IP address for
authentication. It also allows the interception of traffic destined
for other nodes by spoofing the IP address.
If the link is not shared, T6.4.1 is absent, as there is only one
client on the link, and ingress filtering can prevent the use of the
authorized IP and MAC addresses by the attacker on another link.
Threat T6.4.2 exists, as the attacker can use the IP or MAC address
of the real PaC to gain access to the network.
If the link is shared, both the threats are present. If layer 2
provides per-packet protection using pair-wise keys, both the threats
can be prevented.
Requirement 7
PANA MUST securely bind the authenticated session to the device
identifier of the client, to prevent service theft. PANA MUST be
able to bootstrap a shared secret between the PaC and PAA that can be
further used to set up a security association between the PaC and EP
to provide cryptographic protection against service theft.
6.5. PAA-EP Communication
After a successful authentication, the PAA needs to communicate the
access control information of the PaC to the EP so that the PaC will
be allowed to access the network. The information communicated would
contain at least the device identifier of the PaC. If strong
security is needed, the PAA will communicate a shared secret known
only to the PaC and PAA, for setting up a security association
between the PaC and EP. The following are possible threats:
T6.5.1: An attacker can eavesdrop to learn the information
communicated between the PAA and EP. The attacker can
further use this information to spoof the real PaC and also
to set up security association for gaining access to the
network. This threat is absent if the attacker cannot
eavesdrop on the link; e.g., the PAA and EP communicate on a
link separate from that of visiting PaCs.
T6.5.2: An attacker can pretend to be a PAA and send false
information to an EP to gain access to the network. In the
case of stronger security, the attacker has to send its own
device identifier and also a shared secret, so that the EP
will let the attacker access the network.
If the communication between the PAA and EP is protected, these
threats are absent.
Requirement 8
The communication between the PAA and EP MUST be protected against
eavesdropping and spoofing attacks.
6.6. Miscellaneous Attacks
T6.6.1: There are various forms of DoS attacks that can be launched
on the PAA or AS. A few are mentioned below. As it is hard
to defend against some of the DoS attacks, the protocol
should be designed carefully to mitigate or prevent such
attacks.
o An attacker can bombard the PAA with lots of
authentication requests. If the PAA and AS are not co-
located, the PAA may have to allocate resources to store
some state about the PaC locally before it receives the
response from the back-end AS. This can deplete memory
resources on the PAA.
o With minimal effort, an attacker can force the PAA or AS
to make computationally intensive operations with minimal
effort, that can deplete the CPU resources of the PAA or
AS.
T6.6.2: PaC acquires an IP address by using stateful or stateless
mechanisms before PANA authentication begins [PANAREQ]. When
the IP addresses are assigned before the client
authentication, it opens up the possibility of DoS attacks in
which unauthenticated malicious nodes can deplete the IP
address space by acquiring multiple IP addresses or deny
allocation to others by responding to every duplicate address
detection (DAD) query.
Depleting a /64 IPv6 link-local address space or a /8 RFC1918
private address space requires a brute-force attack. Such an
attack is part of a DoS class that can equally target the
link capacity or the CPU cycles on the target system by
bombarding arbitrary packets. Therefore, solely handling the
IP address depletion attack is not going to improve the
security, as a more general solution is needed to tackle the
whole class of brute-force attacks.
The DAD attack can be prevented by deploying secure address
resolution that does not depend on the client authentication,
such as [SEND]. The attack may also be prevented if the EP
is placed between the PaCs to monitor the ND/ARP activity and
to detect DAD attacks (excessive NA/ARP replies). If none of
these solutions are applicable to a deployment, the PaCs can
send arbitrary packets to each other without going through
the EP, which enables a class of attacks that are based on
interfering with the PANA messaging (See T6.1.1). Since
there will always be a threat in this class (e.g., insecure
discovery), it is not going to improve the overall security
by addressing DAD.
7. Summary of Requirements
1. PANA MUST not assume that the discovery process is protected.
2. PANA MUST be able to mutually authenticate the PaC and PAA. PANA
MUST be able to establish keys between the PaC and PAA to protect
the PANA messages.
3. When compound authentication methods are used in PANA, the methods
MUST be cryptographically bound.
4. PANA MUST be able to protect itself against replay attacks.
5. PANA MUST be able to protect the device identifier against
spoofing when it is exchanged between the PaC and PAA.
6. PANA MUST be able to protect disconnect and revocation messages.
PANA MUST NOT depend on whether the PaC sends a disconnect
message.
7. PANA MUST securely bind the authenticated session to the device
identifier of the client, to prevent service theft. PANA MUST be
able to bootstrap a shared secret between the PaC and PAA that can
be further used to set up a security association between the PaC
and EP to provide cryptographic protection against service theft.
8. The communication between the PAA and EP MUST be protected against
eavesdropping and spoofing attacks.
8. Security Considerations
This document discusses various threats with IP based network access
authentication protocol. Though this document discusses the threats
for shared and unshared links separately, it may be difficult to make
such a distinction in practice (e.g., a dial-up link may be a point-
to-point IP tunnel). Hence, the link should be assumed to be a
shared link for most of the threats in this document.
9. Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10. Informative References
[PANAREQ] Yegin, A., Ed., Ohba, Y., Penno, R., Tsirtsis, G., and
C. Wang, "Protocol for Carrying Authentication for
Network Access (PANA) Requirements and Terminology",
Work in Progress, August 2004.
[EAP-KEY] Aboba, B., et al., "EAP keying framework", Work in
Progress.
[RAD-EAP] Aboba, B. and P. Calhoun, "RADIUS (Remote
Authentication Dial In User Service) Support For
Extensible Authentication Protocol (EAP)", RFC 3579,
September 2003.
[TUN-EAP] Puthenkulam, J., et al., "The compound authentication
binding problem", Work in Progress.
[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March
2005.
11. Acknowledgements
The author would like to thank the following people (in no specific
order) for providing valuable comments: Alper Yegin, Basavaraj Patil,
Pekka Nikander, Bernard Aboba, Francis Dupont, Michael Thomas,
Yoshihiro Ohba, Gabriel Montenegro, Tschofenig Hannes, Bill
Sommerfeld, N. Asokan, Pete McCan, Derek Atkins, and Thomas Narten.
Author’s Address
Mohan Parthasarathy
Nokia
313 Fairchild Drive
Mountain View, CA-94303
EMail: mohanp@sbcglobal.net
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.