idnits 2.17.1 draft-igoe-secsh-x509v3-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 191 has weird spacing: '... string certi...' == Line 193 has weird spacing: '... string ocsp-...' == Line 340 has weird spacing: '... string dss_s...' == Line 358 has weird spacing: '... string rsa_s...' == Line 377 has weird spacing: '... string rsa_s...' == (5 more instances...) -- The document date (January 3, 2011) is 4833 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'ID-TLS-CERTS' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Igoe 3 Internet-Draft National Security Agency 4 Intended status: Standards Track D. Stebila 5 Expires: July 7, 2011 Queensland University of Technology 6 January 3, 2011 8 X.509v3 Certificates for Secure Shell Authentication 9 draft-igoe-secsh-x509v3-07 11 Abstract 13 X.509 public key certificates use a signature by a trusted 14 certification authority to bind a given public key to a given digital 15 identity. This document specifies how to use X.509 version 3 public 16 key certificates in public key algorithms in the Secure Shell 17 protocol. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 7, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Public Key Algorithms Using X.509 Version 3 Certificates . . . 5 55 2.1. Public Key Format . . . . . . . . . . . . . . . . . . . . 5 56 2.2. Certificate Extensions . . . . . . . . . . . . . . . . . . 7 57 2.2.1. KeyUsage . . . . . . . . . . . . . . . . . . . . . . . 7 58 2.2.2. ExtendedKeyUsage . . . . . . . . . . . . . . . . . . . 8 59 3. Signature Encoding . . . . . . . . . . . . . . . . . . . . . . 9 60 3.1. x509v3-ssh-dss . . . . . . . . . . . . . . . . . . . . . . 9 61 3.2. x509v3-ssh-rsa . . . . . . . . . . . . . . . . . . . . . . 9 62 3.3. x509v3-rsa2048-sha256 . . . . . . . . . . . . . . . . . . 9 63 3.4. x509v3-ecdsa-sha2-* . . . . . . . . . . . . . . . . . . . 10 64 4. Use in public key algorithms . . . . . . . . . . . . . . . . . 12 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 70 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 19 71 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 20 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 74 1. Introduction 76 There are two Secure Shell (SSH) protocols that use public key 77 cryptography for authentication. The Transport Layer Protocol, 78 described in [RFC4253], requires that a digital signature algorithm 79 (called the "public key algorithm") MUST be used to authenticate the 80 server to the client. Additionally, the User Authentication Protocol 81 described in [RFC4252] allows for the use of a digital signature to 82 authenticate the client to the server ("publickey" authentication). 84 In both cases, the validity of the authentication depends upon the 85 strength of the linkage between the public signing key and the 86 identity of the signer. Digital certificates, such as those in X.509 87 version 3 (X.509v3) format [RFC5280], are used in many corporate and 88 government environments to provide identity management. They use a 89 chain of signatures by a trusted root certification authority and its 90 intermediate certificate authorites to bind a given public signing 91 key to a given digital identity. 93 The following public key authentication algorithms are currently 94 available for use in SSH: 96 +--------------+-----------+ 97 | Algorithm | Reference | 98 +--------------+-----------+ 99 | ssh-dss | [RFC4253] | 100 | | | 101 | ssh-rsa | [RFC4253] | 102 | | | 103 | pgp-sign-dss | [RFC4253] | 104 | | | 105 | pgp-sign-rsa | [RFC4253] | 106 | | | 107 | ecdsa-sha2-* | [RFC5656] | 108 +--------------+-----------+ 110 Since Pretty Good Privacy (PGP) has its own method for binding a 111 public key to a digital identity, this document focuses solely upon 112 the non-PGP methods. In particular, this document defines the 113 following public key algorithms which differ from the above solely in 114 their use of X.509v3 certificates to convey the signer's public key. 116 +-----------------------+ 117 | Algorithm | 118 +-----------------------+ 119 | x509v3-ssh-dss | 120 | | 121 | x509v3-ssh-rsa | 122 | | 123 | x509v3-rsa2048-sha256 | 124 | | 125 | x509v3-ecdsa-sha2-* | 126 +-----------------------+ 128 Public keys conveyed using the x509v3-ecdsa-sha2-* public key 129 algorithms can be used with the ecmqv-sha2 key exchange method. 131 Implementation of this specification requires familiarity with the 132 Secure Shell protocol [RFC4251] [RFC4253] and X.509v3 certificates 133 [RFC5280]. Data types used in describing protocol messages are 134 defined in Section 5 of [RFC4251]. 136 This document is concerned with SSH implementation details; 137 specification of the underlying cryptographic algorithms and the 138 handling and structure of X.509v3 certificates is left to other 139 standards documents, particularly [RFC3447], [FIPS-186-3], 140 [FIPS-180-2], [FIPS-180-3], [SEC1], and [RFC5280]. 142 An earlier Internet-Draft for the use of X.509v3 certificates in the 143 Secure Shell was proposed by O. Saarenmaa and J. Galbraith; while 144 this document is informed in part by that Internet-Draft, it does not 145 maintain strict compatibility. 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 2. Public Key Algorithms Using X.509 Version 3 Certificates 153 This document defines the following new public key algorithms for use 154 in the Secure Shell protocol: x509v3-ssh-dss, x509v3-ssh-rsa, x509v3- 155 rsa2048-sha256, and the family of algorithms given by x509v3-ecdsa- 156 sha2-*. In these algorithms, a public key is stored in an X.509v3 157 certificate. This certificate, a chain of certificates leading to a 158 trusted certificate authority, and optional messages giving the 159 revocation status of the certificates are sent as the public key data 160 in the Secure Shell protocol according to the format in this section. 162 2.1. Public Key Format 164 The reader is referred to [RFC5280] for a general description of 165 X.509 version 3 certificates. For the purposes of this document, it 166 suffices to know that in X.509 a chain or sequence of certificates 167 (possibly of length one) allows a trusted root certificate authority 168 and its intermediate certificate authorities to cryptographically 169 bind a given public key to a given digital identity using public key 170 signatures. 172 For all of the public key algorithms specified in this document, the 173 key format consists of a sequence of one or more X.509v3 certificates 174 followed by a sequence of 0 or more Online Certificate Status 175 Protocol (OCSP) responses as in Section 4.2 of [RFC2560]. Providing 176 OCSP responses directly in this data structure can reduce the number 177 of communication rounds required (saving the implementation from 178 needing to perform OCSP checking out-of-band) and can also allow a 179 client outside of a private network to receive OCSP responses from a 180 server behind firewall. As with any use of OCSP data, 181 implementations SHOULD check that the production time of the OCSP 182 response is acceptable. It is RECOMMENDED, but not REQUIRED, that 183 implementations reject certificates for which the certificate status 184 is revoked. 186 The key format has the following specific encoding: 188 string "x509v3-ssh-dss" / "x509v3-ssh-rsa" / 189 "x509v3-rsa2048-sha256" / "x509v3-ecdsa-sha2-[identifier]" 190 uint32 certificate-count 191 string certificate[1..certificate-count] 192 uint32 ocsp-response-count 193 string ocsp-response[0..ocsp-response-count] 195 In the figure above, the string [identifier] is the identifier of the 196 elliptic curve domain parameters. The format of this string is 197 specified in Section 6.1 of [RFC5656]. Information on the REQUIRED 198 and RECOMMENDED sets of elliptic curve domain parameters for use with 199 this algorithm can be found in Section 10 of [RFC5656]. 201 Each certificate and ocsp-response MUST be encoded as a string of 202 octets using the Distinguished Encoding Rules (DER) encoding of 203 Abstract Syntax Notation One (ASN.1) [ASN1]. An example of an SSH 204 key exchange involving one of these public key algorithms is given in 205 Appendix A. 207 Additionally, the following constraints apply: 209 o The sender's certificate MUST be the first certificate and the 210 public key conveyed by this certificate MUST be consistent with 211 the public key algorithm being employed to authenticate the 212 sender. 214 o Each following certificate MUST certify the one preceding it. 216 o The self-signed certificate specifying the root authority MAY be 217 omitted. All other intermediate certificates in the chain leading 218 to a root authority MUST be included. 220 o To improve the chances that a peer can verify certificate chains 221 and OCSP responses, individual certificates and OCSP responses 222 SHOULD be signed using only signature algorithms corresponding to 223 public key algorithms supported by the peer, as indicated in the 224 server_host_key_algorithms field of the SSH_MSG_KEXINIT packet 225 (see Section 7.1 of [RFC4253]). However, other algorithms MAY be 226 used. The choice of signature algorithm used by any given 227 certificate or OCSP response is independent of the signature 228 algorithms chosen by other elements in the chain. 230 o Verifiers MUST be prepared to receive certificate chains and OCSP 231 responses that use algorithms not listed in the 232 server_host_key_algorithms field of the SSH_MSG_KEXINIT packet, 233 including algorithms which potentially have no Secure Shell 234 equivalent. However, peers sending such chains should recognize 235 that such chains are more likely to be unverifiable than chains 236 which use only algorithms listed in the server_host_key_algorithms 237 field. 239 o There is no requirement on the ordering of OCSP responses. The 240 number of OCSP responses MUST NOT exceeed the number of 241 certificates. 243 Upon receipt of a certificate chain, implementations MUST verify the 244 certificate chain according to Section 6.1 of [RFC5280] based on a 245 root of trust configured by the system administrator or user. 247 Issues associated with the use of certificates (such as expiration of 248 certificates and revocation of compromised certificates) are 249 addressed in [RFC5280] and are outside the scope of this document. 250 However, compliant implementations MUST comply with [RFC5280]. 251 Implementations providing and processing OCSP responses MUST comply 252 with [RFC2560]. 254 When no OCSP responses are provided, it is up to the implementation 255 and system administrator to decide whether to accept the certificate 256 or not. It may be possible for the implementation to retrieve OCSP 257 responses based on the id-ad-ocsp access description in the 258 certificate's Authority Information Access data (Section 4.2.2.1 of 259 [RFC5280]). However, if the id-ad-ocsp access description indicates 260 that the certificate authority employs OCSP, and no OCSP response 261 information is available, it is RECOMMENDED that the certificate be 262 rejected. 264 [RFC5480] and [RFC5758] describes the structure of X.509v3 265 certificates to be used with Elliptic Curve Digitial Signature 266 Algorithm (ECDSA) public keys. [RFC3279] and [RFC5280] describe the 267 structure of X.509v3 certificates to be used with RSA and Digital 268 Signature Algorithm (DSA) public keys. [RFC5759] provides additional 269 guidance for ECDSA keys in Suite B X.509v3 certificate and 270 certificate revocation list profiles. 272 2.2. Certificate Extensions 274 Certificate extensions allow for the specification of additional 275 attributes associated with a public key in an X.509v3 certificate 276 (see Section 4.2 of [RFC5280]). The KeyUsage and ExtendedKeyUsage 277 extensions may be used to restrict the use of X.509v3 certificates in 278 the context of the Secure Shell protocol as specified in the 279 following sections. 281 2.2.1. KeyUsage 283 The KeyUsage extension MAY be used to restrict a certificate's use. 284 In accordance with Section 4.2.1.3 of [RFC5280], if the KeyUsage 285 extension is present, then the certificate MUST be used only for one 286 of the purposes indicated. There are two relevant keyUsage 287 identifiers for the certificate corresponding to the public key 288 algorithm in use: 290 o If the KeyUsage extension is present in a certificate for the 291 x509v3-ssh-dss, x509v3-ssh-rsa, or x509v3-ecdsa-sha2-* public key 292 algorithms, then the digitalSignature bit MUST be set. 294 o If the KeyUsage extension is present in a certificate for ecmqv- 295 sha2 key exchange method, then the keyAgreement bit MUST be set. 297 For the remaining certificates in the certificate chain, 298 implementations MUST comply with existing conventions on KeyUsage 299 identifiers and certificates as in Section 4.2.1.3 on [RFC5280]. 301 2.2.2. ExtendedKeyUsage 303 This document defines two ExtendedKeyUsage key purpose IDs that MAY 304 be used to restrict a certificate's use: id-kp-secureShellClient, 305 which indicates that the key can be used for a Secure Shell client, 306 and id-kp-secureShellServer, which indicates that the key can be used 307 for a Secure Shell server. In accordance with Section 4.2.1.12 of 308 [RFC5280], if the ExtendedKeyUsage extension is present, then the 309 certificate MUST be used only for one of the purposes indicated. The 310 object identifiers of the two key purpose IDs defined in this 311 document are as follows: 313 o id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 314 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 316 o id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } -- extended key purpose 317 identifiers 319 o id-kp-secureShellClient OBJECT IDENTIFIER ::= { id-kp 21 } 321 o id-kp-secureShellServer OBJECT IDENTIFIER ::= { id-kp 22 } 323 3. Signature Encoding 325 Signing and verifying using the X.509v3-based public key algorithms 326 specified in this document (x509v3-ssh-dss, x509v3-ssh-rsa, x509v3- 327 ecdsa-sha2-*) is done in the analogous way for the corresponding non- 328 X.509v3-based public key algorithms (ssh-dss, ssh-rsa, ecdsa-sha2-*, 329 respectively). For concreteness, we specify this explicitly below. 331 3.1. x509v3-ssh-dss 333 Signing and verifying using the x509v3-ssh-dss key format is done 334 according to the Digital Signature Standard [FIPS-186-3] using the 335 SHA-1 hash [FIPS-180-2]. 337 The resulting signature is encoded as follows: 339 string "ssh-dss" 340 string dss_signature_blob 342 The value for dss_signature_blob is encoded as a string containing r, 343 followed by s (which are fixed-length 160-bit integers, without 344 lengths or padding, unsigned, and in network byte order). 346 This format is the same as for ssh-dss signatures in Section 6.6 of 347 [RFC4253]. 349 3.2. x509v3-ssh-rsa 351 Signing and verifying using the x509v3-ssh-rsa key format is 352 performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC3447] 353 using the SHA-1 hash [FIPS-180-2]. 355 The resulting signature is encoded as follows: 357 string "ssh-rsa" 358 string rsa_signature_blob 360 The value for rsa_signature_blob is encoded as a string containing s 361 (which is an integer, without lengths or padding, unsigned, and in 362 network byte order). 364 This format is the same as for ssh-rsa signatures in Section 6.6 of 365 [RFC4253]. 367 3.3. x509v3-rsa2048-sha256 369 Signing and verifying using the x509v3-rsa2048-sha256 key format is 370 performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC3447] 371 using the SHA-256 hash [FIPS-180-3]; RSA keys conveyed using this 372 format MUST have a modulus of at least 2048 bits. 374 The resulting signature is encoded as follows: 376 string "rsa2048-sha256" 377 string rsa_signature_blob 379 The value for rsa_signature_blob is encoded as a string containing s 380 (which is an integer, without lengths or padding, unsigned, and in 381 network byte order). 383 Unlike the other public key formats specified in this document, the 384 x509v3-rsa2048-sha256 public key format does not correspond to any 385 previously existing SSH non-certificate public key format. The main 386 purpose of introducing this public key format is to provide an RSA- 387 based public key format that is compatible with current 388 recommendations on key size and hash functions. For example, NIST's 389 draft recommendations on cryptographic algorithms and key lengths 390 [SP-800-131] specify that digital signature generation using an RSA 391 key with modulus less than 2048 bits or with the SHA-1 hash function 392 is acceptable through 2010 and deprecated from 2011 through 2013, 393 whereas an RSA key with modulus at least 2048 bits and SHA-256 is 394 acceptable for the indefinite future. The introduction of other non- 395 certificate-based SSH public key formats compatible with the above 396 recommendations is outside the scope of this document. 398 3.4. x509v3-ecdsa-sha2-* 400 Signing and verifying using the x509v3-ecdsa-sha2-* key formats is 401 performed according to the ECDSA algorithm in [FIPS-186-3] using the 402 SHA2 hash function family [FIPS-180-3]. The choice of hash function 403 from the SHA2 hash function family is based on the key size of the 404 ECDSA key as specified in Section 6.2.1 of [RFC5656]. 406 The resulting signature is encoded as follows: 408 string "ecdsa-sha2-[identifier]" 409 string ecdsa_signature_blob 411 The string [identifier] is the identifier of the elliptic curve 412 domain parameters. The format of this string is specified in Section 413 6.1 of [RFC5656]. 415 The ecdsa_signature_blob value has the following specific encoding: 417 mpint r 418 mpint s 420 The integers r and s are the output of the ECDSA algorithm. 422 This format is the same as for ecdsa-sha2-* signatures in Section 423 3.1.2 of [RFC5656]. 425 4. Use in public key algorithms 427 The public key algorithms and encodings defined in this document 428 SHOULD be accepted any place in the Secure Shell protocol suite where 429 public keys are used, including, but not limited to, the following 430 protocol messages for server authentication and user authentication: 432 o in the SSH_MSG_USERAUTH_REQUEST message when "publickey" 433 authentication is used [RFC4252] 435 o in the SSH_MSG_USERAUTH_REQUEST message when "hostbased" 436 authentication is used [RFC4252] 438 o in the SSH_MSG_KEXDH_REPLY message [RFC4253] 440 o in the SSH_MSG_KEXRSA_PUBKEY message [RFC4432] 442 o in the SSH_MSG_KEXGSS_HOSTKEY message [RFC4462] 444 o in the SSH_MSG_KEX_ECDH_REPLY message [RFC5656] 446 o in the SSH_MSG_KEX_ECMQV_REPLY message [RFC5656] 448 When a public key from this specification is included in the input to 449 a hash algorithm, the exact bytes that are transmitted on the wire 450 must be used as input to the hash functions. In particular, 451 implementations MUST NOT omit any of the chain certificates or OCSP 452 responses that were included on the wire, nor change encoding of the 453 certificate or OCSP data. Otherwise hashes that are meant to be 454 computed in parallel by both peers will have differing values. 456 For the purposes of user authentication, the mapping between 457 certificates and user names is left as an implementation and 458 configuration issue for implementers and system administrators. 460 For the purposes of server authentication, it is RECOMMENDED that 461 implementations support the following mechanism mapping host names to 462 certificates. However, local policy MAY disable the mechanism or MAY 463 impose additional constraints before considering a matching 464 successful. Furthermore, additional mechanisms mapping host names to 465 certificates MAY be used and are left as implementation and 466 configuration issues for implementers and system administrators. 468 The RECOMMENDED server authentication mechanism is as follows. The 469 subjectAlternativeName X.509v3 extension, as described in Section 470 4.2.1.6 of [RFC5280], SHOULD be used to convey the server host name, 471 using either dNSName entries or iPAddress entries to convey domain 472 names or IP addresses as appropriate. Multiple entries MAY be 473 specified. The following rules apply: 475 o If the client's reference identifier (e.g., the host name typed by 476 the client) is a DNS domain name, the server's identity SHOULD be 477 checked using the rules specified in [ID-TLS-CERTS]. Support for 478 the DNS-ID identifier type is RECOMMENDED in client and server 479 software implementations. Certification authorities that issue 480 certificates for use by Secure Shell servers SHOULD support the 481 DNS-ID identifier type. Service providers SHOULD include the 482 DNS-ID identifier type in certificate requests. The DNS-ID MAY 483 contain the wildcard character '*' as the complete left-most label 484 within the identifier. 486 o If the client's reference identifier is an IP address as defined 487 by [RFC0791] or [RFC2460], the client SHOULD convert that address 488 to the "network byte order" octet string representation and 489 compare it against a subjectAltName entry of type iPAddress. A 490 match occurs if the octet strings are identifier for the reference 491 identifier and any presented identifier. 493 5. Security Considerations 495 This document provides new public key algorithms for the Secure Shell 496 protocol that convey public keys using X.509v3 certificates. For the 497 most part, the security considerations involved in using the Secure 498 Shell protocol apply, since all of the public key algorithms 499 introduced in this document are based on existing algorithms in the 500 Secure Shell protocol. However, implementers should be aware of 501 security considerations specific to the use of X.509v3 certificates 502 in a public key infrastructure, including considerations related to 503 expired certificates and certificate revocation lists. 505 The reader is directed to the security considerations sections of 506 [RFC5280] for the use of X.509v3 certificates, [RFC2560] for the use 507 of OCSP response, [RFC4253] for server authentication, and [RFC4252] 508 for user authentication. Implementations SHOULD NOT use revoked 509 certificates because many causes of certificate revocation mean that 510 the critical authentication properties needed are no longer true. 511 For example, compromise of a certificate's private key or issuance of 512 a certificate to the wrong party are common reasons to revoke a 513 certificate. 515 If a party to the SSH exchange attempts to use a revoked X.509v3 516 certificate, this attempt along with the date, time, certificate 517 identity, and apparent origin IP address of the attempt SHOULD be 518 logged as a security event in the system's audit logs or the system's 519 general event logs. Similarly, if a certificate indicates that OCSP 520 is used and there is no response to the OCSP query, the absence of a 521 response along with the details of the attempted certificate use (as 522 before) SHOULD be logged. 524 As with all specifications involving cryptographic algorithms, the 525 quality of security provided by this specification depends on the 526 strength of the cryptographic algorithms in use, the security of the 527 keys, the correctness of the implementation, and the security of the 528 public key infrastructure and the certificate authorities. 529 Accordingly, implementers are encouraged to use high assurance 530 methods when implementing this specification and other parts of the 531 Secure Shell protocol suite. 533 6. IANA Considerations 535 Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250], 536 this document makes the following registrations: 538 In the Public Key Algorithm Names registry: 540 o The SSH public key algorithm "x509v3-ssh-dss". 542 o The SSH public key algorithm "x509v3-ssh-rsa". 544 o The SSH public key algorithm "x509v3-rsa2048-sha256". 546 o The family of SSH public key algorithm names beginning with 547 "x509v3-ecdsa-sha2-" and not containing the at-sign ('@'). 549 This document creates no new registries. 551 The two object identifiers used in Section 2.2.2 were assigned from 552 an arc delegated by IANA to the PKIX Working Group. No further 553 action by IANA is necessary for this document. 555 7. References 557 7.1. Normative References 559 [ASN1] International Telecommunications Union, "Abstract Syntax 560 Notation One (ASN.1): Specification of basic notation", 561 X.680, July 2002. 563 [FIPS-180-2] 564 National Institute of Standards and Technology, "Secure 565 Hash Standard", FIPS 180-2, August 2002. 567 [FIPS-180-3] 568 National Institute of Standards and Technology, "Secure 569 Hash Standard", FIPS 180-3, October 2008. 571 [FIPS-186-3] 572 National Institute of Standards and Technology, "Digital 573 Signature Standard (DSS)", FIPS 186-3, June 2009. 575 [ID-TLS-CERTS] 576 Saint-Andre, P. and J. Hodges, "Representation and 577 Verification of Domain-Based Application Service Identity 578 within Internet Public Key Infrastructure Using X.509 579 (PKIX) Certificates in the Context of Transport Layer 580 Security (TLS)", December 2010, . 583 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 584 September 1981. 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, March 1997. 589 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 590 (IPv6) Specification", RFC 2460, December 1998. 592 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 593 Adams, "X.509 Internet Public Key Infrastructure Online 594 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 596 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 597 Identifiers for the Internet X.509 Public Key 598 Infrastructure Certificate and Certificate Revocation List 599 (CRL) Profile", RFC 3279, April 2002. 601 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 602 Standards (PKCS) #1: RSA Cryptography Specifications 603 Version 2.1", RFC 3447, February 2003. 605 [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) 606 Protocol Assigned Numbers", RFC 4250, January 2006. 608 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 609 Protocol Architecture", RFC 4251, January 2006. 611 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 612 Authentication Protocol", RFC 4252, January 2006. 614 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 615 Transport Layer Protocol", RFC 4253, January 2006. 617 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 618 Housley, R., and W. Polk, "Internet X.509 Public Key 619 Infrastructure Certificate and Certificate Revocation List 620 (CRL) Profile", RFC 5280, May 2008. 622 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 623 "Elliptic Curve Cryptography Subject Public Key 624 Information", RFC 5480, March 2009. 626 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 627 Integration in the Secure Shell Transport Layer", 628 RFC 5656, December 2009. 630 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 631 Polk, "Internet X.509 Public Key Infrastructure: 632 Additional Algorithms and Identifiers for DSA and ECDSA", 633 RFC 5758, January 2010. 635 [SEC1] Standards for Efficient Cryptography Group, "Elliptic 636 Curve Cryptography", SEC 1, September 2000, 637 . 639 7.2. Informative References 641 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) 642 Transport Layer Protocol", RFC 4432, March 2006. 644 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 645 "Generic Security Service Application Program Interface 646 (GSS-API) Authentication and Key Exchange for the Secure 647 Shell (SSH) Protocol", RFC 4462, May 2006. 649 [RFC5759] Solinas, J. and L. Zieglar, "Suite B Certificate and 650 Certificate Revocation List (CRL) Profile", RFC 5759, 651 January 2010. 653 [SP-800-131] 654 Barker, E. and A. Roginsky, "DRAFT Recommendation for the 655 Transitioning of Cryptographic Algorithms and Key 656 Lengths", NIST Special Publication 800-131, June 2010. 658 Appendix A. Example 660 The following example illustrates the use of an X.509v3 certificate 661 for a public key for the Digital Signature Algorithm when used in a 662 Diffie-Hellman key exchange method. In the example, there is a chain 663 of certificates of length 2, and a single OCSP response is provided. 665 byte SSH_MSG_KEXDH_REPLY 666 string 0x00 0x00 0xXX 0xXX -- length of the remaining data in 667 this string 668 0x00 0x00 0x00 0x0D -- length of string "x509v3-ssh-dss" 669 "x509v3-ssh-dss" 670 0x00 0x00 0x00 0x02 -- there are 2 certificates 671 0x00 0x00 0xXX 0xXX -- length of sender certificate 672 DER-encoded sender certificate 673 0x00 0x00 0xXX 0xXX -- length of issuer certificate 674 DER-encoded issuer certificate 675 0x00 0x00 0x00 0x01 -- there is 1 OCSP response 676 0x00 0x00 0xXX 0xXX -- length of OCSP response 677 DER-encoded OCSP response 678 mpint f 679 string signature of H 681 Appendix B. Acknowledgements 683 The authors gratefully acknowledge helpful comments from Ran 684 Atkinson, Samuel Edoho-Eket, Joseph Galbraith, Russ Housley, Jeffrey 685 Hutzelman, Jan Pechanec, Peter Saint-Andre, Sean Turner, and Nicolas 686 Williams. 688 O. Saarenmaa and J. Galbraith previously prepared an Internet-Draft 689 on a similar topic. 691 Authors' Addresses 693 Kevin M. Igoe 694 National Security Agency 695 NSA/CSS Commercial Solutions Center 696 United States of America 698 Email: kmigoe@nsa.gov 700 Douglas Stebila 701 Queensland University of Technology 702 Information Security Institute 703 Level 7, 126 Margaret St 704 Brisbane, Queensland 4000 705 Australia 707 Email: douglas@stebila.ca