idnits 2.17.1 draft-ietf-secsh-publickeyfile-12.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 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 408. ** 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 == Line 194 has weird spacing: '... string cer...' -- 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 1, 2006) is 6602 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 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 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 2, 2006 R. Thayer 5 The Tillerman Group 6 March 1, 2006 8 SSH Public Key File Format 9 draft-ietf-secsh-publickeyfile-12.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 September 2, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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 In addition, this document defines a standard textual representation 47 for SSH public key fingerprints. 49 Table of Contents 51 1. Conventions used in this document . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Key File Format . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1. Line Termination Characters . . . . . . . . . . . . . . . 5 55 3.2. Begin and End Markers . . . . . . . . . . . . . . . . . . 5 56 3.3. Key File Header . . . . . . . . . . . . . . . . . . . . . 5 57 3.3.1. Subject Header . . . . . . . . . . . . . . . . . . . . 6 58 3.3.2. Comment Header . . . . . . . . . . . . . . . . . . . . 6 59 3.3.3. Private Use Headers . . . . . . . . . . . . . . . . . 6 60 3.4. Public Key File Body . . . . . . . . . . . . . . . . . . . 6 61 3.5. Differences with RFC1421 PEM formats . . . . . . . . . . . 7 62 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4. Public Key Fingerprints . . . . . . . . . . . . . . . . . . . 9 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 70 Intellectual Property and Copyright Statements . . . . . . . . . . 14 72 1. 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 2. Introduction 80 The SSH protocol supports the use of public/private key pairs in 81 order to perform perform authentication based on public-key 82 cryptography. However, in order to use public-key authentication in 83 the SSH protocol, public keys must first be exchanged between client 84 and server. 86 This document formally describes an existing public-key file format 87 which can be used with any of the common existing file transfer 88 mechanisms in order to exchange public keys. 90 The SSH protocol also uses public/private key pairs to authenticate 91 the server. In this scenario, it is important to verify that the 92 public key provided by the server is indeed the server's public-key. 93 This document describes a mechanism for creating a short text string 94 that uniquely represents a particular public key, called 95 fingerprinting. 97 3. Key File Format 99 In order to implement public key authentication, SSH implementations 100 must share public key files between the client and the server in 101 order to interoperate. 103 A key file is a text file, containing a sequence of lines. Each line 104 in the file MUST NOT be longer than 72 8-bit bytes excluding line 105 termination characters. 107 3.1. Line Termination Characters 109 Implementations SHOULD generate public key files using their system's 110 local text file representation. 112 In the event that public key files are not transferred as text files, 113 implementations SHOULD be prepared to read files using any of the 114 common line termination sequence, , or . 116 3.2. Begin and End Markers 118 The first line of a conforming key file MUST be a begin marker, which 119 is the literal text: 121 ---- BEGIN SSH2 PUBLIC KEY ---- 123 The last line of a conforming key file MUST be an end marker, which 124 is the literal text: 126 ---- END SSH2 PUBLIC KEY ---- 128 3.3. Key File Header 130 The key file header section consists of multiple RFC822-style header 131 fields. Each field is a line of the following format: 133 Header-tag ':' ' ' Header-value 135 The Header-tag MUST NOT be more than 64 8-bit bytes, and is case- 136 insensitive. The Header-value MUST NOT be more than 1024 8-bit 137 bytes. Each line in the header MUST NOT be more than 72 8-bit bytes. 139 A line is continued if the last character in the line is a '\'. If 140 the last character of a line is a '\', then the logical contents of 141 the line is formed by removing the '\' and the line termination 142 characters, and appending the contents of the next line. 144 The Header-tag MUST be encoded in US-ASCII. The Header-value MUST be 145 encoded in UTF-8. [RFC3629] 147 A line that is not a continuation line that has no ':' in it is the 148 first line of the base 64 encoded body (See Section 3.4.) 150 The space of header-tags is managed as described in Section 5. 152 Compliant implementations MUST ignore headers with unrecognized 153 header-tags. Implementations SHOULD preserve such unrecognized 154 headers when manipulating the key file. 156 3.3.1. Subject Header 158 This field is used to store the login-name that the key was generated 159 under. For example: 161 Subject: user 163 3.3.2. Comment Header 165 The comment header contains a user specified comment. The comment 166 SHOULD be displayed when using the key. 168 It is suggested that this field default to user@hostname for the user 169 and machine used to generate the key. For example: 171 Comment: user@example.com 173 Currently, common practice is to quote the Header-value of the 174 Comment by prefixing and suffixing it with '"' characters, and some 175 existing implementations fail if these quotation marks are omitted. 177 Compliant implementations MUST function correctly if the quotation 178 marks are omitted. 180 Implementations MAY include the quotation marks. If the first and 181 last characters of the Header-value are matching quotation marks, 182 implementations SHOULD remove them before using the value. 184 3.3.3. Private Use Headers 186 Headers with header-tags beginning with "x-" are reserved for private 187 use. 189 3.4. Public Key File Body 191 The body of a public-key file is the base64 encoded ([RFC2045]) 192 public-key data as specified by [RFC4253], section 6.6: 194 string certificate or public key format identifier 195 byte[n] key/certificate data 197 As with all other lines, each line in the body MUST NOT be longer 198 than 72 8-bit bytes excluding line termination characters. 200 3.5. Differences with RFC1421 PEM formats 202 Implementers should take care to notice that while the format is 203 superficially similar to those specified by PEM [RFC1421] and OpenPGP 204 [RFC2440], it is not identical; most notably: 206 o The other specifications use different BEGIN/END delimiters (five 207 dashes, no space rather than four dashes and a space). 209 o There is no blank line before the start of the base64-encoded 210 contents. 212 o There is no CRC at the end of the base64-encoded block. 214 o Header continuation uses a backslash at the end of the continued 215 line rather then whitespace at the start of the next line. 217 3.6. Examples 219 The following are some example public key files that are compliant 220 (note that the examples all wrap before 72 bytes to meet ietf 221 document requirements; however, they are still compliant.) 223 ---- BEGIN SSH2 PUBLIC KEY ---- 224 Comment: "1024-bit RSA, converted from OpenSSH by me@example.com" 225 x-command: /home/galb/bin/lock-in-guest.sh 226 AAAAB3NzaC1yc2EAAAABIwAAAIEA1on8gxCGJJWSRT4uOrR13mUaUk0hRf4RzxSZ1zRb 227 YYFw8pfGesIFoEuVth4HKyF8k1y4mRUnYHP1XNMNMJl1JcEArC2asV8sHf6zSPVffozZ 228 5TT4SfsUu/iKy9lUcCfXzwre4WWZSXXcPff+EHtWshahu3WzBdnGxm5Xoi89zcE= 229 ---- END SSH2 PUBLIC KEY ---- 230 ---- BEGIN SSH2 PUBLIC KEY ---- 231 Comment: This is my public key for use on \ 232 servers which I don't like. 233 AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET 234 W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH 235 YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c 236 vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf 237 J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA 238 vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB 239 AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS 240 n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 241 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV 242 ---- END SSH2 PUBLIC KEY ---- 244 ---- BEGIN SSH2 PUBLIC KEY ---- 245 Comment: DSA Public Key for use with MyIsp 246 AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET 247 W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH 248 YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c 249 vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf 250 J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA 251 vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB 252 AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS 253 n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 254 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV 255 ---- END SSH2 PUBLIC KEY ---- 257 ---- BEGIN SSH2 PUBLIC KEY ---- 258 Subject: galb 259 Comment: 1024-bit rsa, created by me@example.com Mon Jan 15 08:31:24 2001 260 AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt4 261 596k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4 262 soW6NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= 263 ---- END SSH2 PUBLIC KEY ---- 265 4. Public Key Fingerprints 267 The security of the SSH protocols relies on the verification of 268 public host keys. Since public keys tend to be very large, it is 269 difficult for a human to verify an entire host key. Even with a PKI 270 in place, it is useful to have a standard for exchanging short 271 fingerprints of public keys. 273 This section formally describes the method of generating public key 274 fingerprints that is in common use in the SSH community. 276 The fingerprint of a public key consists of the output of the MD5 277 message-digest algorithm [RFC1321]. The input to the algorithm is 278 the public-key data as specified by [RFC4253]. (This is the same 279 data that is base64 encoded to form the body of the public-key file.) 281 The output of the algorithm is presented to the user as a sequence of 282 16 octets printed as hexadecimal with lowercase letters and separated 283 by colons. 285 For example: "c1:b1:30:29:d7:b8:de:6c:97:77:10:d7:46:41:63:87" 287 5. IANA Considerations 289 Section 3.3 defines a new namespace of "Header-tags". These are US- 290 ASCII strings of maximum length 64 characters, and are case- 291 insensitive. 293 The following header-tags are defined by this document: 295 subject 297 comment 299 In addition, all header-tags beginning with "x-" are reserved for 300 Private Use, as defined in [RFC2434]. 302 Further allocations are to be made by IETF Consensus, as defined in 303 [RFC2434]. 305 6. Security Considerations 307 The file format described by this document provides no mechanism to 308 verify the integrity or otherwise detect tampering with the data 309 stored in such files. Given the potential of an adversarial 310 tampering with this data, system-specific measures (e.g. Access 311 Control Lists, UNIX permissions, other Discretionary and/or Mandatory 312 Access Controls) SHOULD be used to protect these files. Also, if the 313 contents of these files are transferred it SHOULD be done over a 314 trusted channel. 316 The header data allowed by this file format could contain an 317 unlimited range of information. While in many environments the 318 information conveyed by this header data may be considered innocuous 319 public information, it may constitute a channel through which 320 information about a user, a key or its use may be disclosed 321 intentionally or otherwise (e.g "Comment: Mary E. Jones, 123 Main St, 322 Home Phone:..."). The presence and use of this header data SHOULD be 323 reviewed by sites that deploy this file format. 325 The public-key fingerprint method presented here relies on the MD5 326 one-way hash function, which is known to have certain weaknesses 327 regarding its collision resistance; however, the particular use made 328 of MD5 here depends solely on its 2nd-preimage resistance, not on its 329 collision resistance. 331 MD5 is used here for historical reasons. 333 7. References 335 7.1. Normative References 337 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 338 April 1992. 340 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 341 Extensions (MIME) Part One: Format of Internet Message 342 Bodies", RFC 2045, November 1996. 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, March 1997. 347 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 348 10646", STD 63, RFC 3629, November 2003. 350 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 351 Transport Layer Protocol", RFC 4253, January 2006. 353 7.2. Informative References 355 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 356 Mail: Part I: Message Encryption and Authentication 357 Procedures", RFC 1421, February 1993. 359 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 360 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 361 October 1998. 363 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 364 "OpenPGP Message Format", RFC 2440, November 1998. 366 Authors' Addresses 368 Joseph Galbraith 369 VanDyke Software 370 4848 Tramway Ridge Blvd 371 Suite 101 372 Albuquerque, NM 87111 373 US 375 Phone: +1 505 332 5700 376 Email: galb-list@vandyke.com 378 Rodney Thayer 379 The Tillerman Group 380 370 Altair Way, PMB 321 381 Sunnyvale, CA 94086 383 Phone: +1 408 757 9693 384 Email: rodney@tillerman.to 386 Intellectual Property Statement 388 The IETF takes no position regarding the validity or scope of any 389 Intellectual Property Rights or other rights that might be claimed to 390 pertain to the implementation or use of the technology described in 391 this document or the extent to which any license under such rights 392 might or might not be available; nor does it represent that it has 393 made any independent effort to identify any such rights. Information 394 on the procedures with respect to rights in RFC documents can be 395 found in BCP 78 and BCP 79. 397 Copies of IPR disclosures made to the IETF Secretariat and any 398 assurances of licenses to be made available, or the result of an 399 attempt made to obtain a general license or permission for the use of 400 such proprietary rights by implementers or users of this 401 specification can be obtained from the IETF on-line IPR repository at 402 http://www.ietf.org/ipr. 404 The IETF invites any interested party to bring to its attention any 405 copyrights, patents or patent applications, or other proprietary 406 rights that may cover technology that may be required to implement 407 this standard. Please address the information to the IETF at 408 ietf-ipr@ietf.org. 410 Disclaimer of Validity 412 This document and the information contained herein are provided on an 413 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 414 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 415 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 416 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 417 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 418 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 420 Copyright Statement 422 Copyright (C) The Internet Society (2006). This document is subject 423 to the rights, licenses and restrictions contained in BCP 78, and 424 except as set forth therein, the authors retain all their rights. 426 Acknowledgment 428 Funding for the RFC Editor function is currently provided by the 429 Internet Society.