idnits 2.17.1 draft-ietf-secsh-publickeyfile-10.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 397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 387. ** 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 5, 2005) is 6777 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 informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 8 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: April 8, 2006 R. Thayer 5 The Tillerman Group 6 October 5, 2005 8 SSH Public Key File Format 9 draft-ietf-secsh-publickeyfile-10.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 April 8, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document formally documents an existing public key file format 43 in use for exchanging public keys between different SSH 44 implementations. 46 Table of Contents 48 1. Conventions used in this document . . . . . . . . . . . . . . 3 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Key File Format . . . . . . . . . . . . . . . . . . . . . . . 5 51 3.1. Line Termination Characters . . . . . . . . . . . . . . . 5 52 3.2. Begin and End Markers . . . . . . . . . . . . . . . . . . 5 53 3.3. Key File Header . . . . . . . . . . . . . . . . . . . . . 5 54 3.3.1. Subject Header . . . . . . . . . . . . . . . . . . . . 6 55 3.3.2. Comment Header . . . . . . . . . . . . . . . . . . . . 6 56 3.3.3. New Headers . . . . . . . . . . . . . . . . . . . . . 6 57 3.4. Public Key File Body . . . . . . . . . . . . . . . . . . . 6 58 3.5. Differences with RFC1421 PEM formats . . . . . . . . . . . 7 59 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4. Public Key Fingerprints . . . . . . . . . . . . . . . . . . . 9 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 67 Intellectual Property and Copyright Statements . . . . . . . . . . 14 69 1. Conventions used in this document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 2. Introduction 77 The SSH protocol supports the use of public/private key pairs in 78 order to perform perform authentication based on public-key 79 cryptography. However, in order to use public-key authentication in 80 the SSH protocol, public keys must first be exchanged between client 81 and server. 83 This document formally describes an existing public-key file format 84 which can be used with any of the common existing file transfer 85 mechanisms in order to exchange public keys. 87 The SSH protocol also uses public/private key pairs to authenticate 88 the server. In this scenario, it is important to verify that the 89 public key provided by the server is indeed the server's public-key. 90 This document describes a mechanism for creating a short text string 91 that that uniquely represents a particular public key, called 92 fingerprinting. 94 3. Key File Format 96 In order to implement public key authentication, SSH implementations 97 must share public key files between the client and the server in 98 order to interoperate. 100 A key file is a text file, containing a sequence of lines. Each line 101 in the file MUST NOT be longer than 72 8-bit bytes excluding line 102 termination characters. 104 3.1. Line Termination Characters 106 Implementations SHOULD generate public key files using their system's 107 local text file representation. 109 In the event that public key files are not transferred as text files, 110 implementations SHOULD be prepared to read files using any of the 111 common line termination sequence, , or . 113 3.2. Begin and End Markers 115 The first line of a conforming key file MUST be a begin marker, which 116 is the literal text: 118 ---- BEGIN SSH2 PUBLIC KEY ---- 120 The last line of a conforming key file MUST be an end marker, which 121 is the literal text: 123 ---- END SSH2 PUBLIC KEY ---- 125 3.3. Key File Header 127 The key file header section consists of multiple RFC822-style header 128 fields. Each field is a line of the following format: 130 Header-tag ':' ' ' Header-value 132 The Header-tag MUST NOT be more than 64 8-bit bytes, and is case- 133 insensitive. The Header-value MUST NOT be more than 1024 8-bit 134 bytes. Each line in the header MUST NOT be more than 72 8-bit bytes. 136 A line is continued if the last character in the line is a '\'. If 137 the last character of a line is a '\', then the logical contents of 138 the line is formed by removing the '\' and the line termination 139 characters, and appending the contents of the next line. 141 The Header-tag MUST be encoded in US-ASCII. The Header-value MUST be 142 encoded in UTF-8. [RFC3629] 144 A line that is not a continuation line that has no ':' in it is the 145 first line of the base 64 encoded body (See Section 3.4.) 147 Compliant implementations MUST ignore unrecognized header fields. 148 Implementations SHOULD preserve unrecognized header fields when 149 manipulating the key file. 151 3.3.1. Subject Header 153 This field is used to store the login-name that the key was generated 154 under. For example: 156 Subject: user 158 3.3.2. Comment Header 160 The comment header contains a user specified comment. The comment 161 SHOULD be displayed when using the key. 163 It is suggested that this field default to user@hostname for the user 164 and machine used to generate the key. For example: 166 Comment: user@example.com 168 Currently, common practice is to quote the Header-value of the 169 Comment by prefixing and suffixing it with '"' characters, and some 170 existing implementations fail if these quotation marks are omitted 172 Compliant implementations MUST function correctly if the quotation 173 marks are omitted. 175 Implementations MAY include the quotation marks. If the first and 176 last characters of the Header-value are matching quotation marks, 177 implementations SHOULD remove them before using the value. 179 3.3.3. New Headers 181 New headers that are of the from "x-" are considered experimental, 182 and may be used without IETF consensus. 184 All other headers are reserved for use only by IETF consensus. 186 3.4. Public Key File Body 188 The body of a public key file consists of the public key blob as 189 described in [I-D.ietf-secsh-transport], section 4.6, "Public Key 190 Algorithms", encoded in base 64 as specified in [RFC2045], section 191 6.8, "Base64 Content-Transfer-Encoding". 193 As with all other lines, each line in the body MUST NOT be longer 194 than 72 8-bit bytes excluding line termination characters. 196 3.5. Differences with RFC1421 PEM formats 198 Implemetors should take care to notice that while the format is 199 superficially similar to those specified by PEM [RFC1421] and OpenPGP 200 [RFC2440], it is not identical; most notably: 202 o The other specifications use different BEGIN/END delimeters (five 203 dashes, no space rather than four dashes and a space). 205 o There is no blank line before the start of the base64-encoded 206 contents. 208 o There is no CRC at the end of the base64-encoded block. 210 o Header continuation uses a backslash at the end of the continued 211 line rather then whitespace at the start of the next line. 213 3.6. Examples 215 The following are some example public key files that are compliant 216 (note that the examples all wrap before 72 bytes to meet ietf 217 document requirements; however, they are still compliant.) 219 ---- BEGIN SSH2 PUBLIC KEY ---- 220 Comment: "1024-bit RSA, converted from OpenSSH by me@example.com" 221 x-command: /home/galb/bin/lock-in-guest.sh 222 AAAAB3NzaC1yc2EAAAABIwAAAIEA1on8gxCGJJWSRT4uOrR13mUaUk0hRf4RzxSZ1zRb 223 YYFw8pfGesIFoEuVth4HKyF8k1y4mRUnYHP1XNMNMJl1JcEArC2asV8sHf6zSPVffozZ 224 5TT4SfsUu/iKy9lUcCfXzwre4WWZSXXcPff+EHtWshahu3WzBdnGxm5Xoi89zcE= 225 ---- END SSH2 PUBLIC KEY ---- 226 ---- BEGIN SSH2 PUBLIC KEY ---- 227 Comment: This is my public key for use on \ 228 servers which I don't like. 229 AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET 230 W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH 231 YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c 232 vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf 233 J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA 234 vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB 235 AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS 236 n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 237 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV 238 ---- END SSH2 PUBLIC KEY ---- 240 ---- BEGIN SSH2 PUBLIC KEY ---- 241 Comment: DSA Public Key for use with MyIsp 242 AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET 243 W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH 244 YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c 245 vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf 246 J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA 247 vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB 248 AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS 249 n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 250 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV 251 ---- END SSH2 PUBLIC KEY ---- 253 ---- BEGIN SSH2 PUBLIC KEY ---- 254 Subject: galb 255 Comment: 1024-bit rsa, created by me@example.com Mon Jan 15 08:31:24 2001 256 AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt4 257 596k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4 258 soW6NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= 259 ---- END SSH2 PUBLIC KEY ---- 261 4. Public Key Fingerprints 263 The security of the SSH protocols relies on the verification of 264 public host keys. Since public keys tend to be very large, it is 265 difficult for a human to verify an entire host key. Even with a PKI 266 in place, it is useful to have a standard for exchanging short 267 fingerprints of public keys. 269 This section formally describes the method of generating public key 270 fingerprints that is in common use in the SSH community. 272 The fingerprint of a public key consists of the output of the MD5 273 message-digest algorithm [RFC1321]. The input to the algorithm is 274 the public key blob as described in [I-D.ietf-secsh-transport]. The 275 output of the algorithm is presented to the user as a sequence of 16 276 octets printed as hexadecimal with lowercase letters and separated by 277 colons. 279 For example: "c1:b1:30:29:d7:b8:de:6c:97:77:10:d7:46:41:63:87" 281 5. IANA Considerations 283 There are no IANA registries or other considerations associated with 284 this document. 286 6. Security Considerations 288 The file format described by this document provides no mechanism to 289 verify the integrity or otherwise detect tampering with the data 290 stored in such files. Given the potential of an adversarial 291 tampering with this data, system-specific measures (e.g. Access 292 Control Lists, UNIX permissions, other Discretionary and/or Mandatory 293 Access Controls) SHOULD be used to protect these files. Also, if the 294 contents of these files are transferred it SHOULD be done over a 295 trusted channel. 297 The header data allowed by this file format could contain an 298 unlimited range of information. While in many environments the 299 information conveyed by this header data may be considered innocuous 300 public information, it may constitute a channel through which 301 information about a user, a key or its use may be disclosed 302 intentionally or otherwise (e.g "Comment: Mary E. Jones, 123 Main St, 303 Home Phone:..."). The presence and use of this header data SHOULD be 304 reviewed by sites that deploy this file format. 306 The public-key fingerprint method presented here relies on the MD5 307 one-way hash function, which is known to have certain weaknesses 308 regarding its collision resistance; however, the particular use made 309 of MD5 here depends solely on its 2nd-preimage resistance, not on its 310 collision resistance. 312 MD5 is used here for historical reasons. 314 7. References 316 7.1. Normative References 318 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 319 April 1992. 321 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 322 Extensions (MIME) Part One: Format of Internet Message 323 Bodies", RFC 2045, November 1996. 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, March 1997. 328 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 329 10646", STD 63, RFC 3629, November 2003. 331 [I-D.ietf-secsh-transport] 332 Lonvick, C., "SSH Transport Layer Protocol", 333 draft-ietf-secsh-transport-24 (work in progress), 334 March 2005. 336 7.2. Informative References 338 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 339 Mail: Part I: Message Encryption and Authentication 340 Procedures", RFC 1421, February 1993. 342 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 343 "OpenPGP Message Format", RFC 2440, November 1998. 345 Authors' Addresses 347 Joseph Galbraith 348 VanDyke Software 349 4848 Tramway Ridge Blvd 350 Suite 101 351 Albuquerque, NM 87111 352 US 354 Phone: +1 505 332 5700 355 Email: galb-list@vandyke.com 357 Rodney Thayer 358 The Tillerman Group 359 370 Altair Way, PMB 321 360 Sunnyvale, CA 94086 362 Phone: +1 408 757 9693 363 Email: rodney@tillerman.to 365 Intellectual Property Statement 367 The IETF takes no position regarding the validity or scope of any 368 Intellectual Property Rights or other rights that might be claimed to 369 pertain to the implementation or use of the technology described in 370 this document or the extent to which any license under such rights 371 might or might not be available; nor does it represent that it has 372 made any independent effort to identify any such rights. Information 373 on the procedures with respect to rights in RFC documents can be 374 found in BCP 78 and BCP 79. 376 Copies of IPR disclosures made to the IETF Secretariat and any 377 assurances of licenses to be made available, or the result of an 378 attempt made to obtain a general license or permission for the use of 379 such proprietary rights by implementers or users of this 380 specification can be obtained from the IETF on-line IPR repository at 381 http://www.ietf.org/ipr. 383 The IETF invites any interested party to bring to its attention any 384 copyrights, patents or patent applications, or other proprietary 385 rights that may cover technology that may be required to implement 386 this standard. Please address the information to the IETF at 387 ietf-ipr@ietf.org. 389 Disclaimer of Validity 391 This document and the information contained herein are provided on an 392 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 393 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 394 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 395 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 396 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 397 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 399 Copyright Statement 401 Copyright (C) The Internet Society (2005). This document is subject 402 to the rights, licenses and restrictions contained in BCP 78, and 403 except as set forth therein, the authors retain all their rights. 405 Acknowledgment 407 Funding for the RFC Editor function is currently provided by the 408 Internet Society.