Internet DRAFT - draft-vanrein-krb5-kdh

draft-vanrein-krb5-kdh







Network Working Group                                        R. Van Rein
Internet-Draft                                          InternetWide.org
Intended status: Standards Track                        October 11, 2014
Expires: April 14, 2015


   KRB5-KDH: Cryptographically binding Kerberos5 with Diffie-Hellman
                       draft-vanrein-krb5-kdh-00

Abstract

   This specification extends Kerberos5 with primitives that create a
   cryptographic binding between Kerberos5 authentication and Diffie-
   Hellman encryption.  This yields their combined advantages.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 14, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Van Rein                 Expires April 14, 2015                 [Page 1]

Internet-Draft                  krb5-kdh                    October 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  KDH Subkey Specification  . . . . . . . . . . . . . . . . . .   3
   3.  Signalling support for KDH  . . . . . . . . . . . . . . . . .   5
   4.  Negotiating Diffie-Hellman shared secrets . . . . . . . . . .   5
     4.1.  Relation to Kerberos messages . . . . . . . . . . . . . .   6
     4.2.  Negotiating Diffie-Hellman Parameters . . . . . . . . . .   6
   5.  Impact on GSS-API . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Efficiency Considerations . . . . . . . . . . . . . . . . . .   8
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Kerberos5 lends itself well to infrastructure-supported mutual
   authentication, which is mainly used on intranets.  It provides
   additional facilities to authenticate across realm boundaries, in
   which case the control over the network infrastructure used is often
   distributed, and may in extreme usecases be as diverse as the
   Internet.

   In such distributed-control scenario's, it is attractive to enhance
   the encryption facilities of Kerberos with support for Perfect
   Forward Secrecy.  Diffie-Hellman key exchange [RFC2631] can be used
   to incorporate this desirable property, but its lack of
   authentication must then be overcome by cryptographically binding it
   to an authentication mechanism, for which Kerberos itself would be
   suited.

   Kerberos-with-Diffie-Hellman, or KDH for short, defines Kerberos5
   extensions and usage patterns that support this cryptographic binding
   between principals.  Specifically, the session key will be replaced
   with one based on a Diffie-Hellman key exchange that is built into
   AP-REQ and AP-REP messages.  A new ticket flag signals if a foreign
   principal can be expected to implement the KDH mechanism.

   There is no need to change the GSS-API or code using it to deploy
   this mechanism.  Implementations of GSS-API can choose to
   automatically implement the additional subkey mechanism against
   remote principals that support it; the KDC administrator can use the
   new ticket flag to signal that rejection of the KDH mechanism by
   given principals is not to be expected.





Van Rein                 Expires April 14, 2015                 [Page 2]

Internet-Draft                  krb5-kdh                    October 2014


2.  KDH Subkey Specification

   When a client principal initiates mutual authentication against a
   server principal, it sends an AP-REQ message, containing a ticket
   obtained from the KDC.  Appended to this message is a freshly created
   authenticator, which may include an optional subkey field.  The
   normal response is an AP-REP message, with a freshly created enc-part
   appended, which may also include an optional subkey field.

   To setup KDH, the subkey fields in these messages are used for the
   Diffie-Hellman key exchange process.  Being part of the authenticator
   and enc-part fields, the subkey field is subject to encryption with
   the session key that the KDC created for the two parties.  This
   requires the ability to encrypt on the sending side and to decrypt on
   the receiving side, and since each side sends, this mutually proves
   the authenticity of the two principals involved.  In other words, the
   subkey fields are exchanged over an encrypted channel between
   principals whose authenticity is proven by the Kerberos framework.

   Although it would be possible to send one of the subkeys in plain
   text, there is no good reason to do this, and the message formats of
   AP-REQ and AP-REP do not provide a suitable place for it.

   The subkey fields defined for KDH have encryption types labelled dh-
   param-pubkey, dh-pubkey, ecdh-param-pubkey and ecdh-pubkey.  The dh-
   and ecdh- are similar, but reflect Diffie-Hellman and its Elliptic
   Curve variation, respectively.  The -param-pubkey version represents
   both a Diffie-Hellman paramaters type and a public key, where the
   other -pubkey variations represent just the Diffie-Hellman public
   key.  More formally,





















