doc/standardisation/draft-josefsson-kerberos5-starttls-00.txt

   1 Network Working Group                                       S. Josefsson
   2 Internet-Draft                                         November 13, 2004
   3 Expires: May 14, 2005
   4
   5
   6           Using Transport Layer Security (TLS) with Kerberos 5
   7                  draft-josefsson-kerberos5-starttls-00
   8
   9 Status of this Memo
  10
  11    This document is an Internet-Draft and is subject to all provisions
  12    of section 3 of RFC 3667.  By submitting this Internet-Draft, each
  13    author represents that any applicable patent or other IPR claims of
  14    which he or she is aware have been or will be disclosed, and any of
  15    which he or she become aware will be disclosed, in accordance with
  16    RFC 3668.
  17
  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
  21    Internet-Drafts.
  22
  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."
  27
  28    The list of current Internet-Drafts can be accessed at
  29    http://www.ietf.org/ietf/1id-abstracts.txt.
  30
  31    The list of Internet-Draft Shadow Directories can be accessed at
  32    http://www.ietf.org/shadow.html.
  33
  34    This Internet-Draft will expire on May 14, 2005.
  35
  36 Copyright Notice
  37
  38    Copyright (C) The Internet Society (2004).
  39
  40 Abstract
  41
  42    This document specify how the Transport Layer Security (TLS) protocol
  43    is used in conjunction with the Kerberos 5 protocol.
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53 Josefsson                 Expires May 14, 2005                  [Page 1]
  54
  55 Internet-Draft         Using TLS with Kerberos 5           November 2004
  56
  57
  58 Table of Contents
  59
  60    1.  Introduction and Background  . . . . . . . . . . . . . . . . .  3
  61    2.  Extension Mechanism for TCP/IP transport . . . . . . . . . . .  4
  62    3.  Kerberos 5 STARTTLS Extension  . . . . . . . . . . . . . . . .  4
  63      3.1   STARTTLS requested by client (extension 1) . . . . . . . .  4
  64      3.2   STARTTLS request accepted by server (extension 2)  . . . .  5
  65      3.3   Proceeding after successful TLS negotiation  . . . . . . .  5
  66      3.4   Proceeding after failed TLS negotiation  . . . . . . . . .  5
  67      3.5   STARTTLS aware KDC Discovery . . . . . . . . . . . . . . .  5
  68      3.6   Initial Authentication via TLS . . . . . . . . . . . . . .  5
  69    4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
  70    5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
  71    5.1   Normative References . . . . . . . . . . . . . . . . . . . .  6
  72    5.2   Informative References . . . . . . . . . . . . . . . . . . .  6
  73        Author's Address . . . . . . . . . . . . . . . . . . . . . . .  7
  74        Intellectual Property and Copyright Statements . . . . . . . .  8
  75
  76
  77
  78
  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 Josefsson                 Expires May 14, 2005                  [Page 2]
 110
 111 Internet-Draft         Using TLS with Kerberos 5           November 2004
 112
 113
 114 1.  Introduction and Background
 115
 116    This document describe how Shishi, a Kerberos 5 [1] implementation,
 117    upgrade communication between clients and Key Distribution Centers
 118    (KDCs) to use the Transport Layer Security (TLS) [2] protocol.
 119
 120    The TLS protocol offer integrity and privacy protected exchanges that
 121    can be authentication using X.509 certificates, OpenPGP keys [6], and
 122    user name and passwords via SRP [5].
 123
 124    An inconclusive list of the motivation for using TLS with Kerberos 5
 125    is given below.
 126
 127    o  Explicit server authentication of the KDC to the client.  In
 128       traditional Kerberos 5, authentication of the KDC is proved as a
 129       side effect that the KDC knows your encryption key (i.e., your
 130       password).
 131
 132    o  Flexible authentication against KDC.  Kerberos 5 assume the user
 133       knows a key (usually in the form of a password).  Sometimes
 134       external factors make this hard to fulfill.  In some situations,
 135       users are equipped with smart cards with a RSA authentication key.
 136       In others, users have a OpenPGP client on their desktop, with a
 137       public OpenPGP key known to the server.  In some situations, the
 138       policy may be that password authentication may only be done
 139       through SRP.
 140
 141    o  Kerberos exchanges are privacy protected.  Part of many Kerberos
 142       packets are transfered without privacy protection (i.e.,
 143       encryption).  That part contains information, such as the client
 144       principal name, the server principal name, the encryption types
 145       supported by the client, the lifetime of tickets, etc.  Revealing
 146       such information is, in some threat models, considered a problem.
 147
 148    o  Prevents downgrade attacks affecting encryption types.  The
 149       encryption type of the ticket in KDC-REQ are sent in the clear in
 150       Kerberos 5.  This allows an attacker to replace the encryption
 151       type with a compromised mechanisms, e.g.  56-bit DES.  Since
 152       clients in general cannot know the encryption types other servers
 153       support, it is difficult for the client to detect if there was a
 154       man-in-the-middle or if the remote server simply did not support a
 155       stronger mechanism.  Clients could chose to refuse 56-bit DES
 156       altogether, but in some environments this leads to operational
 157       difficulties.
 158
 159    o  The TLS protocol has been studied by many parties.  In some threat
 160       models, the designer prefer to reduce the number of protocols that
 161       can hurt the overall system security if they are compromised.
 162
 163
 164
 165 Josefsson                 Expires May 14, 2005                  [Page 3]
 166
 167 Internet-Draft         Using TLS with Kerberos 5           November 2004
 168
 169
 170    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 171    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 172    document are to be interpreted as described in RFC 2119 [4].
 173
 174 2.  Extension Mechanism for TCP/IP transport
 175
 176    Kerberos 5 require Key Distribution Centers (KDCs) to accept requests
 177    over TCP.  Each request and response is prefixed by 4 octets,
 178    encoding an integer in network byte order, that indicate the length
 179    of the packet.  The high bit of the 4 octet length field was reserved
 180    for future expansion.  Servers that do not understand how to
 181    interpret a set high bit are required to return a KRB-ERROR with the
 182    KRB_ERR_FIELD_TOOLONG error code, and to close the TCP stream.
 183
 184    We will use the reserved bit to provide an extension mechanism.  When
 185    the reserved high bit is set, the remaining 31 bits of the 4 octets
 186    are treated as an extensible typed hole, and thus form a 31 bit
 187    integer enumerating various extensions.  Each of the values indicate
 188    a specific extended operation mode, two of which are used and defined
 189    here, and the rest are left for others to use.
 190
 191    If the KDC do not understand a requested extension, it MUST return a
 192    KRB-ERROR with a KRB_ERR_FIELD_TOOLONG value (prefixed by the 4 octet
 193    length integer, with the high bit clear, as usual) and close the TCP
 194    stream.
 195
 196    The following table specify the meaning of the 31 lower bits in the 4
 197    octet field, when the high bit is set:
 198
 199    0               RESERVED.
 200    1               STARTTLS requested by client.
 201    2               STARTTLS request accepted by server.
 202    3...2147483647  AVAILABLE for registration (via bug-shishi@josefsson.org)
 203 .
 204    2147483648      RESERVED.
 205
 206
 207 3.  Kerberos 5 STARTTLS Extension
 208
 209 3.1  STARTTLS requested by client (extension 1)
 210
 211    When this message is sent by the client, the client is requesting the
 212    server to start TLS negotiation on the TCP stream.  The client MUST
 213    NOT start TLS negotiation immediately.  Instead, the client wait for
 214    either a KRB-ERROR (sent normally, prefixed by a 4 octet length
 215    integer) indicating the server do not understand the set high bit, or
 216    4 octets which is to be interpreted as an integer in network byte
 217    order, where the high bit is set and the remaining 31 bit are
 218    interpreted as an integer specifying ``STARTTLS request accepted by
 219
 220
 221
 222 Josefsson                 Expires May 14, 2005                  [Page 4]
 223
 224 Internet-Draft         Using TLS with Kerberos 5           November 2004
 225
 226
 227    server'' (extension 2).  In the first case, the client infer that the
 228    server do not understand (or wish to support) STARTTLS, and can
 229    re-try using normal TCP, if unprotected Kerberos 5 exchanges are
 230    acceptable to the client policy.  In the latter case, it should
 231    invoke TLS negotiation on the stream.  If any other data is received,
 232    the client MUST close the TCP stream.
 233
 234 3.2  STARTTLS request accepted by server (extension 2)
 235
 236    This message should be sent by the server when it has received the
 237    extension 1 message.  The message is an acknowledgment of the
 238    client's request to initiate STARTTLS on the channel.  The server
 239    MUST then invoke a TLS negotiation.
 240
 241 3.3  Proceeding after successful TLS negotiation
 242
 243    If the TLS negotiation ended successfully, possibly also considering
 244    client or server policies, the exchange within the TLS protected
 245    stream is performed like normal UDP Kerberos 5 exchanges, i.e., there
 246    is no TCP 4 octet length field before each packet.  Instead each
 247    Kerberos packet MUST be sent within one TLS record, so the
 248    application can use the TLS record length as the Kerberos 5 packet
 249    length.
 250
 251 3.4  Proceeding after failed TLS negotiation
 252
 253    If the TLS negotiation fails, possibly due to client or server policy
 254    (e.g., inadequate support of encryption types in TLS, or lack of
 255    client or server authentication) the entity that detect the failure
 256    MUST disconnected the connection.  It is expected that any error
 257    messages that explain the error condition is transfered by TLS.
 258
 259 3.5  STARTTLS aware KDC Discovery
 260
 261    Section 7.2.3 of Kerberos 5 [1] describe how Domain Name System (DNS)
 262    SRV records [3] can be used to find the address of an KDC.  To locate
 263    a KDC that support the STARTTLS extension, we use the "_tls" domain.
 264    For example:
 265
 266    _kerberos._tls._tcp.EXAMPLE.COM.   IN      SRV     0 0 88 kdc1.example.com.
 267    _kerberos._tls._tcp.EXAMPLE.COM.   IN      SRV     1 0 88 kdc2.example.com.
 268
 269
 270 3.6  Initial Authentication via TLS
 271
 272    The server MAY consider the authentication performed by the TLS
 273    exchange as sufficient to issue Kerberos 5 tickets to the client,
 274    without requiring, e.g., pre-authentication.  However, it is not an
 275
 276
 277
 278 Josefsson                 Expires May 14, 2005                  [Page 5]
 279
 280 Internet-Draft         Using TLS with Kerberos 5           November 2004
 281
 282
 283    error to require or use pre-authentication as well.
 284
 285    The client may also indicate that it wishes to use TLS both for
 286    authentication and data protection by using the NULL encryption type
 287    in its request.  The server can decide from its local policy whether
 288    or not issuing tickets based solely on TLS authentication, and
 289    whether NULL encryption within TLS, is acceptable or not.
 290
 291 4.  Security Considerations
 292
 293    Because the initial token is not protected, it is possible for an
 294    active attacker to make it appear to the client that the server do
 295    not support this extension.  It is up to client configuration to
 296    disallow non-TLS connections, if that vulnerability is deemed
 297    unacceptable.  For interoperability, we suggest the default behaviour
 298    should be to allow automatic fall back to TCP or UDP.
 299
 300    The security considerations of both TLS and Kerberos 5 are inherited.
 301    Using TLS for authentication and/or data protection together with
 302    Kerberos alter the authentication logic fundamentally.  Thus, it may
 303    be that even if the TLS and Kerberos 5 protocols and implementations
 304    were secure, the combination of TLS and Kerberos 5 described here
 305    could be insecure.
 306
 307    No channel bindings are provided in the Kerberos messages.  It is an
 308    open question whether, and how, this could be solved.  One idea for
 309    solving this may be to specify a new encryption algorithm in Kerberos
 310    5 that is similar to the NULL encryption algorithm, but also include
 311    the TLS session identifier.
 312
 313 5.  References
 314
 315 5.1  Normative References
 316
 317    [1]  Neuman, C., "The Kerberos Network Authentication Service (V5)",
 318         draft-ietf-krb-wg-kerberos-clarifications-07 (work in progress),
 319         September 2004.
 320
 321    [2]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
 322         2246, January 1999.
 323
 324    [3]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
 325         specifying the location of services (DNS SRV)", RFC 2782,
 326         February 2000.
 327
 328 5.2  Informative References
 329
 330    [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 331
 332
 333
 334 Josefsson                 Expires May 14, 2005                  [Page 6]
 335
 336 Internet-Draft         Using TLS with Kerberos 5           November 2004
 337
 338
 339         Levels", BCP 14, RFC 2119, March 1997.
 340
 341    [5]  Taylor, D., "Using SRP for TLS Authentication",
 342         draft-ietf-tls-srp-08 (work in progress), August 2004.
 343
 344    [6]  Mavroyanopoulos, N., "Using OpenPGP keys for TLS
 345         authentication", draft-ietf-tls-openpgp-keys-05 (work in
 346         progress), April 2004.
 347
 348
 349 Author's Address
 350
 351    Simon Josefsson
 352
 353    EMail: simon@josefsson.org
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390 Josefsson                 Expires May 14, 2005                  [Page 7]
 391
 392 Internet-Draft         Using TLS with Kerberos 5           November 2004
 393
 394
 395 Intellectual Property Statement
 396
 397    The IETF takes no position regarding the validity or scope of any
 398    Intellectual Property Rights or other rights that might be claimed to
 399    pertain to the implementation or use of the technology described in
 400    this document or the extent to which any license under such rights
 401    might or might not be available; nor does it represent that it has
 402    made any independent effort to identify any such rights.  Information
 403    on the procedures with respect to rights in RFC documents can be
 404    found in BCP 78 and BCP 79.
 405
 406    Copies of IPR disclosures made to the IETF Secretariat and any
 407    assurances of licenses to be made available, or the result of an
 408    attempt made to obtain a general license or permission for the use of
 409    such proprietary rights by implementers or users of this
 410    specification can be obtained from the IETF on-line IPR repository at
 411    http://www.ietf.org/ipr.
 412
 413    The IETF invites any interested party to bring to its attention any
 414    copyrights, patents or patent applications, or other proprietary
 415    rights that may cover technology that may be required to implement
 416    this standard.  Please address the information to the IETF at
 417    ietf-ipr@ietf.org.
 418
 419
 420 Disclaimer of Validity
 421
 422    This document and the information contained herein are provided on an
 423    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 424    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 425    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 426    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 427    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 428    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 429
 430
 431 Copyright Statement
 432
 433    Copyright (C) The Internet Society (2004).  This document is subject
 434    to the rights, licenses and restrictions contained in BCP 78, and
 435    except as set for
 436 th therein, the authors retain all their rights.
 437
 438
 439 Acknowledgment
 440
 441    Funding for the RFC Editor function is currently provided by the
 442    Internet Society.
 443
 444
 445
 446
 447 Josefsson                 Expires May 14, 2005                  [Page 8]