idnits 2.17.1 draft-saarenmaa-ssh-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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 253. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 277. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 119 has weird spacing: '... string rsa...' == Line 143 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 7, 2007) is 6288 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Saarenmaa 3 Internet-Draft F-Secure 4 Intended status: Informational J. Galbraith 5 Expires: August 11, 2007 VanDyke Software 6 February 7, 2007 8 X.509 authentication in SSH 9 draft-saarenmaa-ssh-x509-00.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 August 11, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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 4. Use in SSH Protocol . . . . . . . . . . . . . . . . . . . . . . 3 52 4.1. x509v3-sign-rsa . . . . . . . . . . . . . . . . . . . . . . 3 53 4.2. x509v3-sign-dss . . . . . . . . . . . . . . . . . . . . . . 4 54 5. Implementation Considerations . . . . . . . . . . . . . . . . . 4 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 59 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 61 Intellectual Property and Copyright Statements . . . . . . . . . . 7 63 1. Introduction 65 The Secure Shell protocol can use public keys for both server and 66 user authentication. However, particularly for server 67 authentication, plain public keys lack a good method of verifying 68 that the the key provided really does belong to the host asserting 69 ownership. X.509v3 certificates can address this problem in 70 environments where a PKI infrastructure is available. 72 2. Conventions Used in This Document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 3. Certificate validation 80 Implementations are expected to follow the basic certificate and 81 certificate path validation guidelines defined in [RFC3280]. This 82 document does not define new X.509v3 extensions. 84 Users deploying certificates have often had little control over the 85 capabilities of CAs available to them. Implementations of this 86 specification MAY include configuration knobs to disable checks 87 required by this specification in order to permit use with inflexible 88 and/or noncompliant CAs. Before disabling any checks the 89 administrators and users need to understand the purposes of those 90 checks as well as the security implications that may raise when they 91 are disabled. 93 4. Use in SSH Protocol 95 Key type names are of the form "x509v3-sign*". This document defines 96 two new key formats. As opposed to formats defined in [RFC4253], 97 these new formats do NOT include the key type or length of any fields 98 inside the key blob. Implementations are expected to have obtained 99 these values out-of-band. 101 4.1. x509v3-sign-rsa 103 Certificates that use the RSA public key algorithm MUST use the 104 "x509v3-sign-rsa" key format. This format is as follows: 106 byte[n] DER encoded X.509v3 certificate data 108 Signing using this key format, uses the certificate's private key, in 109 exactly the same manner specified for "ssh-rsa" public keys in 110 [RFC4253]. That is to say, signing and verifying using this key 111 format is performed according to the RSASSA-PKCS1-v1_5 scheme in 112 [RFC3447] using the SHA-1 hash [FIPS-180-2]. 114 The signature format for x509v3-sign-rsa-sha1 certificates is the 115 "ssh-rsa" signing format specified in [RFC4253]. This format is as 116 follows: 118 string "ssh-rsa" 119 string rsa_signature_blob 121 The value for 'rsa_signature_blob' is encoded as a string containing 122 s (which is an integer, without lengths or padding, unsigned and in 123 network byte order). 125 4.2. x509v3-sign-dss 127 Certificates that use the DSA public key algorithm MUST use the 128 "x509v3-sign-dss" key format. This format is as follows: 130 byte[n] DER encoded X.509v3 certificate data 132 Signing and verifying using this key format, uses the certificate's 133 private key, in exactly the same manner specified for "ssh-dss" 134 public keys in [RFC4253]. That is to say, signing and verifying 135 using this key format is done according to the Digital Signature 136 Standard [FIPS-186-2] using the SHA-1 hash [FIPS-180-2]. 138 The signature format for x509v3-sign-dss-sha1 certificates is the 139 "ssh-dss" signing format specified in [RFC4253]. This format is as 140 follows: 142 string "ssh-dss" 143 string dss_signature_blob 145 The value for 'dss_signature_blob' is encoded as a string containing 146 r followed by s (which are 160-bit integers, without lengths or 147 padding, unsigned and in network byte order). 149 5. Implementation Considerations 151 Implementations should be careful when using X.509v3 certificates as 152 hostkeys. If the peer does not implement the required algorithms to 153 validate both the end-entity certificate and all certificates in the 154 chain, it MUST disconnect. There is no way to renegotiate the key 155 during key exchange. 157 6. IANA Considerations 159 This document adds "x509v3-sign-rsa" and "x509v3-sign-dss" to the SSH 160 publickey type registry. 162 7. Security Considerations 164 PKI is an extremely complex topic, and care must be taken by both 165 implementors and deployers to understand the complex interactions 166 involved. This document intentionally leaves the details of 167 certificate validation and PKI profile to use unspecified. 169 Implementations should carefully validate the certificate, including 170 but not limited to, certificate expiration, certificate signature, 171 certification revocation status etcetera. Implementations must also 172 be careful to validate all these properties of all certificates in 173 the path leading to a trust anchor. For more information 174 implementors should refer to [ITU.X509.2000] and [RFC3280]. 176 8. References 178 8.1. Normative References 180 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 181 Requirement Levels", BCP 14, RFC 2119, March 1997. 183 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 184 Standards (PKCS) #1: RSA Cryptography Specifications 185 Version 2.1", RFC 3447, February 2003. 187 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 188 Transport Layer Protocol", RFC 4253, January 2006. 190 [FIPS-180-2] 191 National Institute of Standards and Technology, "Secure 192 Hash Standard (SHS)", Federal Information Processing 193 Standards Publication 180-2, August 2002. 195 [FIPS-186-2] 196 National Institute of Standards and Technology, "Digital 197 Signature Standard (DSS)", Federal Information Processing 198 Standards Publication 186-2, January 2000. 200 8.2. Informative References 202 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 203 X.509 Public Key Infrastructure Certificate and 204 Certificate Revocation List (CRL) Profile", RFC 3280, 205 April 2002. 207 [ITU.X509.2000] 208 International Telecommunications Union, "Information 209 technology - Open Systems Interconnection - The Directory: 210 Public-key and attribute certificate frameworks", ITU- 211 T Recommendation X.509, ISO Standard 9594-8, March 2000. 213 Trademark notice 215 "ssh" is a registered trademark in the United States and/or other 216 countries. 218 Authors' Addresses 220 Oskari Saarenmaa 221 F-Secure 222 Tammasaarenkatu 7 223 PL 24 224 Helsinki 00181 225 FI 227 Email: oskari.saarenmaa@f-secure.com 229 Joseph Galbraith 230 VanDyke Software 231 4848 Tramway Ridge Blvd 232 Suite 101 233 Albuquerque, NM 87111 234 US 236 Phone: +1 505 332 5700 237 Email: galb-list@vandyke.com 239 Full Copyright Statement 241 Copyright (C) The IETF Trust (2007). 243 This document is subject to the rights, licenses and restrictions 244 contained in BCP 78, and except as set forth therein, the authors 245 retain all their rights. 247 This document and the information contained herein are provided on an 248 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 249 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 250 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 251 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 252 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 253 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 255 Intellectual Property 257 The IETF takes no position regarding the validity or scope of any 258 Intellectual Property Rights or other rights that might be claimed to 259 pertain to the implementation or use of the technology described in 260 this document or the extent to which any license under such rights 261 might or might not be available; nor does it represent that it has 262 made any independent effort to identify any such rights. Information 263 on the procedures with respect to rights in RFC documents can be 264 found in BCP 78 and BCP 79. 266 Copies of IPR disclosures made to the IETF Secretariat and any 267 assurances of licenses to be made available, or the result of an 268 attempt made to obtain a general license or permission for the use of 269 such proprietary rights by implementers or users of this 270 specification can be obtained from the IETF on-line IPR repository at 271 http://www.ietf.org/ipr. 273 The IETF invites any interested party to bring to its attention any 274 copyrights, patents or patent applications, or other proprietary 275 rights that may cover technology that may be required to implement 276 this standard. Please address the information to the IETF at 277 ietf-ipr@ietf.org. 279 Acknowledgment 281 Funding for the RFC Editor function is provided by the IETF 282 Administrative Support Activity (IASA).