Van Rein                 Expires April 14, 2015                 [Page 3]

Internet-Draft                  krb5-kdh                    October 2014


   -- The type of a dh-param-pubkey subkey:
   DHParamsPubkey ::= struct {
      INTEGER etype2;      -- Encryption Type
      ServerDHParams params;   -- From RFC 5246
      pktype pubkey;       -- Defined below
   };

   -- The type of a dh-pubkey subkey:
   DHPubkey ::= struct {
      pktype pubkey;       -- Defined below
   };

   -- Type pktype matches dh_Ys or dh_Yc as defined in RFC 5246
   -- Value is a DH public-key value (g^X mod p)
   pktype ::= opaque pubkey<1..2^16-1>;

   -- The type of a ecdh-param-pubkey subkey:
   ECDHParamsPubkey ::= struct {
      INTEGER etype2;      -- Encryption Type
      ECParameters params;         -- From RFC 4492
      ECPoint pubkey;      -- From RFC 4492
   };

   -- The type of a ecdh-pubkey subkey:
   ECDHPubkey ::= struct {
      ECPoint pubkey;      -- From RFC 4492
   }

   The etype2 fields provide the encryption type to be applied once the
   (Elliptic-Curve) Diffie-Hellman shared secret has been derived.  The
   possible values for this field are defined in the IANA Registry for
   Kerberos Encryption Type Numbers.

   A Diffie-Hellman key generated for use in the subkey field of an AP-
   REQ authenticator or AP-REP enc-part SHOULD NOT be used in any other
   messages, except for literal resends of messages to overcome network
   connectivity problems.  A principal that conforms to this principle
   enforces variation in the session keys, and so there is no gain to be
   had from a replay attack by the other side.  This means that a
   conforming principal MAY bypass checks for replay attacks on its
   side, and also that the current session does not need to be stored in
   a replay buffer that may still exist in support of non-KDH traffic.

   NOTE: The replay buffer is mostly useful in service principals; these
   may also be contacted by user principals that do not implement KDH.
   In such cases, the replay buffer must be used.  This means that the
   replay buffer must still be implemented, but it is easier to scale,




Van Rein                 Expires April 14, 2015                 [Page 4]

Internet-Draft                  krb5-kdh                    October 2014


   and also, a lower performance level may be tolerable if switching to
   KDH on the client is a realistic alternative.

3.  Signalling support for KDH

   When KDH is used, the AP-REQ message MUST offer a -param-pubkey
   encryption type.  When the subkey offer is accepted by a remote
   principal, its AP-REP response MUST contain a subkey with the -pubkey
   encryption type for the same algorithm (DH or ECDH).

   A recipient uncapable of KDH will reject the subkey in the AP-REQ
   message and report an error instead of the expected AP-REP message.
   This error is not authenticated in Kerberos5, meaning that a
   potential of denial-of-service against KDH exists.  An opportunistic
   procedure might try KDH and fall back to Kerberos5 without Diffie-
   Hellman, but such an approach would make the stack vulnerable to
   denial-of-service attacks that result in bypassing Perfect Forward
   Secrecy.

   To mitigate this problem on the client side, we introduce a ticket
   flag have-kdh, that may be set by the KDC on tickets delivered as
   part of KDC-REP messages.  When a ticket for a remote principal has
   this flag set, there is no reason for a KDH-capable sender to ever
   send it a message without a subkey following KDH formatting; so,
   there is never a need to bypass Perfect Forward Secrecy.

   On the server side, things are much simpler.  An AP-REP message from
   a conforming implementation MUST incorporate a Diffie-Hellman subkey
   field if and only if the responded-to AP-REQ message held a Diffie-
   Hellman subkey field.  This is the behaviour of a Kerberos5
   implementation that supports KDH; unsupporting implementations would
   return an empty subkey field or, more likely, respond with an error
   message.  This behaviour is only acceptable from principals whose
   have-kdh flag is disabled in the KDC.

   It is possible to send AP-REQ with KDH to a principal without the
   have-kdh flag, but the behaviour of unsupporting implementations
   means that fallback to an AP-REQ without KDH may be required when
   failures are reported.  In cases where this opportunistic approach to
   KDH succeeds, the advantage is that passive observation is now
   subject to Perfect Forward Secrecy.

