contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt

   1 Secure Shell Working Group                                   J. Schlyter
   2 Internet-Draft                                                   OpenSSH
   3 Expires: March 5, 2004                                        W. Griffin
   4                                                                   SPARTA
   5                                                        September 5, 2003
   6
   7
   8            Using DNS to Securely Publish SSH Key Fingerprints
   9                       draft-ietf-secsh-dns-05.txt
  10
  11 Status of this Memo
  12
  13    This document is an Internet-Draft and is in full conformance with
  14    all provisions of Section 10 of RFC2026.
  15
  16    Internet-Drafts are working documents of the Internet Engineering
  17    Task Force (IETF), its areas, and its working groups. Note that other
  18    groups may also distribute working documents as Internet-Drafts.
  19
  20    Internet-Drafts are draft documents valid for a maximum of six months
  21    and may be updated, replaced, or obsoleted by other documents at any
  22    time. It is inappropriate to use Internet-Drafts as reference
  23    material or to cite them other than as "work in progress."
  24
  25    The list of current Internet-Drafts can be accessed at http://
  26    www.ietf.org/ietf/1id-abstracts.txt.
  27
  28    The list of Internet-Draft Shadow Directories can be accessed at
  29    http://www.ietf.org/shadow.html.
  30
  31    This Internet-Draft will expire on March 5, 2004.
  32
  33 Copyright Notice
  34
  35    Copyright (C) The Internet Society (2003). All Rights Reserved.
  36
  37 Abstract
  38
  39    This document describes a method to verify SSH host keys using
  40    DNSSEC. The document defines a new DNS resource record that contains
  41    a standard SSH key fingerprint.
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53 Schlyter & Griffin       Expires March 5, 2004                  [Page 1]
  54
  55 Internet-Draft          DNS and SSH Fingerprints          September 2003
  56
  57
  58 Table of Contents
  59
  60    1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
  61    2.    SSH Host Key Verification  . . . . . . . . . . . . . . . . .  3
  62    2.1   Method . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  63    2.2   Implementation Notes . . . . . . . . . . . . . . . . . . . .  3
  64    2.3   Fingerprint Matching . . . . . . . . . . . . . . . . . . . .  4
  65    2.4   Authentication . . . . . . . . . . . . . . . . . . . . . . .  4
  66    3.    The SSHFP Resource Record  . . . . . . . . . . . . . . . . .  4
  67    3.1   The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . .  5
  68    3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . .  5
  69    3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . .  5
  70    3.1.3 Fingerprint  . . . . . . . . . . . . . . . . . . . . . . . .  5
  71    3.2   Presentation Format of the SSHFP RR  . . . . . . . . . . . .  6
  72    4.    Security Considerations  . . . . . . . . . . . . . . . . . .  6
  73    5.    IANA Considerations  . . . . . . . . . . . . . . . . . . . .  7
  74          Normative References . . . . . . . . . . . . . . . . . . . .  8
  75          Informational References . . . . . . . . . . . . . . . . . .  8
  76          Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  9
  77    A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  9
  78          Intellectual Property and Copyright Statements . . . . . . . 10
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109 Schlyter & Griffin       Expires March 5, 2004                  [Page 2]
 110
 111 Internet-Draft          DNS and SSH Fingerprints          September 2003
 112
 113
 114 1. Introduction
 115
 116    The SSH [6] protocol provides secure remote login and other secure
 117    network services over an insecure network.  The security of the
 118    connection relies on the server authenticating itself to the client
 119    as well as the user authenticating itself to the server.
 120
 121    If a connection is established to a server whose public key is not
 122    already known to the client, a fingerprint of the key is presented to
 123    the user for verification.  If the user decides that the fingerprint
 124    is correct and accepts the key, the key is saved locally and used for
 125    verification for all following connections. While some
 126    security-conscious users verify the fingerprint out-of-band before
 127    accepting the key, many users blindly accept the presented key.
 128
 129    The method described here can provide out-of-band verification by
 130    looking up a fingerprint of the server public key in the DNS [1][2]
 131    and using DNSSEC [5] to verify the lookup.
 132
 133    In order to distribute the fingerprint using DNS, this document
 134    defines a new DNS resource record, "SSHFP", to carry the fingerprint.
 135
 136    Basic understanding of the DNS system [1][2] and the DNS security
 137    extensions [5] is assumed by this document.
 138
 139    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 140    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 141    document are to be interpreted as described in RFC 2119 [3].
 142
 143 2. SSH Host Key Verification
 144
 145 2.1 Method
 146
 147    Upon connection to a SSH server, the SSH client MAY look up the SSHFP
 148    resource record(s) for the host it is connecting to.  If the
 149    algorithm and fingerprint of the key received from the SSH server
 150    match the algorithm and fingerprint of one of the SSHFP resource
 151    record(s) returned from DNS, the client MAY accept the identity of
 152    the server.
 153
 154 2.2 Implementation Notes
 155
 156    Client implementors SHOULD provide a configurable policy used to
 157    select the order of methods used to verify a host key. This document
 158    defines one method: Fingerprint storage in DNS. Another method
 159    defined in the SSH Architecture [6] uses local files to store keys
 160    for comparison. Other methods that could be defined in the future
 161    might include storing fingerprints in LDAP or other databases. A
 162
 163
 164
 165 Schlyter & Griffin       Expires March 5, 2004                  [Page 3]
 166
 167 Internet-Draft          DNS and SSH Fingerprints          September 2003
 168
 169
 170    configurable policy will allow administrators to determine which
 171    methods they want to use and in what order the methods should be
 172    prioritized. This will allow administrators to determine how much
 173    trust they want to place in the different methods.
 174
 175    One specific scenario for having a configurable policy is where
 176    clients do not use fully qualified host names to connect to servers.
 177    In this scenario, the implementation SHOULD verify the host key
 178    against a local database before verifying the key via the fingerprint
 179    returned from DNS. This would help prevent an attacker from injecting
 180    a DNS search path into the local resolver and forcing the client to
 181    connect to a different host.
 182
 183 2.3 Fingerprint Matching
 184
 185    The public key and the SSHFP resource record are matched together by
 186    comparing algorithm number and fingerprint.
 187
 188       The public key algorithm and the SSHFP algorithm number MUST
 189       match.
 190
 191       A message digest of the public key, using the message digest
 192       algorithm specified in the SSHFP fingerprint type, MUST match the
 193       SSHFP fingerprint.
 194
 195
 196 2.4 Authentication
 197
 198    A public key verified using this method MUST NOT be trusted if the
 199    SSHFP resource record (RR) used for verification was not
 200    authenticated by a trusted SIG RR.
 201
 202    Clients that do validate the DNSSEC signatures themselves SHOULD use
 203    standard DNSSEC validation procedures.
 204
 205    Clients that do not validate the DNSSEC signatures themselves MUST
 206    use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8],
 207    between themselves and the entity performing the signature
 208    validation.
 209
 210 3. The SSHFP Resource Record
 211
 212    The SSHFP resource record (RR) is used to store a fingerprint of a
 213    SSH public host key that is associated with a Domain Name System
 214    (DNS) name.
 215
 216    The RR type code for the SSHFP RR is TBA.
 217
 218
 219
 220
 221 Schlyter & Griffin       Expires March 5, 2004                  [Page 4]
 222
 223 Internet-Draft          DNS and SSH Fingerprints          September 2003
 224
 225
 226 3.1 The SSHFP RDATA Format
 227
 228    The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
 229    type and the fingerprint of the public host key.
 230
 231          1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 232          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
 233          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 234          |   algorithm   |    fp type    |                               /
 235          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
 236          /                                                               /
 237          /                          fingerprint                          /
 238          /                                                               /
 239          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 240
 241
 242 3.1.1 Algorithm Number Specification
 243
 244    This algorithm number octet describes the algorithm of the public
 245    key.  The following values are assigned:
 246
 247           Value    Algorithm name
 248           -----    --------------
 249           0        reserved
 250           1        RSA
 251           2        DSS
 252
 253    Reserving other types requires IETF consensus [4].
 254
 255 3.1.2 Fingerprint Type Specification
 256
 257    The fingerprint type octet describes the message-digest algorithm
 258    used to calculate the fingerprint of the public key.  The following
 259    values are assigned:
 260
 261           Value    Fingerprint type
 262           -----    ----------------
 263           0        reserved
 264           1        SHA-1
 265
 266    Reserving other types requires IETF consensus [4].
 267
 268    For interoperability reasons, as few fingerprint types as possible
 269    should be reserved.  The only reason to reserve additional types is
 270    to increase security.
 271
 272 3.1.3 Fingerprint
 273
 274
 275
 276
 277 Schlyter & Griffin       Expires March 5, 2004                  [Page 5]
 278
 279 Internet-Draft          DNS and SSH Fingerprints          September 2003
 280
 281
 282    The fingerprint is calculated over the public key blob as described
 283    in [7].
 284
 285    The message-digest algorithm is presumed to produce an opaque octet
 286    string output which is placed as-is in the RDATA fingerprint field.
 287
 288 3.2 Presentation Format of the SSHFP RR
 289
 290    The RDATA of the presentation format of the SSHFP resource record
 291    consists of two numbers (algorithm and fingerprint type) followed by
 292    the fingerprint itself presented in hex, e.g:
 293
 294          host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890
 295
 296    The use of mnemonics instead of numbers is not allowed.
 297
 298 4. Security Considerations
 299
 300    Currently, the amount of trust a user can realistically place in a
 301    server key is proportional to the amount of attention paid to
 302    verifying that the public key presented actually corresponds to the
 303    private key of the server. If a user accepts a key without verifying
 304    the fingerprint with something learned through a secured channel, the
 305    connection is vulnerable to a man-in-the-middle attack.
 306
 307    The overall security of using SSHFP for SSH host key verification is
 308    dependent on the security policies of the SSH host administrator and
 309    DNS zone administrator (in transferring the fingerprint), detailed
 310    aspects of how verification is done in the SSH implementation, and in
 311    the client's diligence in accessing the DNS in a secure manner.
 312
 313    One such aspect is in which order fingerprints are looked up (e.g.
 314    first checking local file and then SSHFP).  We note that in addition
 315    to protecting the first-time transfer of host keys, SSHFP can
 316    optionally be used for stronger host key protection.
 317
 318       If SSHFP is checked first, new SSH host keys may be distributed by
 319       replacing the corresponding SSHFP in DNS.
 320
 321       If SSH host key verification can be configured to require SSHFP,
 322       SSH host key revocation can be implemented by removing the
 323       corresponding SSHFP from DNS.
 324
 325    As stated in Section 2.2, we recommend that SSH implementors provide
 326    a policy mechanism to control the order of methods used for host key
 327    verification. One specific scenario for having a configurable policy
 328    is where clients use unqualified host names to connect to servers. In
 329    this case, we recommend that SSH implementations check the host key
 330
 331
 332
 333 Schlyter & Griffin       Expires March 5, 2004                  [Page 6]
 334
 335 Internet-Draft          DNS and SSH Fingerprints          September 2003
 336
 337
 338    against a local database before verifying the key via the fingerprint
 339    returned from DNS. This would help prevent an attacker from injecting
 340    a DNS search path into the local resolver and forcing the client to
 341    connect to a different host.
 342
 343    A different approach to solve the DNS search path issue would be for
 344    clients to use a trusted DNS search path, i.e., one not acquired
 345    through DHCP or other autoconfiguration mechanisms. Since there is no
 346    way with current DNS lookup APIs to tell whether a search path is
 347    from a trusted source, the entire client system would need to be
 348    configured with this trusted DNS search path.
 349
 350    Another dependency is on the implementation of DNSSEC itself.  As
 351    stated in Section 2.4, we mandate the use of secure methods for
 352    lookup and that SSHFP RRs are authenticated by trusted SIG RRs.  This
 353    is especially important if SSHFP is to be used as a basis for host
 354    key rollover and/or revocation, as described above.
 355
 356    Since DNSSEC only protects the integrity of the host key fingerprint
 357    after it is signed by the DNS zone administrator, the fingerprint
 358    must be transferred securely from the SSH host administrator to the
 359    DNS zone administrator.  This could be done manually between the
 360    administrators or automatically using secure DNS dynamic update [11]
 361    between the SSH server and the nameserver.  We note that this is no
 362    different from other key enrollment situations, e.g. a client sending
 363    a certificate request to a certificate authority for signing.
 364
 365 5. IANA Considerations
 366
 367    IANA needs to allocate a RR type code for SSHFP from the standard RR
 368    type space (type 44 requested).
 369
 370    IANA needs to open a new registry for the SSHFP RR type for public
 371    key algorithms.  Defined types are:
 372
 373          0 is reserved
 374          1 is RSA
 375          2 is DSA
 376
 377     Adding new reservations requires IETF consensus [4].
 378
 379    IANA needs to open a new registry for the SSHFP RR type for
 380    fingerprint types.  Defined types are:
 381
 382          0 is reserved
 383          1 is SHA-1
 384
 385     Adding new reservations requires IETF consensus [4].
 386
 387
 388
 389 Schlyter & Griffin       Expires March 5, 2004                  [Page 7]
 390
 391 Internet-Draft          DNS and SSH Fingerprints          September 2003
 392
 393
 394 Normative References
 395
 396    [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
 397         13, RFC 1034, November 1987.
 398
 399    [2]  Mockapetris, P., "Domain names - implementation and
 400         specification", STD 13, RFC 1035, November 1987.
 401
 402    [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 403         Levels", BCP 14, RFC 2119, March 1997.
 404
 405    [4]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
 406         Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 407
 408    [5]  Eastlake, D., "Domain Name System Security Extensions", RFC
 409         2535, March 1999.
 410
 411    [6]  Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
 412         Lehtinen, "SSH Protocol Architecture",
 413         draft-ietf-secsh-architecture-14 (work in progress), July 2003.
 414
 415    [7]  Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
 416         Lehtinen, "SSH Transport Layer Protocol",
 417         draft-ietf-secsh-transport-16 (work in progress), July 2003.
 418
 419 Informational References
 420
 421    [8]   Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
 422          Roadmap", RFC 2411, November 1998.
 423
 424    [9]   Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
 425          "Secret Key Transaction Authentication for DNS (TSIG)", RFC
 426          2845, May 2000.
 427
 428    [10]  Eastlake, D., "DNS Request and Transaction Signatures (
 429          SIG(0)s)", RFC 2931, September 2000.
 430
 431    [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
 432          Update", RFC 3007, November 2000.
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445 Schlyter & Griffin       Expires March 5, 2004                  [Page 8]
 446
 447 Internet-Draft          DNS and SSH Fingerprints          September 2003
 448
 449
 450 Authors' Addresses
 451
 452    Jakob Schlyter
 453    OpenSSH
 454    812 23rd Avenue SE
 455    Calgary, Alberta  T2G 1N8
 456    Canada
 457
 458    EMail: jakob@openssh.com
 459    URI:   http://www.openssh.com/
 460
 461
 462    Wesley Griffin
 463    SPARTA
 464    7075 Samuel Morse Drive
 465    Columbia, MD  21046
 466    USA
 467
 468    EMail: wgriffin@sparta.com
 469    URI:   http://www.sparta.com/
 470
 471 Appendix A. Acknowledgements
 472
 473    The authors gratefully acknowledge, in no particular order, the
 474    contributions of the following persons:
 475
 476       Martin Fredriksson
 477
 478       Olafur Gudmundsson
 479
 480       Edward Lewis
 481
 482       Bill Sommerfeld
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501 Schlyter & Griffin       Expires March 5, 2004                  [Page 9]
 502
 503 Internet-Draft          DNS and SSH Fingerprints          September 2003
 504
 505
 506 Intellectual Property Statement
 507
 508    The IETF takes no position regarding the validity or scope of any
 509    intellectual property or other rights that might be claimed to
 510    pertain to the implementation or use of the technology described in
 511    this document or the extent to which any license under such rights
 512    might or might not be available; neither does it represent that it
 513    has made any effort to identify any such rights. Information on the
 514    IETF's procedures with respect to rights in standards-track and
 515    standards-related documentation can be found in BCP-11. Copies of
 516    claims of rights made available for publication and any assurances of
 517    licenses to be made available, or the result of an attempt made to
 518    obtain a general license or permission for the use of such
 519    proprietary rights by implementors or users of this specification can
 520    be obtained from the IETF Secretariat.
 521
 522    The IETF invites any interested party to bring to its attention any
 523    copyrights, patents or patent applications, or other proprietary
 524    rights which may cover technology that may be required to practice
 525    this standard. Please address the information to the IETF Executive
 526    Director.
 527
 528
 529 Full Copyright Statement
 530
 531    Copyright (C) The Internet Society (2003). All Rights Reserved.
 532
 533    This document and translations of it may be copied and furnished to
 534    others, and derivative works that comment on or otherwise explain it
 535    or assist in its implementation may be prepared, copied, published
 536    and distributed, in whole or in part, without restriction of any
 537    kind, provided that the above copyright notice and this paragraph are
 538    included on all such copies and derivative works. However, this
 539    document itself may not be modified in any way, such as by removing
 540    the copyright notice or references to the Internet Society or other
 541    Internet organizations, except as needed for the purpose of
 542    developing Internet standards in which case the procedures for
 543    copyrights defined in the Internet Standards process must be
 544    followed, or as required to translate it into languages other than
 545    English.
 546
 547    The limited permissions granted above are perpetual and will not be
 548    revoked by the Internet Society or its successors or assignees.
 549
 550    This document and the information contained herein is provided on an
 551    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 552    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 553    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 554
 555
 556
 557 Schlyter & Griffin       Expires March 5, 2004                 [Page 10]
 558
 559 Internet-Draft          DNS and SSH Fingerprints          September 2003
 560
 561
 562    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 563    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 564
 565
 566 Acknowledgement
 567
 568    Funding for the RFC Editor function is currently provided by the
 569    Internet Society.
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613 Schlyter & Griffin       Expires March 5, 2004                 [Page 11]
 614