Internet DRAFT - draft-narayanan-pba
draft-narayanan-pba
Network Working Group N. Venkitaraman
Internet-Draft Motorola
Expires: December 24, 2006 V. Narayanan
L. Dondeti
QUALCOMM, Inc.
June 22, 2006
Symmetric-key Based IPv6 Addresses
draft-narayanan-pba-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on December 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
A cryptographically generated address (CGA) is an IPv6 address
generated by applying a hash function over the public key of a node
and some additional parameters. CGA ownership can be asserted only
by the node claiming the address, but is readily verifiable using the
public-key of that node by any other entity. Such address
authorization is also plausible using symmetric keys, where a node
Venkitaraman, et al. Expires December 24, 2006 [Page 1]
Internet-Draft SBA June 2006
generating the self-identifying address shares a key with the
verifier or its agent. This document specifies symmetric-key based
address (SBA) generation. The infrastructure support comes with
several advantages including proxy-mode operation; the symmetric key
usage results in efficient operation; and finally the use of keyed
hashing provides security advantages over CGAs.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Symmetric Key based IPv6 address Generation . . . . . . . . . 4
3.1. Input key considerations for SBA . . . . . . . . . . . . . 5
3.2. Input key generation for SBA . . . . . . . . . . . . . . . 5
4. SBA Generation and Verification . . . . . . . . . . . . . . . 6
4.1. Parameters for SBA Generation . . . . . . . . . . . . . . 6
4.2. SBA Generation . . . . . . . . . . . . . . . . . . . . . . 8
4.3. SBA Verification . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5.1. On the input parameters to SBA generation . . . . . . . . 10
5.2. Strength of the SBA derivation . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Venkitaraman, et al. Expires December 24, 2006 [Page 2]
Internet-Draft SBA June 2006
1. Introduction
Cryptographically generated addresses (CGAs) [RFC3972] are IPv6
addresses where the interface identifier -- the lower 64 bits of the
address -- is generated using a cryptographic hash of a public key
and other parameters. The corresponding private key can be used to
assert the claim to the generated address. Any node can verify
whether a node claiming the address indeed owns that address by using
the known public key. While the asymmetric key based operations can
be expensive, the key advantage of CGA generation and verification is
that it works without the need for infrastructure support.
Many systems employ AAA-based infrastructure support with pre-
provisioned symmetric keys; such existing key sharing relationships
can be used for generation and verification of IPv6 addresses.
Address generation using symmetric keys have a number of benefits.
In many systems, especially those involving mobile nodes, trusted
entities other than the node which owns the address may have to
generate messages on behalf of the node. For instance a Home Agent
(HA) may need to generate a proxy neighbor advertisement when a
mobile node is away from its home network. In such a case,
generating a HoA of the mobile node using a shared key between the HA
and the MN enables the HA to simply proxy for the mobile when the
mobile node is away from home. Similarly an access router (AR) may
need to generate advertisement messages to defend an IP address
corresponding to a mobile node that is presently under a different
subnet. Generating a CoA using a shared key between the AR and the
MN enables the AR to generate advertisements on behalf of the mobile
node.
In many of the above mentioned situations, a shared key is already
available between the mobile node and the entity generating messages
on behalf of it. For example, the MN shares a security association
with the HA in the case of Mobile IP. In the case of FMIPv6
operation, the MN shares a handover key with the AR. Both these SAs
could have been generated with the aid of a AAA server: running
IKEv2/EAP with the HA to generate an SA for MIP6 involves the shared
secret the MN shares with the AAA server; similarly, AAA-based
handover keys may be generated for FMIPv6. In the presence of such
SAs, it is desirable to extend that trust relationship to provide
address authorization.
In a number of systems, packets always flow via an access router. In
such systems, in the presence of a shared key between a node and the
AR, it is more efficient to generate IP addresses to prove address
ownership using symmetric keys rather than asymmetric cryptography.
Venkitaraman, et al. Expires December 24, 2006 [Page 3]
Internet-Draft SBA June 2006
This draft provides a means of IPv6 address generation using a shared
secret so that the IP address of a node can be verified by the entity
with which the node shares the secret. This is generally applicable
to systems where a node generating an address needs to prove the
ownership only to a selected number of nodes with which it has a
direct or a derived trust relationship.
2. Terminology
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 RFC 2119 [RFC2119].
In addition, this document uses the following terms:
Symmetric Key Based Address (SBA)
An IPv6 address generated cryptographically using a pre-shared
key. SBAs are self-identifying addresses in that the verifier can
independently determine the validity of the address by running the
address generation process.
Address Generation Key (AGK)
A key generated from the PSK specifically for use in the
generation of SBAs.
SBA Generator
This is an entity that generates a self-identifying IPv6 address
using a shared-key.
SBA Verifier
SBA Verifier is the entity that needs to determine the validity of
the generator's claim to an IPv6 SBA, either using a key available
locally or with the help of a third party that holds the key used
to generate the address. The third party is typically a AAA
server.
3. Symmetric Key based IPv6 address Generation
This section describes a method using symmetric keys to derive the
interface identifier part of the IPv6 address of a node. Similar to
the CGA specification [RFC3972], this document refers to IPv6
addresses where the leftmost 64 bits form the IPv6 prefix and the
Venkitaraman, et al. Expires December 24, 2006 [Page 4]
Internet-Draft SBA June 2006
rightmost 64 bits of the address form the interface identifier.
Unlike the CGA addresses, there is no 'Sec' field.
An SBA is the truncated output of a PRF, keyed with the symmetric key
known to the generator and the verifier or its agent; other inputs to
the PRF are the IPv6 prefix, generator or IPv6 node's identity (used
to look up the symmetric key), and a random nonce selected by the
generator.
The leftmost 64bits of the output of the PRF are taken and masked
with 0xfcffffffffffffff to set bits 6 and 7 (i.e., the "u" and "g"
bits) [RFC3513] to zero. These bits are ignored by the verifier in
comparing the locally generated IPv6 suffix, based on the input
parameters and the shared symmetric key, and the claimed suffix.
3.1. Input key considerations for SBA
SBAs are derived using a symmetric key shared between the IPv6 suffix
generator and the verifier. Alternatively, the verifier may use the
help of a third party (e.g., AAA server) which shares a key with the
generator.
In either case, there may already be a key specifically designated
for the purpose of address generation. If there is only a generic
shared key between the generator and the verifier, it is desirable to
generate a separate key for the purpose of address generation to
avoid using a single key for different purposes.
Note that address generation keys (AGK) may be static as in case of a
key generated from a PSK (see the next section) or dynamic when the
it is derived as part of another authentication process (note that
the PSK may or may not be used for that authentication).
3.2. Input key generation for SBA
When a designated key for IPv6 address generation is not available,
the pre-shared key (PSK) may be used to derive an AGK using the
following key derivation function (KDF).
AGK = PRF+ (PSK, "Address Generation Key", Op-data)
Op-data or optional data is NULL when the AGK is derived within the
entity that holds the PSK, and is equal to the Verifier's ID, when
the AGK is derived for a verifier. The third party, typically a AAA
server, generates an AGK and sends it on demand to the verifier using
the AAA protocol.
The AGK has the following properties.
Venkitaraman, et al. Expires December 24, 2006 [Page 5]
Internet-Draft SBA June 2006
o The length, l, of the AGK is dependent on the PRF algorithm used
in generating the SBA. We may use a cipher-based or a hash-based
PRF. In some cases, for instance in AES-256 based PRFs, the
output size of the PRF is less than the AGK length. Thus, we
specify the use of PRF+ as defined in [RFC4306] to generate the
AGK. The first l bits of the PRF+ output serves as the AGK.
o The AGK may be delivered to another entity in some special cases.
This applies when the verifier is authorized to possess the key
for subsequent verifications without any interaction with the
third party.
o The AGK is cryptographically separate from any other keys derived
from the PSK.
o This document does not mandate a lifetime value for the AGK.
However, protocols specifying the derivation and use of such AGKs
must specify a lifetime depending on the usage scenario. The
maximum lifetime of a dynamically derived AGK MUST NOT exceed 8
hours.
o A given AGK MUST NOT be shared by multiple verifiers.
o AGKs have a name associated with them. If an AGK is derived from
a PSK, the AGK name is derived as follows:
AGK-name = trunc-64(SHA-256(VerifierID, NodeID, ServerID, "AGK-
name")),
where trunc-64 indicates that the output of SHA-256 is
truncated to 64 bits.
4. SBA Generation and Verification
4.1. Parameters for SBA Generation
SBAs rely on a symmetric key shared between the address generator and
the verifier (or the verifier's agent, such as a AAA server) either
via pre-configuration or a bootstrapping protocol. To identify the
shared key, an identity of the shared key (e.g., key name) or that of
the address generator (e.g., NAI) is included as one of the
parameters. This is required for the verifier to lookup the AGK, or
if that is not available, to lookup the PSK and generate the AGK from
there following the procedure in Section 3.1. The simplest technique
to identify the key is to use the generator's ID; given that and the
context of the key lookup, the search semantics are unambiguous.
Alternatively, the generator may use the AGK's key name as the
identity. In that case, the AGK is known to be a key designated for
the purpose of address generation and known to be readily available
(for instance, the key and the key name might be pre-computed and
cached for easy lookup) at the verifier or its agent.
Note that the key identity is required to be included in the SBA data
structure so that the verifier can lookup the AGK. It is included in
Venkitaraman, et al. Expires December 24, 2006 [Page 6]
Internet-Draft SBA June 2006
the SBA generation to increase the work of a brute-force attacker.
Another technique to expand the work involved in a brute-force attack
is to include the IPv6 prefix in the data structure and the SBA
generation. The prefix is included to prevent the use of the same
interface identifier across multiple prefixes. The prefix MAY be set
to zero when the node wishes to re-use the same suffix across
multiple prefixes. A verifier MAY require the use of the actual
prefix for which the suffix is being generated.
Finally, a 16-octet random nonce is added to SBA generation. The
nonce serves a couple of different purposes: First, whereas the
earlier parameters are static during a single derivation process, the
nonce can be modified as necessary by the generator. After SBA
generation, the generator runs the duplicate address detection (DAD)
[RFC2462] procedure and if the generated address is already being
used, it needs to derive a new address. The generator picks a new
random nonce and derives a new SBA and repeats DAD. This is the
primary purpose of the nonce. In case of address collisions, the
number of SBAs generated using varying nonces MAY be restricted to a
certain number based on local policy.
Next, changing the nonce allows generation of different addresses for
privacy purposes. Note that the generator's ID, prefix and the AGK
might be static or semi-static (the IPv6 node may move and use a
different prefix or the AGK might be periodically changed, especially
if it is not directly derived from a PSK along the lines of the
derivation in Section 3.2), but the nonce can be changed by the
generator at will.
With that background, we specify the SBA data structure;
Venkitaraman, et al. Expires December 24, 2006 [Page 7]
Internet-Draft SBA June 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CR-ID |ID Type| Length | |
+++++++++++++++++++++++++++++++++ Node/Key identity (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subnet Prefix (8 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ nonce (16 octets) +
| |
+ +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Data structure of parameters used in SBA Generation and
Verification
CR-ID: This is a 4-bit field indicating the cryptographic suite ID.
The value 0000 indicates HMAC-SHA-256, the default transform.
ID Type: ID Type is a 4-bit indicating the type of the identity. The
following values are currently defined:
0000 Node ID
0001 AGK derived from a PSK
0010 AGK derived through other means
Length: The Length field indicates the size of the Node/Key Identity
field in octets. When Node ID is 0001, the Length is in fact
fixed, as specified in Section 3.2, and is 8 octets.
Node/Key Identity This field, whose type and length are indicated by
the preceding two fields, namely ID Type and Length, is used to
indicate the identity of the generator (node ID), or the identity
of the key used by the generator (key ID).
Subnet Prefix: This field contains the 8-octet subnet prefix. It may
be all 0s if the verifier's policy allows it and the generator
wants to generate and use an address across multiple prefixes.
4.2. SBA Generation
The IPv6 suffix of the address of the node is derived as follows:
Address Suffix = trunc-64(PRF(AGK, node or key identity || subnet
prefix || nonce)), where || denotes concatenation.
Venkitaraman, et al. Expires December 24, 2006 [Page 8]
Internet-Draft SBA June 2006
The default PRF is HMAC-SHA-256.
The SBA generation procedure is as follows:
1. The generator identifies the AGK and it's identity. The identity
forms the first component of the SBA data structure.
2. Then the generator selects the IPv6 suffix it wants to use.
Generally this is advertised by a router.
3. Finally, the generator selects a random nonce and completes the
formation of the SBA data structure.
4. The generator then uses the AGK to compute the PRF over the node/
key identity, subnet prefix and the nonce.
5. The output of the PRF is truncted to 64 bits and then AND'ed with
0xfcffffffffffffff to set bits 6 and 7 (i.e., the "u" and "g"
bits) [RFC3513] to zero. The result is the interface identifier.
6. The generator runs the IPv6 duplicate address detection process.
If there is an address collision, the procedure above, starting
at step 3, is repeated.
7. The generated suffix is then concatenated with the advertised
prefix to form a complete IPv6 address for the node.
4.3. SBA Verification
The SBA verification procedure is as follows:
1. The verifier compares IPv6 prefix of the claimed address with the
IPv6 prefix in the SBA data structure.
2. Next, the verifier uses the ID type field to determine the type
of the identity specified by the Generator. The ID length field
is then used to extract the Node/Key Identity value.
1. If the ID type is NAI, the verifier may have to route (based
on the NAI) the request for address verification to a third
party.
2. If the ID type is a key ID, it is plausible that the verifier
has the key cached locally. The verifier looks up the key ID
in its key cache/store.
3. If the ID is not found, the verifier sends the request to its
agent.
3. The verifier's agent, typically a AAA server, uses the following
steps:
1. If the ID type is NAI, the AAA server looks up the PSK and
derives an AGK to compute the SBA, using the SBA generation
parameters.
2. If the ID type is key ID, the server looks up the key and
computes the SBA.
4. The verifier or its agent then uses the AGK to compute the PRF,
following the procedure specified in Section 4.2. The Crypto ID
field indicates the PRF to be used in the computation.
Venkitaraman, et al. Expires December 24, 2006 [Page 9]
Internet-Draft SBA June 2006
5. The output of the PRF is truncted to 64 bits and then AND'ed with
0xfcffffffffffffff to set bits 6 and 7 (i.e., the "u" and "g"
bits) [RFC3513] to zero.
6. The locally computed suffix is compared with the claimed suffix.
If any of the comparisons fail, the verifier stops immediately and
logs an error.
5. Security Considerations
The goal of SBA generation is to prevent arbitrary claims to IPv6
addresses. To that end, the only means of address generation are
algorithms that can be independently executed by the verifier of
claims to addresses using keys that are known to the generator, and
possible the verifier. CGAs generation uses asymmetric key
cryptography for this purpose and SBAs use symmetric key
cryptography.
5.1. On the input parameters to SBA generation
The simplest technique to generate the SBA might be to generate a PRF
over a constant string, say, "SBA Generation", using a key shared
between the generator and the verifier or its agent. Given that the
key is secret, a third party should not be able to claim an address
generated using that method. However, this procedure allows the
adversary to build a database of PRFs over the constant string and
use that to determine the AGK being used for key derivation. We
propose to include some additional parameters in the SBA generation
function to avoid such brute force attacks.
o First, the node or key ID is added to the derivation process.
Addition of this parameter forces the brute-force attacker to
build the database on a per NAI or a per key ID (which is a random
number of length, typically around 64 bits) basis.
o Second, the prefix is added to the derivation process. This also
increases the burden on the attacker. Furthermore, inclusion of
the prefix allows the verifier to enforce a policy on the
generator to change its interface id when the generator moves into
the verifier's subnet. Note that the prefix MAY be all 0s
depending on the verifier's policy. Thus, in those cases, the
node or key ID mitigates the effectiveness of brute-force attacks.
o Finally, a random nonce is used in the derivation process. The
primary property of the nonce is that it is a dynamic parameter:
if the SBA is a duplicate address, the generator is to change the
nonce to derive another address. The nonce also allows the
generator to change its address for privacy purposes.
Note that the Cryptographic Suite ID, ID Type and Length are not used
Venkitaraman, et al. Expires December 24, 2006 [Page 10]
Internet-Draft SBA June 2006
in the derivation. There is no real advantage to adding those fields
to the derivation and if those fields are tampered with the key
look-up will fail or an incorrect key and/or algorithm will be used
in the derivation causing the verification to fail. In other words
any modifications to those fields are detectable even without adding
them as inputs to the PRF.
5.2. Strength of the SBA derivation
SBA generation uses 62 bits from the output of a PRF. Thus the
effective strength of the derivation is 2^62 computations. Given
similar strength, CGAs use a modifier to increase the computational
requirements on brute-force attacks. Such modifiers are not required
to increase the strength of SBAs.
Suppose an attacker succeeds in finding a random key that results in
the same SBAs as the victim. Note that the attacker cannot really
use the key to assert ownership on any generated addresses. To get
the verifier to accept the SBA, the generator would have to have
established its random key as the AGK with the verifier or its agent.
Since the AGK is generated from the PSK or other keying material
using a PRF, this is not possible.
Note that the attacker could send an SBA that it generates with the
victim's NAI. Under the assumptions of this attack (the attacker
having found a collision in SBA generation in 2^62 computations), the
attacker would be able to change the address of the victim. We feel
that is sufficient strength at the moment. Note that such an attack
could be mitigated by protecting the messages that contain SBAs
(e.g., neighbor discovery) with a MAC of sufficient strength.
6. IANA Considerations
IANA registration requirements will be specified in a future version
of this document.
7. Acknowledgments
We thank Greg Rose for his help with the security analysis of shared-
key based address generation.
8. References
Venkitaraman, et al. Expires December 24, 2006 [Page 11]
Internet-Draft SBA June 2006
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
8.2. Informative References
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004.
Venkitaraman, et al. Expires December 24, 2006 [Page 12]
Internet-Draft SBA June 2006
Authors' Addresses
Narayanan Venkitaraman
Motorola
1301 E. Algonquin Road
Schaumburg, IL 60196
US
Email: narayanan.venkitaraman@motorola.com
Vidya Narayanan
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA 92121
US
Email: vidyan@qualcomm.com
Lakshminath Dondeti
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com
Venkitaraman, et al. Expires December 24, 2006 [Page 13]
Internet-Draft SBA June 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Venkitaraman, et al. Expires December 24, 2006 [Page 14]