4.  Negotiating Diffie-Hellman shared secrets

   This specification defines how the introduced subkey encryption types
   may be used.  Other uses SHOULD lead to an encryption type errors,
   unless future specifications extend upon the behaviour.




Van Rein                 Expires April 14, 2015                 [Page 5]

Internet-Draft                  krb5-kdh                    October 2014


4.1.  Relation to Kerberos messages

   The Diffie-Hellman subkey encryption types are defined for use with
   the AP-REQ and AP-REP messages.  These messages are assumed to occur
   as a pair, and the permitted combinations of these messages with
   encryption types is defined in the following table:

   +--------------------+--------------------+-------------------------+
   | AP-REQ enctype     | AP-REP enctype     | Meaning                 |
   +--------------------+--------------------+-------------------------+
   | dh-params-pubkey   | dh-pubkey          | Construction of shared  |
   |                    |                    | secret                  |
   | dh-params-pubkey   | dh-params-pubkey   | Rejected parameters;    |
   |                    |                    | new suggestion          |
   | dh-params-pubkey   | ecdh-params-pubkey | Rejected plain DH;      |
   |                    |                    | suggest ECDH            |
   | ecdh-params-pubkey | ecdh-pubkey        | Construction of shared  |
   |                    |                    | secret                  |
   | ecdh-params-pubkey | dh-params-pubkey   | Rejected ECDH; suggest  |
   |                    |                    | plain DH                |
   +--------------------+--------------------+-------------------------+

   After both AP-REQ and AP-REP have been processed, and their joint
   meaning in the table above indicates that a shared secret can be
   constructed, then both parties MUST derive that shared secret and
   continue to communicate using that, employing the encryption type
   specified in the AP-REQ message's subkey field, notably the etype2
   subtype.

   The only exception to this enforced encryption will be any further
   AP-REQ and AP-REP messages which MUST NOT be subjected to the newly
   derived subkey, but to the session key provided by the KDC.

   These semantics of enforced encryption are required with every use of
   the syntax introduced by this specification.

4.2.  Negotiating Diffie-Hellman Parameters

   Given that an authenticated source supplies Diffie-Hellman parameters
   as part of the subkey field, they can be assumed to be protected from
   rogue influence that would jeapourdise their security.  Still, the
   option exists that principals' realms enforce different policies.
   This raises the issue of negotiation about Diffie-Hellman parameters.

   In the previous subsection, situations were described that reject the
   algorithm (plain Diffie-Hellman or Elliptic-Curve Diffie-Hellman) and
   that reject the parameters suggested within the algorithm.  These
   usage forms represent a rejection of the subkey suggestion in an AP-



Van Rein                 Expires April 14, 2015                 [Page 6]

Internet-Draft                  krb5-kdh                    October 2014


   REQ message.  If left unhandled, the client's subkey field may be
   considered rejected by the server, but it is preferred that the
   client instead engages in another AP-REQ / AP-REP exchange based on
   the suggested response.

   Most of this discussion comes down to desired minimum modulus,
   generator and generator-order sizes (for reasons of security) and
   maximum modulus sizes (for reasons of efficiency, and perhaps to
   counter denial-of-service on public services).  In addition, there
   may be a whitelist or blacklist of certain Diffie-Hellman parameters.
   We suggest that implementations SHOULD aim to accept at least all
   RFC-published Diffie-Hellman parameters [RFC5114] that have an
   acceptable modulus, generator and generator-order, inasfar as they
   have not been publicly withdrawn.  In addition, we suggest that
   offered Diffie-Hellman parameters are selected from RFC-published
   sources of acceptable sizes that have not been publicly withdrawn.

   If a service receives Diffie-Hellman parameters that it dislikes,
   then it includes newly proposed Diffie-Hellman parameters in the
   response.  If the proposal is rejected because aspects of the
   parameters fall under a set minimum, then the response should propose
   the smallest acceptable parameters.  If the proposal is rejected
   because the modulus is too long, then the response should propose
   parameters with the longest acceptable modulus (and generator).  If
   the proposal is rejected because the keys are blacklisted and/or not
   whitelisted, then the response should propose an alternative whose
   modulus and generator are "similar", according to the service's
   interpretation.

   Each participant MAY impose a maximum on the number of iterations.
   And all participants SHOULD be liberal in what they accept, and
   conservative in what they send.  This should mean that most the
   negotiations do find a suitable configuration.

