idnits 2.17.1 draft-ietf-secsh-x509-01.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 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 302. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 82: '... The client MAY verify that the serv...' RFC 2119 keyword, line 86: '... Implementations SHOULD validate the h...' RFC 2119 keyword, line 95: '... The server MAY verify that the clie...' RFC 2119 keyword, line 114: '...SA public key algorithm SHOULD use the...' RFC 2119 keyword, line 136: '...SA public key algorithm SHOULD use the...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 109 has weird spacing: '... string key...' == Line 128 has weird spacing: '... string rsa...' == Line 150 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 (April 19, 2005) is 6946 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: 6 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: October 21, 2005 O. Saarenmaa 5 F-Secure Corporation 6 April 19, 2005 8 X.509 authentication in SSH2 9 draft-ietf-secsh-x509-01.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 October 21, 2005. 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. Certificate validation . . . . . . . . . . . . . . . . . . . . 3 49 2.1 Host Authentication . . . . . . . . . . . . . . . . . . . 3 50 2.2 User Authentication . . . . . . . . . . . . . . . . . . . 3 51 3. Use in SSH2 Protocol . . . . . . . . . . . . . . . . . . . . . 3 52 3.1 x509v3-sign-rsa-sha1 . . . . . . . . . . . . . . . . . . . 4 53 3.2 x509v3-sign-dss-sha1 . . . . . . . . . . . . . . . . . . . 4 54 3.3 x509v3-sign . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Implementation Considerations . . . . . . . . . . . . . . . . 5 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 7.1 Normative References . . . . . . . . . . . . . . . . . . . 6 60 7.2 Informative References . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 62 Intellectual Property and Copyright Statements . . . . . . . . 8 64 1. Introduction 66 The SSH protocol can use public keys for both host and user 67 authentication. However, particularly for host authentication, plain 68 public keys lack a good method of verifying that the the key provided 69 really does belong to the host asserting ownership. X.509v3 70 certificates can address this problem in environments where a PKI 71 infrastructure is available. 73 2. Certificate validation 75 Implementations are expected to follow the basic certificate and 76 certificate path validation guidelines described in [RFC3280]. No 77 SSH specific X.509 certificate extensions are defined in this 78 document. 80 2.1 Host Authentication 82 The client MAY verify that the serverAuth option, as specified in 83 [RFC3280], is present in the host certificate's extendedKeyUsage 84 field. 86 Implementations SHOULD validate the host certificates by matching the 87 host's fully qualified domain name [RFC1034] against the host 88 certificate's subjectAltName extensions's dNSName entries. If the 89 certificate does not contain dNSName subjectAltName extensions, the 90 (most specific) Common Name field in the certificate Subject is to be 91 used. This is similiar to host validation in [RFC2818]. 93 2.2 User Authentication 95 The server MAY verify that the clientAuth option, as specified in 96 [RFC3280], is present in the user certificate's extendedKeyUsage 97 field. 99 No constraints are placed on the presence of user accounts in the 100 certificates used for user authentication. Their validation is left 101 as an implementation and configuration detail for the implementors 102 and deployers. 104 3. Use in SSH2 Protocol 106 Key type names are of the form "x509v3-sign*". Keys are encoded as 107 follows: 109 string key-type-name 110 string DER encoded x.509v3 certificate data 112 3.1 x509v3-sign-rsa-sha1 114 Certificates that use the RSA public key algorithm SHOULD use the 115 "x509v3-sign-rsa-sha1" key-type-name. 117 Signing and verifying using this key format, uses the certificate's 118 private key, in exactly the same manner specified for "ssh-rsa" 119 public keys in [I-D.ietf-secsh-transport]. That is to say, signing 120 and verifying using this key format is performed according to the 121 RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash. 123 The signature format for x509v3-sign-rsa-sha1 certificates is the 124 "ssh-rsa" signing format specified in [I-D.ietf-secsh-transport]. 125 This format is as follows: 127 string "ssh-rsa" 128 string rsa_signature_blob 130 The value for 'rsa_signature_blob' is encoded as a string containing 131 s (which is an integer, without lengths or padding, unsigned and in 132 network byte order). 134 3.2 x509v3-sign-dss-sha1 136 Certificates that use the DSA public key algorithm SHOULD use the 137 "x509v3-sign-dss-sha1" key-type-name. 139 Signing and verifying using this key format, uses the certificate's 140 private key, in exactly the same manner specified for "ssh-dss" 141 public keys in [I-D.ietf-secsh-transport]. That is to say, signing 142 and verifying using this key format is done according to the Digital 143 Signature Standard [FIPS-186-2] using the SHA-1 hash [FIPS-180-2]. 145 The signature format for x509v3-sign-dss-sha1 certificates is the 146 "ssh-dss" signing format specified in [I-D.ietf-secsh-transport]. 147 This format is as follows: 149 string "ssh-dss" 150 string dss_signature_blob 152 The value for 'dss_signature_blob' is encoded as a string containing 153 r followed by s (which are 160-bit integers, without lengths or 154 padding, unsigned and in network byte order). 156 3.3 x509v3-sign 158 Certificates that use another algorithm other than the two specified 159 above, MUST use the "x509v3-sign" key-type-name. 161 Signing and verifying is done according to the specification 162 associated with the public-key algorithm oid encoded in the 163 certificate. 165 The signature, and description of the signature algorithms is encoded 166 as specificied in [PKCS.7.1993]. The signature MUST be detached (the 167 signed data MUST NOT be includeded in the pkcs7 data). 169 The pkcs7 data is encoded in the SSH protocol as follows: 171 string "pkcs7" 172 string DER encoded PKCS7 data 174 4. Implementation Considerations 176 Implemenations should be careful when using x.509v3 certificates as 177 hostkeys. If the peer does not implement the required algorithms to 178 validate both the x.509v3 certificate and all certificates in the 179 chain, it MUST disconnect. There is no way to renegotiate the key 180 during key exchange. 182 This is especially true when using the "x509v3-sign" key type, since 183 in this case the peer has no knowledge whatsoever of required 184 algorithms. 186 5. IANA Considerations 188 This document reserves all key types beginning with "x509v3-sign" in 189 the SSH publickey type registery. 191 This document specifically adds "x509v3-sign-rsa-sha1", "x509v3-sign- 192 dss-sha1", and "x509v3-sign" to the SSH publickey type registry. 194 This document adds "x509v3-sign-rsa" and "x509v3-sign-dss" to the SSH 195 publickey type registry as "poisoned" by historical use. 197 6. Security Considerations 199 PKI is an extremely complex topic, and care must be taken by both 200 implementors and deployers to understand the complex interactions 201 involved. 203 Implementations should carefully validate the certificate, including, 204 but not limitted to, certificate expiration, certificate signature, 205 certificate revokation lists, etc. 207 For more information, implementors should refer to [ITU.X509.2000] 208 and [RFC3280]. 210 7. References 212 7.1 Normative References 214 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 215 X.509 Public Key Infrastructure Certificate and 216 Certificate Revocation List (CRL) Profile", RFC 3280, 217 April 2002. 219 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 220 Standards (PKCS) #1: RSA Cryptography Specifications 221 Version 2.1", RFC 3447, February 2003. 223 [I-D.ietf-secsh-transport] 224 Lonvick, C., "SSH Transport Layer Protocol", 225 draft-ietf-secsh-transport-24 (work in progress), 226 March 2005. 228 [PKCS.7.1993] 229 RSA Laboratories, "Cryptographic Message Syntax Standard. 230 Version 1.5", PKCS 7, November 1993. 232 [FIPS-180-2] 233 National Institute of Standards and Technology, "Secure 234 Hash Standard (SHS)", Federal Information Processing 235 Standards Publication 180-2, August 2002. 237 [FIPS-186-2] 238 National Institute of Standards and Technology, "Digital 239 Signature Standard (DSS)", Federal Information Processing 240 Standards Publication 186-2, January 2000. 242 [ITU.X509.2000] 243 International Telecommunications Union, "Information 244 technology - Open Systems Interconnection - The Directory: 245 Public-key and attribute certificate frameworks", ITU- 246 T Recommendation X.509, ISO Standard 9594-8, March 2000. 248 7.2 Informative References 250 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 251 STD 13, RFC 1034, November 1987. 253 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 255 Authors' Addresses 257 Joseph Galbraith 258 VanDyke Software 259 4848 Tramway Ridge Blvd 260 Suite 101 261 Albuquerque, NM 87111 262 US 264 Phone: +1 505 332 5700 265 Email: galb-list@vandyke.com 267 Oskari Saarenmaa 268 F-Secure Corporation 269 Tammasaarenkatu 7 270 Helsinki 00180 271 FI 273 Email: oskari.saarenmaa@f-secure.com 275 Trademark notice 277 "ssh" is a registered trademark in the United States and/or other 278 countries. 280 Intellectual Property Statement 282 The IETF takes no position regarding the validity or scope of any 283 Intellectual Property Rights or other rights that might be claimed to 284 pertain to the implementation or use of the technology described in 285 this document or the extent to which any license under such rights 286 might or might not be available; nor does it represent that it has 287 made any independent effort to identify any such rights. Information 288 on the procedures with respect to rights in RFC documents can be 289 found in BCP 78 and BCP 79. 291 Copies of IPR disclosures made to the IETF Secretariat and any 292 assurances of licenses to be made available, or the result of an 293 attempt made to obtain a general license or permission for the use of 294 such proprietary rights by implementers or users of this 295 specification can be obtained from the IETF on-line IPR repository at 296 http://www.ietf.org/ipr. 298 The IETF invites any interested party to bring to its attention any 299 copyrights, patents or patent applications, or other proprietary 300 rights that may cover technology that may be required to implement 301 this standard. Please address the information to the IETF at 302 ietf-ipr@ietf.org. 304 Disclaimer of Validity 306 This document and the information contained herein are provided on an 307 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 308 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 309 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 310 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 311 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 312 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 314 Copyright Statement 316 Copyright (C) The Internet Society (2005). This document is subject 317 to the rights, licenses and restrictions contained in BCP 78, and 318 except as set forth therein, the authors retain all their rights. 320 Acknowledgment 322 Funding for the RFC Editor function is currently provided by the 323 Internet Society.