idnits 2.17.1 draft-ietf-ipsra-getcert-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** 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 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. ** The abstract seems to contain references ([SCEP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (November 2000) is 8563 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) == Missing Reference: 'RFC2617' is mentioned on line 206, but not defined ** Obsolete undefined reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) == Unused Reference: 'RFC2401' is defined on line 269, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1866 (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-23) exists of draft-nourse-scep-03 ** Downref: Normative reference to an Historic draft: draft-nourse-scep (ref. 'SCEP') Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bellovin and Moskowitz 3 Internet Draft AT&T Labs Research; ICSA Labs 5 Expiration Date: May 2001 November 2000 7 Client Certificate and Key Retrieval for IKE 9 draft-ietf-ipsra-getcert-00.txt 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 2. Abstract 34 IKE was designed for use with certificates. In a remote access 35 scenario, that implies that clients must possess their own 36 certificates. We leverage off of work already done to fast-start 37 certificate use with IPsec via the Simple Certificate Enrollment 38 Protocol [SCEP]. We use only parts of SCEP over a client 39 authenticated TLS/HTTP connection to a CA. By using TLS, the client 40 can trust a CA root certificate it receives, without an out-of-band 41 verification and the CA can perform automatic enrollment. We replace 42 the out-of-band client identification process for a certificate 43 enrollment with a legacy authentication, like RADIUS. Further, since 44 the certificates issued here are short-lived, there is no need to 45 support client-based revocation or rekeying. Also, there is 46 typically no need for CRL support. 48 3. Introduction 50 IKE was designed for use with certificates. In a remote access 51 scenario, that implies that clients must possess their own 52 certificates. Unfortunately, that is not always practical. Apart 53 from the lack of a suitable PKI in many companies, there is often the 54 need (or desire) to use other forms of personal identification, 55 especially some sort of authentication token in conjunction with a 56 RADIUS server. 58 We consider inadvisable to change IKE [RFC2409] to meet these needs. 59 IKE is a complex protocol; adding more features to it is a bad idea. 60 Instead, we propose a layered approach: use standard IKE, with 61 certificates, but provide a simple mechanism to provide clients with 62 keys and certificates. 64 A number of objections have been raised to using certificates. The 65 most important is that we lack a public key infrastructure (PKI). We 66 do not agree that this is an obstacle. Our proposal provides a 67 simple mechanism for certificate generation and retrieval, while 68 still relying on legacy authentication infrastructures. Furthermore, 69 we provide for an easy migration path to certificate use once 70 organizational PKIs are deployed. 72 In the interests of simplicity, we have chosen to reuse standard 73 protocols and components. In particular, we use HTTP [RFC2616] for 74 transport, HTML [RFC1866] as a data representation and TLS [RFC2246] 75 for confidentiality. However, we do not mandate (or even necessarily 76 encourage) use of a actual Web browser for certificate retrieval. 78 The client authentication mechanism is not specified, but we assume 79 that a legacy authentication, like a challenge/response 80 authentication to a RADIUS server, will be preformed by the client 81 after the server-based TLS session is set up. Thus the certificate 82 server will have access to adequate information from the 83 authentication server about the client to create a certificate. 85 We further concluded that our scheme is semantically equivalent to a 86 general certificate enrollment protocol. That is, we suggest that 87 our preferred mechanism is equivalent to what is needed for any sort 88 of certificate issuance; the only difference is that our certificates 89 are very short-lived, which generally eliminates the need for 90 detailed, comprehensive record-keeping and CRLs. 92 The actual mechanism to get certificates will be the Simple 93 Certificate Enrollment Protocol [SCEP]. This will enable client-side 94 certificate generation that is currently used by many in the IPsec 95 community. 97 3.1. Requirements Keywords 99 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 100 and "MAY" that appear in this document are to be interpreted as 101 described in [RFC2119]. 103 4. Protocol Definition 105 As noted, we suggest using SCEP. Apart from certificate issuance, 106 there are two other functions that may be needed, root certificate 107 retrieval and CRL retrieval. Both of these functions are provided 108 for in SCEP. 110 4.1. CA root certificate retrieval 112 A client MAY need to retrieve the CA's root certificate, if it does 113 not have it cached. The client will use the SCEP Get CA/RA Cert 114 transaction for this as follows: 116 END ENTITY CA SERVER Get CA/RA Cert: 117 HTTP Get message 118 -----------------------------> 119 CA/RA Cert download: HTTP Response message 120 <--------------------------------------- 122 There is no need for out-of-band root certificate validation here, as 123 the client has an authenticated connection to the server. 125 4.2. CRL retrieval 127 CRL support in GETCERT is OPTIONAL. In many client-to-gateway 128 environments, there is no need for the client to do CRL checking on 129 the gateway. However, in some peer-to-peer IPSRA environments, CRLs 130 could be important. If CRL support is desired, the CRL retrieval 131 guidelines in SCEP SHOULD be followed. The GETCRL transaction is: 133 END ENTITY CA SERVER 134 GetCRL: PKI CRL query msg 135 ----------------------------------> CertRep: CRL attached 136 <-------------------------------- 138 4.3. Client certificate request and retrieval (enrollment) 140 The SCEP 'automatic mode' is used: 142 END ENTITY CA SERVER 143 PKCSReq: PKI cert. enrollment msg 144 --------------------------------> CertRep: pkiStatus = GRANTED 145 certificate attached 146 <------------------------------ 147 Receive issued certificate. 149 4.4. HTTP "GET" Message Format 151 In the protocol, CA certificates are send to the end entity in clear, 152 whereas the end entity certificates are send out using the PKCS#7 153 secure protocol. This results in two types of GET operations. The 154 type of GET operation is specified by augmenting the GET message with 155 OPERATION and MESSAGE parameters in the Request-URL. OPERATION 156 identifies the type of GET operation, and MESSAGE is actually the PKI 157 message encoded as a text string. 159 The following is the syntax definition of a HTTP GET message send 160 from an end entity to a certificate authority server: 162 Request = "GET " PKI-PATH "?operation=" OPERATION "&message=" MESSAGE 163 where: PKI-PATH defines the actual path to invoke the program which 164 parses the request. This is intended to be the program that the CA 165 will use to handle the SCEP transactions, (Note: the original SCEP 166 specification requires this to end with "pkiclient.exe". We choose 167 to permit the actual path to vary, though of course nothing precludes 168 use of that string.) OPERATION is set to be the string 169 "PKIOperation" when the GET message carries a PKI message to request 170 certificates or CRL; OPERATION is set to be the string "GetCACert" or 171 "GetCACertChain" when the GET operation is used to get CA/RA 172 certificate or the CA Cert chain (respectively). When OPERATION is 173 "PKIOperation", MESSAGE is a base64-encoded PKI message when 174 OPERATION is "GetCACert" or "GetCACertChain", MESSAGE is a string 175 which represents the certificate authority issuer identifier. 177 4.5. Response Message Format 179 For each GET operation, the CA/RA server will return a MIME object 180 via HTTP. For a GET operation with PKIOperation as its type, the 181 response is tagged as having a Content Type of application/x-pki- 182 message. The body of this message is a DER encoded binary PKI 183 message. The following is an example of the response: 185 "Content-Type:application/x-x509-ca-cert\n\n" 187 5. Authentication Techniques 189 Although this document is carefully agnostic about the user 190 authentication techniques to be used, there are two underlying 191 assumptions. First, we assume that the authentication is actually 192 being performed by a back-end RADIUS server, over the TLS HTTP 193 connection, with its accompanying database. Second, we wish to 194 support a variety of common authentication techniques, including 195 ordinary passwords, time-varying tokens, and challenge/response 196 tokens. All are believed to be accommodated by this framework. 197 Finally, we rely on this client and server authentication so that the 198 SCEP assumptions on CA root certificate distribution and subjectName 199 checking are automated. 201 Requests for certificates must be authenticated. Since we prescribe 202 HTTP, HTTP authentication mechanisms -- under protection of TLS -- 203 MUST be used. Specifically, the request will generally include an 204 appropriate Authorization: line, using whatever form of 205 authentication is locally preferred. If it does not, the server MUST 206 return a 401 error line, per [RFC2616] and [RFC2617]; the client MUST 207 then resubmit the request with the appropriate Authentication: line. 208 (This two-phase process is permitted in order to support 209 challenge/response forms of authentication.) 211 6. Certificate Characteristics 213 Signed or generated certificates should, as noted, have a distinctive 214 name format that can be recognized and accepted by the IPsec servers. 215 The expiration time of the certificates is limited by local policy on 216 reuse. In some cases, these certificates will valid for several 217 hours (and hence several sessions, if needed); in other cases, they 218 will expire within a very few minutes and are thus practically usable 219 only for a single IKE exchange. (Note that this also requires tight 220 time synchronization between the authentication server, the IPsec 221 servers, and -- if they care -- the IPsec clients.) 223 7. Process Flow 225 The client establishes a TLS secured HTTP connection to the CA 226 service. 228 The client authenticates the server certificate. The subject is the 229 desired server. 231 The client provides its authentication over this connection. 233 The client requests via SCEP the CA root certificate. Note: The 234 server certificate might be a commercial SSL certificate. This way 235 the client might be expected to have that certificate's signing 236 certificate for validation. 238 The client requests a certificate via SCEP. 240 The server sends the certificate via SCEP after validating the 241 request against the RADIUS database information. 243 The client uses the issued certificate in its IKE negotiation with a 244 gateway. 246 8. Security Considerations 248 The client -- the program and the ultimate human -- MUST check the 249 server's TLS certificate to guard against man-in-the-middle attacks. 251 <> 253 9. Acknowledgements 255 Paul Hoffman supplied considerable encouragement to the production of 256 this document. 258 10. References 260 [RFC1866] "Hypertext Markup Language - 2.0". T. Berners-Lee, D. 261 Connolly. November 1995. 263 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels". 264 S. Bradner. March 1997. 266 [RFC2246] "The TLS Protocol Version 1.0". T. Dierks, C. Allen. 267 January 1999. 269 [RFC2401] "Security Architecture for the Internet Protocol". S. Kent, 270 R. Atkinson. November 1998. 272 [RFC2409] "The Internet Key Exchange (IKE)". D. Harkins, D. Carrel. 273 November 1998. 275 [RFC2616] "Hypertext Transfer Protocol -- HTTP/1.1". R. Fielding, J. 276 Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. 277 Jun 1999. 279 [SCEP] "Cisco Systems' Simple Certificate Enrollment 280 Protocol". draft-nourse-scep-03.txt, X. Liu, C. Madsen, D. McDrew, 281 A. Nourse. August, 2000. 283 11. Author Information 285 Steven M. Bellovin 286 AT&T Labs Research 287 Shannon Laboratory 288 180 Park Avenue 289 Florham Park, NJ 07974 290 USA 291 Phone: +1 973-360-8656 292 Email: smb@research.att.com 294 Robert G. Moskowitz 295 ICSA Labs, a division of TruSecure Corporation 296 1200 Walnut Bottom Rd. 297 Carlisle, PA 17013 298 Email: rgm@icsa.net