! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #2 ! KEY_OAKLEY | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ alternate SA attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The responder replies in kind but selects, and returns, one transform
proposal (the ISAKMP SA attributes).
The second exchange consists of the following payloads:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_KE ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_NONCE ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ D-H Public Value (g^xi from initiator g^xr from responder) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Ni (from initiator) or Nr (from responder) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The shared keys, SKEYID_e and SKEYID_a, are now used to protect and
authenticate all further communication. Note that both SKEYID_e and
SKEYID_a are unauthenticated.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_ID and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_SIG ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification Data of the ISAKMP negotiator ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ signature verified by the public key of the ID above ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The key exchange is authenticated over a signed hash as described in
section 5.1. Once the signature has been verified using the
authentication algorithm negotiated as part of the ISAKMP SA, the
shared keys, SKEYID_e and SKEYID_a can be marked as authenticated.
(For brevity, certificate payloads were not exchanged).
7.2 Phase 2 using Quick Mode
The following payloads are exchanged in the first round of Quick Mode
with ISAKMP SA negotiation. In this hypothetical exchange, the ISAKMP
negotiators are proxies for other parties which have requested
authentication.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Quick Mode, ~
~ Next Payload of ISA_HASH and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_SA ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ keyed hash of message ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_NONCE ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain Of Interpretation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (4 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_TRANS ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #1 ! AH_SHA | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! other SA attributes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #2 ! AH_MD5 | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! other SA attributes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_ID ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ nonce ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_ID ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ID of source for which ISAKMP is a client ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ID of destination for which ISAKMP is a client ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the contents of the hash are described in 5.5 above. The
responder replies with a similar message which only contains one
transform-- the selected AH transform. Upon receipt, the initiator
can provide the key engine with the negotiated security association
and the keying material. As a check against replay attacks, the
responder waits until receipt of the next message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Quick Mode, ~
~ Next Payload of ISA_HASH and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ hash data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the contents of the hash are described in 5.5 above.
8. Perfect Forward Secrecy Example
This protocol can provide PFS of both keys and identities. The
identies of both the ISAKMP negotiating peer and, if applicable, the
identities for whom the peers are negotiating can be protected with
PFS.
To provide Perfect Forward Secrecy of both keys and all identities,
two parties would perform the following:
o A Main Mode Exchange to protect the identities of the ISAKMP
peers.
This establishes an ISAKMP SA.
o A Quick Mode Exchange to negotiate other security protocol
protection.
This establishes a SA on each end for this protocol.
o Delete the ISAKMP SA and its associated state.
Since the key for use in the non-ISAKMP SA was derived from the
single ephemeral Diffie-Hellman exchange PFS is preserved.
To provide Perfect Forward Secrecy of merely the keys of a non-ISAKMP
security association, it in not necessary to do a phase 1 exchange if
an ISAKMP SA exists between the two peers. A single Quick Mode in
which the optional KE payload is passed, and an additional Diffie-
Hellman exchange is performed, is all that is required. At this point
the state derived from this Quick Mode must be deleted from the
ISAKMP SA as described in section 5.5.
9. Implementation Hints
Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2
negotiations extremely quick. As long as the Phase 1 state remains
cached, and PFS is not needed, Phase 2 can proceed without any
exponentiation. How many Phase 2 negotiations can be performed for a
single Phase 1 is a local policy issue. The decision will depend on
the strength of the algorithms being used and level of trust in the
peer system.
An implementation may wish to negotiate a range of SAs when
performing Quick Mode. By doing this they can speed up the "re-
keying". Quick Mode defines how KEYMAT is defined for a range of SAs.
When one peer feels it is time to change SAs they simply use the next
one within the stated range. A range of SAs can be established by
negotiating multiple SAs (identical attributes, different SPIs) with
one Quick Mode.
An optimization that is often useful is to establish Security
Associations with peers before they are needed so that when they
become needed they are already in place. This ensures there would be
no delays due to key management before initial data transmission.
This optimization is easily implemented by setting up more than one
Security Association with a peer for each requested Security
Association and caching those not immediately used.
Also, if an ISAKMP implementation is alerted that a SA will soon be
needed (e.g. to replace an existing SA that will expire in the near
future), then it can establish the new SA before that new SA is
needed.
The base ISAKMP specification describes conditions in which one party
of the protocol may inform the other party of some activity-- either
deletion of a security association or in response to some error in
the protocol such as a signature verification failed or a payload
failed to decrypt. It is strongly suggested that these Informational
exchanges not be responded to under any circumstances. Such a
condition may result in a "notify war" in which failure to understand
a message results in a notify to the peer who cannot understand it
and sends his own notify back which is also not understood.
10. Security Considerations
This entire memo discusses a hybrid protocol, combining parts of
Oakley and parts of SKEME with ISAKMP, to negotiate, and derive
keying material for, security associations in a secure and
authenticated manner.
Confidentiality is assured by the use of a negotiated encryption
algorithm. Authentication is assured by the use of a negotiated
method: a digital signature algorithm; a public key algorithm which
supports encryption; or, a pre-shared key. The confidentiality and
authentication of this exchange is only as good as the attributes
negotiated as part of the ISAKMP security association.
Repeated re-keying using Quick Mode can consume the entropy of the
Diffie-Hellman shared secret. Implementors should take note of this
fact and set a limit on Quick Mode Exchanges between exponentiations.
This memo does not prescribe such a limit.
Perfect Forward Secrecy (PFS) of both keying material and identities
is possible with this protocol. By specifying a Diffie-Hellman group,
and passing public values in KE payloads, ISAKMP peers can establish
PFS of keys-- the identities would be protected by SKEYID_e from the
ISAKMP SA and would therefore not be protected by PFS. If PFS of both
keying material and identities is desired, an ISAKMP peer MUST
establish only one non-ISAKMP security association (e.g. IPsec
Security Association) per ISAKMP SA. PFS for keys and identities is
accomplished by deleting the ISAKMP SA (and optionally issuing a
DELETE message) upon establishment of the single non-ISAKMP SA. In
this way a phase one negotiation is uniquely tied to a single phase
two negotiation, and the ISAKMP SA established during phase one
negotiation is never used again.
The strength of a key derived from a Diffie-Hellman exchange using
any of the groups defined here depends on the inherent strength of
the group, the size of the exponent used, and the entropy provided by
the random number generator used. Due to these inputs it is difficult
to determine the strength of a key for any of the defined groups. The
default Diffie-Hellman group (number one) when used with a strong
random number generator and an exponent no less than 160 bits is
sufficient to use for DES. Groups two through four provide greater
security. Implementations should make note of these conservative
estimates when establishing policy and negotiating security
parameters.
Note that these limitations are on the Diffie-Hellman groups
themselves. There is nothing in IKE which prohibits using stronger
groups nor is there anything which will dilute the strength obtained
from stronger groups. In fact, the extensible framework of IKE
encourages the definition of more groups; use of elliptical curve
groups will greatly increase strength using much smaller numbers.
For situations where defined groups provide insufficient strength New
Group Mode can be used to exchange a Diffie-Hellman group which
provides the necessary strength. In is incumbent upon implementations
to check the primality in groups being offered and independently
arrive at strength estimates.
It is assumed that the Diffie-Hellman exponents in this exchange are
erased from memory after use. In particular, these exponents must not
be derived from long-lived secrets like the seed to a pseudo-random
generator.
IKE exchanges maintain running initialization vectors (IV) where the
last ciphertext block of the last message is the IV for the next
message. To prevent retransmissions (or forged messages with valid
cookies) from causing exchanges to get out of sync IKE
implementations SHOULD NOT update their running IV until the
decrypted message has passed a basic sanity check and has been
determined to actually advance the IKE state machine-- i.e. it is not
a retransmission.
While the last roundtrip of Main Mode (and optionally the last
message of Aggressive Mode) is encrypted it is not, strictly
speaking, authenticated. An active substitution attack on the
ciphertext could result in payload corruption. If such an attack
corrupts mandatory payloads it would be detected by an authentication
failure, but if it corrupts any optional payloads (e.g. notify
payloads chained onto the last message of a Main Mode exchange) it
might not be detectable.
11. IANA Considerations
This document contains many "magic numbers" to be maintained by the
IANA. This section explains the criteria to be used by the IANA to
assign additional numbers in each of these lists.
11.1 Attribute Classes
Attributes negotiated in this protocol are identified by their class.
Requests for assignment of new classes must be accompanied by a
standards-track RFCwhich describes the use of this attribute.
11.2 Encryption Algorithm Class
Values of the Encryption Algorithm Class define an encryption
algorithm to use when called for in this document. Requests for
assignment of new encryption algorithm values must be accompanied by
a reference to a standards-track or Informational RFCor a reference
to published cryptographic literature which describes this algorithm.
11.3 Hash Algorithm
Values of the Hash Algorithm Class define a hash algorithm to use
when called for in this document. Requests for assignment of new hash
algorithm values must be accompanied by a reference to a standards-
track or Informational RFCor a reference to published cryptographic
literature which describes this algorithm. Due to the key derivation
and key expansion uses of HMAC forms of hash algorithms in IKE,
requests for assignment of new hash algorithm values must take into
account the cryptographic properties-- e.g it's resistance to
collision-- of the hash algorithm itself.
11.4 Group Description and Group Type
Values of the Group Description Class identify a group to use in a
Diffie-Hellman exchange. Values of the Group Type Class define the
type of group. Requests for assignment of new groups must be
accompanied by a reference to a standards-track or Informational RFC
which describes this group. Requests for assignment of new group
types must be accompanied by a reference to a standards-track or
Informational RFCor by a reference to published cryptographic or
mathmatical literature which describes the new type.
11.5 Life Type
Values of the Life Type Class define a type of lifetime to which the
ISAKMP Security Association applies. Requests for assignment of new
life types must be accompanied by a detailed description of the units
of this type and its expiry.
12. Acknowledgements
This document is the result of close consultation with Hugo Krawczyk,
Douglas Maughan, Hilarie Orman, Mark Schertler, Mark Schneider, and
Jeff Turner. It relies on protocols which were written by them.
Without their interest and dedication, this would not have been
written.
Special thanks Rob Adams, Cheryl Madson, Derrell Piper, Harry Varnis,
and Elfed Weaver for technical input, encouragement, and various
sanity checks along the way.
We would also like to thank the many members of the IPSec working
group that contributed to the development of this protocol over the
past year.
13. References
[CAST] Adams, C., "The CAST-128 Encryption Algorithm", RFC2144,
May 1997.
[BLOW] Schneier, B., "The Blowfish Encryption Algorithm", Dr.
Dobb's Journal, v. 19, n. 4, April 1994.
[Bra97] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[DES] ANSI X3.106, "American National Standard for Information
Systems-Data Link Encryption", American National Standards
Institute, 1983.
[DH] Diffie, W., and Hellman M., "New Directions in
Cryptography", IEEE Transactions on Information Theory, V.
IT-22, n. 6, June 1977.
[DSS] NIST, "Digital Signature Standard", FIPS 186, National
Institute of Standards and Technology, U.S. Department of
Commerce, May, 1994.
[IDEA] Lai, X., "On the Design and Security of Block Ciphers," ETH
Series in Information Processing, v. 1, Konstanz: Hartung-
Gorre Verlag, 1992
[KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC2104, February
1997.
[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", from IEEE Proceedings of the 1996
Symposium on Network and Distributed Systems Security.
[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC1321,
April 1992.
[MSST98] Maughhan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC2408, November 1998.
[Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC
2412, November 1998.
[PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard",
November 1993.
[Pip98] Piper, D., "The Internet IP Security Domain Of
Interpretation for ISAKMP", RFC2407, November 1998.
[RC5] Rivest, R., "The RC5 Encryption Algorithm", Dr. Dobb's
Journal, v. 20, n. 1, January 1995.
[RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for
Obtaining Digital Signatures and Public-Key Cryptosystems",
Communications of the ACM, v. 21, n. 2, February 1978.
[Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms,
and Source Code in C", 2nd edition.
[SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institue
of Standards and Technology, U.S. Department of Commerce,
May 1994.
[TIGER] Anderson, R., and Biham, E., "Fast Software Encryption",
Springer LNCS v. 1039, 1996.
Appendix A
This is a list of DES Weak and Semi-Weak keys. The keys come from
[Sch96]. All keys are listed in hexidecimal.
DES Weak Keys
0101 0101 0101 0101
1F1F 1F1F E0E0 E0E0
E0E0 E0E0 1F1F 1F1F
FEFE FEFE FEFE FEFE
DES Semi-Weak Keys
01FE 01FE 01FE 01FE
1FE0 1FE0 0EF1 0EF1
01E0 01E0 01F1 01F1
1FFE 1FFE 0EFE 0EFE
011F 011F 010E 010E
E0FE E0FE F1FE F1FE
FE01 FE01 FE01 FE01
E01F E01F F10E F10E
E001 E001 F101 F101
FE1F FE1F FE0E FE0E
1F01 1F01 0E01 0E01
FEE0 FEE0 FEF1 FEF1
Attribute Assigned Numbers
Attributes negotiated during phase one use the following definitions.
Phase two attributes are defined in the applicable DOI specification
(for example, IPsec attributes are defined in the IPsec DOI), with
the exception of a group description when Quick Mode includes an
ephemeral Diffie-Hellman exchange. Attribute types can be either
Basic (B) or Variable-length (V). Encoding of these attributes is
defined in the base ISAKMP specification as Type/Value (Basic) and
Type/Length/Value (Variable).
Attributes described as basic MUST NOT be encoded as variable.
Variable length attributes MAY be encoded as basic attributes if
their value can fit into two octets. If this is the case, an
attribute offered as variable (or basic) by the initiator of this
protocol MAY be returned to the initiator as a basic (or variable).
Attribute Classes
class value type
-------------------------------------------------------------------
Encryption Algorithm 1 B
Hash Algorithm 2 B
Authentication Method 3 B
Group Description 4 B
Group Type 5 B
Group Prime/Irreducible Polynomial 6 V
Group Generator One 7 V
Group Generator Two 8 V
Group Curve A 9 V
Group Curve B 10 V
Life Type 11 B
Life Duration 12 V
PRF 13 B
Key Length 14 B
Field Size 15 B
Group Order 16 V
values 17-16383 are reserved to IANA. Values 16384-32767 are for
private use among mutually consenting parties.
Class Values
- Encryption Algorithm Defined In
DES-CBC 1 RFC2405
IDEA-CBC 2
Blowfish-CBC 3
RC5-R16-B64-CBC 4
3DES-CBC 5
CAST-CBC 6
values 7-65000 are reserved to IANA. Values 65001-65535 are for
private use among mutually consenting parties.
- Hash Algorithm Defined In
MD5 1 RFC1321
SHA 2 FIPS 180-1
Tiger 3 See Reference [TIGER]
values 4-65000 are reserved to IANA. Values 65001-65535 are for
private use among mutually consenting parties.
- Authentication Method
pre-shared key 1
DSS signatures 2
RSA signatures 3
Encryption with RSA 4
Revised encryption with RSA 5
values 6-65000 are reserved to IANA. Values 65001-65535 are for
private use among mutually consenting parties.
- Group Description
default 768-bit MODP group (section 6.1) 1
alternate 1024-bit MODP group (section 6.2) 2
EC2N group on GP[2^155] (section 6.3) 3
EC2N group on GP[2^185] (section 6.4) 4
values 5-32767 are reserved to IANA. Values 32768-65535 are for
private use among mutually consenting parties.
- Group Type
MODP (modular exponentiation group) 1
ECP (elliptic curve group over GF[P]) 2
EC2N (elliptic curve group over GF[2^N]) 3
values 4-65000 are reserved to IANA. Values 65001-65535 are for
private use among mutually consenting parties.
- Life Type
seconds 1
kilobytes 2
values 3-65000 are reserved to IANA. Values 65001-65535 are for
private use among mutually consenting parties. For a given "Life
Type" the value of the "Life Duration" attribute defines the actual
length of the SA life-- either a number of seconds, or a number of
kbytes protected.
- PRF
There are currently no pseudo-random functions defined.
values 1-65000 are reserved to IANA. Values 65001-65535 are for
private use among mutually consenting parties.
- Key Length
When using an Encryption Algorithm that has a variable length key,
this attribute specifies the key length in bits. (MUST use network
byte order). This attribute MUST NOT be used when the specified
Encryption Algorithm uses a fixed length key.
- Field Size
The field size, in bits, of a Diffie-Hellman group.
- Group Order
The group order of an elliptical curve group. Note the length of
this attribute depends on the field size.
Additional Exchanges Defined-- XCHG values
Quick Mode 32
New Group Mode 33
Appendix B
This appendix describes encryption details to be used ONLY when
encrypting ISAKMP messages. When a service (such as an IPSEC
transform) utilizes ISAKMP to generate keying material, all
encryption algorithm specific details (such as key and IV generation,
padding, etc...) MUST be defined by that service. ISAKMP does not
purport to ever produce keys that are suitable for any encryption
algorithm. ISAKMP produces the requested amount of keying material
from which the service MUST generate a suitable key. Details, such
as weak key checks, are the responsibility of the service.
Use of negotiated PRFs may require the PRF output to be expanded due
to the PRF feedback mechanism employed by this document. For example,
if the (ficticious) DOORAK-MAC requires 24 bytes of key but produces
only 8 bytes of output, the output must be expanded three times
before being used as the key for another instance of itself. The
output of a PRF is expanded by feeding back the results of the PRF
into itself to generate successive blocks. These blocks are
concatenated until the requisite number of bytes has been acheived.
For example, for pre-shared key authentication with DOORAK-MAC as the
negotiated PRF:
BLOCK1-8 = prf(pre-shared-key, Ni_b | Nr_b)
BLOCK9-16 = prf(pre-shared-key, BLOCK1-8 | Ni_b | Nr_b)
BLOCK17-24 = prf(pre-shared-key, BLOCK9-16 | Ni_b | Nr_b)
and
SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24
so therefore to derive SKEYID_d:
BLOCK1-8 = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
BLOCK9-16 = prf(SKEYID, BLOCK1-8 | g^xy | CKY-I | CKY-R | 0)
BLOCK17-24 = prf(SKEYID, BLOCK9-16 | g^xy | CKY-I | CKY-R | 0)
and
SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24
Subsequent PRF derivations are done similarly.
Encryption keys used to protect the ISAKMP SA are derived from
SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long
enough to supply all the necessary keying material an algorithm
requires, the key is derived from feeding the results of a pseudo-
random function into itself, concatenating the results, and taking
the highest necessary bits.
For example, if (ficticious) algorithm AKULA requires 320-bits of key
(and has no weak key check) and the prf used to generate SKEYID_e
only generates 120 bits of material, the key for AKULA, would be the
first 320-bits of Ka, where:
Ka = K1 | K2 | K3
and
K1 = prf(SKEYID_e, 0)
K2 = prf(SKEYID_e, K1)
K3 = prf(SKEYID_e, K2)
where prf is the negotiated prf or the HMAC version of the negotiated
hash function (if no prf was negotiated) and 0 is represented by a
single octet. Each result of the prf provides 120 bits of material
for a total of 360 bits. AKULA would use the first 320 bits of that
360 bit string.
In phase 1, material for the initialization vector (IV material) for
CBC mode encryption algorithms is derived from a hash of a
concatenation of the initiator's public Diffie-Hellman value and the
responder's public Diffie-Hellman value using the negotiated hash
algorithm. This is used for the first message only. Each message
should be padded up to the nearest block size using bytes containing
0x00. The message length in the header MUST include the length of the
pad since this reflects the size of the ciphertext. Subsequent
messages MUST use the last CBC encryption block from the previous
message as their initialization vector.
In phase 2, material for the initialization vector for CBC mode
encryption of the first message of a Quick Mode exchange is derived
from a hash of a concatenation of the last phase 1 CBC output block
and the phase 2 message id using the negotiated hash algorithm. The
IV for subsequent messages within a Quick Mode exchange is the CBC
output block from the previous message. Padding and IVs for
subsequent messages are done as in phase 1.
After the ISAKMP SA has been authenticated all Informational
Exchanges are encrypted using SKEYID_e. The initiaization vector for
these exchanges is derived in exactly the same fashion as that for a
Quick Mode-- i.e. it is derived from a hash of a concatenation of the
last phase 1 CBC output block and the message id from the ISAKMP
header of the Informational Exchange (not the message id from the
message that may have prompted the Informational Exchange).
Note that the final phase 1 CBC output block, the result of
encryption/decryption of the last phase 1 message, must be retained
in the ISAKMP SA state to allow for generation of unique IVs for each
Quick Mode. Each post- phase 1 exchange (Quick Modes and
Informational Exchanges) generates IVs independantly to prevent IVs
from getting out of sync when two different exchanges are started
simultaneously.
In all cases, there is a single bidirectional cipher/IV context.
Having each Quick Mode and Informational Exchange maintain a unique
context prevents IVs from getting out of sync.
The key for DES-CBC is derived from the first eight (8) non-weak and
non-semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first
8 bytes of the IV material derived above.
The key for IDEA-CBC is derived from the first sixteen (16) bytes of
SKEYID_e. The IV is the first eight (8) bytes of the IV material
derived above.
The key for Blowfish-CBC is either the negotiated key size, or the
first fifty-six (56) bytes of a key (if no key size is negotiated)
derived in the aforementioned pseudo-random function feedback method.
The IV is the first eight (8) bytes of the IV material derived above.
The key for RC5-R16-B64-CBC is the negotiated key size, or the first
sixteen (16) bytes of a key (if no key size is negotiated) derived
from the aforementioned pseudo-random function feedback method if
necessary. The IV is the first eight (8) bytes of the IV material
derived above. The number of rounds MUST be 16 and the block size
MUST be 64.
The key for 3DES-CBC is the first twenty-four (24) bytes of a key
derived in the aforementioned pseudo-random function feedback method.
3DES-CBC is an encrypt-decrypt-encrypt operation using the first,
middle, and last eight (8) bytes of the entire 3DES-CBC key. The IV
is the first eight (8) bytes of the IV material derived above.
The key for CAST-CBC is either the negotiated key size, or the first
sixteen (16) bytes of a key derived in the aforementioned pseudo-
random function feedback method. The IV is the first eight (8) bytes
of the IV material derived above.
Support for algorithms other than DES-CBC is purely optional. Some
optional algorithms may be subject to intellectual property claims.
Authors' Addresses
Dan Harkins
cisco Systems
170 W. Tasman Dr.
San Jose, California, 95134-1706
United States of America
Phone: +1 408 526 4000
EMail: dharkins@cisco.com
Dave Carrel
76 Lippard Ave.
San Francisco, CA 94131-2947
United States of America
Phone: +1 415 337 8469
EMail: carrel@ipsec.org
Authors' Note
The authors encourage independent implementation, and
interoperability testing, of this hybrid protocol.
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.