idnits 2.17.1 draft-ietf-secsh-x509-00.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 246. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 253. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 259. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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: '...SA public key algorithm SHOULD use the...' RFC 2119 keyword, line 104: '...SA public key algorithm SHOULD use the...' RFC 2119 keyword, line 127: '... above, MUST use the "x509v3-sign" k...' RFC 2119 keyword, line 134: '... [PKCS.7.1993]. The signature MUST be...' RFC 2119 keyword, line 135: '...(the signed data MUST NOT be includede...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 96 has weird spacing: '... string rsa...' == Line 118 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 (March 22, 2005) is 6973 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 3447 (Obsoleted by RFC 8017) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X509.2000' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-2' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 10 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: September 23, 2005 O. Saarenmaa 5 F-Secure 6 March 22, 2005 8 X.509 authentication in SSH2 9 draft-ietf-secsh-x509-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 23, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 The X.509 extension specifies how X.509 keys and signatures are used 45 within the SSH2 protocol. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. x509v3 keys . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.1 x509v3-sign-rsa2 . . . . . . . . . . . . . . . . . . . . . 4 52 2.2 x509v3-sign-dss2 . . . . . . . . . . . . . . . . . . . . . 4 53 2.3 x509v3-sign . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Implementation Considerations . . . . . . . . . . . . . . . . 6 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 6.1 Normative References . . . . . . . . . . . . . . . . . . . 9 59 6.2 Informative References . . . . . . . . . . . . . . . . . . 9 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 61 Intellectual Property and Copyright Statements . . . . . . . . 11 63 1. Introduction 65 The SSH protocol can use public keys for both host and user 66 authentication. However, particularly for host authentication, plain 67 public keys lack a good method of verifying that the the key provided 68 really does belong to the host asserting ownership. X.509v3 69 certificates can address this problem in environments where a PKI 70 infrastructure is available. 72 2. x509v3 keys 74 Key type names are of the form "x509v3-sign*". Keys are encoded as 75 follows: 77 string key-type-name 78 string DER encoded x.509v3 certificate data 80 2.1 x509v3-sign-rsa2 82 Certificates that use the RSA public key algorithm SHOULD use the 83 "x509v3-sign-rsa2" key-type-name. 85 Signing and verifying using this key format, uses the certificate's 86 private key, in exactly the same manner specified for "ssh-rsa" 87 public keys in [I-D.ietf-secsh-transport]. That is to say, signing 88 and verifying using this key format is performed according to the 89 RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash. 91 The signature format for x509v3-sign-rsa2 certificates is the 92 "ssh-rsa" signing format specified in [I-D.ietf-secsh-transport]. 93 This format is as follows: 95 string "ssh-rsa" 96 string rsa_signature_blob 98 The value for 'rsa_signature_blob' is encoded as a string containing 99 s (which is an integer, without lengths or padding, unsigned and in 100 network byte order). 102 2.2 x509v3-sign-dss2 104 Certificates that use the DSA public key algorithm SHOULD use the 105 "x509v3-sign-dss2" key-type-name. 107 Signing and verifying using this key format, uses the certificate's 108 private key, in exactly the same manner specified for "ssh-dss" 109 public keys in [I-D.ietf-secsh-transport]. That is to say, signing 110 and verifying using this key format is done according to the Digital 111 Signature Standard [FIPS-186-2] using the SHA-1 hash [FIPS-180-2]. 113 The signature format for x509v3-sign-rsa2 certificates is the 114 "ssh-dss" signing format specified in [I-D.ietf-secsh-transport]. 115 This format is as follows: 117 string "ssh-dss" 118 string dss_signature_blob 120 The value for 'dss_signature_blob' is encoded as a string containing 121 r followed by s (which are 160-bit integers, without lengths or 122 padding, unsigned and in network byte order). 124 2.3 x509v3-sign 126 Certificates that use another algorithm other than the two specified 127 above, MUST use the "x509v3-sign" key-type-name. 129 Signing and verifying is done according to the specification 130 associated with the public-key algorithm oid encoded in the 131 certificate. 133 The signature, and description of the signature algorithms is encoded 134 as specificied in pkcs7 [PKCS.7.1993]. The signature MUST be 135 detached (the signed data MUST NOT be includeded in the pkcs7 data. 137 The pkcs7 data is encoded in the SSH protocol as follows: 139 string "pkcs7" 140 string DER encoded PKCS7 data 142 3. Implementation Considerations 144 Implemenations SHOULD be careful when using x.509v3 certificates as 145 hostkeys. If the peer does not implement the required algorithms to 146 validate both the x.509v3 certificate and all certificates in the 147 chain, it MUST disconnect. There is no way to renegotiate the key 148 during key exchange. 150 This is especially true when using the "x509v3-sign" key type, since 151 in this case the peer has no knowledge whatsoever of required 152 algorithms. 154 4. IANA Considerations 156 This document reserves all key types beginning with "x509v3-sign" in 157 the SSH publickey type registery. 159 This document specifically adds "x509v3-sign-rsa2", 160 "x509v3-sign-dss2", and "x509v3-sign" to the SSH publickey type 161 registry. 163 This document adds "x509v3-sign-rsa" and "x509v3-sign-dss" to the SSH 164 publickey type registry as "poisoned" by historical use. 166 5. Security Considerations 168 PKI is an extremely complex topic, and care MUST be taken by both 169 implementors and deployers to understand the complex interactions 170 involved. 172 Implementations SHOULD carefully validate the certificate, including, 173 but not limitted to, certificate expiration, certificate signature, 174 certificate revokation lists, etc. 176 For more information, implementors should refer to [ITU.X509.2000] 177 and [RFC3820]. 179 6. References 181 6.1 Normative References 183 [I-D.ietf-secsh-transport] 184 Lonvick, C., "SSH Transport Layer Protocol", 185 Internet-Draft draft-ietf-secsh-transport-24, March 2005. 187 [PKCS.7.1993] 188 RSA Laboratories, "Cryptographic Message Syntax Standard. 189 Version 1.5", PKCS 7, November 1993. 191 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 192 Standards (PKCS) #1: RSA Cryptography Specifications 193 Version 2.1", RFC 3447, February 2003. 195 [RFC3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L. and M. 196 Thompson, "Internet X.509 Public Key Infrastructure (PKI) 197 Proxy Certificate Profile", RFC 3820, June 2004. 199 [ITU.X509.2000] 200 International Telecommunications Union, "Information 201 technology - Open Systems Interconnection - The Directory: 202 Public-key and attribute certificate frameworks", 203 ITU-T Recommendation X.509, ISO Standard 9594-8, March 204 2000. 206 [FIPS-180-2] 207 National Institute of Standards and Technology, "Secure 208 Hash Standard (SHS)", Federal Information Processing 209 Standards Publication 180-2, August 2002. 211 [FIPS-186-2] 212 National Institute of Standards and Technology, "Digital 213 Signature Standard (DSS)", Federal Information Processing 214 Standards Publication 186-2, January 2000. 216 6.2 Informative References 217 Authors' Addresses 219 Joseph Galbraith 220 VanDyke Software 221 4848 Tramway Ridge Blvd 222 Suite 101 223 Albuquerque, NM 87111 224 US 226 Phone: +1 505 332 5700 227 Email: galb-list@vandyke.com 229 Oskari Saarenmaa 230 F-Secure 231 A Street Address 232 A City, State or Region A Postal Code 233 FI 235 Email: oskari.saarenmaa@f-secure.com 237 Intellectual Property Statement 239 The IETF takes no position regarding the validity or scope of any 240 Intellectual Property Rights or other rights that might be claimed to 241 pertain to the implementation or use of the technology described in 242 this document or the extent to which any license under such rights 243 might or might not be available; nor does it represent that it has 244 made any independent effort to identify any such rights. Information 245 on the procedures with respect to rights in RFC documents can be 246 found in BCP 78 and BCP 79. 248 Copies of IPR disclosures made to the IETF Secretariat and any 249 assurances of licenses to be made available, or the result of an 250 attempt made to obtain a general license or permission for the use of 251 such proprietary rights by implementers or users of this 252 specification can be obtained from the IETF on-line IPR repository at 253 http://www.ietf.org/ipr. 255 The IETF invites any interested party to bring to its attention any 256 copyrights, patents or patent applications, or other proprietary 257 rights that may cover technology that may be required to implement 258 this standard. Please address the information to the IETF at 259 ietf-ipr@ietf.org. 261 Disclaimer of Validity 263 This document and the information contained herein are provided on an 264 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 265 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 266 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 267 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 268 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 269 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 271 Copyright Statement 273 Copyright (C) The Internet Society (2005). This document is subject 274 to the rights, licenses and restrictions contained in BCP 78, and 275 except as set forth therein, the authors retain all their rights. 277 Acknowledgment 279 Funding for the RFC Editor function is currently provided by the 280 Internet Society.