external/bsd/bind/dist/doc/rfc/rfc4255.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        J. Schlyter
   8 Request for Comments: 4255                                       OpenSSH
   9 Category: Standards Track                                     W. Griffin
  10                                                                   SPARTA
  11                                                             January 2006
  12
  13
  14    Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
  15
  16 Status of This Memo
  17
  18    This document specifies an Internet standards track protocol for the
  19    Internet community, and requests discussion and suggestions for
  20    improvements.  Please refer to the current edition of the "Internet
  21    Official Protocol Standards" (STD 1) for the standardization state
  22    and status of this protocol.  Distribution of this memo is unlimited.
  23
  24 Copyright Notice
  25
  26    Copyright (C) The Internet Society (2006).
  27
  28 Abstract
  29
  30    This document describes a method of verifying Secure Shell (SSH) host
  31    keys using Domain Name System Security (DNSSEC).  The document
  32    defines a new DNS resource record that contains a standard SSH key
  33    fingerprint.
  34
  35 Table of Contents
  36
  37    1. Introduction ....................................................2
  38    2. SSH Host Key Verification .......................................2
  39       2.1. Method .....................................................2
  40       2.2. Implementation Notes .......................................2
  41       2.3. Fingerprint Matching .......................................3
  42       2.4. Authentication .............................................3
  43    3. The SSHFP Resource Record .......................................3
  44       3.1. The SSHFP RDATA Format .....................................4
  45            3.1.1. Algorithm Number Specification ......................4
  46            3.1.2. Fingerprint Type Specification ......................4
  47            3.1.3. Fingerprint .........................................5
  48       3.2. Presentation Format of the SSHFP RR ........................5
  49    4. Security Considerations .........................................5
  50    5. IANA Considerations .............................................6
  51    6. Normative References ............................................7
  52    7. Informational References ........................................7
  53    8. Acknowledgements ................................................8
  54
  55
  56
  57
  58 Schlyter & Griffin          Standards Track                     [Page 1]
  59 \f
  60 RFC 4255                DNS and SSH Fingerprints            January 2006
  61
  62
  63 1.  Introduction
  64
  65    The SSH [6] protocol provides secure remote login and other secure
  66    network services over an insecure network.  The security of the
  67    connection relies on the server authenticating itself to the client
  68    as well as the user authenticating itself to the server.
  69
  70    If a connection is established to a server whose public key is not
  71    already known to the client, a fingerprint of the key is presented to
  72    the user for verification.  If the user decides that the fingerprint
  73    is correct and accepts the key, the key is saved locally and used for
  74    verification for all following connections.  While some security-
  75    conscious users verify the fingerprint out-of-band before accepting
  76    the key, many users blindly accept the presented key.
  77
  78    The method described here can provide out-of-band verification by
  79    looking up a fingerprint of the server public key in the DNS [1][2]
  80    and using DNSSEC [5] to verify the lookup.
  81
  82    In order to distribute the fingerprint using DNS, this document
  83    defines a new DNS resource record, "SSHFP", to carry the fingerprint.
  84
  85    Basic understanding of the DNS system [1][2] and the DNS security
  86    extensions [5] is assumed by this document.
  87
  88    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  89    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  90    document are to be interpreted as described in RFC 2119 [3].
  91
  92 2.  SSH Host Key Verification
  93
  94 2.1.  Method
  95
  96    Upon connection to an SSH server, the SSH client MAY look up the
  97    SSHFP resource record(s) for the host it is connecting to.  If the
  98    algorithm and fingerprint of the key received from the SSH server
  99    match the algorithm and fingerprint of one of the SSHFP resource
 100    record(s) returned from DNS, the client MAY accept the identity of
 101    the server.
 102
 103 2.2.  Implementation Notes
 104
 105    Client implementors SHOULD provide a configurable policy used to
 106    select the order of methods used to verify a host key.  This document
 107    defines one method: Fingerprint storage in DNS.  Another method
 108    defined in the SSH Architecture [6] uses local files to store keys
 109    for comparison.  Other methods that could be defined in the future
 110    might include storing fingerprints in LDAP or other databases.  A
 111
 112
 113
 114 Schlyter & Griffin          Standards Track                     [Page 2]
 115 \f
 116 RFC 4255                DNS and SSH Fingerprints            January 2006
 117
 118
 119    configurable policy will allow administrators to determine which
 120    methods they want to use and in what order the methods should be
 121    prioritized.  This will allow administrators to determine how much
 122    trust they want to place in the different methods.
 123
 124    One specific scenario for having a configurable policy is where
 125    clients do not use fully qualified host names to connect to servers.
 126    In this scenario, the implementation SHOULD verify the host key
 127    against a local database before verifying the key via the fingerprint
 128    returned from DNS.  This would help prevent an attacker from
 129    injecting a DNS search path into the local resolver and forcing the
 130    client to connect to a different host.
 131
 132 2.3.  Fingerprint Matching
 133
 134    The public key and the SSHFP resource record are matched together by
 135    comparing algorithm number and fingerprint.
 136
 137       The public key algorithm and the SSHFP algorithm number MUST
 138       match.
 139
 140       A message digest of the public key, using the message digest
 141       algorithm specified in the SSHFP fingerprint type, MUST match the
 142       SSHFP fingerprint.
 143
 144 2.4.  Authentication
 145
 146    A public key verified using this method MUST NOT be trusted if the
 147    SSHFP resource record (RR) used for verification was not
 148    authenticated by a trusted SIG RR.
 149
 150    Clients that do validate the DNSSEC signatures themselves SHOULD use
 151    standard DNSSEC validation procedures.
 152
 153    Clients that do not validate the DNSSEC signatures themselves MUST
 154    use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8])
 155    between themselves and the entity performing the signature
 156    validation.
 157
 158 3.  The SSHFP Resource Record
 159
 160    The SSHFP resource record (RR) is used to store a fingerprint of an
 161    SSH public host key that is associated with a Domain Name System
 162    (DNS) name.
 163
 164    The RR type code for the SSHFP RR is 44.
 165
 166
 167
 168
 169
 170 Schlyter & Griffin          Standards Track                     [Page 3]
 171 \f
 172 RFC 4255                DNS and SSH Fingerprints            January 2006
 173
 174
 175 3.1.  The SSHFP RDATA Format
 176
 177    The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
 178    type and the fingerprint of the public host key.
 179
 180        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 181        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 182        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 183        |   algorithm   |    fp type    |                               /
 184        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
 185        /                                                               /
 186        /                          fingerprint                          /
 187        /                                                               /
 188        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 189
 190 3.1.1.  Algorithm Number Specification
 191
 192    This algorithm number octet describes the algorithm of the public
 193    key.  The following values are assigned:
 194
 195           Value    Algorithm name
 196           -----    --------------
 197           0        reserved
 198           1        RSA
 199           2        DSS
 200
 201    Reserving other types requires IETF consensus [4].
 202
 203 3.1.2.  Fingerprint Type Specification
 204
 205    The fingerprint type octet describes the message-digest algorithm
 206    used to calculate the fingerprint of the public key.  The following
 207    values are assigned:
 208
 209           Value    Fingerprint type
 210           -----    ----------------
 211           0        reserved
 212           1        SHA-1
 213
 214    Reserving other types requires IETF consensus [4].
 215
 216    For interoperability reasons, as few fingerprint types as possible
 217    should be reserved.  The only reason to reserve additional types is
 218    to increase security.
 219
 220
 221
 222
 223
 224
 225
 226 Schlyter & Griffin          Standards Track                     [Page 4]
 227 \f
 228 RFC 4255                DNS and SSH Fingerprints            January 2006
 229
 230
 231 3.1.3.  Fingerprint
 232
 233    The fingerprint is calculated over the public key blob as described
 234    in [7].
 235
 236    The message-digest algorithm is presumed to produce an opaque octet
 237    string output, which is placed as-is in the RDATA fingerprint field.
 238
 239 3.2.  Presentation Format of the SSHFP RR
 240
 241    The RDATA of the presentation format of the SSHFP resource record
 242    consists of two numbers (algorithm and fingerprint type) followed by
 243    the fingerprint itself, presented in hex, e.g.:
 244
 245        host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890
 246
 247    The use of mnemonics instead of numbers is not allowed.
 248
 249 4.  Security Considerations
 250
 251    Currently, the amount of trust a user can realistically place in a
 252    server key is proportional to the amount of attention paid to
 253    verifying that the public key presented actually corresponds to the
 254    private key of the server.  If a user accepts a key without verifying
 255    the fingerprint with something learned through a secured channel, the
 256    connection is vulnerable to a man-in-the-middle attack.
 257
 258    The overall security of using SSHFP for SSH host key verification is
 259    dependent on the security policies of the SSH host administrator and
 260    DNS zone administrator (in transferring the fingerprint), detailed
 261    aspects of how verification is done in the SSH implementation, and in
 262    the client's diligence in accessing the DNS in a secure manner.
 263
 264    One such aspect is in which order fingerprints are looked up (e.g.,
 265    first checking local file and then SSHFP).  We note that, in addition
 266    to protecting the first-time transfer of host keys, SSHFP can
 267    optionally be used for stronger host key protection.
 268
 269       If SSHFP is checked first, new SSH host keys may be distributed by
 270       replacing the corresponding SSHFP in DNS.
 271
 272       If SSH host key verification can be configured to require SSHFP,
 273       SSH host key revocation can be implemented by removing the
 274       corresponding SSHFP from DNS.
 275
 276
 277
 278
 279
 280
 281
 282 Schlyter & Griffin          Standards Track                     [Page 5]
 283 \f
 284 RFC 4255                DNS and SSH Fingerprints            January 2006
 285
 286
 287    As stated in Section 2.2, we recommend that SSH implementors provide
 288    a policy mechanism to control the order of methods used for host key
 289    verification.  One specific scenario for having a configurable policy
 290    is where clients use unqualified host names to connect to servers.
 291    In this case, we recommend that SSH implementations check the host
 292    key against a local database before verifying the key via the
 293    fingerprint returned from DNS.  This would help prevent an attacker
 294    from injecting a DNS search path into the local resolver and forcing
 295    the client to connect to a different host.
 296
 297    A different approach to solve the DNS search path issue would be for
 298    clients to use a trusted DNS search path, i.e., one not acquired
 299    through DHCP or other autoconfiguration mechanisms.  Since there is
 300    no way with current DNS lookup APIs to tell whether a search path is
 301    from a trusted source, the entire client system would need to be
 302    configured with this trusted DNS search path.
 303
 304    Another dependency is on the implementation of DNSSEC itself.  As
 305    stated in Section 2.4, we mandate the use of secure methods for
 306    lookup and that SSHFP RRs are authenticated by trusted SIG RRs.  This
 307    is especially important if SSHFP is to be used as a basis for host
 308    key rollover and/or revocation, as described above.
 309
 310    Since DNSSEC only protects the integrity of the host key fingerprint
 311    after it is signed by the DNS zone administrator, the fingerprint
 312    must be transferred securely from the SSH host administrator to the
 313    DNS zone administrator.  This could be done manually between the
 314    administrators or automatically using secure DNS dynamic update [11]
 315    between the SSH server and the nameserver.  We note that this is no
 316    different from other key enrollment situations, e.g., a client
 317    sending a certificate request to a certificate authority for signing.
 318
 319 5.  IANA Considerations
 320
 321    IANA has allocated the RR type code 44 for SSHFP from the standard RR
 322    type space.
 323
 324    IANA has opened a new registry for the SSHFP RR type for public key
 325    algorithms.  The defined types are:
 326
 327       0 is reserved
 328       1 is RSA
 329       2 is DSA
 330
 331    Adding new reservations requires IETF consensus [4].
 332
 333
 334
 335
 336
 337
 338 Schlyter & Griffin          Standards Track                     [Page 6]
 339 \f
 340 RFC 4255                DNS and SSH Fingerprints            January 2006
 341
 342
 343    IANA has opened a new registry for the SSHFP RR type for fingerprint
 344    types.  The defined types are:
 345
 346       0 is reserved
 347       1 is SHA-1
 348
 349    Adding new reservations requires IETF consensus [4].
 350
 351 6.  Normative References
 352
 353    [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
 354          13, RFC 1034, November 1987.
 355
 356    [2]   Mockapetris, P., "Domain names - implementation and
 357          specification", STD 13, RFC 1035, November 1987.
 358
 359    [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
 360          Levels", BCP 14, RFC 2119, March 1997.
 361
 362    [4]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
 363          Considerations Section in RFCs", BCP 26, RFC 2434, October
 364          1998.
 365
 366    [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
 367          "DNS Security Introduction and Requirements", RFC 4033, March
 368          2005.
 369
 370          Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
 371          "Resource Records for the DNS Security Extensions", RFC 4034,
 372          March 2005.
 373
 374          Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
 375          "Protocol Modifications for the DNS Security Extensions", RFC
 376          4035, March 2005.
 377
 378    [6]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
 379          Protocol Architecture", RFC 4251, January 2006.
 380
 381    [7]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
 382          Transport Layer Protocol", RFC 4253, January 2006.
 383
 384 7.  Informational References
 385
 386    [8]   Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
 387          Roadmap", RFC 2411, November 1998.
 388
 389
 390
 391
 392
 393
 394 Schlyter & Griffin          Standards Track                     [Page 7]
 395 \f
 396 RFC 4255                DNS and SSH Fingerprints            January 2006
 397
 398
 399    [9]   Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
 400          Wellington, "Secret Key Transaction Authentication for DNS
 401          (TSIG)", RFC 2845, May 2000.
 402
 403    [10]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
 404          ( SIG(0)s )", RFC 2931, September 2000.
 405
 406    [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
 407          Update", RFC 3007, November 2000.
 408
 409 8.  Acknowledgements
 410
 411    The authors gratefully acknowledge, in no particular order, the
 412    contributions of the following persons:
 413
 414       Martin Fredriksson
 415
 416       Olafur Gudmundsson
 417
 418       Edward Lewis
 419
 420       Bill Sommerfeld
 421
 422 Authors' Addresses
 423
 424    Jakob Schlyter
 425    OpenSSH
 426    812 23rd Avenue SE
 427    Calgary, Alberta  T2G 1N8
 428    Canada
 429
 430    EMail: jakob@openssh.com
 431    URI:   http://www.openssh.com/
 432
 433
 434    Wesley Griffin
 435    SPARTA
 436    7075 Samuel Morse Drive
 437    Columbia, MD  21046
 438    USA
 439
 440    EMail: wgriffin@sparta.com
 441    URI:   http://www.sparta.com/
 442
 443
 444
 445
 446
 447
 448
 449
 450 Schlyter & Griffin          Standards Track                     [Page 8]
 451 \f
 452 RFC 4255                DNS and SSH Fingerprints            January 2006
 453
 454
 455 Full Copyright Statement
 456
 457    Copyright (C) The Internet Society (2006).
 458
 459    This document is subject to the rights, licenses and restrictions
 460    contained in BCP 78, and except as set forth therein, the authors
 461    retain all their rights.
 462
 463    This document and the information contained herein are provided on an
 464    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 465    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 466    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 467    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 468    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 469    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 470
 471 Intellectual Property
 472
 473    The IETF takes no position regarding the validity or scope of any
 474    Intellectual Property Rights or other rights that might be claimed to
 475    pertain to the implementation or use of the technology described in
 476    this document or the extent to which any license under such rights
 477    might or might not be available; nor does it represent that it has
 478    made any independent effort to identify any such rights.  Information
 479    on the procedures with respect to rights in RFC documents can be
 480    found in BCP 78 and BCP 79.
 481
 482    Copies of IPR disclosures made to the IETF Secretariat and any
 483    assurances of licenses to be made available, or the result of an
 484    attempt made to obtain a general license or permission for the use of
 485    such proprietary rights by implementers or users of this
 486    specification can be obtained from the IETF on-line IPR repository at
 487    http://www.ietf.org/ipr.
 488
 489    The IETF invites any interested party to bring to its attention any
 490    copyrights, patents or patent applications, or other proprietary
 491    rights that may cover technology that may be required to implement
 492    this standard.  Please address the information to the IETF at
 493    ietf-ipr@ietf.org.
 494
 495 Acknowledgement
 496
 497    Funding for the RFC Editor function is provided by the IETF
 498    Administrative Support Activity (IASA).
 499
 500
 501
 502
 503
 504
 505
 506 Schlyter & Griffin          Standards Track                     [Page 9]
 507 \f