| < draft-ietf-ipsec-oakley-00.txt | draft-ietf-ipsec-oakley-01.txt > | |||
|---|---|---|---|---|
| IPSEC Working Group H. K. Orman | IPSEC Working Group H. K. Orman | |||
| INTERNET-DRAFT Dept. of Computer Science, Univ. of Arizona | INTERNET-DRAFT Dept. of Computer Science, Univ. of Arizona | |||
| draft-ietf-ipsec-oakley-00.txt February 1996 | draft-ietf-ipsec-oakley-01.txt May 1996 | |||
| The Oakley Key Determination Protocol | The OAKLEY Key Determination Protocol | |||
| <draft-ietf-ipsec-oakley-00.txt> | <draft-ietf-ipsec-oakley-01.txt> | |||
| This document describes a protocol, named OAKLEY, | This document describes a protocol, named OAKLEY, | |||
| by which two authenticated parties can agree on secure and secret | by which two authenticated parties can agree on secure and secret | |||
| keying material. The basic mechanism is the Diffie-Hellman key | keying material. The basic mechanism is the Diffie-Hellman key | |||
| exchange algorithm. | exchange algorithm. | |||
| This protocol supports Perfect Forward Secrecy, compatibility with | The OAKLEY protocol supports Perfect Forward Secrecy, | |||
| the ISAKMP protocol for managing security associations, user- | compatibility with the ISAKMP protocol for managing security | |||
| defined abstract group structures for use with the Diffie-Hellman | associations, user-defined abstract group structures for use with | |||
| algorithm, key updates, and incorporation of keys distributed via | the Diffie-Hellman algorithm, key updates, and incorporation of | |||
| out-of-band mechanisms. | keys distributed via out-of-band mechanisms. | |||
| Status of this Memo | Status of this Memo | |||
| This document is being distributed to members of the Internet community in | This document is being distributed to members of the Internet community in | |||
| order to solicit their comments on the protocol described in it. | order to solicit their comments on the protocol described in it. | |||
| This draft expires six months from the day of issue. The expiration | This draft expires six months from the day of issue. The expiration | |||
| date will be August 24, 1996. | date will be August 24, 1996. | |||
| Required text: | Required text: | |||
| skipping to change at page 2, line 23 ¶ | skipping to change at page 2, line 23 ¶ | |||
| The Diffie-Hellman key exchange algorithm provides such a mechanism. | The Diffie-Hellman key exchange algorithm provides such a mechanism. | |||
| It allows two parties to agree on a shared value without requiring | It allows two parties to agree on a shared value without requiring | |||
| encryption. The shared value is immediately available for use in | encryption. The shared value is immediately available for use in | |||
| encrypting subsequent conversation, e.g. data transmission and/or | encrypting subsequent conversation, e.g. data transmission and/or | |||
| authentication. The STS protocol [STS] provides a demonstration of | authentication. The STS protocol [STS] provides a demonstration of | |||
| how to embed the algorithm in a secure protocol, one that ensures | how to embed the algorithm in a secure protocol, one that ensures | |||
| that in addition to securely sharing a secret, the two parties can be | that in addition to securely sharing a secret, the two parties can be | |||
| sure of each other's identities, even when an active attacker exists. | sure of each other's identities, even when an active attacker exists. | |||
| Because this is a generic key exchange protocol, and because the keys | Because OAKLEY is a generic key exchange protocol, and because the | |||
| that it generates might be used for encrypting data with a long | keys that it generates might be used for encrypting data with a long | |||
| privacy lifetime, 20 years or more, it is important that the | privacy lifetime, 20 years or more, it is important that the | |||
| algorithms underlying the protocol be able to ensure the security of | algorithms underlying the protocol be able to ensure the security of | |||
| the keys for that period of time, based on the best prediction | the keys for that period of time, based on the best prediction | |||
| capabilities available for seeing into the mathematical future. The | capabilities available for seeing into the mathematical future. The | |||
| protocol therefore has two options for adding to the difficulties | protocol therefore has two options for adding to the difficulties | |||
| faced by an attacker who has a large amount of recorded key exchange | faced by an attacker who has a large amount of recorded key exchange | |||
| traffic at his disposal (a passive attacker). These options are | traffic at his disposal (a passive attacker). These options are | |||
| useful for deriving keys which will be used for encryption. | useful for deriving keys which will be used for encryption. | |||
| The OAKLEY protocol is related to STS, sharing the similarity of | The OAKLEY protocol is related to STS, sharing the similarity of | |||
| doing key exchange first and encrypted authentication next, but it | authenticating the Diffie-Hellman exponentials and using them for | |||
| extends the STS protocol in five ways. | determining a shared key, and also of achieving Perfect Forward | |||
| Secrecy for the shared key, but it differs from the STS protocol in | ||||
| several ways. | ||||
| The first is the addition of a weak authentication mechanism | The first is the addition of a weak address identification | |||
| ("cookies", described by Phil Karn [Photuris]) to help avoid | mechanism ("cookies", described by Phil Karn [Photuris]) to help | |||
| denial of service attacks. | avoid denial of service attacks. | |||
| The second extension is to allow the two parties to select | The second extension is to allow the two parties to select | |||
| mutually agreeable supporting algorithms for the protocol: the | mutually agreeable supporting algorithms for the protocol: the | |||
| encryption method, the key derivation method, and the | encryption method, the key derivation method, and the | |||
| authentication method. | authentication method. | |||
| Thirdly, the protocol provides Perfect Forward Secrecy (PFS) in | Thirdly, the authentication does not depend on encryption using | |||
| its standard mode of operation; with PFS, the security of the | the Diffie-Hellman exponentials; instead, the authentication | |||
| shared key against passive attacks is not dependent on other any | validates the binding of the exponentials to the identities of the | |||
| other secret. | parties. | |||
| The protocol does not require the two parties compute the shared | ||||
| exponentials prior to authentication. | ||||
| This protocol adds additional security to the derivation of keys | This protocol adds additional security to the derivation of keys | |||
| meant for use with encryption (as opposed to authentication) by | meant for use with encryption (as opposed to authentication) by | |||
| including a dependence on an additional algorithm. The derivation | including a dependence on an additional algorithm. The derivation | |||
| of keys for encryption is made to depend not only on the Diffie- | of keys for encryption is made to depend not only on the Diffie- | |||
| Hellman algorithm, but also on the cryptographic method used to | Hellman algorithm, but also on the cryptographic method used to | |||
| securely authenticate the communicating parties to each other. | securely authenticate the communicating parties to each other. | |||
| Finally, this protocol explicitly defines how the two parties can | Finally, this protocol explicitly defines how the two parties can | |||
| select the mathematical structures (group representation and | select the mathematical structures (group representation and | |||
| operation) for performing the Diffie-Hellman algorithm; they can | operation) for performing the Diffie-Hellman algorithm; they can | |||
| use standard groups or define their own. User-defined groups | use standard groups or define their own. User-defined groups | |||
| provide an additional degree of long-term security. | provide an additional degree of long-term security. | |||
| OAKLEY has several modes for distributing keys. In addition to the | OAKLEY has several options for distributing keys. In addition to the | |||
| classic Diffie-Hellman exchange, this protocol has a mode of use for | classic Diffie-Hellman exchange, this protocol can be used to derive | |||
| deriving a new key from a pre-existing key, and a mode for | a new key from an existing key and to distribute an externally | |||
| distributing an externally derived key by encrypting it. | derived key by encrypting it. | |||
| The protocol allows two parties to use all or some of the anti- | ||||
| clogging and perfect forward secrecy features. It also permits the | ||||
| use of authentication based on symmetric encryption or non-encryption | ||||
| algorithms. This flexibility is included in order to allow the | ||||
| parties to use the features that are best suited to their security | ||||
| and performance requirements. | ||||
| This document draws extensively in spirit and approach from the | This document draws extensively in spirit and approach from the | |||
| Photuris draft by Karn and Simpson [Photuris] (and from discussions | Photuris draft by Karn and Simpson [Photuris] (and from discussions | |||
| with the authors), specifics of the ISAKMP draft by Schertler et al. | with the authors), specifics of the ISAKMP draft by Schertler et al. | |||
| [ISAKMP], and it was also influenced by papers by Paul van Oorschot | [ISAKMP], and it was also influenced by papers by Paul van Oorschot | |||
| and Hugo Krawcyzk. | and Hugo Krawcyzk. | |||
| 2. The Protocol Outline | 2. The Protocol Outline | |||
| 2.1 General Remarks | 2.1 General Remarks | |||
| The OAKLEY protocol is used to establish a shared key with an | The OAKLEY protocol is used to establish a shared key with an | |||
| assigned identifier and associated authenticated identities for the | assigned identifier and associated authenticated identities for the | |||
| two parties. Subsequent stages of the protocol may derive other keys | two parties. The name of the key can be used later to derive | |||
| from a named key and assign an identifier to the new key. The name | security associations for the RFC1826 and RFC1827 protocols (AH and | |||
| of the key can be used later to derive security associations for the | ESP) or to achieve other network security goals. | |||
| RFC1826 and RFC1827 protocols (AH and ESP) or to achieve other | ||||
| network security goals. | ||||
| Each key is associated with algorithms that are used for | Each key is associated with algorithms that are used for | |||
| authentication, privacy, and one-way functions. These are anciliary | authentication, privacy, and one-way functions. These are ancillary | |||
| algorithms for OAKLEY; their appearance in subsequent security | algorithms for OAKLEY; their appearance in subsequent security | |||
| association definitions derived with other protocols is neither | association definitions derived with other protocols is neither | |||
| required nor prohibited. | required nor prohibited. | |||
| The anti-clogging tokens, or "cookies", provide a weak form of | The specification of the details of how to apply an algorithm to data | |||
| authentication for both parties; the cookie exchange can be completed | is called a transform. This document does not supply the transform | |||
| before they must perform the computationally expensive part of the | definitions; they will be in separate RFC's. | |||
| protocol (the exponentiations). | ||||
| The anti-clogging tokens, or "cookies", provide a weak form of source | ||||
| address identification for both parties; the cookie exchange can be | ||||
| completed before they perform the computationally expensive part of | ||||
| the protocol (large integer exponentiations). | ||||
| It is important to note that OAKLEY uses the cookies for two | It is important to note that OAKLEY uses the cookies for two | |||
| purposes: anti-clogging and key naming. The two parties to the | purposes: anti-clogging and key naming. The two parties to the | |||
| protocol each contribute one cookie at the initiation of key | protocol each contribute one cookie at the initiation of key | |||
| establishment; the pair of cookies becomes the key identifier | establishment; the pair of cookies becomes the key identifier | |||
| (KEYID), a reusable name for the keying material. Because of this | (KEYID), a reusable name for the keying material. Because of this | |||
| dual role, we will use the notation for the concatenation of the | dual role, we will use the notation for the concatenation of the | |||
| cookies ("COOKIE-I, COOKIE-R") interchangeably with the symbol | cookies ("COOKIE-I, COOKIE-R") interchangeably with the symbol | |||
| "KEYID". | "KEYID". | |||
| The only requirement for the protocol environment is that the | OAKLEY is designed to be a compatible component of the ISAKMP | |||
| protocol [ISAKMP], which runs over the UDP protocol using a well- | ||||
| known port (see the RFC on port assignments, STD02-RFC-1700). The | ||||
| only technical requirement for the protocol environment is that the | ||||
| underlying protocol stack must be able to supply the Internet address | underlying protocol stack must be able to supply the Internet address | |||
| of the remote party for each message. Thus, OAKLEY can be used | of the remote party for each message. Thus, OAKLEY could, in theory, | |||
| directly over the IP protocol as protocol id [TBD] or over the UDP | be used directly over the IP protocol or over UDP, if suitable | |||
| protocol. In the latter case, the only addressing requirement is | protocol or port number assignments were available. | |||
| that protocol exchanges be initiated by using the OAKLEY well-known | ||||
| port [TBD] in the destination address. | ||||
| The machine running OAKLEY must provide a good random number | The machine running OAKLEY must provide a good random number | |||
| generator, as described in RFCxxxx, as the source of random numbers | generator, as described in [RFC1750], as the source of random numbers | |||
| required in this protocol description. Any mention of a "nonce" | required in this protocol description. Any mention of a "nonce" | |||
| implies that the nonce value is generated by such a generator. | implies that the nonce value is generated by such a generator. The | |||
| same is true for "pseudorandom" values. | ||||
| 2.2 Notation | 2.2 Notation | |||
| The section describes the notation used in this document for message | The section describes the notation used in this document for message | |||
| sequences and content. | sequences and content. | |||
| 2.2.1 Message descriptions | 2.2.1 Message descriptions | |||
| The protocol exchanges below are written in an abbreviated notation | The protocol exchanges below are written in an abbreviated notation | |||
| that is intended to convey the essential elements of the exchange in | that is intended to convey the essential elements of the exchange in | |||
| skipping to change at page 4, line 42 ¶ | skipping to change at page 4, line 58 ¶ | |||
| The fields in the message are named and comma separated. The | The fields in the message are named and comma separated. The | |||
| protocol uses the convention that the first several fields constitute | protocol uses the convention that the first several fields constitute | |||
| a fixed header format for all messages. | a fixed header format for all messages. | |||
| For example, consider a HYPOTHETICAL exchange of messages involving a | For example, consider a HYPOTHETICAL exchange of messages involving a | |||
| fixed format message, the four fixed fields being two "cookies", the | fixed format message, the four fixed fields being two "cookies", the | |||
| third field being a message type name, the fourth field being a | third field being a message type name, the fourth field being a | |||
| multi-precision integer representing a power of a number: | multi-precision integer representing a power of a number: | |||
| Initiator Responder | Initiator Responder | |||
| -> Cookie-I, 0, IREQ, g^x -> | -> Cookie-I, 0, OK_KEYX, g^x -> | |||
| <- Cookie-R, Cookie-I, IRES, g^y <- | <- Cookie-R, Cookie-I, OK_KEYX, g^y <- | |||
| The notation describes a two message sequence. The initiator begins | The notation describes a two message sequence. The initiator begins | |||
| by sending a message with 4 fields to the responder; the first field | by sending a message with 4 fields to the responder; the first field | |||
| has the unspecified value "Cookie-I", second field has the numeric | has the unspecified value "Cookie-I", second field has the numeric | |||
| value 0, the third field indicates the message type is IREQ, the | value 0, the third field indicates the message type is OK_KEYX, the | |||
| fourth value is an abstract group element g to the x'th power. | fourth value is an abstract group element g to the x'th power. | |||
| The second line indicates that the responder replies with value | The second line indicates that the responder replies with value | |||
| "Cookie-R" in the first field, a copy of the "Cookie-I" value in the | "Cookie-R" in the first field, a copy of the "Cookie-I" value in the | |||
| second field, message type IRES, and the number g raised to the y'th | second field, message type OK_KEYX, and the number g raised to the | |||
| power. | y'th power. | |||
| The values IRES and IREQ are in capitals to indicate that they are | The value OK_KEYX is in capitals to indicate that it is a unique | |||
| unique constants (constants are defined the appendices). | constant (constants are defined the appendices). | |||
| 2.2.2 Guide to symbols | Variable precision integers with length zero are null values for the | |||
| protocol. | ||||
| Cookie-I and Cookie-R are 64-bit pseudo-random numbers. The | Sometimes the protocol will indicate that an entire payload (usually | |||
| generation method must ensure with high probability that the numbers | the Key Exchange Payload) has null values. The payload is still | |||
| are unique over some previous time period, such as one hour. | present in the message, for the purpose of simplifying parsing. | |||
| DOI is the Domain of Interpretation; see appendix I. The domains are | 2.2.2 Guide to symbols | |||
| statically assigned numbers that indicate classes of cryptographic | ||||
| service -- particularly the strength of the algorithm. | Cookie-I and Cookie-R (or CKY-I and CKY-R) are 64-bit pseudo-random | |||
| numbers. The generation method must ensure with high probability | ||||
| that the numbers used for each IP remote address are unique over some | ||||
| previous time period, such as one hour. | ||||
| KEYID is the concatenation of the initiator and responder cookies and | KEYID is the concatenation of the initiator and responder cookies and | |||
| the domain of interpretation; it is the name of keying material. | the domain of interpretation; it is the name of keying material. | |||
| sKEYID is used to denote the keying material named by the KEYID. It | sKEYID is used to denote the keying material named by the KEYID. It | |||
| is never transmitted, but it is used in various calculations | is never transmitted, but it is used in various calculations | |||
| performed by the two parties. | performed by the two parties. | |||
| IREQ, IREP, IKERQ, and IKERS are distinct message identifiers. | OK_KEYX and OK_NEWGRP are distinct message types. | |||
| Auth/Priv (or A/P) is the encoded choice for the intended use of the | IDP is a bit indicating whether or not material after the encryption | |||
| keying material; either authentication or privacy. | boundary (see appendix D), is encrypted. | |||
| g^x and g^y are encodings of group elements, where g is a special | g^x and g^y are encodings of group elements, where g is a special | |||
| group element indicated in the group description (see Appendix Group | group element indicated in the group description (see Appendix A) and | |||
| Descriptors) and g^x indicates that element raised to the x'th power. | g^x indicates that element raised to the x'th power. The type of the | |||
| The type of the encoding is either a variable precision integer or a | encoding is either a variable precision integer or a pair of such | |||
| pair of such integers, as indicated in the group operation in the | integers, as indicated in the group operation in the group | |||
| group description. Note that we will write g^xy as a short-hand for | description. Note that we will write g^xy as a short-hand for | |||
| g^(xy). See Appenix J for references that describe implementing | g^(xy). See Appendix J for references that describe implementing | |||
| large integer computations and the relationship between various group | large integer computations and the relationship between various group | |||
| definitions and basic arithmetic operations. | definitions and basic arithmetic operations. | |||
| EHAO is a list of encryption/hash/authentication choices. Each item | EHAO is a list of encryption/hash/authentication choices. Each item | |||
| is a pair values: a class name and an algorithm name. | is a pair of values: a class name and an algorithm name. | |||
| EHAS is a set of three items selected from the EHAO list, one from | EHAS is a set of three items selected from the EHAO list, one from | |||
| each of the classes for encryption, hash, authentication. | each of the classes for encryption, hash, authentication. | |||
| GRP is a name for the group and its relevant parameters: the size of | GRP is a name (32-bit value) for the group and its relevant | |||
| the integers, the arithmetic operation, and the generator element. | parameters: the size of the integers, the arithmetic operation, and | |||
| There are a few pre-defined GRP's (for 768 bit modular exponentiation | the generator element. There are a few pre-defined GRP's (for 768 | |||
| groups, 1024 bit modexp, 2048 bit modexp, 155-bit elliptic curve, see | bit modular exponentiation groups, 1024 bit modexp, 2048 bit modexp, | |||
| Appendix H), but participants can share other group descriptions in a | 155-bit elliptic curve, see Appendix H), but participants can share | |||
| later protocol stage (see the section NEW GROUP). | other group descriptions in a later protocol stage (see the section | |||
| NEW GROUP). It is important to separate notion of the GRP from the | ||||
| group descriptor (Appendix A); the former is a name for the latter. | ||||
| The symbol vertical bar "|" is used to denote concatenation of bit | The symbol vertical bar "|" is used to denote concatenation of bit | |||
| strings. | strings. Fields are concatenated using their encoded form as they | |||
| appear in their payload. | ||||
| 2.3 Main Mode | Ni and Nr are nonces selected by the initiator and responder, | |||
| respectively. | ||||
| The goal of Main Mode processing is to establish common state in the | ID(I) and ID(R) are the identities to be used in authenticating the | |||
| two parties. This state information is a key name, secret keying | initiator and responder respectively. | |||
| material, and three algorithms for use during authentication: | ||||
| encryption, hashing, and authentication. The encodings and meanings | E{x}Ki indicates the encryption of x using the public key of the | |||
| for these choices are presented in an Appendix. | initiator. Encryption is done using the algorithm associated with | |||
| the authentication method; usually this will be RSA. | ||||
| Main Mode processing is always followed by Authentication, as | S{x}Ki indicates the signature over x using the private key (signing | |||
| described in the Authentication Exchange section. However, see also | key) of the initiator. Signing is done using the algorithm | |||
| the section on use of Main Mode with private group definitions. | associated with the authentication method; usually this will be RSA | |||
| or DSS. | ||||
| Initiator Responder | prf(a, b) denotes the result of applying pseudo-random function "a" | |||
| -> Cookie-I, 0, DOI, IREQ, A/P, GRP, EHAO -> | to data "b". One may think of "a" as a key or as a value that | |||
| <- Cookie-R, Cookie-I, DOI, IKREQ, A/P, g^y, EHAS <- | characterizes the function prf; in the latter case it is the index | |||
| -> Cookie-I, Cookie-R, DOI, IKRES, g^x -> | into a family of functions. | |||
| The processing outline for each stage of the protocol is as follows: | prf(0, b) denotes the application of a one-way function to data "b". | |||
| The similarity with the previous notation is deliberate and indicates | ||||
| that a single algorithm, e.g. MD5, might will used for both purposes. | ||||
| In the first case a "keyed" MD5 transform would be used with key "a"; | ||||
| in the second case the transform would have the fixed key value zero, | ||||
| resulting in a one-way function. | ||||
| The term "transform" is used to refer to functions defined in | ||||
| auxiliary RFC's. The the transform RFC's will be drawn from those | ||||
| defined for IPSEC AH and ESP (see RFC1825 for the overall | ||||
| architecture encompassing these protocols). | ||||
| 2.3 The Key Exchange Message Overview | ||||
| The goal of key exchange processing is the secure establishment of | ||||
| common keying information state in the two parties. This state | ||||
| information is a key name, secret keying material, the identification | ||||
| of the two parties, and three algorithms for use during | ||||
| authentication: encryption (for privacy of the identities of the two | ||||
| parties), hashing (a pseudorandom function for protecting the | ||||
| integrity of the messages and for authenticating message fields), and | ||||
| authentication (the algorithm on which the mutual authentication of | ||||
| the two parties is based). The encodings and meanings for these | ||||
| choices are presented in Appendix B. | ||||
| The main mode exchange has five optional features: stateless cookie | ||||
| exchange, perfect forward secrecy for the keying material, secrecy | ||||
| for the identities, perfect forward secrecy for identity secrecy, use | ||||
| of signatures (for non-repudiation). The two parties can use all or | ||||
| none of these features. | ||||
| The general outline of processing is that the Initiator of the | ||||
| exchange begins by specifying as much information as he wishes in his | ||||
| first message. The Responder replies, supplying as much information | ||||
| as he wishes. The two sides exchange messages, supplying more | ||||
| information each time, until their requirements are satisfied. | ||||
| The choice of how much information to include in each message depends | ||||
| on which options are desirable. For example, if stateless cookies | ||||
| are not a requirement, and identity secrecy and perfect forward | ||||
| secrecy for the keying material are not requirements, and if non- | ||||
| repudiatable signatures are acceptable, then the exchange can be | ||||
| completed in three messages. | ||||
| Additional features may increase the number of roundtrips needed for | ||||
| the keying material determination. | ||||
| ISAKMP provides fields for specifying the security association | ||||
| parameters for use with the AH and ESP protocols. These security | ||||
| association payload types are specified in the ISAKMP draft; the | ||||
| payload types can be protected with OAKLEY keying material and | ||||
| algorithms, but this document does not discuss their use. | ||||
| 2.3.1 The Essential Key Exchange Message Fields | ||||
| There are 12 fields in an OAKLEY key exchange message. Not all the | ||||
| fields are relevant in every message; if a field is not relevant it | ||||
| can have a null value or not be present (no payload). | ||||
| CK-I originator cookie. | ||||
| CK-R responder cookie. | ||||
| MSGTYPE for key exchange, will be ISA_KE&AUTH_REQ or ISA_KE&AUTH_REP; | ||||
| for new group definitions, will be ISA_NEW_GROUP_REQ | ||||
| or ISA_NEW_GROUP_REP | ||||
| GRP the name of the Diffie-Hellman group used for the exchange | ||||
| g^x (or g^y) variable length integer representing a power of | ||||
| group generator | ||||
| EHAO or EHAS encryption, hash, authentication functions, offered | ||||
| and selected | ||||
| IDP an indicator as to whether or not encryption with | ||||
| g^xy follows (perfect forward secrecy for ID's) | ||||
| ID(I) the identity for the Initiator | ||||
| ID(R) the identity for the Responder | ||||
| Ni nonce supplied by the Initiator | ||||
| Nr nonce supplied by the Responder | ||||
| The construction of the cookies is implementation dependent. Phil | ||||
| Karn has recommended making them the result of a one-way function | ||||
| applied to a secret value (changed periodically), the local and | ||||
| remote IP address, and the local and remote UDP port. In this way, | ||||
| the cookies remain stateless and expire periodically. Note that with | ||||
| OAKLEY, this would cause the KEYID's derived from the secret value to | ||||
| also expire, necessitating the removal of any state information | ||||
| associated with it. | ||||
| In order to support pre-distributed keys, we recommend that | ||||
| implementations reserved some portion of their cookie space to | ||||
| permanent keys. The encoding of these depends only on the local | ||||
| implementation. | ||||
| The encryption functions used with OAKLEY must be cryptographic | ||||
| transforms which guarantee privacy and integrity for the message | ||||
| data. Merely using DES in CBC mode is not permissible. The | ||||
| MANDATORY and OPTIONAL transforms will include any that satisfy this | ||||
| criteria and are defined for use with RFC1827 (ESP). | ||||
| The one-way (hash) functions used with OAKLEY must be cryptographic | ||||
| transforms which can be used as either keyed hash (pseudo-random) or | ||||
| non-keyed transforms. The MANDATORY and OPTIONAL transforms will | ||||
| include any that are defined for use with RFC1826 (AH). | ||||
| Where nonces are indicated, they will be variable precision integers | ||||
| with an entropy value that matches the "strength" attribute of the | ||||
| GRP used with the exchange. If no GRP is indicated, the nonces must | ||||
| be at least 90 bits long. The pseudo-random generator for the nonce | ||||
| material should start with initial data that has at least 90 bits of | ||||
| entropy; see RFC1750. | ||||
| 2.3.2 Mapping to ISAKMP Message Structures | ||||
| All the OAKLEY message fields correspond to ISAKMP message payloads | ||||
| or payload components. The relevant payload fields are the SA | ||||
| payload, the AUTH payload, the Certificate Payload, the Key Exchange | ||||
| Payload. | ||||
| Some of the ISAKMP header and payload fields will have constant | ||||
| values when used with OAKLEY: | ||||
| DOI, the Domain of Interpretation, will have the value INTERNET. In this | ||||
| document, the DOI will not be mentioned; it is assumed that the | ||||
| software implementing OAKLEY will always be in the IPv4 or IPv6 DOI. | ||||
| Unless otherwise noted, the Key Exchange Identifier is Oakley Main Mode. | ||||
| In the SA Payload, the Situation is ISAKMPID. This value is fixed | ||||
| at a constant value because Oakley uses the ID fields in AUTH payload | ||||
| to identify the two parties. | ||||
| In the following we indicate where each OAKLEY field appears in the | ||||
| ISAKMP message structure. | ||||
| CK-I ISAKMP header | ||||
| CK-R ISAKMP header | ||||
| MSGTYPE Message Type in ISAKMP header | ||||
| GRP SA payload, Proposal section | ||||
| g^x (or g^y) Key Exchange Payload, encoded as a variable precision integer | ||||
| EHAO and EHAS SA payload, Proposal section | ||||
| IDP A bit in the RESERVED field in the AUTH header | ||||
| ID(I) AUTH payload, Identity field | ||||
| ID(R) AUTH payload, Identity field | ||||
| Ni AUTH payload, Nonce Field | ||||
| Nr AUTH payload, Nonce Field | ||||
| S{...}Kx AUTH payload, Data Field | ||||
| prf{K,...} AUTH payload, Data Field | ||||
| 2.4 The Key Exchange Protocol | ||||
| The exact number and content of messages exchanged during an OAKLEY | ||||
| key exchange depends on which options the Initiator and Responder | ||||
| want to use. A key exchange can be completed with three or more | ||||
| messages, depending on those options. | ||||
| The three components of the key determination protocol are the | ||||
| 1. cookie exchange (optionally stateless) | ||||
| 2. Diffie-Hellman half-key exchange (optional, but essential for | ||||
| perfect forward secrecy) | ||||
| 3. authentication (options: privacy for ID's, privacy for ID's with PFS, | ||||
| non-repudiatable) | ||||
| The initiator can supply as little information as a bare exchange | ||||
| request, carrying no additional information. On the other hand the | ||||
| initiator can begin by supplying all of the information necessary for | ||||
| the responder to authenticate the request and complete the key | ||||
| determination quickly, if the responder chooses to accept this | ||||
| method. If not, the responder can reply with a minimal amount of | ||||
| information (at the minimum, a cookie). | ||||
| The Initiator is responsible for retransmitting messages if the | ||||
| protocol does not terminate in a timely fashion. The Responder must | ||||
| therefore avoid discarding reply information until it is acknowledged | ||||
| by Initiator in the course of continuing the protocol. | ||||
| The remainder of this section contains examples demonstrating how to | ||||
| use OAKLEY options. | ||||
| 2.4.1 An Aggressive Example | ||||
| The following example indicates how two parties can complete a key | ||||
| exchange in two messages. The identities are not secret, the derived | ||||
| keying material is protected by PFS. | ||||
| By using digital signatures, the two parties will have a proof of | ||||
| communication that can be recorded and presented later to a third | ||||
| party. | ||||
| The keying material implied by the group exponentials is not needed | ||||
| for completing the exchange. If it is desirable to defer the | ||||
| computation, the implementation can save the "x" and "g^y" values and | ||||
| mark the keying material as "uncomputed". It can be computed from | ||||
| this information later. | ||||
| Initiator Responder | ||||
| --------- --------- | ||||
| -> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, -> | ||||
| ID(I), ID(R), Ni, 0, | ||||
| S{ID(I) | ID(R) | Ni | 0 | GRP | g^x | EHAO}Ki | ||||
| <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, | ||||
| ID(R), ID(I), Nr, Ni, | ||||
| S{ID(R) | ID(I) | Nr | Ni | GRP | g^y | EHAS}Kr <- | ||||
| -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAO, NIDP, -> | ||||
| ID(I), ID(R), Ni, Nr, | ||||
| S{ID(I) | ID(R) | Ni | Nr | GRP | g^y | EHAO}Ki | ||||
| NB "NIDP" means that the PFS option for hiding identities is not used. | ||||
| i.e., the identities are not encrypted using g^xy | ||||
| NB Fields are concatenated using their encoded form as they appear in | ||||
| their payload. | ||||
| The result of this exchange is a key with KEYID = CKY-I|CKY-R and | ||||
| value | ||||
| sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R). | ||||
| The processing outline for this exchange is as follows: | ||||
| Initiation | Initiation | |||
| The initiator generates a unique cookie and associates it with the | ||||
| The Initiator generates a unique cookie and associates it with the | ||||
| expected IP address of the responder, and its chosen state | expected IP address of the responder, and its chosen state | |||
| information: DOI, Auth/Priv, GRP, EHAO list, | information: GRP, a pseudo-randomly selected exponent x, g^x, EHAO | |||
| list, nonce, identities. The first authentication choice in the | ||||
| EHAO list is an algorithm that supports digital signatures, and | ||||
| this is used to sign the ID's and the nonce and group id. The | ||||
| initiator further | ||||
| notes that the key is in the initial state of "unauthenticated", | notes that the key is in the initial state of "unauthenticated", | |||
| and | and | |||
| sets a timer for possible retransmission and/or termination of the | sets a timer for possible retransmission and/or termination of the | |||
| request. | request. | |||
| The responder receives IREQ and does the following: | When the Responder receives the message, he may choose to ignore all | |||
| Generates a unique cookie, Cookie-R, | the information and treat it as merely a request for a cookie, | |||
| creating no state. If CKY-I is not already in use by the source | ||||
| address in the IP header, the responder generates a unique cookie, | ||||
| CKY-R. The next steps depend on the Responder's preferences. The | ||||
| minimal required response is to reply with the first cookie field set | ||||
| to zero and CKY-R in the second field. For this example we will | ||||
| assume that responder is more aggressive (for the alternatives, see | ||||
| section 6) and accepts the following: | ||||
| group with identifier GRP, | ||||
| first authentication choice (which must be the digital signature | ||||
| method | ||||
| used to sign the Initiator message), | ||||
| lack of perfect forward secrecy for protecting the identities, | ||||
| identity ID(I) and identity ID(R) | ||||
| associates the triple (Cookie-I, Cookie-R, DOI) with the Auth/Priv | In this example the Responder decides to accept all the information | |||
| choice, the group GRP and the IP address of the responder, and | offered by the initiator. It validates the signature over the signed | |||
| portion of the message, and associate the pair (CKY-I, CKY-R) with | ||||
| the following state information: | ||||
| puts the network address of the message into the state and, | the source and destination network addresses of the message | |||
| key state of "unauthenticated" | ||||
| the first algorithm from the authentication offer | ||||
| group GRP, a "y" exponent value in group GRP, and g^x from the | ||||
| message | ||||
| the nonce Ni and a pseudorandomly selected value Nr | ||||
| a timer for possible destruction of the state. | ||||
| The Responder computes g^y, forms the reply message, and then signs | ||||
| the state information with the private key of ID(R) and sends it to | ||||
| the Initiator. | ||||
| In this example, to expedite the protocol, the Responder implicitly | ||||
| accepts the first algorithm in the Authentication class of the EHAO | ||||
| list. This because he cannot validate the Initiator signature | ||||
| without accepting the algorithm for doing the signature. The | ||||
| Responder's EHAS list will also reflect his acceptance. | ||||
| The Initiator receives the reply message and | ||||
| validates that CKY-I is a valid association for the network | ||||
| address of the incoming message, | ||||
| adds the CKY-R value to the state for the pair (CKY-I, network | ||||
| address), and associates all state information with the pair | ||||
| (CKY-I, CKY-R), | ||||
| validates the signature of the responder over the state | ||||
| information (should validation fail, the message is discarded) | ||||
| adds g^y to its state information, | ||||
| saves the EHA selections in the state, | ||||
| optionally computes (g^y)^x (= g^xy) (this can be deferred until | ||||
| after sending the reply message), | ||||
| sends the reply message, signed with the public key of ID(I), | ||||
| marks the KEYID (CKY-I|CKY-R) as authenticated, | ||||
| and composes the reply message and signature. | ||||
| When the Responder receives the Initiator message, and if the | ||||
| signature is valid, it marks the key as being in the authenticated | ||||
| state. It should compute g^xy and associate it with the KEYID. | ||||
| Note that although PFS for identity protection is not used, PFS for | ||||
| the derived keying material is still present because the Diffie- | ||||
| Hellman half-keys g^x and g^y are exchanged. | ||||
| Even if the Responder only accepts some of the Initiator information, | ||||
| the Initiator will consider the protocol to be progressing. The | ||||
| Initiator should assume that fields that were not accepted by the | ||||
| Responder were not recorded by the Responder. | ||||
| If the Responder does not accept the aggressive exchange and selects | ||||
| another algorithm for the A function, then the protocol will not | ||||
| continue using the signature algorithm or the signature value from | ||||
| the first message. | ||||
| 2.4.1.1 Fields Not Present | ||||
| If the Responder does not accept all the fields offered by the | ||||
| Initiator, he should include null values for those fields in his | ||||
| response. Section 6 has guidelines on how to select fields in a | ||||
| "left-to-right" manner. If a field is not accepted, then it and all | ||||
| following fields must have null values. | ||||
| The Responder should not record any information that it does not | ||||
| accept. If the ID's and nonces have null values, there will not be a | ||||
| signature over these null values. | ||||
| 2.4.1.2 Signature via Pseudo-Random Functions | ||||
| The aggressive example is written to suggest that public key | ||||
| technology is used for the signatures. However, a pseudorandom | ||||
| function can be used, if the parties have previously agreed to such a | ||||
| scheme and have a shared key. | ||||
| If the first proposal in the EHAO list is an "existing key" method, | ||||
| then the KEYID named in that proposal will supply the keying material | ||||
| for the "signature" which is computed using the "H" algorithm | ||||
| associated with the KEYID. | ||||
| Suppose the first proposal in EHAO is | ||||
| EXISTING-KEY, 32 | ||||
| and the "H" algorithm for KEYID 32 is MD5-HMAC, by prior negotiation. | ||||
| The keying material is some string of bits, call it sK32. Then in | ||||
| the first message in the aggressive exchange, where the signature | ||||
| S{ID(I), ID(R), Ni, 0, GRP, g^x, EHAO}Ki | ||||
| is indicated, the signature computation would be performed by | ||||
| MD5-HMAC_func(KEY=sK32, DATA = ID(I) | ID(R) | Ni | 0 | GRP | g^x | ||||
| | EHAO) | ||||
| (The exact definition of the algorithm corresponding to "MD5-HMAC- | ||||
| func" will appear in the RFC defining that transform). | ||||
| The result of this computation appears in the Authentication payload. | ||||
| 2.4.2 An Aggressive Example With Hidden Identities | ||||
| The following example indicates how two parties can complete a key | ||||
| exchange without using digital signatures. Public key cryptography | ||||
| hides the identities during authentication. The group exponentials | ||||
| are exchanged and authenticated, but the implied keying material | ||||
| (g^xy) is not needed during the exchange. | ||||
| This exchange has an important difference from the previous signature | ||||
| scheme --- in the first message, an identity for the responder is | ||||
| indicated as cleartext: ID(R'). However, the identity hidden with | ||||
| the public key cryptography is different: ID(R). This happens | ||||
| because the Initiator must somehow tell the Responder which | ||||
| public/private key pair to use for the decryption, but at the same | ||||
| time, the identity is hidden by encryption with that public key. | ||||
| The Initiator might elect to forgo secrecy of the Responder identity, | ||||
| but this is undesirable. Instead, if there is a well-known identity | ||||
| for the Responder node, the public key for that identity can be used | ||||
| to encrypt the actual Responder identity. | ||||
| Initiator Responder | ||||
| --------- --------- | ||||
| -> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, -> | ||||
| ID(R'), E{ID(I), ID(R), E{Ni}Kr}Kr' | ||||
| <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, | ||||
| E{ID(R), ID(I), Nr}Ki, | ||||
| prf(Kir, ID(R) | ID(I) | Nr | Ni | GRP | g^y | g^x) <- | ||||
| -> CKY-I, CKY-R, OK_KEYX, GRP, 0, 0, NIDP, | ||||
| prf(Kir, ID(I)| ID(R) | Ni | Nr | GRP | g^x | g^y) -> | ||||
| Kir = prf(0, Ni | Nr) | ||||
| NB "NIDP" means that the PFS option for hiding identities is not used. | ||||
| NB The ID(R') value is included in the Authentication payload as | ||||
| described in Appendix B. | ||||
| The result of this exchange is a key with KEYID = CKY-I|CKY-R and | ||||
| value sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R). | ||||
| The processing outline for this exchange is as follows: | ||||
| Initiation | ||||
| The Initiator generates a unique cookie and associates it with the | ||||
| expected IP address of the responder, and its chosen state | ||||
| information: GRP, g^x, EHAO list. The first authentication choice | ||||
| in the EHAO list is an algorithm that supports public key | ||||
| encryption. The Initiator also names the two identities to be | ||||
| used for the connection and enters these into the state. A well- | ||||
| known identity for the responder machine is also chosen, and the | ||||
| public key for this identity is used to encrypt the nonce Ni and | ||||
| the two connection identities. The Initiator further | ||||
| notes that the key is in the initial state of "unauthenticated", | notes that the key is in the initial state of "unauthenticated", | |||
| and | and | |||
| selects one algorithm from each class in the EHAO (encryption- | sets a timer for possible retransmission and/or termination of the | |||
| hash-authentication algorithm offers) list, and | request. | |||
| selects a g^y value and associates it with the current state, and | When the Responder receives the message, he may choose to ignore all | |||
| the information and treat it as merely a request for a cookie, | ||||
| creating no state. | ||||
| sets a timer for possible retransmission, and | If CKY-I is not already in use by the source address in the IP | |||
| header, the Responder generates a unique cookie, CKY-R. As before, | ||||
| the next steps depend on the responders preferences. The minimal | ||||
| required response is a message with the first cookie field set to | ||||
| zero and CKY-R in the second field. For this example we will assume | ||||
| that responder is more aggressive and accepts the following: | ||||
| group GRP, first authentication choice (which must be the public key | ||||
| encryption algorithm used to encrypt the payload), lack of perfect | ||||
| forward secrecy for protecting the identities, identity ID(I), | ||||
| identity ID(R) | ||||
| sends the IKREQ message. | The Responder must decrypt the ID and nonce information, using the | |||
| private key for the R' ID. After this, the private key for the R ID | ||||
| will be used to decrypt the nonce field. | ||||
| The initiator receives the IKREQ message and | The Responder now associates the pair (CKY-I, CKY-R) with the | |||
| validates that Cookie-I is a valid association for the network | following state information: | |||
| the source and destination network addresses of the message | ||||
| key state of "unauthenticated" | ||||
| the first algorithm from each class in the EHAO (encryption-hash- | ||||
| authentication algorithm offers) list | ||||
| group GRP and a y and g^y value in group GRP | ||||
| the nonce Ni and a pseudorandomly selected value Nr | ||||
| a timer for possible destruction of the state. | ||||
| The Responder then encrypts the state information with the public key | ||||
| of ID(I), forms the prf value, and sends it to the Initiator. | ||||
| The Initiator receives the reply message and | ||||
| validates that CKY-I is a valid association for the network | ||||
| address of the incoming message, | address of the incoming message, | |||
| adds the Cookie-R value to the state for the pair (Cookie-I, | adds the CKY-R value to the state for the pair (CKY-I, network | |||
| network address), and associates all state information with the | address), and associates all state information with the pair | |||
| pair (Cookie-I, Cookie-R DOI), | (CKY-I, CKY-R), | |||
| adds g^y to its state information, | ||||
| chooses an exponent x and corresponding g^x value, | decrypts the ID and nonce information | |||
| checks the prf calculation (should this fail, the message is | ||||
| discarded) | ||||
| adds g^y to its state information, | ||||
| saves the EHA selections in the state, | saves the EHA selections in the state, | |||
| computes (g^x)^y (= g^xy) at this point, or | optionally computes (g^x)^y (= g^xy) (this may be deferred), and | |||
| sends the IKRES message. | sends the reply message, encrypted with the public key of ID(R), | |||
| The responder receives the IKRES message and | and marks the KEYID (CKY-I|CKY-R) as authenticated. | |||
| validates the Cookie pair against the network address for the | ||||
| incoming messages, | ||||
| computes (g^y)^x (= g^yx = g^xy). | When the Responder receives this message, it marks the key as being | |||
| in the authenticated state. If it has not already done so, it should | ||||
| compute g^xy and associate it with the KEYID. | ||||
| The responder can upgrade the initiator's A/P choice from | The secret keying material sKEYID = prf(Ni | Nr, g^xy | CKY-I | | |||
| Authentication to Privacy; the initiator must cooperate. | CKY-R) | |||
| If privacy is a requirement, then encryption in the algorithm | Note that although PFS for identity protection is not used, PFS for | |||
| indicated by the EHA class will affect subsequent messages of the | the derived keying material is still present because the Diffie- | |||
| exchange. The cookies and message type word will be the only non- | Hellman half-keys g^x and g^y are exchanged. | |||
| encrypted part of those messages (see Appendix Message Formats for | ||||
| the encryption boundary). | ||||
| Note that the Initiator must and Responder must agree on one set of | 2.4.3 An Aggressive Example With Private Identities and Without Diffie- | |||
| EHA algorithms; there is not one set for the Responder and one for | Hellman | |||
| the Initiator. The Initiator must include at least MD5 and DES in | ||||
| the initial offer. | ||||
| Both parties compute the shared key material sKEYID as | Considerable computational expense can be avoided if perfect forward | |||
| hash(g^xy | Cookie-I | Cookie-R) | secrecy is not a requirement for the session key derivation. The two | |||
| where "hash" is the algorithm in class "hash" selected in the EHA | parties can exchange nonces and secret key parts to achieve the | |||
| list. | authentication and derive keying material. The long-term privacy of | |||
| data protected with derived keying material is dependent on the | ||||
| private keys of each of the parties. | ||||
| The initiator considers the ability of the responder to repeat | In this exchange, the GRP has the value 0 and the field for the group | |||
| Cookie-I as weak evidence that the message originates from a "live" | exponential is used to hold a nonce value instead. | |||
| correspondent on the network and the correspondent is associated with | ||||
| the responder's network address. The responder makes similar | ||||
| assumptions when Cookie-R is repeated to the responder. All messages | ||||
| except IREQ messages must have valid cookies; information in | ||||
| violating messages cannot be used for any OAKLEY operations. | ||||
| 2.3.1 Retransmission, Timeouts, and Error Messages | As in the previous section, the first proposed algorithm must be a | |||
| public key encryption system; by responding with a cookie and a non- | ||||
| zero exponential field, the Responder implicitly accepts the first | ||||
| proposal and the lack of perfect forward secrecy for the identities | ||||
| and derived keying material. | ||||
| Retransmissions due to failure to elicit an expected response in the | Initiator Responder | |||
| appropriate time interval must be handled gracefully by both parties. | --------- --------- | |||
| -> CKY-I, 0, OK_KEYX, 0, 0, EHAO, NIDP, -> | ||||
| ID(R'), E{ID(I), ID(R), sKi}Kr', | ||||
| prf(Kir, ID(R), ID(I) <- | ||||
| <- CKY-R, CKY-I, OK_KEYX, 0, 0, EHAS, NIDP, | ||||
| E{ID(R), ID(I), sKr}Ki, | ||||
| prf(Kir, ID(R), ID(I), Nr, Ni) <- | ||||
| -> CKY-I, CKY-R, OK_KEYX, EHAS, NIDP, | ||||
| prf(Kir, ID(I), ID(R), Ni, Nr) -> | ||||
| Either party may destroy the current state and optionally send an | Kir = prf(0, sKi | sKr) | |||
| error message at any point in the protocol. | ||||
| The responder can explicitly reject the initial request for several | NB The sKi and sKr values go into the nonce fields. The change in | |||
| reasons: no support for a well-known but optional group, a malformed | notation is meant to emphasize that their entropy is critical to setting | |||
| EHA list, or a temporary lack of resources, for example. The exact | the keying material. | |||
| format for error messages is TBD. | ||||
| 2.3.2 ISAKMP Compatibility | NB "NIDP" means that the PFS option for hiding identities is not used. | |||
| In addition to Main Mode, this document describes three other key | The result of this exchange is a key with KEYID = CKY-I|CKY-R and | |||
| determination methods. Each method is intended to constitute a Key | value sKEYID = prf(Kir, CKY-I | CKY-R). | |||
| Exchange Interface (KEI) that could be used with ISAKMP; each method | ||||
| also constitutes a protocol that could be used independently from | ||||
| ISAKMP. | ||||
| The next method is described in order to establish an exact | 2.4.4 A Conservative Example | |||
| correspondence with the initial processing of ISAKMP in draft 03; the | ||||
| cookie exchange and the g^x exchanges are done as separate steps. | ||||
| This orthogonality may be desirable to some implementors, and it is | ||||
| thus included as a required OAKLEY mode. | ||||
| 2.3.2.1 ISAKMP Cookie/KE Mode | In this example the two parties are minimally aggressive; they use | |||
| the cookie exchange to delay creation of state, and they use perfect | ||||
| forward secrecy to protect the identities. | ||||
| The ISAKMP protocol draft [ISAKMP-03] separates the cookie exchange | The responder considers the ability of the initiator to repeat CKY-R | |||
| entirely from the exchange of group elements. This is also allowable | as weak evidence that the message originates from a "live" | |||
| in OAKLEY. The following table illustrates the message sequence and | correspondent on the network and the correspondent is associated with | |||
| fields roughly as described in ISAKMP-03. This sequence uses | the initiator's network address. The initiator makes similar | |||
| notation from the ISAKMP-03 draft and is included for merely to | assumptions when CKY-I is repeated to the initiator. | |||
| illustrate how Oakley and ISAKMP can be closely related to each | ||||
| other. A fuller treatment will appear later. | ||||
| Initiator Responder | All messages must have either have valid cookies or at least one zero | |||
| --------- ---------- | cookie. If both cookies are zero, this indicates a request for a | |||
| -> Cookie-I, 0, IREQI, SPI-I -> | cookie; if only the initiator cookie is zero, it is a response to a | |||
| <- Cookie-R, Cookie-I, IRESI, SPI-R <- | cookie request. | |||
| -> Cookie-I, Cookie-R, IKREQI, SPI-I, g^x, EHAO -> | ||||
| <- Cookie-R, Cookie-I, IKRESI, SPI-R, g^y, EHAS <- | ||||
| For compatibility with ISAKMP, the following message type value | Information in messages violating the cookie rules cannot be used for | |||
| equivalences are required: | any OAKLEY operations. | |||
| IREQI == ISA_INIT_REQ | ||||
| IRESI == ISA_INIT_RESP | ||||
| IKREQI == ISA_KE_REQ | ||||
| IKRESI == ISA_KE_RESP | ||||
| Note that the ISAKMP version 3 uses the GRPID field for a SPI field. | ||||
| Appendix C shows the correspondence of fields. | ||||
| Fields that are not mentioned in the message summaries above are must | Note that the Initiator must and Responder must agree on one set of | |||
| contain the value zero. | EHA algorithms; there is not one set for the Responder and one for | |||
| the Initiator. The Initiator must include at least MD5 and DES in | ||||
| the initial offer. | ||||
| 2.4 Authentication | Fields not indicated have null values. | |||
| After the shared keying material and its identifier are established | Initiator Responder | |||
| in Main Mode, the two parties must establish their identities to each | --------- --------- | |||
| other. The keying material cannot be used for any trusted purpose | -> 0, 0, OK_KEYX -> | |||
| until the authentication is completed. If the purpose of the keying | <- 0, CKY-R, OK_KEYX <- | |||
| material is for encryption, then the identities of the initiator and | -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAO -> | |||
| responder will be hidden by encrypting the messages using the | <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS <- | |||
| algorithm selected from the encryption clas in the EHAO list. | -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, IDP*, | |||
| ID(I), ID(R), E{Ni}Kr, -> | ||||
| <- CKY-R, CKY-I, OK_KEYX, GRP, 0 , 0, IDP, <- | ||||
| E{Nr, Ni}Ki, ID(R), ID(I), | ||||
| prf(Nr | Ni, GRP, g^xy, ID(R), ID(I)) | ||||
| -> CKY-I, CKY-R, OK_KEYX, GRP, 0 , 0, IDP, | ||||
| prf(Ni | Nr, GRP | g^xy | ID(I) | ID(R)) -> | ||||
| The authentication exchange not only hides the identities of the two | * when IDP is in effect, authentication payloads are encrypted with | |||
| parties, but it also avoids using public key technology that would | the selected encryption algorithm using the keying material prf(0, g^xy). | |||
| provide a proof, verifiable by a third party, of communication | (The transform defining the encryption algorithm will define | |||
| between the initiator and responder. This technique and its | how to select key bits from the keying material.) | |||
| justification are due to [Krawcyzk]. | This encryption is in addition to and after any public key encryption. | |||
| See Appendix B. | ||||
| 2.4.1 The Authentication Exchange | Note the in first messages, several fields are omitted from the | |||
| description. These fields are present as null values. | ||||
| The Authentication Exchange should be initiated after Main Mode. The | The first exchange allows the Responder to use stateless cookies; if | |||
| purpose of it is to change the state of KEYID from Unauthenticated to | the responder generates cookies in a manner that allows him to | |||
| Authenticated. When using Main Mode with a well-known group, The | validate them without saving them, as in Photuris, then this is | |||
| authentication MUST be completed before using the keying material for | possible. Even if the Initiator includes a cookie in his initial | |||
| any purpose, other than described in this section. | request, the responder can still use stateless cookies by merely | |||
| omitting the CKY-I from his reply and by declining to record the | ||||
| Initiator cookie until it appears in a later message. | ||||
| The authentication sequence binds the identities of the two parties | After the exchange is complete, both parties compute the shared key | |||
| to the KEYID. However, for most authentication methods, there will | material sKEYID as | |||
| be two further steps: retrieving the material that describes the | prf(Ni | Nr, g^xy | CKY-I | CKY-R) | |||
| binding between the identity and a public key (e.g. a certificate), | where "prf" is the pseudo-random function in class "hash" selected in | |||
| and validating that material (e.g. verifying the signature of the | the EHA list. | |||
| certifying authority). This section describes the binding to the | ||||
| KEYID; subsequent sections discuss the formats for the descriptive | ||||
| material and the retrieval methods. | ||||
| The Authentication Exchange is carried out in the following classic | As with the cookies, each party considers the ability of the remote | |||
| Needham-Schroeder style: | side to repeat the Ni or Nr value as a proof that Ka, the public key | |||
| of party a, speaks for the remote party and establishes its identity. | ||||
| Initiator Responder | In analyzing this exchange, it is important to note that although the | |||
| --------- ---------- | IDP option ensures that the identities are protected with an | |||
| -> KEYID, IAUTH_REQ, ID[A] -> | ephemeral key g^xy, the authentication itself does not depend on | |||
| <- KEYID, IAUTH_RES, ID[B], ID[A], | g^xy. It is essential that the authentication steps validate the g^x | |||
| E[Nb]KA, hash(sKEYID | Nb | ID[A] | ID[B]) <- | and g^y values, and it is thus imperative that the authentication not | |||
| -> KEYID, IAUTH_PRF, E[Na]KB, hash(sKEYID | Na | Nb | ID[A],ID[B]) -> | involve a circular dependency on them. A third party could intervene | |||
| <- KEYID, IAUTH_PRF_R, hash(sKEYID | Nb | Na | ID[B] | ID[A]) <- | with a "man-in-middle" scheme to convince the initiator and responder | |||
| to use different g^xy values; although such an attack might result in | ||||
| revealing the identities to the eavesdropper, the authentication | ||||
| would fail. | ||||
| The symbol ID[A] means the encoding of the identity of the initiator, | 2.4.5 Extra Strength for Protection of Encryption Keys | |||
| the symbol ID[B] is for the responder. See the next section for a | ||||
| discussion of the encoding of the identities. | ||||
| The notation E[Nb]KA means the encryption of the nonce supplied by | The nonces Ni and Nr are used to provide an extra dimension of | |||
| the responder encrypted using the key belonging to the initiator. | secrecy in deriving session keys. This makes the secrecy of the key | |||
| When public key technology is used for authentication, this | depend on two different problems: the discrete logarithm problem in | |||
| encryption is done using the public key encryption algorithm. If | the group G, and the problem of breaking the nonce encryption scheme. | |||
| symmetric keys are used, the encryption is done in the symmetric | If RSA encryption is used, then this second problem is roughly | |||
| algorithm. | equivalent to factoring the RSA public keys of both the initiator and | |||
| responder. | ||||
| The encryption of the nonces is carried out in addition to the | For authentication, the key type, the validation method, and the | |||
| encryption described next. The nonce encryption is used to validate | certification requirement must be indicated. | |||
| identities; the privacy encryption is to prevent disclosure of the | ||||
| purported identities of the two parties. | ||||
| If the Auth/Priv type of KEYID is Privacy, then these messages are | 2.5 Identity and Authentication | |||
| encrypted using the algorithm implied by the KEYID. The encryption | ||||
| boundary is shown in Appendix C. The KEYID and Message Type word are | ||||
| in cleartext. | ||||
| The encryption of the nonces Na and Nb is done with the privacy | 2.5.1 Identity | |||
| algorithm established for the keyid. The key used in the encryption | ||||
| varies, depending on the authentication type selected during the Main | ||||
| Mode. If pre-shared keys are used, then the encryption is done with | ||||
| the pre-shared key. If public keys are used, then the public key of | ||||
| the opposite party is used. | ||||
| As with the cookies, each party considers the ability of the remote | In OAKLEY exchanges the Initiator offers Initiator and Responder ID's | |||
| side to repeat the Na or Nb value as a proof that Ki, the public key | -- the former is the claimed identity for the Initiator, and the | |||
| of party i, speaks for the remote party and establishes its identity. | latter is the requested ID for the Responder. | |||
| After the Authentication Exchange is complete, the state of the KEYID | If neither ID is specified, the ID's are taken from the IP header | |||
| is changed from Unauthenticated to Authenticated, and the keying | source and destination addresses. | |||
| material is ready for use. | ||||
| 2.4.1.1 Extra Strength for Protection of Encryption Keys | If the Initiator doesn't supply a responder ID, the Responder can | |||
| reply by naming any identity that the local policy allows. The | ||||
| Initiator can refuse acceptance by terminating the exchange. | ||||
| If the Auth/Priv type associated with KEYID is Privacy, then after | The Responder can also reply with a different ID than the Initiator | |||
| the authentication exchange is complete, the nonces Na and Nb are | suggested; the Initiator can accept this implicitly by continuing the | |||
| used to provide an extra dimension of secrecy in deriving session | exchange or refuse it by terminating (not replying). | |||
| keys. They are used as input to a hash function that derives the | ||||
| keying material: | ||||
| sKEYID <- hash(sKEYID | Na | Nb) | 2.5.2 Authentication | |||
| This makes the secrecy of the key depend on two different problems: | The authentication of principals to one another is at the heart of | |||
| the discrete logarithm problem in the group G, and the problem of | any key exchange scheme. The Internet community must decide on a | |||
| breaking the nonce encryption scheme. If RSA encryption is used, | scalable standard for solving this problem, and OAKLEY must make use | |||
| then this second problem is roughly equivalent to factoring the RSA | of that standard. At the time of this writing, there is no such | |||
| public keys of both the initiator and responder. | standard, though several are emerging. This document attempts to | |||
| describe how a handful of standards could be incorporated into | ||||
| OAKLEY, without attempting to pick and choose among them. | ||||
| 2.4.2 Formats of Identity Data Structures | The following methods can appear in OAKLEY offers: | |||
| At this time, there is no commonly accepted basis for determining | a. Pre-shared Keys | |||
| identities on the Internet, so the protocol must maintain room for | When two parties have arranged for a trusted method of | |||
| flexibility on this point. There will be the following | distributing secret keys for their mutual authentication, they can | |||
| possibilities: | be used for authentication. This has obvious scaling problems for | |||
| large systems, but it is an acceptable interim solution for some | ||||
| situations. Support for pre-shared keys is REQUIRED. | ||||
| a. Pre-shared symmetric keys | The encryption, hash, and authentication algorithm for use with a | |||
| Each pair of parties has arranged for a trusted method of | pre-shared key must be part of the state information distributed | |||
| distributing secret keys for their mutual authentication. This | with the key itself. | |||
| has obvious scaling problems for large systems, but it is an | ||||
| acceptable interim solution for some situations. Support for | ||||
| pre-shared keys is REQUIRED. See Quick Mode. | ||||
| b. RSA public keys w/o certification authority signature | The pre-shared keys have a KEYID and keying material sKEYID; the | |||
| KEYID is used in a pre-shared key authentication option offer. | ||||
| There can be more than one pre-shared key offer in a list. | ||||
| Because the KEYID persists over different invocations of OAKLEY | ||||
| (after a crash, etc.), it must occupy a reserved part of the KEYID | ||||
| space for the two parties. A few bits can be set aside in each | ||||
| party's "cookie space" to accommodate this. | ||||
| There is no certification authority for pre-shared keys. When a | ||||
| pre-shared key is used to generate an authentication payload, the | ||||
| certification authority is "None", the Authentication Type is | ||||
| "Preshared", and the payload contains | ||||
| the KEYID, encoded as two 64-bit quantities, and | ||||
| the result of applying the pseudorandom hash function to the | ||||
| message body with the sKEYID forming the key for the function | ||||
| See Appendix B for details of formats for the Authentication | ||||
| Payload. | ||||
| b. DNS public keys | ||||
| Security extensions to the DNS protocol [DNSSEC] provide a | ||||
| convenient way to access public key information, especially for | ||||
| public keys associated with hosts. RSA keys are a requirement for | ||||
| secure DNS implementations; extensions to allow optional DSS keys | ||||
| are a near-term possibility. | ||||
| DNS KEY records have associated SIG records that are signed by a | ||||
| zone authority, and a hierarchy of signatures back to the root | ||||
| server establishes a foundation for trust. The SIG records | ||||
| indicate the algorithm used for forming the signature. | ||||
| OAKLEY implementations MUST support the use of DNS KEY and SIG | ||||
| records for authenticating with respect to IPv4 and IPv6 addresses | ||||
| and fully qualified domain names. However, implementations are | ||||
| not required to support any particular algorithm (RSA, DSS, etc.). | ||||
| c. RSA public keys w/o certification authority signature | ||||
| PGP [Zimmerman] uses public keys with an informal method for | PGP [Zimmerman] uses public keys with an informal method for | |||
| establishing trust. The format of PGP public keys and naming | establishing trust. The format of PGP public keys and naming | |||
| methods is described in Appendix PGP. Support for this is | methods will be described in a separate RFC. The RSA algorithm | |||
| OPTIONAL. | can be used with PGP keys for either signing or encryption; the | |||
| authentication option should indicate either RSA-SIG or RSA-ENC, | ||||
| respectively. Support for this is OPTIONAL. | ||||
| c. RSA public keys w/ certificates | d.1 RSA public keys w/ certificates | |||
| There are various formats and naming conventions for public keys | There are various formats and naming conventions for public keys | |||
| that are signed by one or more certification authorities. The | that are signed by one or more certification authorities. The | |||
| Public Key Interchange Protocol discusses X.509 encodings and | Public Key Interchange Protocol discusses X.509 encodings and | |||
| validation. | validation. Support for this is OPTIONAL. | |||
| i. The format for X.509 OAKLEY certificates is described in | d.2 DSS keys w/ certificates | |||
| Appendix X.509. Support for this is OPTIONAL. | Encoding for the Digital Signature Standard with X.509 is | |||
| described in draft-ietf-ipsec-dss-cert-00.txt. Support for this | ||||
| is OPTIONAL; an ISAKMP Authentication Type will be assigned. | ||||
| d. DSS keys w/ certificates | 2.5.3 Validating Authentication Keys | |||
| Encoding for the Digital Signature Standard is described in | ||||
| Appendix H and in internet-draft-dss-00.txt. | ||||
| 2.4.2 Validating Identity Data Structures | The combination of the Authentication algorithm, the Authentication | |||
| Authority, the Authentication Type, and a key (usually public) define | ||||
| how to validate the messages with respect to the claimed identity. | ||||
| The key information will be available either from a pre-shared key, | ||||
| or from some kind of certification authority. | ||||
| The combination of the Authentication algorithm defines how to | Generally the certification authority produces a certificate binding | |||
| interpret the identity, its certificate, and the preferred method for | the entity name to a public key. OAKLEY implementations must be | |||
| fetching the cerificate if it is not included as part of the identity | prepared to fetch and validate certificates before using the public | |||
| in the authentication exchange. | key for OAKLEY authentication purposes. | |||
| Once the certificate is obtained (see 2.4.3), the validation method | The ISAKMP Authentication Payload defines the Authentication | |||
| will depend on the Authentication algorithm; if it is PGP then the | Authority field for specifying the authority that must be apparent in | |||
| PGP signature validation routines can be called to satisfy the local | the trust hierarchy for authentication. | |||
| web-of-trust predicates; if it is RSA with X.509 certificates, the | ||||
| certificate must be examined to see if the certification authority | ||||
| signature can be validated, and if the hierarchy is recognized by the | ||||
| local policy. | ||||
| At this time there is no required format or validation method. | Once an appropriate certificate is obtained (see 2.4.3), the | |||
| validation method will depend on the Authentication Type; if it is | ||||
| PGP then the PGP signature validation routines can be called to | ||||
| satisfy the local web-of-trust predicates; if it is RSA with X.509 | ||||
| certificates, the certificate must be examined to see if the | ||||
| certification authority signature can be validated, and if the | ||||
| hierarchy is recognized by the local policy. | ||||
| 2.4.3 Fetching Identity Objects | 2.5.4 Fetching Identity Objects | |||
| In addition to interpreting the certificate or other data structure | In addition to interpreting the certificate or other data structure | |||
| that contains an identity, users of OAKLEY must face the task of | that contains an identity, users of OAKLEY must face the task of | |||
| retrieving certificates that bind a public key to an identifier and | retrieving certificates that bind a public key to an identifier and | |||
| also retrieving auxiliary certificates for certifying authorities or | also retrieving auxiliary certificates for certifying authorities or | |||
| co-signers (as in the PGP web of trust). | co-signers (as in the PGP web of trust). | |||
| The retrieval method will be specified via an implicit attribute of | The ISAKMP Credentials Payload can be used to attach useful | |||
| the Auth class name. | certificates to OAKLEY messages. The Credentials Payload is defined | |||
| in Appendix B. | ||||
| Support for accessing and revoking public key certificates via the | Support for accessing and revoking public key certificates via the | |||
| Secure DNS protocol [SECDNS] is MANDATORY for Oakley implementations. | Secure DNS protocol [SECDNS] is MANDATORY for OAKLEY implementations. | |||
| Other retrieval methods can be used when the AUTH class indicates a | Other retrieval methods can be used when the AUTH class indicates a | |||
| preference. | preference. | |||
| The Public Key Interchange Protocol discusses a full protocol that | The Public Key Interchange Protocol discusses a full protocol that | |||
| might be used with X.509 encoded certificates. | might be used with X.509 encoded certificates. | |||
| 2.5 Additional Security for Privacy Keys: Private Groups | 2.6 Interface to Cryptographic Transforms | |||
| The keying material computed by the key exchange should have at least | ||||
| 90 bits of entropy, which means that it must be at least 90 bits in | ||||
| length. This may be more or less than is required for keying the | ||||
| encryption and/or pseudorandom function transforms. | ||||
| The transforms used with OAKLEY should have auxiliary algorithms | ||||
| which take a variable precision integer and turn it into keying | ||||
| material of the appropriate length. For example, a DES algorithm | ||||
| could take the low order 56 bits, a triple DES algorithm might use | ||||
| the following: | ||||
| K1 = low 56 bits of md5(0|sKEYID) | ||||
| K2 = low 56 bits of md5(1|sKEYID) | ||||
| K3 = low 56 bits of md5(2|sKEYID) | ||||
| The transforms will be called with the keying material encoded as a | ||||
| variable precision integer, the length of the data, and the block of | ||||
| memory with the data. Conversion of the keying material to a | ||||
| transform key is the responsibility of the transform. | ||||
| 2.7 Retransmission, Timeouts, and Error Messages | ||||
| If a response from the Responder is not elicited in an appropriate | ||||
| amount of time, the message should be retransmitted by the Initiator. | ||||
| These retransmissions must be handled gracefully by both parties; the | ||||
| Responder must retain information for retransmitting until the | ||||
| Initiator moves to the next message in the protocol or completes the | ||||
| exchange. | ||||
| Informational error messages present a problem because they cannot be | ||||
| authenticated using only the information present in an incomplete | ||||
| exchange; for this reason, the parties may wish to establish a | ||||
| default key for OAKLEY error messages. A possible method for | ||||
| establishing such a key is described in Appendix B, under the use of | ||||
| ISA_INIT message types. | ||||
| In the following the message type is OAKLEY Error, the KEYID supplies | ||||
| the H algorithm and key for authenticating the message contents; this | ||||
| value is carried in the Sig/Prf payload. | ||||
| The Error payload contains the error code and the contents of the | ||||
| rejected message. | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! ! | ||||
| ~ Initiator-Cookie ~ | ||||
| / ! ! | ||||
| KEYID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| \ ! ! | ||||
| ~ Responder-Cookie ~ | ||||
| ! ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! Domain of Interpretation ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! Message Type ! Exch ! Vers ! Length ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! SPI (unused) ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! SPI (unused) ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! Error Payload ! | ||||
| ~ ~ | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! Sig/prf Payload | ||||
| ~ ~ | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| The error message will contain the cookies as presented in the offending | ||||
| message, the message type OAKLEY_ERROR, and the reason for the error, | ||||
| followed by the rejected message. | ||||
| Error messages are informational only, and the correctness of the | ||||
| protocol does not depend on them. | ||||
| Error reasons: | ||||
| TIMEOUT exchange has taken too long, state destroyed | ||||
| AEH_ERROR an unknown algorithm appears in an offer | ||||
| GROUP_NOT_SUPPORTED GRP named is not supported | ||||
| EXPONENTIAL_UNACCEPTABLE exponential too large/small | ||||
| SELECTION_NOT_OFFERED selection does not occur in offer | ||||
| NO_ACCEPTABLE_OFFERS no offer meets host requirements | ||||
| AUTHENTICATION_FAILURE signature or hash function fails | ||||
| RESOURCE_EXCEEDED too many exchanges or too much state info | ||||
| NO_EXCHANGE_IN_PROGRESS a reply received with no request in progress | ||||
| 2.8 Additional Security for Privacy Keys: Private Groups | ||||
| If the two parties have need to use a Diffie-Hellman key | If the two parties have need to use a Diffie-Hellman key | |||
| determination scheme that does not depend on the standard group | determination scheme that does not depend on the standard group | |||
| definitions, they have the option of establishing a private group. | definitions, they have the option of establishing a private group. | |||
| The authentication need not be repeated, because this stage of the | The authentication need not be repeated, because this stage of the | |||
| protocol will be protected by encryption. As an extra security | protocol will be protected by a pre-existing authentication key. As | |||
| measure, the two parties will establish a private name for the shared | an extra security measure, the two parties will establish a private | |||
| keying material, so even if they use exactly the same group to | name for the shared keying material, so even if they use exactly the | |||
| communicate with other parties, the re-use will not be apparent to | same group to communicate with other parties, the re-use will not be | |||
| passive attackers. | apparent to passive attackers. | |||
| Private groups have the advantage of making a widespread passive | Private groups have the advantage of making a widespread passive | |||
| attack much harder by increasing the number of groups that would have | attack much harder by increasing the number of groups that would have | |||
| to be exhaustively analyzed in order to recover a large number of | to be exhaustively analyzed in order to recover a large number of | |||
| session keys. This contrasts with the case when only one or two | session keys. This contrasts with the case when only one or two | |||
| groups are ever used; in that case, one would expect that years and | groups are ever used; in that case, one would expect that years and | |||
| years of session keys would be compromised. | years of session keys would be compromised. | |||
| There are two technical challenges to face: how can a particular user | There are two technical challenges to face: how can a particular user | |||
| create a unique and appropriate group, and how can a second party | create a unique and appropriate group, and how can a second party | |||
| skipping to change at page 13, line 23 ¶ | skipping to change at page 24, line 28 ¶ | |||
| c. The new modulus and generator can be cached for long periods of | c. The new modulus and generator can be cached for long periods of | |||
| time; they are not security critical and need not be associated | time; they are not security critical and need not be associated | |||
| with ongoing activity. | with ongoing activity. | |||
| d. Generating a new g^x value periodically will be more expensive | d. Generating a new g^x value periodically will be more expensive | |||
| if there are many groups cached; however, the importance of | if there are many groups cached; however, the importance of | |||
| frequently generating new g^x values is reduced, so the time | frequently generating new g^x values is reduced, so the time | |||
| period can be lengthened correspondingly. | period can be lengthened correspondingly. | |||
| 2.5.1 Defining a New Group | 2.8.1 Defining a New Group | |||
| This section describes how to define a new group. The description of | This section describes how to define a new group. The description of | |||
| the group is hidden from eavesdroppers, and the identifier assigned | the group is hidden from eavesdroppers, and the identifier assigned | |||
| to the group is unique to the two parties. Use of the new group for | to the group is unique to the two parties. Use of the new group for | |||
| Diffie-Hellman key exchanges is described in the next section. | Diffie-Hellman key exchanges is described in the next section. | |||
| The secrecy of the description and the identifier increases the | The secrecy of the description and the identifier increases the | |||
| difficulty of a passive attack, because if the group descriptor is | difficulty of a passive attack, because if the group descriptor is | |||
| not known to the attacker, there is no straightforward and efficient | not known to the attacker, there is no straightforward and efficient | |||
| way to gain information about keys calculated using the group. | way to gain information about keys calculated using the group. | |||
| Only the description of the new group need be encrypted in this | Only the description of the new group need be encrypted in this | |||
| exchange. The hash algorithm is implied by the OAKLEY session named | exchange. The hash algorithm is implied by the OAKLEY session named | |||
| by the group. The encryption is the authentication encryption | by the group. The encryption is the authentication encryption | |||
| function of the OAKLEY session. | function of the OAKLEY session. | |||
| The descriptor of the new group is encoded in the new group payload. | ||||
| The nonces are encoded in the Auth Payload. | ||||
| Data beyond the encryption boundary is encrypted using the transform | ||||
| named by the KEYID. | ||||
| The following message use the ISAKMP Key Exchange Identifier OAKLEY | ||||
| New Group. | ||||
| To define a new modular exponentiation group: | To define a new modular exponentiation group: | |||
| Initiator Responder | Initiator Responder | |||
| --------- ---------- | --------- ---------- | |||
| -> KEYID, -> | -> KEYID, -> | |||
| INEWGRP, | INEWGRP, | |||
| E[Desc(New Group), Na]Kb, | Desc(New Group), Na | |||
| hash(Desc(New Group) | Na) | prf(sKEYID, Desc(New Group) | Na) | |||
| <- KEYID, | <- KEYID, | |||
| INEWGRPRS, | INEWGRPRS, | |||
| E[Nb, Na]Ka, | Na, Nb | |||
| hash(Na | Nb | Desc(New Group)) <- | prf(sKEYID, Na | Nb | Desc(New Group)) <- | |||
| -> KEYID, | -> KEYID, | |||
| INEWGRPACK | INEWGRPACK | |||
| hash( Nb | Na | Desc(New Group)) -> | prf(sKEYID, Nb | Na | Desc(New Group)) -> | |||
| These messages are encrypted at the encryption boundary using the key | These messages are encrypted at the encryption boundary using the key | |||
| indicated. The hash value is placed in the "digital signature" field | indicated. The hash value is placed in the "digital signature" field | |||
| (see Appendix C). | (see Appendix C). | |||
| INEWGRP, INEWGRPRS, INEWGRPACK are distinct message identifiers | ||||
| Kb is the authentication key for B | ||||
| Ka is the authentication key for A | ||||
| These keys are derived during the authentication phase and are | ||||
| part of the state associated with the OAKLEY session named by the | ||||
| cookies. | ||||
| E[x]Ka indicates encryption of x using the initiator's key; Kb | ||||
| indicates the responder's key (if the encryption algorithm is | ||||
| symmetric one the keys will be identical). | ||||
| If Ka and Kb are public keys, then encryption will use the | ||||
| algorithm implied by the public key scheme, i.e., RSA encryption | ||||
| for RSA public keys. | ||||
| New GRP identifier = Na | Nb (the initiator and responder must use | New GRP identifier = Na | Nb (the initiator and responder must use | |||
| nonces that are distinct from any cookies used for current | nonces that are distinct from any used for current GRPID's. | |||
| KEYID's; i.e., the initiator ensures that Na is distinct from any | ||||
| Cookie-I, the responder ensures that Nb is distinct from any | ||||
| Cookie-R). | ||||
| Desc(G) is the encoding of the descriptor for the group descriptor | Desc(G) is the encoding of the descriptor for the group descriptor | |||
| (see Appendix A for the format of a group descriptor) | (see Appendix A for the format of a group descriptor) | |||
| The two parties must store the mapping between the new group | The two parties must store the mapping between the new group | |||
| identifier GRP and the group descriptor Desc(New Group). They must | identifier GRP and the group descriptor Desc(New Group). They must | |||
| also note the identities used for the KEYID and copy these to the | also note the identities used for the KEYID and copy these to the | |||
| state for the new group. | state for the new group. | |||
| Note that one could have the same group descriptor associated with | Note that one could have the same group descriptor associated with | |||
| several KEYID's. Pre-calculation of g^x values may be done based | several KEYID's. Pre-calculation of g^x values may be done based | |||
| only on the group descriptor, not the private group name. | only on the group descriptor, not the private group name. | |||
| 2.6 Deriving a Key Using a Private Group | 2.8.2 Deriving a Key Using a Private Group | |||
| Once a private group has been established, its group id can be used | Once a private group has been established, its group id can be used | |||
| in Main Mode (or ISAKMP mode) to derive new keying material. | in the key exchange messages in the GRP position. No changes to the | |||
| protocol are required. | ||||
| The authentication exchange is unnecessary, because the new group | ||||
| establishment was done using an authenticated key. The identities | ||||
| used in that exchange must be carried over to new key. | ||||
| 2.7 Quick Mode: New Keys From Old | 2.9 Quick Mode: New Keys From Old, | |||
| When an authenticated KEYID and associated keying material sKEYID | When an authenticated KEYID and associated keying material sKEYID | |||
| already exist, it is easy to derive additional KEYID's and keys, | already exist, it is easy to derive additional KEYID's and keys | |||
| using only hashing functions. The KEYID might be one that was | sharing similar attributes (GRP, EHA, etc.) using only hashing | |||
| derived in Main Mode, for example. | functions. The KEYID might be one that was derived in Main Mode, for | |||
| example. | ||||
| On the other hand, the authenticated key may be a manually | On the other hand, the authenticated key may be a manually | |||
| distributed key, one that is shared by the initiator and responder | distributed key, one that is shared by the initiator and responder | |||
| via some means external to OAKLEY. If the the distribution method | via some means external to OAKLEY. If the distribution method has | |||
| has formed the KEYID using appropriately unique values for the two | formed the KEYID using appropriately unique values for the two halves | |||
| halves (Cookie-I and Cookie-R), then this method is applicable. | (CKY-I and CKY-R), then this method is applicable. | |||
| In the following, the Key Exchange Identifier is OAKLEY Quick Mode. | ||||
| The nonces are carried in the Authentication Payload, and the prf | ||||
| value is carried in the Authentication Payload; the Authentication | ||||
| Authority is "None" and the type is "Pre-Shared". | ||||
| The protocol is: | The protocol is: | |||
| Initiator Responder | Initiator Responder | |||
| --------- --------- | --------- --------- | |||
| -> KEYID, INEWKRQ, Na, hash(Na, sKEYID) -> | -> KEYID, INEWKRQ, Ni, prf(sKEYID, Ni) -> | |||
| <- KEYID, INEWKRS, Nb, hash(1 | Na | Nb | sKEYID) <- | <- KEYID, INEWKRS, Nr, prf(sKEYID, 1 | Nr | Ni) <- | |||
| -> KEYID, INEWKRP, 0, hash(1 | Nb | Na | sKEYID) -> | -> KEYID, INEWKRP, 0, prf(sKEYID, 0 | Ni | Nr) -> | |||
| The New KEYID, NKEYID, is NonceA | NonceB | The New KEYID, NKEYID, is Ni | Nr | |||
| sNKEYID = hash(sKEYID, Na, Nb) | sNKEYID = prf(sKEYID, Ni | Nr ) | |||
| The identities associated with NKEYID are the same as those | The identities and EHA values associated with NKEYID are the same as | |||
| associated with KEYID. | those associated with KEYID. | |||
| Each party must validate the hash values before changing any state | Each party must validate the hash values before using the new key for | |||
| information associated with keys. | any purpose. | |||
| 2.8 Distribution of an External Key | 2.10 Defining and Using Pre-Distributed Keys | |||
| Once an OAKLEY session key and anciliary algorithms are established, | ||||
| the keying material and the encryption algorithm can be used to | If a key and an associated key identifier and state information have | |||
| distribute an externally generated key and to assign a KEYID to it. | been distributed manually, then the key can be used for any OAKLEY | |||
| purpose. The key must be associated with the usual state | ||||
| information: ID's and EHA algorithms. | ||||
| Local policy dictates when a manual key can be included in the OAKLEY | ||||
| database. For example, only privileged users would be permitted to | ||||
| introduce keys associated with privileged ID's, an unprivileged user | ||||
| could only introduce keys associated with her own ID. | ||||
| 2.11 Distribution of an External Key | ||||
| Once an OAKLEY session key and ancillary algorithms are established, | ||||
| the keying material and the "H" algorithm can be used to distribute | ||||
| an externally generated key and to assign a KEYID to it. | ||||
| In the following, KEYID represents an existing, authenticated OAKLEY | In the following, KEYID represents an existing, authenticated OAKLEY | |||
| session key, and sNEWKEYID represents the externally generated keying | session key, and sNEWKEYID represents the externally generated keying | |||
| material. Only the first two fields of each message are plaintext, | material. | |||
| the rest is encrypted using the encryption algorithm associated with | ||||
| the KEYID state. | ||||
| Initiator Responder | In the following, the Key Exchange Identifier is OAKLEY External | |||
| --------- --------- | Mode. The Key Exchange Payload contains the new key, which is | |||
| -> KEYID, INEWEXTKEY, Na, sNEWKEYID -> | protected | |||
| <- KEYID, INEWEXTKEYRQ, Nb, hash(Nb, Na, sNEWKEYID) <- | ||||
| -> KEYID, INEWEXTKEYRS, hash(Na, Nb, sNEWKEYID) -> | ||||
| Each party must validate the hash values using the hash function in | Initiator Responder | |||
| --------- --------- | ||||
| -> KEYID, IEXTKEY, Ni, prf(sKEYID, Ni) -> | ||||
| <- KEYID, IEXTKEY, Nr, prf(sKEYID, 1 | Nr | Ni) <- | ||||
| -> KEYID, IEXTKEY, Kir xor sNEWKEYID*, prf(Kir, sNEWKEYID | Ni | Nr) -> | ||||
| Kir = prf(sKEYID, Ni | Nr) | ||||
| * this field is carried in the Key Exchange Payload. | ||||
| Each party must validate the hash values using the "H" function in | ||||
| the KEYID state before changing any key state information. | the KEYID state before changing any key state information. | |||
| The new key is recovered by the Responder by calculating the xor of | ||||
| the field in the Authentication Payload with the Kir value. | ||||
| The new key identifier, naming the keying material sNEWKEYID, is | The new key identifier, naming the keying material sNEWKEYID, is | |||
| hash( 1 | Na | Nb). | prf(sKEYID, 1 | Ni | Nr). | |||
| 2.7.1 Retransmissions, Timeouts, and Error Messages | Note that this exchange does not require encryption. Hugo Krawcyzk | |||
| suggested the method and its advantage. | ||||
| TBD | 2.11.1 Cryptographic Strength Considerations | |||
| 2.8.2 Cryptographic Strength Considerations | ||||
| The strength of the key used to distribute the external key must be | The strength of the key used to distribute the external key must be | |||
| at least equal to the strength of the external key. Generally, this | at least equal to the strength of the external key. Generally, this | |||
| means that the length of the sKEYID material must be greater than or | means that the length of the sKEYID material must be greater than or | |||
| equal to the length of the sNEWKEYID material. | equal to the length of the sNEWKEYID material. | |||
| The derivation of the external key, its strength or intended use are | The derivation of the external key, its strength or intended use are | |||
| not addressed by this protocol; the parties using the key must have | not addressed by this protocol; the parties using the key must have | |||
| some other method for determining these properties. | some other method for determining these properties. | |||
| As of early 1996, it appears that for 90 bits of cryptographic | ||||
| strength, one should use a modular exponentiation group modulus of | ||||
| 2000 bits. For 128 bits of strength, a 3000 bit modulus is required. | ||||
| 3. Specifying and Deriving Security Associations | 3. Specifying and Deriving Security Associations | |||
| When a security association is defined, only the KEYID need be given. | When a security association is defined, only the KEYID need be given. | |||
| The responder should be able to look up the state associated with the | The responder should be able to look up the state associated with the | |||
| KEYID value and find the appropriate keying material, sKEYID. | KEYID value and find the appropriate keying material, sKEYID. | |||
| The OAKLEY protocol does not define security association encodings or | The OAKLEY protocol does not define security association encodings or | |||
| message formats. These can be defined through a protocol such as | message formats. These can be defined through a protocol such as | |||
| ISAKMP. Compatibility with ISAKMP is a goal of the OAKLEY design, | ISAKMP. Compatibility with ISAKMP is a goal of the OAKLEY design, | |||
| and coordination of the message formats and use of identifiers is an | and coordination of the message formats and use of identifiers is an | |||
| ongoing activity at this time. | ongoing activity at this time. | |||
| 4. Security Implementation Notes | 4. ISAKMP Compatibility | |||
| OAKLEY uses ISAKMP header and payload formats, as described in the | ||||
| text and in Appendix B. There are particular noteworthy extensions | ||||
| beyond the version 4 draft. | ||||
| 4.1 Authentication with Existing Keys | ||||
| In the case that two parties do not have suitable public key | ||||
| mechanisms in place for authenticating each other, they can use keys | ||||
| that were distributed manually. After establishment of these keys | ||||
| and their associated state in OAKLEY, they can be used for | ||||
| authentication modes that depend on signatures, e.g. Aggressive Mode. | ||||
| When an existing key is to appear in an offer list, it should be | ||||
| indicated with an Authentication Algorithm of ISAKMP_EXISTING. This | ||||
| value will be assigned in the ISAKMP RFC. | ||||
| When the authentication method is ISAKMP_EXISTING, the authentication | ||||
| authority will have the value ISAKMP_AUTH_EXISTING; the value for | ||||
| this field must not conflict with any authentication authority | ||||
| registered with IANA and will be defined in the ISAKMP RFC. | ||||
| The authentication payload will have two parts: | ||||
| the KEYID for the pre-existing key | ||||
| the identifier for the party to be authenticated by the pre- | ||||
| existing key. | ||||
| The pseudo-random function "H" in the state information for that | ||||
| KEYID will be the signature algorithm, and it will use the keying | ||||
| material for that key (sKEYID) when generating or checking the | ||||
| validity of message data. | ||||
| E.g. if the existing key has an KEYID denoted by KID and 128 bits of | ||||
| keying material denoted by sKID and "H" algorithm a transform named | ||||
| HMAC, then to generate a "signature" for a data block, the output of | ||||
| HMAC(sKID, data) | ||||
| will be the corresponding signature payload. | ||||
| The KEYID state will have the identities of the local and remote | ||||
| parties for which the KEYID was assigned; it is up to the local | ||||
| policy implementation to decide when it is appropriate to use such a | ||||
| key for authenticating other parties. For example, a key distributed | ||||
| for use between two Internet hosts A and B may be suitable for | ||||
| authenticating all identities of the form "alice@A" and "bob@B". | ||||
| 4.2 Third Party Authentication | ||||
| A local security policy might restrict key negotiation to trusted | ||||
| parties. For example, two OAKLEY daemons running with equal | ||||
| sensitivity labels on two machines might wish to be the sole arbiters | ||||
| of key exchanges between users with that same sensitivity label. In | ||||
| this case, some way of authenticating the provenance of key exchange | ||||
| requests is needed. I.e., the identities of the two daemons should | ||||
| be bound to a key, and that key will be used to form a "signature" | ||||
| for the key exchange messages. | ||||
| The Signature Payload, in Appendix B, is for this purpose. This | ||||
| payload names a KEYID that is in existence before the start of the | ||||
| current exchange. The "H" transform for that KEYID is used to | ||||
| calculate an integrity/authentication value for all payloads | ||||
| preceding the signature. | ||||
| Local policy can dictate which KEYID's are appropriate for signing | ||||
| further exchanges. | ||||
| 4.3 New Group Mode | ||||
| OAKLEY uses a new KEI for the exchange that defines a new group. | ||||
| 5. Security Implementation Notes | ||||
| Timing attacks that are capable of recovering the exponent value used | Timing attacks that are capable of recovering the exponent value used | |||
| in Diffie-Hellman calculations have been described by Paul Kocher | in Diffie-Hellman calculations have been described by Paul Kocher | |||
| [Kocher]. In order to nullify the attack, implementors must take | [Kocher]. In order to nullify the attack, implementors must take | |||
| pains to obscure the sequence of operations involved in carrying out | pains to obscure the sequence of operations involved in carrying out | |||
| modular exponentiations. | modular exponentiations. | |||
| A "blinding factor" can accomplish this goal. A group element, r, is | A "blinding factor" can accomplish this goal. A group element, r, is | |||
| chosen at random. When an exponent x is chosen, the value r^(-x) is | chosen at random. When an exponent x is chosen, the value r^(-x) is | |||
| also calculated. Then, when calculating (g^y)^x, the implementation | also calculated. Then, when calculating (g^y)^x, the implementation | |||
| skipping to change at page 16, line 37 ¶ | skipping to change at page 30, line 34 ¶ | |||
| Timing attacks that are capable of recovering the exponent value used | Timing attacks that are capable of recovering the exponent value used | |||
| in Diffie-Hellman calculations have been described by Paul Kocher | in Diffie-Hellman calculations have been described by Paul Kocher | |||
| [Kocher]. In order to nullify the attack, implementors must take | [Kocher]. In order to nullify the attack, implementors must take | |||
| pains to obscure the sequence of operations involved in carrying out | pains to obscure the sequence of operations involved in carrying out | |||
| modular exponentiations. | modular exponentiations. | |||
| A "blinding factor" can accomplish this goal. A group element, r, is | A "blinding factor" can accomplish this goal. A group element, r, is | |||
| chosen at random. When an exponent x is chosen, the value r^(-x) is | chosen at random. When an exponent x is chosen, the value r^(-x) is | |||
| also calculated. Then, when calculating (g^y)^x, the implementation | also calculated. Then, when calculating (g^y)^x, the implementation | |||
| will calculate this sequence: | will calculate this sequence: | |||
| A = (rg^y) | A = (rg^y) | |||
| B = A^x = (rg^y)^x = (r^x)(g^(xy)) | B = A^x = (rg^y)^x = (r^x)(g^(xy)) | |||
| C = B*r^(-x) = (r^x)(r^-(x))(g^(xy)) = g^(xy) | C = B*r^(-x) = (r^x)(r^-(x))(g^(xy)) = g^(xy) | |||
| The blinding factor is only necessary if the exponent x is used more | The blinding factor is only necessary if the exponent x is used more | |||
| than 100 times (estimate by Richard Schroeppel). | than 100 times (estimate by Richard Schroeppel). | |||
| 6. OAKLEY Parsing and State Machine | ||||
| There are many pathways through OAKLEY, but they follow a left-to- | ||||
| right parsing patterns of the message fields as defined in section | ||||
| 2.1. | ||||
| The initiator decides on an initial message in the following order: | ||||
| 1. Offer a cookie. This is not necessary but it helps with | ||||
| aggressive exchanges. | ||||
| 2. Pick a group. The choices are the well-known groups or any | ||||
| private groups that may have been negotiated. The very first | ||||
| exchange between two Oakley daemons with no common state must | ||||
| involve a well-known group (0, meaning no group, is a well-known | ||||
| group). Note that the group identifier, not the group descriptor, | ||||
| is used in the message. | ||||
| If a non-null group will be used, it must be included with the | ||||
| first message specifying EHAO. It need not be specified until | ||||
| then. | ||||
| 3. If PFS will be used, pick an exponent x and present g^x. | ||||
| 4. Offer Encryption, Hash, and Authentication lists. | ||||
| 5. Use PFS for hiding the identities | ||||
| If identity hiding is not used, then the initiator has this | ||||
| option: | ||||
| 6. Name the identities and include authentication information | ||||
| The information in the authentication section depends on the first | ||||
| authentication offer. In this aggressive exchange, the Initiator | ||||
| hopes that the Responder will accept all the offered information and | ||||
| the first authentication method. The authentication method | ||||
| determines the authentication payload as follows: | ||||
| 1. Signing method. The signature will be applied to all the offered | ||||
| information. | ||||
| 2. A public key encryption method. The algorithm will be used to | ||||
| encrypt a nonce in the public key of the requested Responder identity. | ||||
| There are two cases possible, depending on whether or not identity | ||||
| hiding is used: | ||||
| a. No identity hiding. The ID's will appear as plaintext. | ||||
| b. Identity hiding. A well-known ID, call it R', will appear as | ||||
| plaintext in the authentication payload. It will be followed | ||||
| by two ID's and a nonce; these will be encrypted using the | ||||
| public key for R'. | ||||
| 3. A pre-existing key method. The pre-existing key will be used to | ||||
| encrypt a nonce. If identity hiding is used, the ID's will be | ||||
| encrypted in place in the payload, using the "E" algorithm associated | ||||
| with the pre-existing key. | ||||
| The Responder can accept all, part or none of the initial message. | ||||
| The Responder accepts as many of the fields as he wishes, using the | ||||
| same decision order as the initiator. At any step he can stop, | ||||
| implicitly rejecting further fields (which will have null values in | ||||
| his response message). The minimum response is a cookie and the GRP. | ||||
| 1. Accept cookie. The Responder may elect to record no state | ||||
| information until the Initiator successfully replies with a cookie | ||||
| chosen by the responder. If so, the Responder replies with a cookie, | ||||
| the GRP, and no other information. | ||||
| 2. Accept GRP. If the group is not acceptable, the Responder will | ||||
| not reply. The Responder may send an error message indicating the | ||||
| the group is not acceptable (modulus too small, unknown identifier, | ||||
| etc.) Note that "no group" has two meanings during the protocol: it | ||||
| may mean the group is not yet specified, or it may mean that no group | ||||
| will be used (and thus PFS is not possible). | ||||
| 3. Accept the g^x value. The Responder indicates his acceptance of | ||||
| the g^x value by including his own g^y value in his reply. He can | ||||
| postpone this by ignoring g^x and putting a zero length g^y value in | ||||
| his reply. | ||||
| 4. Accept one element from each of the EHA lists. The acceptance is | ||||
| indicated by a non-zero proposal. | ||||
| 5. If PFS for identity hiding is requested, then no further data will | ||||
| follow. | ||||
| 6. If the authentication payload is present, and if the first item in | ||||
| the offered authentication class is acceptable, then the Responder | ||||
| must validate/decrypt the information in the authentication payload | ||||
| and signature payload, if present. The Responder should choose a | ||||
| nonce and reply using the same authentication/hash algorithm as the | ||||
| Initiator used. | ||||
| The Initiator notes which information the Responder has accepted, | ||||
| validates/decrypts any signed, hashed, or encrypted fields, and if | ||||
| the data is acceptable, replies in accordance to the EHA methods | ||||
| selected by the Responder. The Initiator replies are distinguished | ||||
| from his initial message by the presence of the non-zero value for | ||||
| the Responder cookie. | ||||
| APPENDIX A Group Descriptors | APPENDIX A Group Descriptors | |||
| Three distinct group representations can be used with OAKLEY. Each | Three distinct group representations can be used with OAKLEY. Each | |||
| group is defined by its group operation and the kind of underlying | group is defined by its group operation and the kind of underlying | |||
| field used to represent group elements. The three types are modular | field used to represent group elements. The three types are modular | |||
| exponentiation groups (named MODP herein), elliptic curve groups | exponentiation groups (named MODP herein), elliptic curve groups | |||
| over the field GF[2^N] (named EC2N herein), and elliptic curve groups | over the field GF[2^N] (named EC2N herein), and elliptic curve groups | |||
| over GF[P] (named ECP herein) For each representation, many distinct | over GF[P] (named ECP herein) For each representation, many distinct | |||
| realizations are possible, depending on parameter selection. | realizations are possible, depending on parameter selection. | |||
| skipping to change at page 18, line 12 ¶ | skipping to change at page 34, line 12 ¶ | |||
| by 4 more parameters, A,B,X,Y. These parameters are elements of the | by 4 more parameters, A,B,X,Y. These parameters are elements of the | |||
| field F[2^N], and can be though of as polynomials of degree < N, with | field F[2^N], and can be though of as polynomials of degree < N, with | |||
| (mod 2) coefficients. They fit in N-bit fields, and are represented | (mod 2) coefficients. They fit in N-bit fields, and are represented | |||
| as integers < 2^N, as if the polynomial were evaluated at U=2. For | as integers < 2^N, as if the polynomial were evaluated at U=2. For | |||
| example, the field element U^2 + 1 would be represented by the | example, the field element U^2 + 1 would be represented by the | |||
| integer 2^2+1, which is 5. The two parameters A and B define the | integer 2^2+1, which is 5. The two parameters A and B define the | |||
| curve. A is frequently 0. B must not be 0. The parameters X and Y | curve. A is frequently 0. B must not be 0. The parameters X and Y | |||
| select a point on the curve. The parameters A,B,X,Y must satisfy the | select a point on the curve. The parameters A,B,X,Y must satisfy the | |||
| defining equation, modulo the defining polynomial, and mod 2. | defining equation, modulo the defining polynomial, and mod 2. | |||
| Group descriptor formats: .sp. nf Type of group: A two-byte field, | Group descriptor formats: | |||
| Type of group: A two-byte field, | ||||
| assigned values for the types "MODP", "ECP", "EC2N" | assigned values for the types "MODP", "ECP", "EC2N" | |||
| will be defined (see ISAKMP-04). Size of a field element, in | will be defined (see ISAKMP-04). | |||
| bits. This is either Ceiling(log2 P) | Size of a field element, in bits. This is either Ceiling(log2 P) | |||
| or the degree of the irreducible polynomial: a 32-bit integer. | or the degree of the irreducible polynomial: a 32-bit integer. | |||
| The prime P or the irreducible field polynomial: a multi-precision | The prime P or the irreducible field polynomial: a multi-precision integer. | |||
| integer. The generator: 1 or 2 values, multi-precision integers. EC | The generator: 1 or 2 values, multi-precision integers. | |||
| only: The parameters of the curve: 2 values, multi-precision | EC only: The parameters of the curve: 2 values, multi-precision integers. | |||
| integers. | ||||
| The following parameters are Optional (each of these may appear | The following parameters are Optional (each of these may appear | |||
| independently): | independently): | |||
| a value of 0 may be used as a place-holder to represent an | a value of 0 may be used as a place-holder to represent an unspecified | |||
| unspecified | ||||
| parameter; any number of the parameters may be sent, from 0 to 3. | parameter; any number of the parameters may be sent, from 0 to 3. | |||
| The largest prime factor: the encoded value that is the LPF of the | The largest prime factor: the encoded value that is the LPF of the group size, | |||
| group size, | ||||
| a multi-precision integer. | a multi-precision integer. | |||
| EC only: The order of the group: multi-precision integer. | EC only: The order of the group: multi-precision integer. | |||
| (The group size for MODP is always P-1.) | (The group size for MODP is always P-1.) | |||
| Strength of group: 32-bit integer. | Strength of group: 32-bit integer. | |||
| The strength of the group is approximately the number of key-bits | The strength of the group is approximately the number of key-bits protected. | |||
| protected. | ||||
| It is determined by the log2 of the effort to attack the group. | It is determined by the log2 of the effort to attack the group. | |||
| It may change as we learn more about cryptography. | It may change as we learn more about cryptography. | |||
| This is a generic example for a "classic" modular exponentiation | This is a generic example for a "classic" modular exponentiation group: | |||
| group: | ||||
| Group type: "MODP" | Group type: "MODP" | |||
| Size of a field element in bits: Log2 (P) rounded *up*. A 32bit integer. | Size of a field element in bits: Log2 (P) rounded *up*. A 32bit integer. | |||
| Defining prime P: a multi-precision integer. | Defining prime P: a multi-precision integer. | |||
| Generator G: a multi-precision integer. 2 <= G <= P-2. | Generator G: a multi-precision integer. 2 <= G <= P-2. | |||
| <optional> | <optional> | |||
| Largest prime factor of P-1: the multi-precision integer Q | Largest prime factor of P-1: the multi-precision integer Q | |||
| Strength of group: a 32-bit integer. We will specify a formula | Strength of group: a 32-bit integer. We will specify a formula | |||
| for calculating this number (TBD). | for calculating this number (TBD). | |||
| This is a generic example for elliptic curve group, mod P: | This is a generic example for elliptic curve group, mod P: | |||
| skipping to change at page 20, line 5 ¶ | skipping to change at page 35, line 51 ¶ | |||
| 1 2 3 | 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ! Fixed value (TBD) ! Length ! | ! Fixed value (TBD) ! Length ! | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| . . | . . | |||
| . Integer . | . Integer . | |||
| . . | . . | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| APPENDIX B New Group Definition | The format of a group descriptor is: | |||
| TBD | ||||
| APPENDIX C Message format | ||||
| 1. Message format template | ||||
| The following message format is meant to be compatible with ISAKMP | ||||
| formats. Any anomalies will be resolved by ongoing coordination | ||||
| activities. | ||||
| 1 2 3 | 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ! ! | !1!1! Group Description ! MODP ! | |||
| ~ Initiator-Cookie ~ | ||||
| / ! ! | ||||
| KEYID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| \ ! ! | ||||
| ~ Responder-Cookie ~ | ||||
| ! ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ! Domain of Interpretation ! | !1!0! Field Size ! Length ! | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ! Message Type ! Exch ! Vers ! Length ! | ! MPI ! | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ! Group ID (or SPI) ! | !1!0! Prime ! Length ! | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ! SPI (unused) ! | ! MPI ! | |||
| eeee +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ eeee | ||||
| ! ! | ||||
| ~ Identification ~ | ||||
| ! ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ! ! | !1!0! Generator1 ! Length ! | |||
| ~ Payload ~ | ||||
| ! ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ! ! | ! MPI ! | |||
| ~ Digital Signature ~ | ||||
| ! ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ! ! | !1!0! Generator2 ! Length ! | |||
| ~ Padding ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ! ! | ! MPI ! | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| !1!0! Curve-p1 ! Length ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! MPI ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| !1!0! Curve-p2 ! Length ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! MPI ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| !1!0! Largest Prime Factor ! Length ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! MPI ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| !1!0! Order of Group ! Length ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! MPI ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| !0!0! Strength of Group ! Length ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! MPI ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| "eeee" represents the encryption boundary for messages requiring privacy. | APPENDIX B Message formats | |||
| The Group ID field is used for the group identifier for the key | 1. The ISAKMP Message Types and Header | |||
| exchange methods described in this document; in other ISAKMP messages | ||||
| the field is used for a SPI. | ||||
| The second SPI field is not used in OAKLEY. It must contain the | OAKLEY uses the ISAKMP Message Types ISA_KE&AUTH_REQ and | |||
| value zero. | ISA_KE&AUTH_REP for all key exchanges. | |||
| 2. Message Types | 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! ! | ||||
| ~ Initiator-Cookie ~ | ||||
| / ! ! | ||||
| KEYID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| \ ! ! | ||||
| ~ Responder-Cookie ~ | ||||
| ! ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! Message Type ! Exch ! Vers ! Length ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! (unused) ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! (unused) ! | ||||
| eeee +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ eeee | ||||
| ! ... ! | ||||
| The following indicates the constant values for message types. These | "eeee" represents the encryption boundary for messages requiring privacy. | |||
| will be assigned unique values, although the values are TBD at the | The message after this point is subject to the encryption transform implied | |||
| time of this writing. | by the KEYID. | |||
| IREQ | The Group ID field is used for the group identifier for the key | |||
| IKREQ | exchange methods described in this document; in other ISAKMP messages | |||
| IKREP | the field is used for a SPI. OAKLEY does not use the two SPI fields | |||
| IAUTH_REQ | in an ISAKMP header. | |||
| IAUTH_REP | ||||
| IAUTH_PRF | ||||
| IAUTH_PRF_R | ||||
| INEWGRP | ||||
| INEWGRRS | ||||
| INEWGRPACK | ||||
| INEWKRQ | ||||
| INEWKRS | ||||
| INEWKRP | ||||
| INEWEXTKEY | ||||
| INEWEXTKEYRQ | ||||
| INEWEXTKEYRS | ||||
| Related ISAKMP types | The second SPI field is not used in OAKLEY. It must contain the | |||
| ISA_INIT_REQ | value zero. | |||
| ISA_INIT_RESP | ||||
| ISA_AUTH&KE_REQ | ||||
| ISA_AUTH&KE_RESP | ||||
| ISA_NEW_GROUP_REQ (recommended addition) | ||||
| ISA_NEW_GROUP_RESP (recommended addition) | ||||
| 3. Payload | The OAKLEY proposal format contains the SA attributes that are | |||
| exchanged in the ISA_INIT messages in order to establish the required | ||||
| security attributes for the key and authentication exchange. | ||||
| The Payload section will carry the g^x values, encoded as variable | 2. OAKLEY Use of ISA_AUTH&KE packets. | |||
| precision integers. | ||||
| 3.1 Generic List Exchange Format for Encryption/Hash/Authentication | 1 2 3 | |||
| Up to three attribute classes, each followed by a count and a list of | 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 | |||
| algorithms. The encoding is as in ISAKMP: | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ~ ISAKMP Header ~ | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! Domain of Interpretation ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! Next Payload ! Payload Len ! RESERVED ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ~ ~ | ||||
| ! Authentication Payload ! | ||||
| ~ ~ | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! Next Payload ! Payload Len ! RESERVED ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ~ ~ | ||||
| ! Key Exchange Payload ! | ||||
| ~ ~ | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ISA_AUTH&KE_REQ and ISA_AUTH&KE_RESP Packet Format | ||||
| a list of pairs, each one indicating its mode of use | The encodings of the OAKLEY parameters into these fields are | |||
| (encryption or hashing), and the algorithm type. | described in the next sections. | |||
| The length of the list is indicated by the count field. | ||||
| 3. The Key Exchange Payload | ||||
| The Key Exchange Payload carries values that are used to derive | ||||
| secret keying material. Because OAKLEY uses both nonces and Diffie- | ||||
| Hellman exponentials for deriving keys, its use of the Key Exchange | ||||
| Payload is slightly different from the use described in ISAKMP; that | ||||
| document expects only one Key Exchange Payload per packet, but OAKLEY | ||||
| can have two, one for nonces, one for an exponential. | ||||
| 1 2 3 | 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! Next Payload ! Payload Len ! RESERVED ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! KEI ! Length ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ~ ~ | ||||
| ! Key Exchange Data ! | ||||
| ~ ~ | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Key Exchange Payload Format | ||||
| o KEI (2 octets) - Key Exchange Identifier | ||||
| o Length (2 octets) - Length of payload in octets | ||||
| o Key Exchange Data (variable) - Data required to | ||||
| create session key. | ||||
| OAKLEY uses four KEI values: OAKLEY Main Mode, OAKLEY Quick Mode, | ||||
| OAKLEY External Mode, OAKLEY New Group Mode. | ||||
| The value encoded in the Key Exchange Data field will be the Diffie- | ||||
| Hellman exponential (if it is used), encoded as variable precision | ||||
| integers as shown in Appendix D. For Oakley External Mode, the field | ||||
| will contain the external key. | ||||
| 3. The OAKLEY Authentication Payload | ||||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ! Attribute Class ! Count ! | ! Next Payload ! Payload Len ! RESERVED ! | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ! Attribute Type ! Attribute Type ! | ! Authentication Authority ! Reserved ! | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ~ ~ | ! Authentication Type ! Length ! | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ! Attribute Type ! Attribute Type ! | ~ ~ | |||
| ! Authentication Data ! | ||||
| ~ ~ | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| 4. Identification | Authentication Payload Format | |||
| The Identification section will carry the values indicated by "ID" in | The Authentication Payload will be used to carry three pieces of | |||
| the text of this document. | essential information: the entity identifiers (ID's), the nonces, and | |||
| the output of a function proving proving knowledge of a secret. | ||||
| 5. Digital Signature | The format of the ID's is described in the next section. A payload | |||
| will have two ID's, for the Initiator and Responder, in that order. | ||||
| If the length of an ID is zero, the ID is unspecified. | ||||
| The Digital Signature section will carry the values indicated by | If the low order bit of the RESERVED field is set, the payload will | |||
| "hash" in the text of this document. | have three ID's; see section 2.4.2, An Aggressive Example With Hidden | |||
| Identities. Note that in this case, only the first ID will be in | ||||
| plaintext. The two following ID's and the encrypted nonce (see next | ||||
| paragraph) will be encrypted in the public key of the first ID. | ||||
| The nonce will follow the ID's; if a nonce is encoded with zero | ||||
| length, it is considered to be not present. If the low order bit of | ||||
| the RESERVED field is set, as in 2.4.2, then the nonce will be | ||||
| encrypted in the public key of the requested responder. | ||||
| The fourth part of the authentication payload will contain the result | ||||
| of applying the pseudorandom function or signature algorithm to the | ||||
| key exchange parameters, as described in the main text. For example, | ||||
| the output might be the result of applying a keyed MD5 transform to | ||||
| the ID's, the cookies, the nonces, and the exponentials. | ||||
| The pseudorandom function output will encoded as a variable precision | ||||
| integer as described in Appendix D. | ||||
| The Authentication Authority and Authentication Type will be taken | ||||
| from the ISAKMP requirements: | ||||
| If the second-most low order bit is set, it means that the remainder | ||||
| of the message is encrypted a key derived from the Diffie-Hellman | ||||
| g^xy value (this is the IDP bit). | ||||
| o Authentication Authority (2 octets) - This field identifies | ||||
| the party | ||||
| that generated the certificates used for authentication. | ||||
| Authorities | ||||
| must be assigned an identifier by the Internet Assigned | ||||
| Numbers | ||||
| Authority (IANA). Before being assigned an identifier, an | ||||
| authority | ||||
| must publish an RFC defining the authority's domain. [RFC- | ||||
| 1422] | ||||
| describes the Internet Policy Registration Authority (IPRA) | ||||
| and the | ||||
| procedures for achieving this registration. | ||||
| If PGP certificates, based on the ``web of trust'', are | ||||
| carried in | ||||
| the authentication payload the Authentication Authority value | ||||
| is one | ||||
| (1). | ||||
| Example certificate authorities that would have to register | ||||
| for an | ||||
| identifier are: | ||||
| -- RSA Commercial Certificate Authority | ||||
| (http://www_csc.rsa.com/netsite) | ||||
| -- Stable Large E-mail Database (SLED) | ||||
| (http://www.four11.com) | ||||
| -- U.S. Postal Service. | ||||
| o Authentication Type (2 octets) - This field indicates the | ||||
| authentication payload format. This field is used by | ||||
| authentication | ||||
| authorities that support more than one certificate type. The | ||||
| authentication types supported by an authentication authority | ||||
| must be | ||||
| defined in the RFC required for authentication authority | ||||
| registration. Examples are: | ||||
| -- PKCS #7 certificates | ||||
| -- PGP certificates | ||||
| -- DNS Signed Keys | ||||
| -- Kerberos Tokens | ||||
| -- X.509 certificates | ||||
| o Length (2 octets) - Length of the Authentication Data field in | ||||
| octets. | ||||
| o Authentication Data (variable) - Actual authentication data. | ||||
| The | ||||
| type of certificate is indicated by the Authentication Type | ||||
| field. | ||||
| 4. The OAKLEY Proposal | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! OAKLEY ! Proposal # ! Proposal Len ! RESERVED ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! EHA Format ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! Group Format ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| OAKLEY Proposal Format | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| !0!1! RESERVED ! GRP ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! GRPID ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| !0!1! GRP ! PRIV ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| !0!1! Encryption Algorithm ! DES ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| !0!1! Hash Algorithm ! MD5 ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| !1!1! Authentication Alg ! RSA ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| !0!1! Authentication Mode ! KEYED ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| OAKLEY Proposal - EHA Format | ||||
| 5. Identity (ID) formats | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! Identification Type ! Length ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ~ ~ | ||||
| ! Identification Data ! | ||||
| ~ ~ | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| There are three identification types: IP_ADDR (value 1), FQDN (value | ||||
| 2), USER_FQDN (value 3). | ||||
| The length of the IP address will be 4 bytes for the IPv4 Domain of | ||||
| Interpretation, 8 bytes for the IPv6 DOI. | ||||
| FQDN is a fully qualified domain name, as used by the DNS protocol. | ||||
| Its form is an ASCII character string. The domain components are | ||||
| separated by "." characters, as in DNS. | ||||
| USER_FQDN is a user id followed by a "." character, followed by a | ||||
| fully qualified domain name, as used by the DNS protocol. Its form | ||||
| is an ASCII character string. | ||||
| 6. OAKLEY's use ISA_INIT_REQ and ISA_INIT_RESP Packets | ||||
| OAKLEY does not require the use the ISAKMP ISA_INIT_REQ and | ||||
| ISA_INIT_RESP packets. Their optional use may include the | ||||
| establishment of ISAKMP-to-ISAKMP daemon KEYID's for later use as | ||||
| signatures over ISA_KE&AUTH packets, providing an extra level of | ||||
| authenticity checking. In this case, the Situation field will have | ||||
| the IP addresses of the two principals; the length of the IP address | ||||
| will depend on the Domain of Interpretation. | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ~ ISAKMP Header ~ | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! Next Payload ! Payload Len ! RESERVED ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! Domain of Interpretation ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! ! | ||||
| ~ Situation ~ | ||||
| ! ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! ! | ||||
| ~ Proposal ~ | ||||
| ! ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ISA_INIT_REQ and ISA_INIT_RESP Packet Format | ||||
| 7. Digital Signature/PRF Payload | ||||
| The Digital Signature/PRF payload will carry a value for | ||||
| authenticating the entire message. When it occurs, it will be the | ||||
| last payload. | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! KEYID ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ~ ~ | ||||
| ! Signature/hash data ! | ||||
| ~ ~ | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| The output of the signature or prf function will be encoded as a | ||||
| variable precision integer as described in Appendix D. The KEYID | ||||
| will indicate KEYID that names keying material and the Hash or | ||||
| Signature function. | ||||
| 8. The Credential Payload | ||||
| Useful certificates with public key information can be attached to | ||||
| OAKLEY messages using Credential Payloads. The format of the payload | ||||
| depends on the Authentication Type, and separate RFC's define the | ||||
| formats. The encoding of the Authority and Type are the same as for | ||||
| the Authentication Payload. | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! Next Payload ! Payload Len ! RESERVED ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! Authentication Authority ! Reserved ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ! Authentication Type ! Length ! | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| ~ ~ | ||||
| ! Credential Data ! | ||||
| ~ ~ | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Credential Payload Format | ||||
| APPENDIX D Encoding a variable precision integer. | APPENDIX D Encoding a variable precision integer. | |||
| Variable precision integers will be encoded as a 32-bit length field | Variable precision integers will be encoded as a 32-bit length field | |||
| followed by one or more 32-bit quantities containing the | followed by one or more 32-bit quantities containing the | |||
| representation of the integer, aligned with the most significant bit | representation of the integer, aligned with the most significant bit | |||
| in the first 32-bit item. | in the first 32-bit item. | |||
| 1 2 3 | 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 | 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 | |||
| skipping to change at page 25, line 5 ¶ | skipping to change at page 46, line 5 ¶ | |||
| key that will be derived from it. We recommend that ISAKMP | key that will be derived from it. We recommend that ISAKMP | |||
| implementors use at least 180 bits of exponent (twice the size of a | implementors use at least 180 bits of exponent (twice the size of a | |||
| 20-year symmetric key). | 20-year symmetric key). | |||
| The mathematical justification for these estimates can be found in | The mathematical justification for these estimates can be found in | |||
| texts that estimate the effort for solving the discrete log problem, | texts that estimate the effort for solving the discrete log problem, | |||
| a task that is strongly related to the efficiency of using the Number | a task that is strongly related to the efficiency of using the Number | |||
| Field Sieve for factoring large integers. Readers are referred to | Field Sieve for factoring large integers. Readers are referred to | |||
| [Stinson] and [Schneier]. | [Stinson] and [Schneier]. | |||
| APPENDIX F PGP Keys for Authentication | APPENDIX F The Well-Known Groups | |||
| TBD | ||||
| APPENDIX G X509 Certificates | ||||
| TBD | ||||
| APPENDIX H DSS Certificates | ||||
| The format and validation methods will be specified in an Internet | ||||
| draft, draft-cylink-dss-cert-00.txt. | ||||
| APPENDIX I The Well-Known Groups | ||||
| This section will have explicit descriptors for three modular | This section will have explicit descriptors for three modular | |||
| exponentiation groups and two elliptic curve over GF[2^n] groups. | exponentiation groups and two elliptic curve over GF[2^n] groups. | |||
| The identifiers for the groups (the well-known KEYID's) will also be | The identifiers for the groups (the well-known GRP's) will also be | |||
| given here. | given here. | |||
| 0 Reserved | 0 No group (used as a placeholder and for non-DH exchanges) | |||
| 1 A modular exponentiation group with a 768 bit modulus (TBD) | 1 A modular exponentiation group with a 768 bit modulus (TBD) | |||
| 2 A modular exponentiation group with a 1024 bit modulus (TBD) | 2 A modular exponentiation group with a 1024 bit modulus (TBD) | |||
| 3 A modular exponentiation group with a 2048 bit modulus (TBD) | 3 A modular exponentiation group with a 2048 bit modulus (TBD) | |||
| 4 An elliptic curve group over GF[2^155] | 4 An elliptic curve group over GF[2^155] | |||
| 5 An elliptic curve group over GF[2^210] | 5 An elliptic curve group over GF[2^210] | |||
| 2^32 and higher are used for private group identifiers | ||||
| Until then, TBD. | values 2^32 and higher are used for private group identifiers | |||
| Appendix J Domain of Interpretation | ||||
| Appendix K Implementing Group Operations | Appendix K Implementing Group Operations | |||
| The group operation must be implemented as a sequence of arithmetic | The group operation must be implemented as a sequence of arithmetic | |||
| operations; the exact operations depend on the type of group. For | operations; the exact operations depend on the type of group. For | |||
| modular exponentiation groups, the operation is multi-precision | modular exponentiation groups, the operation is multi-precision | |||
| integer multiplication and remainders by the group modulus. See | integer multiplication and remainders by the group modulus. See | |||
| Knuth Vol. 2 [Knuth] for a discussion of how to implement these for | Knuth Vol. 2 [Knuth] for a discussion of how to implement these for | |||
| large integers. Implementation recommendations for elliptic curve | large integers. Implementation recommendations for elliptic curve | |||
| group operations over GF[2^N] are described in [Schroeppel]. | group operations over GF[2^N] are described in [Schroeppel]. | |||
| BIBLIOGRAPHY | BIBLIOGRAPHY | |||
| [RFC1825] Atkinson, Randall, RFC's 1825-1827 | [RFC1825] Atkinson, Randall, RFC's 1825-1827 | |||
| [Blaze] Blaze, Matt et al., Recent symmetric key report | [Blaze] Blaze, Matt et al., Recent symmetric key report | |||
| [STS] Diffie, van Oorschot, and Wiener, Authentication and | [STS] Diffie, van Oorschot, and Wiener, Authentication and | |||
| Authenticated Key Exchanges | Authenticated Key Exchanges | |||
| [DSS] DSS draft-cylink-dss-cert-00.txt | [DSS] DSS draft-ietf-ipsec-dss-cert-00.txt | |||
| [SECDNS] DNS Signed Keys, Eastlake & Kaufman, | [SECDNS] DNS Signed Keys, Eastlake & Kaufman, | |||
| draft-ietf-dnssec-secext-09.txt | draft-ietf-dnssec-secext-09.txt | |||
| [Photuris] Karn, Phil and Simpson, William, Photuris, draft-ietf- | [Photuris] Karn, Phil and Simpson, William, Photuris, draft-ietf- | |||
| ipsec-photuris-09.txt | ipsec-photuris-09.txt | |||
| [Kocher] Kocher, Paul, Timing Attack | [Kocher] Kocher, Paul, Timing Attack | |||
| [Krawcyzk] Krawcyzk, Hugo, SKEME, ISOC, SNDS Symposium, San Diego, | [Krawcyzk] Krawcyzk, Hugo, SKEME, ISOC, SNDS Symposium, San Diego, | |||
| End of changes. 178 change blocks. | ||||
| 497 lines changed or deleted | 1519 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||