idnits 2.17.1 draft-keromytis-ike-id-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 114 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2409' on line 76 looks like a reference -- Missing reference section? 'RFC2401' on line 73 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. D. Keromytis 2 Internet Draft Columbia University 3 draft-keromytis-ike-id-00.txt Bill Sommerfeld 4 Sun Microsystems 6 The "suggested ID" extension for IKE 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are draft documents valid for a maximum of six 14 months and may be updated, replaced, or obsoleted by other 15 documents at any time. It is inappropriate to use Internet- Drafts 16 as reference material or to cite them other than as "work in 17 progress." 19 The list of current Internet-Drafts can be accessed at 20 http://www.ietf.org/ietf/1id-abstracts.txt 22 The list of Internet-Draft Shadow Directories can be accessed at 23 http://www.ietf.org/shadow.html. 25 Abstract 27 This document describes an extension to IKE Phase 1 exchanges that 28 increases its usefulness in certain scenarios. 30 1. Introduction 32 In the IKE key negotiation protocol [RFC2409], the Responder in a 33 Phase 1 exchange picks their Phase 1 identity based on the IP 34 address of the remote host, the local IP address used in the 35 negotiation, and the identity of the Initiator. 37 There are some circumstances where the Initiator wishes to 38 establish a security association with a specific identity that the 39 Responder has. For example, when IPsec [RFC2401] is used for 40 protecting user-to-user traffic, it is desirable to inform the 41 Responder's IKE daemon which Identity (and, by extension, 42 authentication material) to use. 44 The proposed extension to IKE is to allow the Initiator to send a 45 suggested Responder ID in the 5th message of main mode, along with 46 the Initiator ID normally sent. The Responder should treat this as 47 a hint; the Responder may return a different Phase 1 ID. The 48 Initiator should verify that the returned Phase 1 ID is the same as 49 the suggested and, if not, whether the returned Phase 1 ID is 50 acceptable. The suggested ID is included in all encryption and 51 authentication operations; for the HASH computation, HASH_I is 52 computed over both the Initiator's identity and the suggested 53 Responder identity. Following the notation in [RFC2409]: 55 HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b | 56 IDir_s ) 58 where IDir_s is the "suggested" Responder ID. 60 2. Security Considerations 62 This documents discusses an extension to the IKE protocol that 63 extends its functionality. The extension has no security 64 implications: the Responder's identity is privacy-protected in the 65 same way the Initiator's identity is. 67 3. IANA Considerations 69 No actions by IANA are required. 71 References: 73 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 74 Internet Protocol", RFC 2401, November 1998. 76 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 77 (IKE)", RFC 2409, November 1998. 79 Authors' addresses: 81 Angelos D. Keromytis 82 Columbia University, CS Department 83 515 CS Building 84 1214 Amsterdam Avenue, Mailstop 0401 85 New York, New York 10027-7003 87 Phone: +1 212 939 7095 88 Email: angelos@cs.columbia.edu 90 Bill Sommerfeld 91 1 Network Drive, UBUR02-212 92 Burlington, MA 01803 94 Phone: +1 781 442 3458 95 Email: sommerfeld@eng.sun.com 97 Expiration and File Name 99 This draft expires in March 2002 101 Its file name is draft-keromytis-ike-id-00.txt