idnits 2.17.1 draft-ietf-ipsec-revised-identity-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. == 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 198 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (April 30, 2002) is 8031 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2409 (ref. 'IKEV1') (Obsoleted by RFC 4306) -- Possible downref: Normative reference to a draft: ref. 'JFK' ** Obsolete normative reference: RFC 2459 (ref. 'PKIX') (Obsoleted by RFC 3280) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Editor: Paul Hoffman 2 draft-ietf-ipsec-revised-identity-00.txt VPN Consortium 3 April 30, 2002 4 Expires in six months 6 Revised Use of Identity in Successors to IKE 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 There is an opportunity in successor-to-IKE to fix two major problems 31 that have plagued IKEv1: a misunderstanding about what is identity, and 32 having to send certificates every time because you don't know if the 33 other party already has your certificate. This proposal covers both 34 topics at once because it turns out that they are related. 36 1. Introduction 38 The discussion in this document is for the successor-to-IKE proposals. 39 It does not use the certificate, certificate request, or ID payloads 40 from IKEv1 [IKEV1]. 42 This proposal could work in either IKEv2 [IKEV2] or JFK [JFK]. In this 43 document, the message numbers refer to either the four-message version 44 of IKEv2 or JFK. 46 In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", 47 and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 49 2. New payloads for messages 1 and 2 51 Messages 1 and 2 MAY include a TrustedRoot payload. The TrustedRoot 52 payload includes a series of one or more PKIX [PKIX] keyIdentifiers of 53 roots trusted by the sender. This payload is completely optional and is 54 used only to inform the recipient of what capabilities the sender has. 56 Messages 1 and 2 MUST include exactly one IDAccepted payload. The 57 payload holds a series of one or more fields indicating the FullID types 58 that the sender will accept. The receiver MUST NOT send any FullID 59 payloads in messages 3 or 4 that are not listed in the sender's 60 IDAccepted payload. 62 3. New payloads for messages 3 and 4 64 Messages 3 and 4 MUST include exactly one FullID payload. The payload's 65 format is an ID type followed by the content. The ID types are: 67 1 PKIX certificate 68 A standalone PKIX certificate. 70 2 Certificate bundle 71 A simple ASN.1 sequence of PKIX certificates. A bundle can have 72 end-entity certificates or certificate chains. The first certificate in 73 the bundle is the sender's preferred identity certificate, but beyond 74 that there is no meaning to the ordering. 76 3 Hash-and-URL of PKIX certificate 77 The first 20 octets are the SHA-1 hash of a certificate; the rest is a 78 URL that resolves to the certificate. This is described in more detail 79 below. 81 4 URL to a PKIX certificate bundle 82 This is described in more detail below. 84 5 PKIX keyIdentifier 85 Identifies a self-signed certificate that the receiver has already 86 pre-loaded. Note that this is only useful when using self-signed 87 certificates. 89 6 IDForSharedSecret 90 This is only for use with shared secrets. It is an ASCII string (all 91 octets are 31 < x < 127) of any length. 93 3.1 Using URLs and caching certificates 95 For FullID types 3 and 4, the URL scheme must be http, although it can 96 be on any port number. Future versions of this document may add 97 requirements for how the named part looks. The URL can be to a 98 persistent repository, or it might be to the initiating machine (such as 99 in a remote access client). 101 If a recipient uses FullID type 3, it might cache the certificate with 102 the hash as an index, or the certificate can be retrieved from the URL. 103 Of course, retrieving a certificate from a URL means many more round 104 trips before the key exchange protocol can finish. On the other hand, if 105 the certificate has been cached, no additional processing is needed and 106 the certificate does not need to be sent in the UDP-based protocol. 108 If a system that is using certificates knows that it cannot resolve URLs 109 (for example, because it is not yet on the Internet), it SHOULD use 110 FullID types 1 and 2 in its IDAccepted payload. If a system can resolve 111 URLs, it SHOULD use type 3 and 4 unless it is sure that it does not 112 have the certificate of the other side, such as if it has just 113 recovered from a crash and its cache is empty. All systems should be 114 able to handle certificate bundles because the other party might have 115 multiple identities which have different certificates. 117 3.2 Using legacy authentication 119 FullID type 6 (IDForSharedSecret) indirectly supports non-certificate, 120 non-shared-secret authentication (commonly called "legacy 121 authentication") with IKEv2. The authentication system must create two 122 temporary tokens, one of which is used as the identity and the other is 123 used as the secret. The IKEv2 system must have some way of securely 124 querying the authentication system with the identity token and receiving 125 back the secret token. 127 As simple scenario is username-and-password. The IDForSharedSecret is 128 the username, and the key added to the HMAC is the password. When 129 receiving this message, the system looks up the password based on the 130 username, possibly using something like RADIUS. 132 A more complex scenario involves a hardware token that doesn't do public 133 key cryptography. Typically, the user does some challenge-response 134 exchange with the authenticating server and is then authenticated. At 135 that point, as long as the user has two pieces of authentication 136 information, they can use them in an HMAC. For systems that only return 137 one item (such as a long hash), there must be some agreement on how to 138 split that into two items, such as "80 bits for the IDForSharedSecret 139 and 80 bits for the secret". That can be done by the legacy 140 authentication vendor, possibly instantiated in an informational RFC. 142 4. New error codes 144 The use of this proposal causes the need for additional error codes: 146 - Could not get your certificate through the URL you gave 148 - Could not get your certificate bundle through the URL you gave 150 - The certificate bundle was malformed 152 - Could not find the certificate that matches the keyIdentifier you gave 154 - Could not use your IDForSharedSecret 156 5. Security Considerations 158 Sending a TrustedRoot payload exposes information about the sender of 159 the payload to a passive attack. The attacker can determine 160 information about the sender, such as which roots the sender trusts. 161 For users in a corporate environment, the TrustedRoot payload may 162 reveal who the sender's employer. 164 An attacker snooping on a receiver can learn the identity of the 165 senders who use certificates that are not cached by the receiver by 166 watching the HTTP traffic generated from the receiver. 168 6. References 170 [IKEV1] "Internet Key Exchange (IKE)", RFC 2409 172 [IKEV2] "Proposal for the IKEv2 Protocol", draft-ietf-ipsec-ikev2 174 [JFK] "Just Fast Keying (JFK)", draft-ietf-ipsec-jfk 176 [PKIX] "Internet X.509 Public Key Infrastructure Certificate and CRL 177 Profile", RFC 2459 179 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 180 BCP 14, RFC 2119 182 7. Editor's Address 184 Paul Hoffman 185 VPN Consortium 186 127 Segre Place 187 Santa Cruz, CA 95060 USA 188 paul.hoffman@vpnc.org