5.  Impact on GSS-API

   This specification does not alter the GSS-API interface.  The only
   thing that requires a change to integrate KDH is the Kerberos5
   implementation of GSS-API.

   When requesting a principal ticket, a supporting implementation
   SHOULD send an KDC-REQ message including the have-kdh ticket flag.
   According to the general behaviour of Kerberos5, the KDC will not
   return the flag if it either does not understand the flag, or if it
   rejects it on grounds of the KDC policy.  Only when requested in the
   KDC-REQ and only if the requested principal is setup to enable the
   have-kdh ticket flag, may the flag be set in the ticket returned from
   the KDC.  These remarks apply to all interactions with the KDC, even



Van Rein                 Expires April 14, 2015                 [Page 7]

Internet-Draft                  krb5-kdh                    October 2014


   when obtaining a Ticket Granting Ticket; so even the interactions
   with the Ticket Granting Service may be protected under Perfect
   Forward Secrecy.

   Based on the ticket flag have-kdh, a GSS-API implementation can
   decide whether to supply a subkey field with a Diffie-Hellman public
   key.  More precisely, after sending an AP-REQ message with a KDH
   subkey it is crystal clear whether to be assured that a corresponding
   subkey will be sent back in the AP-REQ message, after which it is
   possible to continue with the Diffie-Hellman shared secret.

   Note that sending the subkey field with a Diffie-Hellman public key
   implies a responsibility to actually use it after the AP-REQ and AP-
   REP messages have been exchanged.  The KDC-supplied session key MUST
   NOT be used after such an exchange, except for new AP-REQ and AP-REP
   messages.  If the remote principal would use the KDC-supplied session
   key, it SHOULD receive an appropriate error message in return.

6.  Efficiency Considerations

   The Kerberos5 mechanism is among the most efficient frameworks for
   secure authentication in the World.  This is a direct result of its
   reliance on symmetric cryptography.  The one downside to this is that
   a user must stay in contact with the KDC to request new tickets.

   As for Perfect Forward Secrecy, this currently requires Diffie-
   Hellman key exchanges.  The minimum amount of work for this algorithm
   is done as part of KDH.

   It is not possible to perform the work done by the KDH combination of
   mechanisms in either Kerberos or Diffie-Hellman, so the two need to
   work together.  Furthermore, the way the two mechanisms are
   cryptographically bound together is almost optimal; there is a
   minimal need to encrypt at least one of the Diffie-Hellman key
   exchange messages, but encrypting both hardly adds work.

   Finally, the use of fresh Diffie-Hellman keys for every authenticator
   to an AP-REQ and for every enc-part to an AP-REP with the encryption
   types introduced in this specification has the benefit that a replay
   cache can be bypassed.  This saves a complex structure that is
   difficult to integrate into large-scale / redundant principal
   implementations.  In cases where the replay cache is not always used,
   at least this complex structure is used less, making it weigh only on
   the applications that do not implement Diffie-Hellman key exchange,
   and only those will need to fill the replay cache.






Van Rein                 Expires April 14, 2015                 [Page 8]

Internet-Draft                  krb5-kdh                    October 2014


