Network Working Group P. Eronen Internet-Draft Nokia Expires: August 5, 2005 February 4, 2005 IKEv2 Clarifications and Implementation Guidelines draft-eronen-ipsec-ikev2-clarifications-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 5, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document clarifies some areas of the IKEv2 specification that may be difficult to understand to developers not intimately familiar with the specification and its history. The intent is not to introduce any changes to the protocol, but rather to provide descriptions less prone to ambiguous interpretations, and thus encourage the development of interoperable implementations. Readers are advised that this document is work-in-progress, and may contain incorrect interpretations. Eronen Expires August 5, 2005 [Page 1] Internet-Draft IKEv2 Clarifications February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Authentication . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Calculating prf(SK_pi,IDi') and prf(SK_pr,IDr') . . . . . 3 2.2 PRFs with a fixed key size . . . . . . . . . . . . . . . . 4 2.3 Hash function for RSA signatures . . . . . . . . . . . . . 5 2.4 Encoding method for RSA signatures . . . . . . . . . . . . 6 2.5 Identification type for EAP . . . . . . . . . . . . . . . 6 2.6 Identity for policy lookups when using EAP . . . . . . . . 7 2.7 Certificate encoding types . . . . . . . . . . . . . . . . 7 2.8 Rekeying CHILD_SAs . . . . . . . . . . . . . . . . . . . . 8 2.9 Rekeying the IKE_SA vs. reauthentication . . . . . . . . . 10 2.10 Rekeying the IKE_SA . . . . . . . . . . . . . . . . . . 10 3. Configuration payloads . . . . . . . . . . . . . . . . . . . 11 3.1 Length of configuration attribute type field . . . . . . . 11 3.2 Requesting any INTERNAL_IP4/IP6_ADDRESS . . . . . . . . . 11 3.3 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . . . . . . . . . 11 3.4 INTERNAL_IP4_NETMASK . . . . . . . . . . . . . . . . . . . 13 3.5 INTERNAL_IP6_ADDRESS prefix length . . . . . . . . . . . . 14 4. Other issues . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1 Message ID in IKE_SA_INIT messages . . . . . . . . . . . . 16 4.2 INITIAL_CONTACT notify payload . . . . . . . . . . . . . . 16 4.3 Diffie-Hellman for first CHILD_SA . . . . . . . . . . . . 16 4.4 Matching ID_IPV4_ADDR/ID_IPV6_ADDR . . . . . . . . . . . . 16 5. Security considerations . . . . . . . . . . . . . . . . . . 17 6. IANA considerations . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 8.2 Informative References . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . 20 Eronen Expires August 5, 2005 [Page 2] Internet-Draft IKEv2 Clarifications February 2005 1. Introduction This document clarifies some areas of the IKEv2 specification that may be difficult to understand to developers not intimately familiar with the specification and its history. The intent is not to introduce any changes to the protocol, but rather to provide descriptions less prone to ambiguous interpretations, and thus encourage the development of interoperable implementations. Readers are advised that this document is work-in-progress, and may contain incorrect interpretations. Issues where the clarification is known to be incomplete, or there is no consensus on what the the interpretation should be, are marked as such. Clarifications that are incorrect but the author does not know this are not marked as such :-). This document does not place any requirements on anyone, and does not use [RFC2119] keywords such as "MUST" and "SHOULD". The requirements are given in the IKEv2 specification [IKEv2] and IKEv2 cryptographic algorithms document [IKEv2ALG]. In this document, references to a numbered section (such as "Section 2.15") mean that section in [IKEv2]. References to mailing list messages refer to the IPsec WG mailing list at ipsec@ietf.org. Archives of the mailing list can be found at . 2. Authentication 2.1 Calculating prf(SK_pi,IDi') and prf(SK_pr,IDr') Section 2.15 describes how AUTH payloads are calculated; this calculation involves values prf(SK_pi,IDi') and prf(SK_pr,IDr'). The text continues that "In the above calculation, IDi' and IDr' are the entire ID payloads excluding the fixed header.". Here "fixed header" refers to the "generic payload header" described in Section 3.2. In other words, the data fed to the prf includes the ID Type (1 octet), three RESERVED octets, followed by the Identification data (see Section 3.5). (References: Lakshminath Dondeti's mail "prf(SK_p, ID') computation", 2004-11-14. Charlie Kaufman's reply, 2004-11-16.) Eronen Expires August 5, 2005 [Page 3] Internet-Draft IKEv2 Clarifications February 2005 2.2 PRFs with a fixed key size (Preliminary text, still open.) Section 2.15 says that "If the negotiated prf takes a fixed size key, the shared secret MUST be of that fixed size". This statement is correct: the shared secret must be of the correct size. If it is not, it cannot be used; there is no padding, truncation, or other processing involved to force it to that correct size. This requirement means that some special care must be taken when using these PRFs for shared key authentication. The implementation must not propose these PRFs when the secret is of incorrect size; or in other words, if the implementation proposes one of these PRFs, it must not allow the user to configure a shared secret with incorrect size. A strict interpretation of this text also means that these PRFs are unlikely to be useful for EAP authentication, since [EAP] specifies that the MSK is at least 64 octets (512 bits) long, while currently the only PRF that takes a fixed size key (PRF_AES128_CBC) requires a 128-bit key. It is currently under discussion whether truncation or padding should be allowed in the EAP case. Due to the way the AUTH payload is calculated, this requirement also implies that a PRF with a fixed size key can be used for shared key authentication only if the PRF produces an output of the same size as the key. This is the case for PRF_AES128_CBC, which uses a 128-bit key and produces a 128-bit output. Section 2.13 also contains text that is related to PRFs with fixed key size: "When the key for the prf function has fixed length, the data provided as a key is truncated or padded with zeros as necessary unless exceptional processing is explained following the formula". It seems that this text applies to the prf+ construction described in Section 2.13; or in other words, prf+ always accepts a key of any length, even if the underlying prf does not. Since in IKEv2 the key for prf+ is always an output from prf, this padding or truncation can happen only if the prf has a fixed key size that is different from the output size (e.g., it cannot happen for PRF_AES128_CBC). Section 2.14 continues that "If the negotiated prf takes a fixed length key and the lengths of Ni and Nr do not add up to that length, half the bits must come from Ni and half from Nr, taking the first bits of each". This raises the question about what happens if either of the nonces is shorter than half of the key length (note that the nonces are at least 128 bits, so this case cannot happen with PRF_AES128_CBC). Eronen Expires August 5, 2005 [Page 4] Internet-Draft IKEv2 Clarifications February 2005 Due to these complications, this document recommends that o Implementations that use shared secret authentication should prefer PRFs that accept a variable length key, since this makes the life of the administrator easier. o New IKEv2 PRFs defined in the future should accept variable length keys. o If, despite the previous recommendation, a new IKEv2 PRF with a fixed key size is defined in the future, it should produce an output of the same size as the key. o If some future implementation supports a PRF with a fixed key size of greater than 256 bits: when such a PRF is included in a Security Association payload, the corresponding Ni/Nr payload must be at least key size/2 bits long. (References: Paul Hoffman's mail "Re: ikev2-07: last nits", 2003-05-02. Hugo Krawczyk's reply, 2003-05-12. Thread "Question about PRFs with fixed size key", Jan 2005.) 2.3 Hash function for RSA signatures Section 3.8 says that RSA digital signature is "Computed as specified in section 2.15 using an RSA private key over a PKCS#1 padded hash." Unlike IKEv1, IKEv2 does not negotiate a hash function for the IKE_SA. The algorithm for signatures is selected by the signing party who, in general, may not know beforehand what algorithms the verifying party supports. Furthermore, [IKEv2ALG] does not say what algorithms implementations are required or recommended to support. This clearly has a potential for causing interoperability problems, since authentication will fail if the signing party selects an algorithm that is not supported by the verifying party, or not acceptable according to the verifying party's policy. This document recommends that all implementations support SHA-1, and use SHA-1 as the default hash function when generating the signatures, unless there are good reasons (such as explicit manual configuration) to believe that the other end supports something else. Other possible choices include, for example, using the hash function that was used to sign the certificate. However, this approach assumes that the recipient's "IKEv2 module" supports the same algorithms as the "certificate validation module" (which may not be true, especially if something like [SCVP] is used). Furthermore, not all CERT payloads types include a signature; and the certificate Eronen Expires August 5, 2005 [Page 5] Internet-Draft IKEv2 Clarifications February 2005 could be signed with some other algorithm than RSA. (References: Magnus Alstrom's mail "RE:", 2005-01-03. Pasi Eronen's reply, 2005-01-04. Tero Kivinen's reply, 2005-01-04.) 2.4 Encoding method for RSA signatures Section 3.8 says that the RSA digital signature is "Computed as specified in section 2.15 using an RSA private key over a PKCS#1 padded hash." The current version of PKCS#1 (v2.1) [PKCS1v21] defines two different encoding methods (ways of "padding the hash") for signatures. However, IKEv2 points to the older PKCS#1 v2.0 [PKCS1v20]. That version has only one encoding method for signatures (EMSA-PKCS1-v1_5), and thus there is no ambiguity. Note that this encoding method is different from the encoding method used in IKEv1. If future revisions of IKEv2 provide support for other encoding methods (such as EMSA-PSS), they will be given new Auth Method numbers. (References: Pasi Eronen's mail "RE:", 2005-01-04.) 2.5 Identification type for EAP (Preliminary text, still open.) Section 3.5 defines several different types for identification payloads, including, e.g., ID_FQDN, ID_RFC822_ADDR, and ID_KEY_ID. EAP [EAP] does not mandate the use of any particular type of identifier, but often EAP is used with Network Access Identifiers (NAIs) defined in [NAI] and [NAIbis]. Although NAIs look a bit like email addresses (e.g., "joe@example.com"), the syntax is not exactly the same as the syntax of email address in [RFC822]. This raises the question of which identification type should be used. This document recommends that ID_RFC822_ADDR identification type is used for those NAIs that include the realm component. Therefore, responder implementations should not attempt to verify that the contents actually conform to the exact syntax given in [RFC822] or [RFC2822], but instead should accept any reasonable looking NAI. For NAIs that do not include the realm component, this document recommends using the ID_KEY_ID identification type. (References: "need your help on this IKEv2/i18n/EAP issue" and "IKEv2 identifier issue with EAP" threads, Aug 2004.) Eronen Expires August 5, 2005 [Page 6] Internet-Draft IKEv2 Clarifications February 2005 2.6 Identity for policy lookups when using EAP (Preliminary text, better explanation needed.) When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for AAA routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method (see [EAP], Sections 5.1 and 7.3). It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder using, e.g., RADIUS [RADEAP]. In this case, the authenticated identity has to be sent from the AAA server to the IKEv2 responder. (References: Pasi Eronen's mail "RE: Reauthentication in IKEv2", 2004-10-28. "Policy lookups" thread, Oct/Nov 2004. RFC 3748, Section 7.3.) 2.7 Certificate encoding types (Preliminary text, still open.) Section 3.6 defines a total of twelve different certificate encoding types, and continues that "Specific syntax is for some of the certificate type codes above is not defined in this document." However, the text does not provide references to other documents that would contain information about the exact contents and use of those values. Without this information, it is not possible to develop interoperable implementations. Therefore, this document recommends that the following certificate encoding values should not be used before new specifications that specify their use are available. PKCS #7 wrapped X.509 certificate 1 PGP Certificate 2 DNS Signed Key 3 Kerberos Token 6 SPKI Certificate 9 (Future versions of this document may also contain clarifications about how these values are to be used.) This document recommends that most implementations should use only those values that are "MUST"/"SHOULD" requirements in [IKEv2]; i.e., Eronen Expires August 5, 2005 [Page 7] Internet-Draft IKEv2 Clarifications February 2005 "X.509 Certificate - Signature" (4), "Raw RSA Key" (11), "Hash and URL of X.509 certificate" (12), and "Hash and URL of X.509 bundle" (13). 2.8 Rekeying CHILD_SAs (Preliminary text, still open.) Section 2.8 describes that rekeying a CHILD_SA within an existing IKE_SA is done by first creating a new equivalent SA, and then deleting the old one. However, this section does not describe exactly what payloads are involved, and does not even mention the REKEY_SA notify payload. Another description about rekeying can be found in Section 1.3, but this section also omits some of the details that are in Section 2.8. A typical conversation that rekeys an existing CHILD_SA pair and then deletes the old SAs would look like this: Initiator Responder ----------- ----------- [traffic flowing via CHILD_SA pair with SPIi1/SPIr1] HDR, SK {N(REKEY_SA, SPIi1), SA(..., SPIi2, ...), Ni, [KEi], TSi, TSr} --> <-- HDR, SK {SA(..., SPIr2, ...), Nr, [KEr], TSi, TSr} HDR, SK {D(SPIi1)} --> <-- HDR, SK {D(SPIr1)} [traffic flowing via new CHILD_SA pair with SPIi2/SPIr2] However, it seems that exactly the same (or almost the same) end result would have been achieved if the REKEY_SA notify payload was not included. Not including REKEY_SA here is allowed in IKEv2; in that case, it is not called rekeying, but creating a parallel SA with identical traffic selectors, and coincidentally, deleting one of them very soon after that. Why, then, was the REKEY_SA notify payload included in the spec? This document's interpretation is that by including REKEY_SA, the initiator promises that (1) it will move its outbound traffic to the new SA as soon as it receives the CREATE_CHILD_SA response, (2) it Eronen Expires August 5, 2005 [Page 8] Internet-Draft IKEv2 Clarifications February 2005 will not use the old outbound SA after that, and (3) it will delete the old SA pair soon afterwards. If this interpretation is correct (which is not clear yet), there seems to be three main differences between the cases with and without REKEY_SA. First, if REKEY_SA is included, the responder can do certain optimizations that would not be possible without it. Second, the exact point when the responder moves the outbound traffic to the new SA may be different. Third, there may be some differences if rekeying is started simultaneously by both parties. Let's consider the optimization case first. It seems that when doing rekeying, a simple responder implementation could, in fact, replace the old SAs "in place". This can result in some packets being lost, so Section 2.8 recommends against this. Initiator Responder ----------- ----------- HDR, SK {N(REKEY_SA, SPIi1), SA(..., SPIi2, ...), Ni, [KEi], TSi, TSr} --> [responder replaces the old SAs with new ones, but remembers the values SPIi1/SPIr1] <-- HDR, SK {SA(..., SPIr2, ...), Nr, [KEr], TSi, TSr} HDR, SK {D(SPIi1)} --> [the old SA is already gone, but the responder still remembers SPIi1/SPIr1] <-- HDR, SK {D(SPIr1)} [now responder can forget SPIi1 and SPIr1] The second difference seems to be when exactly the responder should move the traffic to the new SA. When REKEY_SA is used, Section 2.8 says that the responder should continue using the old SA until it either receives a packet on the new inbound SA, or receives a Delete request for the old SA pair. When REKEY_SA is not used, the traffic is obviously moved when the old SA is deleted, but not necessarily earlier. Eronen Expires August 5, 2005 [Page 9] Internet-Draft IKEv2 Clarifications February 2005 The third difference may be what exactly happens when both parties start rekeying at the same time, and the requests cross in the network. Here REKEY_SA indicates that neither party wants to keep parallel CHILD_SAs around. (TO BE WRITTEN: details of exactly what happens in this case.) 2.9 Rekeying the IKE_SA vs. reauthentication Rekeying the IKE_SA and reauthentication are different concepts in IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and resets the Message ID counters, but it does not authenticate the parties again (no AUTH or EAP payloads are involved). This procedure is described in more detail in the next section. While rekeying the IKE_SA may be important in some environments, reauthentication, i.e., verifying that the parties still have access to the long-term credentials, is often more important. IKEv2 does not have any special support for reauthentication. Reauthentication is done by creating a new IKE_SA from scratch (using IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify payloads), creating new CHILD_SAs within the new IKE_SA (without REKEY_SA notify payloads), and finally deleting the old IKE_SA (which deletes the old CHILD_SAs as well). This means that reauthentication also establishes new keys for the IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed more often than reauthentication, the situation where "authentication lifetime" is shorter than "key lifetime" does not make sense. While creation of a new IKE_SA can be initiated by either party (initiator or responder in the original IKE_SA), the use of EAP authentication and/or configuration payloads means in practice that reauthentication has to be initiated by the same party as the original IKE_SA. IKEv2 does not currently allow the responder to request reauthentication in this case; however, there is ongoing work to add this functionality [ReAuth]. (References: "Reauthentication in IKEv2" thread, Oct/Nov 2004.) 2.10 Rekeying the IKE_SA To be written. Eronen Expires August 5, 2005 [Page 10] Internet-Draft IKEv2 Clarifications February 2005 3. Configuration payloads 3.1 Length of configuration attribute type field In Section 3.15.1, Figure 23 shows that the length of the "Attribute Type" field is 15 bits, while the text below the figure says the length is 7 bits. The figure is correct, the field is 15 bits. (References: Tero Kivinen's mail "Comments to the draft-ietf-ipsec-ikev2-11.txt", 2003-11-09. Yoav Nir's mail "Will ikev2-16 be the charm?", 2004-09-23. Charlie Kaufman's mail"draft-ietf-ipsec-ikev2-17.txt", 2004-10-04. It is expected that this issue will be fixed during the "Authors' 48 hours" before the RFC is published.) 3.2 Requesting any INTERNAL_IP4/IP6_ADDRESS When describing the INTERNAL_IP4/IP6_ADDRESS attributes, Section 3.15.1 says that "In a request message, the address specified is a requested address (or zero if no specific address is requested)". The question here is that does "zero" mean an address "0.0.0.0" or a zero length string? Earlier, the same section also says that "If an attribute in the CFG_REQUEST Configuration Payload is not zero length it is taken as a suggestion for that attribute". Also, the table of configuration attributes shows that the length of INTERNAL_IP4_ADDRESS is either "0 or 4 octets", and likewise, INTERNAL_IP6_ADDRESS is either "0 or 17 octets". Thus, if the client does not request a specific address, it includes a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, not an attribute containing an all-zeroes address. The example in 2.19 is thus incorrect, since it shows the attribute as "INTERNAL_ADDRESS(0.0.0.0)". However, since the value is only a suggestion, implementations are recommended to ignore suggestions they do not accept; or in other words, treat the same way a zero-length INTERNAL_IP4_ADDRESS, "0.0.0.0", and any other addresses the implementation does not recognize as a reasonable suggestion. 3.3 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET Section 3.15.1 describes the INTERNAL_IP4_SUBNET as "The protected sub-networks that this edge-device protects. This attribute is made Eronen Expires August 5, 2005 [Page 11] Internet-Draft IKEv2 Clarifications February 2005 up of two fields; the first being an IP address and the second being a netmask. Multiple sub-networks MAY be requested. The responder MAY respond with zero or more sub-network attributes." INTERNAL_IP6_SUBNET is defined in a similar manner. This raises two questions: first, since this information is often included in the TSr payload, what does this attribute do? And second, what does this attribute mean in CFG_REQUESTs? To answer the first question, this attribute can indeed sometimes contain exactly the same information as TSr. For instance, if there are two subnets, 192.0.1.0/26 and 192.0.2.0/24, and the client's request contains the following: CP(CFG_REQUEST) = INTERNAL_IP4_ADDRESS() TSi = (0, 0-65536, 0.0.0.0-255.255.255.255) TSr = (0, 0-65536, 0.0.0.0-255.255.255.255) Then a typical valid response would be the following (in which TSr and INTERNAL_IP4_SUBNET contain the same information): CP(CFG_REPLY) = INTERNAL_IP4_ADDRESS(192.0.1.234) INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) TSi = (0, 0-65536, 192.0.1.234-192.0.1.234) TSr = ((0, 0-65536, 192.0.1.0-192.0.1.63), (0, 0-65536, 192.0.2.0-192.0.2.255)) However, the gateway could have a policy that requires the traffic for the two subnets to be carried in separate SAs. Then a response like this would indicate to the client that if it wants access to the second subnet, it needs to create a separate SA: CP(CFG_REPLY) = INTERNAL_IP4_ADDRESS(192.0.1.234) INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) TSi = (0, 0-65536, 192.0.1.234-192.0.1.234) TSr = (0, 0-65536, 192.0.1.0-192.0.1.63) Eronen Expires August 5, 2005 [Page 12] Internet-Draft IKEv2 Clarifications February 2005 INTERNAL_IP4_SUBNET can also be useful if the client's TSr included only part of the address space. For instance, if the client requests the following: CP(CFG_REQUEST) = INTERNAL_IP4_ADDRESS() TSi = (0, 0-65536, 0.0.0.0-255.255.255.255) TSr = (0, 0-65536, 192.0.2.155-192.0.2.155) Then the gateway's reply could be this: CP(CFG_REPLY) = INTERNAL_IP4_ADDRESS(192.0.1.234) INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) TSi = (0, 0-65536, 192.0.1.234-192.0.1.234) TSr = (0, 0-65536, 192.0.2.155-192.0.2.155) To summarize, TSr indicates which subnets are accessible through this SA; the INTERNAL_IP4/6_SUBNET attributes indicate additional subnets that can be reached through this gateway, but need a separate SA. It is less clear what the attributes mean in CFG_REQUESTs, and whether other lengths than zero make sense in this situation (but for INTERNAL_IP6_SUBNET, zero length is not allowed at all!). Currently this document recommends that implementations should not include INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in CFG_REQUESTs. For the IPv4 case, this document recommends using only netmasks consisting of some amount of "1" bits followed by "0" bits; for instance, "255.0.255.0" would not be a valid netmask for INTERNAL_IP4_SUBNET. (References: Tero Kivinen's mail "Intent of couple of attributes in Configuration Payload in IKEv2?", 2004-11-19. Srinivasa Rao Addepalli's mail "INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET in IKEv2", 2004-09-10.) 3.4 INTERNAL_IP4_NETMASK (Preliminary text, still open.) Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute, and says that "The internal network's netmask. Only one netmask is allowed in the request and reply messages (e.g., 255.255.255.0) and it MUST be used only with an INTERNAL_IP4_ADDRESS attribute". Eronen Expires August 5, 2005 [Page 13] Internet-Draft IKEv2 Clarifications February 2005 However, it is not clear what exactly this attribute means, as the concept of "netmask" is not very well defined for point-to-point links (unlike multi-access links, where it means "you can reach hosts inside this netmask directly using layer 2, instead of sending packets via a router"). One possible interpretation would be that the host is given a whole block of IP addresses instead of a single address. This is also what Framed-IP-Netmask does in [RADIUS] and the IPCP "subnet mask" extension does in PPP [IPCPSubnet]. This interpretation would also work nicely with IPv6 (see the following section). However, one IKEv2 guru assured the author that this interpretation is not correct. Section 3.15.1 also says that multiple addresses are assigned using multiple INTERNAL_IP4_ADDRESS attributes. Currently, this document's interpretation is the following: o INTERNAL_IP4_NETMASK in a CFG_REPLY means exactly the same thing as INTERNAL_IP4_SUBNET containing the same information (see the previous section for description of INTERNAL_IP4_SUBNET). o INTERNAL_IP4_NETMASK does not make sense for CFG_REQUESTs, and the example in Section 2.19 is incorrect in this sense. (Another interpretation would be that by sending, for instance, the combination of INTERNAL_IP4_ADDRESS(192.0.2.0) and INTERNAL_IP4_NETMASK(255.255.255.0), the client is asking to be assigned one IP address from the network 192.0.2.0/24. However, this interpretation is not supported by the IKEv2 spec.) This interpretation is not yet settled; and it would imply that the whole attribute is totally unnecessary. Fortunately, Section 4 clearly says that a minimal implementation does not need to include or understand the INTERNAL_IP4_NETMASK attribute, and thus this document recommends that implementations should not use the INTERNAL_IP4_NETMASK attribute at all. (References: Charlie Kaufman's mail "RE: Proposed Last Call based revisions to IKEv2", 2004-05-27. Email discussion with Tero Kivinen, Jan 2005.) 3.5 INTERNAL_IP6_ADDRESS prefix length (Preliminary text, still open.) Earlier versions of the IKEv2 draft had an INTERNAL_IP6_NETMASK attribute corresponding to INTERNAL_IP4_NETMASK, but this was deleted Eronen Expires August 5, 2005 [Page 14] Internet-Draft IKEv2 Clarifications February 2005 when the prefix length field was added to the INTERNAL_IP6_ADDRESS attribute. Thus, it seems logical to assume that their purpose would be similar; however, this is far from obvious. But first a step back: the draft quite clearly says that the client is assigned an IPv6 address using the INTERNAL_IP6_ADDRESS attribute; so using this attribute with prefix length 128 in a CFG_REPLY seems to be clear. Also, this implies that IPv6 stateless autoconfiguration is not involved (and indeed, that would be quite difficult to align with TSi/TSr payloads). Again, one possible interpretation is that a prefix length smaller than 128 in a CFG_REPLY means that the client is assigned a whole block of IPv6 addresses. This would be in line with the IPv6 addressing architecture in general, and with, e.g., the Framed-IPv6-Prefix attribute in [RADIUS6]. However, the previous section rejected this interpretation for IPv4, so it would seem strange to adopt it only for IPv6. Thus, if we assume that INTERNAL_IP4_NETMASK and the prefix length in INTERNAL_IP6_ADDRESS have the same meaning, and the reasoning in the previous section is correct, then a CFG_REPLY containing a prefix length smaller than 128 has the same purpose as INTERNAL_IP6_SUBNET. However, CFG_REQUESTs are more complicated. It seems that a CFG_REQUEST message that requests a specific IPv6 address (usually an address this client was using earlier) should have prefix length 128. But what do other prefix lengths mean in CFG_REQUESTs? Section 3.15.1 says that "With IPv6, a requestor MAY supply the low order address bytes it wants to use": presumably the prefix length tells how many low order bits there are (i.e., if the prefix length is X, there requester supplies 128-X low order address bits). However, this is quite confusing: if, say, a prefix length 126 means that "I want to use these 128-126=2 low order bits", why does prefix length 128 mean that "I want to use these 128 low order bits"? Another interpretation is that instead of "low order", the draft should have said "high order", and thus a prefix length smaller than 128 means "I'd like to get an address from this subnet". Given this very confusing discussion, this document recommends that implementations should not use other INTERNAL_IP6_ADDRESS prefix lengths than 128. Eronen Expires August 5, 2005 [Page 15] Internet-Draft IKEv2 Clarifications February 2005 4. Other issues 4.1 Message ID in IKE_SA_INIT messages To be written. (References: "Question about N(COOKIE) and N(INVALID_KE_PAYLOAD) combination" thread, Oct 2004.) 4.2 INITIAL_CONTACT notify payload To be written. (References: Michael Richardson's mail "Initial Contact Messages", 2004-12-05. Paul Hoffman's reply, 2004-12-05. Tero Kivinen's reply, 2004-12-07. "Replicated identities" thread in Jan 2005.) 4.3 Diffie-Hellman for first CHILD_SA (Preliminary text, references missing.) Section 1.2 shows that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. This implies that the SA payload in IKE_AUTH exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with any other value than NONE. 4.4 Matching ID_IPV4_ADDR/ID_IPV6_ADDR When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match the address in the IP header (of IKEv2 packets), or anything in the TSi/TSr payloads. The contents of IDi/IDr is used purely to fetch the policy and authentication data related to the other party. (References: "Identities types IP address,FQDN/user FQDN and DN and its usage in pershared key authentication" thread, Jan 2005.) Eronen Expires August 5, 2005 [Page 16] Internet-Draft IKEv2 Clarifications February 2005 5. Security considerations This document does not introduce any new security considerations to IKEv2. If anything, clarifying complex areas of the specification can reduce the likelihood of implementation problems that may have security implications. 6. IANA considerations This document has no IANA Actions. 7. Acknowledgments This document is mainly based on conversations on the IPsec WG mailing list. The author would especially like to thank Bernard Aboba, Jari Arkko, Paul Hoffman, Mika Joutsenvirta, Charlie Kaufman, Tero Kivinen, Yoav Nir, and Michael Richardson for their contributions. 8. References 8.1 Normative References [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17 (work in progress), September 2004. [IKEv2ALG] Schiller, J., "Cryptographic Algorithms for use in the Internet Key Exchange Version 2", draft-ietf-ipsec-ikev2-algorithms-05 (work in progress), April 2004. [PKCS1v20] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998. [PKCS1v21] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. 8.2 Informative References [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. Eronen Expires August 5, 2005 [Page 17] Internet-Draft IKEv2 Clarifications February 2005 [EAPKey] Aboba, B., Simon, D., Arkko, J., Eronen, P. and H. Levkowetz, "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-04 (work in progress), November 2004. [IPCPSubnet] Cisco Systems, Inc., "IPCP Subnet Mask Support Enhancements", http://www.cisco.com/univercd/cc/td/doc/product/software/i os121/121newft/121limit/121dc/121dc3/ipcp_msk.htm, January 2003. [NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [NAIbis] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network Access Identifier", draft-ietf-radext-rfc2486bis-03 (work in progress), November 2004. [RADEAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RADIUS] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RADIUS6] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", RFC 822, August 1982. [ReAuth] Nir, Y., "Repeated Authentication in IKEv2", draft-nir-ikev2-auth-lt-01 (work in progress), November 2004. [SCVP] Freeman, T., Housley, R. and A. Malpani, "Simple Certificate Validation Protocol (SCVP)", draft-ietf-pkix-scvp-16 (work in progress), October 2004. Eronen Expires August 5, 2005 [Page 18] Internet-Draft IKEv2 Clarifications February 2005 Author's Address Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland EMail: pasi.eronen@nokia.com Eronen Expires August 5, 2005 [Page 19] Internet-Draft IKEv2 Clarifications February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Eronen Expires August 5, 2005 [Page 20]