idnits 2.17.1 draft-ietf-secsh-x509-02.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 322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 299. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 306. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 312. ** 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 116 has weird spacing: '... string key...' == Line 135 has weird spacing: '... string rsa...' == Line 157 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 (July 15, 2005) is 6852 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 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' -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Shell Working Group J. Galbraith 3 Internet-Draft VanDyke Software 4 Expires: January 16, 2006 O. Saarenmaa 5 F-Secure Corporation 6 July 15, 2005 8 X.509 authentication in SSH2 9 draft-ietf-secsh-x509-02.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 January 16, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The X.509 extension specifies how X.509 keys and signatures are used 43 within the SSH2 protocol. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 49 3. Certificate validation . . . . . . . . . . . . . . . . . . . . 3 50 3.1 Host Authentication . . . . . . . . . . . . . . . . . . . 3 51 3.2 User Authentication . . . . . . . . . . . . . . . . . . . 3 52 4. Use in SSH2 Protocol . . . . . . . . . . . . . . . . . . . . . 4 53 4.1 x509v3-sign-rsa-sha1 . . . . . . . . . . . . . . . . . . . 4 54 4.2 x509v3-sign-dss-sha1 . . . . . . . . . . . . . . . . . . . 4 55 4.3 x509v3-sign . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Implementation Considerations . . . . . . . . . . . . . . . . 5 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 8.1 Normative References . . . . . . . . . . . . . . . . . . . 6 61 8.2 Informative References . . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 63 Intellectual Property and Copyright Statements . . . . . . . . 8 65 1. Introduction 67 The SSH protocol can use public keys for both host and user 68 authentication. However, particularly for host authentication, plain 69 public keys lack a good method of verifying that the the key provided 70 really does belong to the host asserting ownership. X.509v3 71 certificates can address this problem in environments where a PKI 72 infrastructure is available. 74 2. Conventions Used in This Document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 3. Certificate validation 82 Implementations are expected to follow the basic certificate and 83 certificate path validation guidelines described in [RFC3280]. No 84 SSH specific X.509 certificate extensions are defined in this 85 document. 87 3.1 Host Authentication 89 The client MAY verify that the serverAuth option, as specified in 90 [RFC3280], is present in the host certificate's extendedKeyUsage 91 field. 93 Implementations SHOULD validate the host certificates by matching the 94 host's fully qualified domain name [RFC1034] against the host 95 certificate's subjectAltName extension's dNSName entries. If the 96 certificate does not contain dNSName subjectAltName extensions, the 97 (most specific) Common Name field in the certificate Subject is to be 98 used. This is similar to host validation in [RFC2818]. 100 3.2 User Authentication 102 The server MAY verify that the clientAuth option, as specified in 103 [RFC3280], is present in the user certificate's extendedKeyUsage 104 field. 106 No constraints are placed on the presence of user account information 107 in the certificates used for user authentication. Their validation 108 and mapping is left as an implementation and configuration detail for 109 the implementors and deployers. 111 4. Use in SSH2 Protocol 113 Key type names are of the form "x509v3-sign*". Keys are encoded as 114 follows: 116 string key-type-name 117 string DER encoded x.509v3 certificate data 119 4.1 x509v3-sign-rsa-sha1 121 Certificates that use the RSA public key algorithm SHOULD use the 122 "x509v3-sign-rsa-sha1" key-type-name. 124 Signing and verifying using this key format, uses the certificate's 125 private key, in exactly the same manner specified for "ssh-rsa" 126 public keys in [I-D.ietf-secsh-transport]. That is to say, signing 127 and verifying using this key format is performed according to the 128 RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash. 130 The signature format for x509v3-sign-rsa-sha1 certificates is the 131 "ssh-rsa" signing format specified in [I-D.ietf-secsh-transport]. 132 This format is as follows: 134 string "ssh-rsa" 135 string rsa_signature_blob 137 The value for 'rsa_signature_blob' is encoded as a string containing 138 s (which is an integer, without lengths or padding, unsigned and in 139 network byte order). 141 4.2 x509v3-sign-dss-sha1 143 Certificates that use the DSA public key algorithm SHOULD use the 144 "x509v3-sign-dss-sha1" key-type-name. 146 Signing and verifying using this key format, uses the certificate's 147 private key, in exactly the same manner specified for "ssh-dss" 148 public keys in [I-D.ietf-secsh-transport]. That is to say, signing 149 and verifying using this key format is done according to the Digital 150 Signature Standard [FIPS-186-2] using the SHA-1 hash [FIPS-180-2]. 152 The signature format for x509v3-sign-dss-sha1 certificates is the 153 "ssh-dss" signing format specified in [I-D.ietf-secsh-transport]. 154 This format is as follows: 156 string "ssh-dss" 157 string dss_signature_blob 159 The value for 'dss_signature_blob' is encoded as a string containing 160 r followed by s (which are 160-bit integers, without lengths or 161 padding, unsigned and in network byte order). 163 4.3 x509v3-sign 165 Certificates that use another algorithm other than the two specified 166 above, MUST use the "x509v3-sign" key-type-name. 168 Signing and verifying is done according to the specification 169 associated with the public-key algorithm oid encoded in the 170 certificate. 172 The signature, and description of the signature algorithms is encoded 173 as specified in [PKCS.7.1993]. The signature MUST be detached (the 174 signed data MUST NOT be included in the pkcs7 data). 176 The pkcs7 data is encoded in the SSH protocol as follows: 178 string "pkcs7" 179 string DER encoded PKCS7 data 181 5. Implementation Considerations 183 Implementations should be careful when using x.509v3 certificates as 184 hostkeys. If the peer does not implement the required algorithms to 185 validate both the x.509v3 certificate and all certificates in the 186 chain, it MUST disconnect. There is no way to renegotiate the key 187 during key exchange. 189 This is especially true when using the "x509v3-sign" key type, since 190 in this case the peer has no knowledge whatsoever of required 191 algorithms. 193 6. IANA Considerations 195 This document reserves all key types beginning with "x509v3-sign" in 196 the SSH publickey type registry. 198 This document specifically adds "x509v3-sign-rsa-sha1", "x509v3-sign- 199 dss-sha1", and "x509v3-sign" to the SSH publickey type registry. 201 This document adds "x509v3-sign-rsa" and "x509v3-sign-dss" to the SSH 202 publickey type registry as "poisoned" by historical use. 204 7. Security Considerations 206 PKI is an extremely complex topic, and care must be taken by both 207 implementors and deployers to understand the complex interactions 208 involved. 210 Implementations should carefully validate the certificate, including, 211 but not limited to, certificate expiration, certificate signature, 212 certificate revocation lists, etc. 214 For more information, implementors should refer to [ITU.X509.2000] 215 and [RFC3280]. 217 8. References 219 8.1 Normative References 221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", BCP 14, RFC 2119, March 1997. 224 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 225 X.509 Public Key Infrastructure Certificate and 226 Certificate Revocation List (CRL) Profile", RFC 3280, 227 April 2002. 229 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 230 Standards (PKCS) #1: RSA Cryptography Specifications 231 Version 2.1", RFC 3447, February 2003. 233 [I-D.ietf-secsh-transport] 234 Lonvick, C., "SSH Transport Layer Protocol", 235 draft-ietf-secsh-transport-24 (work in progress), 236 March 2005. 238 [PKCS.7.1993] 239 RSA Laboratories, "Cryptographic Message Syntax Standard. 240 Version 1.5", PKCS 7, November 1993. 242 [FIPS-180-2] 243 National Institute of Standards and Technology, "Secure 244 Hash Standard (SHS)", Federal Information Processing 245 Standards Publication 180-2, August 2002. 247 [FIPS-186-2] 248 National Institute of Standards and Technology, "Digital 249 Signature Standard (DSS)", Federal Information Processing 250 Standards Publication 186-2, January 2000. 252 [ITU.X509.2000] 253 International Telecommunications Union, "Information 254 technology - Open Systems Interconnection - The Directory: 255 Public-key and attribute certificate frameworks", ITU- 256 T Recommendation X.509, ISO Standard 9594-8, March 2000. 258 8.2 Informative References 260 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 261 STD 13, RFC 1034, November 1987. 263 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 265 Authors' Addresses 267 Joseph Galbraith 268 VanDyke Software 269 4848 Tramway Ridge Blvd 270 Suite 101 271 Albuquerque, NM 87111 272 US 274 Phone: +1 505 332 5700 275 Email: galb-list@vandyke.com 277 Oskari Saarenmaa 278 F-Secure Corporation 279 Tammasaarenkatu 7 280 Helsinki 00180 281 FI 283 Email: oskari.saarenmaa@f-secure.com 285 Trademark notice 287 "ssh" is a registered trademark in the United States and/or other 288 countries. 290 Intellectual Property Statement 292 The IETF takes no position regarding the validity or scope of any 293 Intellectual Property Rights or other rights that might be claimed to 294 pertain to the implementation or use of the technology described in 295 this document or the extent to which any license under such rights 296 might or might not be available; nor does it represent that it has 297 made any independent effort to identify any such rights. Information 298 on the procedures with respect to rights in RFC documents can be 299 found in BCP 78 and BCP 79. 301 Copies of IPR disclosures made to the IETF Secretariat and any 302 assurances of licenses to be made available, or the result of an 303 attempt made to obtain a general license or permission for the use of 304 such proprietary rights by implementers or users of this 305 specification can be obtained from the IETF on-line IPR repository at 306 http://www.ietf.org/ipr. 308 The IETF invites any interested party to bring to its attention any 309 copyrights, patents or patent applications, or other proprietary 310 rights that may cover technology that may be required to implement 311 this standard. Please address the information to the IETF at 312 ietf-ipr@ietf.org. 314 Disclaimer of Validity 316 This document and the information contained herein are provided on an 317 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 318 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 319 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 320 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 321 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 322 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 324 Copyright Statement 326 Copyright (C) The Internet Society (2005). This document is subject 327 to the rights, licenses and restrictions contained in BCP 78, and 328 except as set forth therein, the authors retain all their rights. 330 Acknowledgment 332 Funding for the RFC Editor function is currently provided by the 333 Internet Society.