7.  Privacy Considerations

   The information shared publicly by this protocol does not exceed what
   is published by other Kerberos5 implementations.  The only added
   field is the subkey field, whose presence may be inferred from the
   message size, but its value is invisible to third parties because
   Kerberos encrypts it.

   Overall, the privacy of the principals' sessions improves when KDH is
   applied, because future breakage of Kerberos5 credentials would not
   enable the decryption of a recorded session.

8.  Security Considerations

   The Diffie-Hellman key exchange can be performed in plain text,
   provided that it is authenticated.  Kerberos5 implements
   authentication through encryption of the text or its secure hash; KDH
   encrypts the entire Diffie-Hellman key exchange for reasons of
   protocol simplicity.

   In Kerberos5, session keys are supplied by the KDC.  This realm
   service must be properly shielded from outside attacks, because it is
   a vital point in the Kerberos5 infrastructure.

   The importance of KDC security does not necessarily reduce with KDH;
   parties that can read the KDC-generated session key between a pair of
   principals are in a position to mount an undetectable man-in-the-
   middle attack on the session even when KDH is added.

   When client and server are in different realms, they have cross-
   signed directly or through a chain of KDC's, and all KDC's involved
   are potential places where the session key could be determined.  The
   weakest KDC in the chain then defines the security of the entire
   chain.

   Kerberos5 has introduced numerous refinements that are highly
   practical in daily use.  One worth noting is S4U2Proxy, under which a
   service can upgrade a received ticket to one with which it can be a
   client using a ticket with the client's authenticated name.  Such
   provisions are usually limited in the KDC through Constrained
   Delegation, but it nonetheless introduces an extra degree of freedom
   for attackers.  Especially interesting is the combination with
   S4U2Self, which allows a service to obtain a client ticket without
   proving (in the Kerberos sense) that the client has actually
   authenticated to, or even contacted the server.

   Kerberos requires accurate clocks in order to operate securely;
   without it, once-used and since-forgotten credentials could be



Van Rein                 Expires April 14, 2015                 [Page 9]

Internet-Draft                  krb5-kdh                    October 2014


   replayed by an attacker that has been able to recover an old service
   ticket's session key.  This problem is worsened in cross-realm
   scenario's where clock synchronisation may be more difficult to
   realise.  This is overcome when KDH is used with freshly generated
   Diffie-Hellman keys, but clients are never forced by this
   specification to send an AP-REQ with a Diffie-Hellman key, so replay
   attack handling is still needed to serve non-KDH clients securely.

9.  IANA Considerations

   This specification introduces four Diffie-Hellman exchange formats to
   be added to the registry of Encryption Type Numbers, representing a
   subkey field that matches the syntax as specified below:

   +--------+-----------------------------+----------------------------+
   | Number | Kerberos Encryption Type    | Syntax Corresponding to    |
   |        | Name                        |                            |
   +--------+-----------------------------+----------------------------+
   | TBD    | dh-param-pubkey             | [THIS SPEC] DHParamsPubkey |
   | TBD    | dh-pubkey                   | [THIS SPEC] DHPubkey       |
   | TBD    | ecdh-param-pubkey           | [THIS SPEC]                |
   |        |                             | ECDHParamsPubkey           |
   | TBD    | ecdh-pubkey                 | [THIS SPEC] ECDHPubkey     |
   +--------+-----------------------------+----------------------------+

   This specification also introduces a new entry in the Kerberos
   registry for Ticket flag.  The flag is named have-kdh:

   TicketFlags ::= KerberosFlags
       -- have-kdh(TBD)

10.  Normative References

   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
              2631, June 1999.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
              for Transport Layer Security (TLS)", RFC 4492, May 2006.

   [RFC5114]  Lepinski, M. and S. Kent, "Additional Diffie-Hellman
              Groups for Use with IETF Standards", RFC 5114, January
              2008.





Van Rein                 Expires April 14, 2015                [Page 10]

Internet-Draft                  krb5-kdh                    October 2014


Author's Address

   Rick van Rein
   InternetWide.org
   Haarlebrink 5
   Enschede, Overijssel  7544 WP
   The Netherlands

   Email: rick@openfortress.nl










































Van Rein                 Expires April 14, 2015                [Page 11]