idnits 2.17.1 draft-ietf-secsh-x509-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 375. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 381. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 201 has weird spacing: '... string rsa...' == Line 227 has weird spacing: '... string dss...' -- 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 (February 28, 2006) is 6625 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) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X509.2000' -- Possible downref: Non-RFC (?) normative reference: ref. 'RIPEMD-160' -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Shell Working Group O. Saarenmaa 3 Internet-Draft F-Secure 4 Expires: September 1, 2006 J. Galbraith 5 VanDyke Software 6 February 28, 2006 8 X.509 authentication in SSH 9 draft-ietf-secsh-x509-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 1, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document specifies how X.509 certificates and signatures are 43 used within the Secure Shell protocol for user and server 44 authentication. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 50 3. Certificate validation . . . . . . . . . . . . . . . . . . . . 3 51 3.1. Certificate Extensions . . . . . . . . . . . . . . . . . . 3 52 3.1.1. ExtendedKeyUsage . . . . . . . . . . . . . . . . . . . 3 53 3.2. Server Authentication . . . . . . . . . . . . . . . . . . 4 54 3.3. User Authentication . . . . . . . . . . . . . . . . . . . 4 55 4. Use in SSH Protocol . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. x509v3-sign . . . . . . . . . . . . . . . . . . . . . . . 4 57 4.2. x509v3-sign-rsa-sha1 . . . . . . . . . . . . . . . . . . . 5 58 4.3. x509v3-sign-dss-sha1 . . . . . . . . . . . . . . . . . . . 6 59 5. Implementation Considerations . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 66 Intellectual Property and Copyright Statements . . . . . . . . . . 10 68 1. Introduction 70 The Secure Shell protocol can use public keys for both server and 71 user authentication. However, particularly for server 72 authentication, plain public keys lack a good method of verifying 73 that the the key provided really does belong to the host asserting 74 ownership. X.509v3 certificates can address this problem in 75 environments where a PKI infrastructure is available. 77 2. Conventions Used in This Document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 3. Certificate validation 85 Implementations are expected to follow the basic certificate and 86 certificate path validation guidelines defined in [RFC3280]. This 87 document does not define any new X.509 certificate extensions. 89 Users deploying certificates have often had little control over the 90 capabilities of CAs available to them. Implementations of this 91 specification MAY include configuration knobs to disable checks 92 required by this specification in order to permit use with inflexible 93 and/or noncompliant CAs. Before disabling any checks the 94 administrators and users need to understand the purposes of those 95 checks as well as the security implications that may raise when they 96 are disabled. 98 3.1. Certificate Extensions 100 Implementations MUST recognize the following extensions: 101 BasicConstraints, KeyUsage, and SubjectAltName. Implementations also 102 MUST be able to handle all other extensions that have been marked 103 critical or reject the certificate. 105 3.1.1. ExtendedKeyUsage 107 Certificates meant for use within the SSH protocol SHOULD NOT include 108 the ExtendedKeyUsage extension. If the certificates require an EKU 109 extension because of use in another protocol or application, it is 110 RECOMMENDED to also specify the anyExtendedKeyUsage keyPurposeID 111 [RFC3280]. 113 Nevertheless, this document defines several ExtendedKeyUsage 114 keyPurposeID that MAY be used to limit a certificate's use. These 115 are id-kp-ssh-server, for use in server certificates, id-kp-ssh- 116 client for use in client (user) certificates, and id-kp-ssh- 117 clientHostbased for use in server certificates that can be used with 118 hostbased authentication [RFC4252]. The object identifiers are 119 listed below: 121 id-kp-ssh-server OBJECT IDENTIFIER 122 ::= { 1.3.6.1.4.1.2213.15.1.1 } 123 id-kp-ssh-client OBJECT IDENTIFIER 124 ::= { 1.3.6.1.4.1.2213.15.1.2 } 125 id-kp-ssh-clientHostbased OBJECT IDENTIFIER 126 ::= { 1.3.6.1.4.1.2213.15.1.3 } 128 3.2. Server Authentication 130 Implementations MUST validate the server host certificates by 131 matching the server's fully qualified domain name [RFC1034] against 132 the certificate's subjectAltName extension's dNSName entries. If the 133 certificate does not contain dNSName subjectAltName extensions, the 134 (most specific) Common Name field in the certificate Subject MUST be 135 used. This is similar to host validation in HTTP Over TLS [RFC2818]. 137 3.3. User Authentication 139 No constraints are placed on the presence of user account information 140 in the certificates used for user authentication. The mapping of 141 user certificates to user accounts is left as an implementation 142 choice and configuration issue for the implementors and deployers. 144 4. Use in SSH Protocol 146 This document defines three new key formats which are in the form 147 "x509v3-sign*". Each of the formats encodes the key type name in the 148 beginning of the key blob. 150 4.1. x509v3-sign 152 This is the most flexible key and signature format defined by the 153 document. It is RECOMMENDED that implementations prefer this 154 algorithm over the two other x509v3-sign* algorithms that this 155 document defines and may be supported. This format supports multiple 156 certificates in a chain as well as including OCSP-responses [RFC2560] 157 along with the certificate data. It also supports multiple different 158 hash algorithms for signatures. Keys using this format are encoded 159 as follows: 161 string "x509v3-sign" 162 uint32 number of certificates 163 string[1..] DER encoded X.509v3 certificate data 164 uint32 number of ocsp responses 165 string[0..] OCSP response data 167 The first certificate in the list MUST be the end-entity one, and any 168 other certificates MUST be part of the end-entity certificate's path. 170 Signatures are encoded as follows: 172 string "x509v3-sign" 173 string hash algorithm OID 174 string signature data 176 Possible hash algorithms include, but are not limited to, SHA1 177 (1.3.14.3.2.26) [FIPS-180-2], SHA256 (2.16.840.1.101.3.4.2.1) [FIPS- 178 180-2], MD5 (1.2.840.113549.2.5) [RFC1321] and RIPEMD160 179 (1.3.36.3.2.1) [RIPEMD-160]. 181 4.2. x509v3-sign-rsa-sha1 183 Certificates that use the RSA public key algorithm MAY use the 184 "x509v3-sign-rsa-sha1" key format. This key type uses the following 185 format: 187 string "x509v3-sign-rsa-sha1" 188 string DER encoded X.509v3 certificate data 190 Signing using this key format, uses the certificate's private key, in 191 exactly the same manner specified for "ssh-rsa" public keys in 192 [RFC4253]. That is to say, signing and verifying using this key 193 format is performed according to the RSASSA-PKCS1-v1_5 scheme in 194 [RFC3447] using the SHA-1 hash [FIPS-180-2]. 196 The signature format for x509v3-sign-rsa-sha1 certificates is the 197 "ssh-rsa" signing format specified in [RFC4253]. This format is as 198 follows: 200 string "ssh-rsa" 201 string rsa_signature_blob 203 The value for 'rsa_signature_blob' is encoded as a string containing 204 s (which is an integer, without lengths or padding, unsigned and in 205 network byte order). 207 4.3. x509v3-sign-dss-sha1 209 Certificates that use the DSA public key algorithm MAY use the 210 "x509v3-sign-rsa-sha1" key format. This key type uses the following 211 format: 213 string "x509v3-sign-dss-sha1" 214 string DER encoded X.509v3 certificate data 216 Signing and verifying using this key format, uses the certificate's 217 private key, in exactly the same manner specified for "ssh-dss" 218 public keys in [RFC4253]. That is to say, signing and verifying 219 using this key format is done according to the Digital Signature 220 Standard [FIPS-186-2] using the SHA-1 hash [FIPS-180-2]. 222 The signature format for x509v3-sign-dss-sha1 certificates is the 223 "ssh-dss" signing format specified in [RFC4253]. This format is as 224 follows: 226 string "ssh-dss" 227 string dss_signature_blob 229 The value for 'dss_signature_blob' is encoded as a string containing 230 r followed by s (which are 160-bit integers, without lengths or 231 padding, unsigned and in network byte order). 233 5. Implementation Considerations 235 Implementations should be careful when using X.509v3 certificates as 236 hostkeys. If the peer does not implement the required algorithms to 237 validate both the end-entity certificate and all certificates in the 238 chain, it MUST disconnect. There is no way to renegotiate the key 239 during key exchange. 241 This is especially true when using the "x509v3-sign" key type, since 242 in this case the peer has no knowledge whatsoever of required 243 algorithms. The peer might also refuse a "x509v3-sign" key if the 244 required intermediate certificates and OCSP responses are not 245 included. 247 6. IANA Considerations 249 This document reserves all key types beginning with "x509v3-sign" in 250 the SSH publickey type registry. 252 This document specifically adds "x509v3-sign-rsa-sha1", "x509v3-sign- 253 dss-sha1", and "x509v3-sign" to the SSH publickey type registry. 255 This document adds "x509v3-sign-rsa" and "x509v3-sign-dss" to the SSH 256 publickey type registry as "poisoned" by historical use. 258 7. Security Considerations 260 PKI is an extremely complex topic, and care must be taken by both 261 implementors and deployers to understand the complex interactions 262 involved. 264 This document suggests that validation of the ExtendedKeyUsage 265 extension MAY be disabled by configuration in the implementations. 266 Disabling validation of other extensions such as KeyUsage or 267 BasicConstraints MUST NOT be done, as that might lead into invalid 268 trust paths being established. 270 Implementations should carefully validate the certificate, including 271 but not limited to, certificate expiration, certificate signature, 272 certification revocation status etcetera. Implementations must also 273 be careful to validate all these properties of all certificates in 274 the path leading to a trust anchor. For more information 275 implementors should refer to [ITU.X509.2000] and [RFC3280]. 277 8. References 279 8.1. Normative References 281 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 282 April 1992. 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 288 Adams, "X.509 Internet Public Key Infrastructure Online 289 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 291 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 292 X.509 Public Key Infrastructure Certificate and 293 Certificate Revocation List (CRL) Profile", RFC 3280, 294 April 2002. 296 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 297 Standards (PKCS) #1: RSA Cryptography Specifications 298 Version 2.1", RFC 3447, February 2003. 300 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 301 Authentication Protocol", RFC 4252, January 2006. 303 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 304 Transport Layer Protocol", RFC 4253, January 2006. 306 [FIPS-180-2] 307 National Institute of Standards and Technology, "Secure 308 Hash Standard (SHS)", Federal Information Processing 309 Standards Publication 180-2, August 2002. 311 [FIPS-186-2] 312 National Institute of Standards and Technology, "Digital 313 Signature Standard (DSS)", Federal Information Processing 314 Standards Publication 186-2, January 2000. 316 [ITU.X509.2000] 317 International Telecommunications Union, "Information 318 technology - Open Systems Interconnection - The Directory: 319 Public-key and attribute certificate frameworks", ITU- 320 T Recommendation X.509, ISO Standard 9594-8, March 2000. 322 [RIPEMD-160] 323 Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD- 324 160: A Strengthened Version of RIPEMD", April 1996. 326 8.2. Informative References 328 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 329 STD 13, RFC 1034, November 1987. 331 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 333 Trademark notice 335 "ssh" is a registered trademark in the United States and/or other 336 countries. 338 Authors' Addresses 340 Oskari Saarenmaa 341 F-Secure 342 Tammasaarenkatu 7 343 PL 24 344 Helsinki 00181 345 FI 347 Email: oskari.saarenmaa@f-secure.com 349 Joseph Galbraith 350 VanDyke Software 351 4848 Tramway Ridge Blvd 352 Suite 101 353 Albuquerque, NM 87111 354 US 356 Phone: +1 505 332 5700 357 Email: galb-list@vandyke.com 359 Intellectual Property Statement 361 The IETF takes no position regarding the validity or scope of any 362 Intellectual Property Rights or other rights that might be claimed to 363 pertain to the implementation or use of the technology described in 364 this document or the extent to which any license under such rights 365 might or might not be available; nor does it represent that it has 366 made any independent effort to identify any such rights. Information 367 on the procedures with respect to rights in RFC documents can be 368 found in BCP 78 and BCP 79. 370 Copies of IPR disclosures made to the IETF Secretariat and any 371 assurances of licenses to be made available, or the result of an 372 attempt made to obtain a general license or permission for the use of 373 such proprietary rights by implementers or users of this 374 specification can be obtained from the IETF on-line IPR repository at 375 http://www.ietf.org/ipr. 377 The IETF invites any interested party to bring to its attention any 378 copyrights, patents or patent applications, or other proprietary 379 rights that may cover technology that may be required to implement 380 this standard. Please address the information to the IETF at 381 ietf-ipr@ietf.org. 383 Disclaimer of Validity 385 This document and the information contained herein are provided on an 386 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 387 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 388 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 389 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 390 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 391 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 393 Copyright Statement 395 Copyright (C) The Internet Society (2006). This document is subject 396 to the rights, licenses and restrictions contained in BCP 78, and 397 except as set forth therein, the authors retain all their rights. 399 Acknowledgment 401 Funding for the RFC Editor function is currently provided by the 402 Internet Society.