Change GPLv2+ to GPLv3+.

[shishi.git] / doc / specifications / draft-weber-krb-wg-kerberos-pfs-00.txt

INTERNET DRAFT                                         Joel N. Weber II
                                                          July 24, 2003
                                               Expires January 24, 2004

                    Kerberos Perfect Forward Secrecy
                 draft-weber-krb-wg-kerberos-pfs-00.txt

   This document is an Internet-Draft and is subject to all the
   provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   The distribution of this memo is unlimited.  It is filed as draft-
   weber-krb-wg-kerberos-pfs-00.txt, and expires 24 January 2004.
   Please send comments to the author or to ietf-krb-wg@anl.gov

ABSTRACT

   This document defines the use of a Diffie-Hellman exchange in
   Kerberos, both with AP-REQ/AP-REP (in order to protect against
   passive eavesdropping of a session by the realm administrator), and
   as a preauthentication method (in order to prevent a passive
   eavesdropper from capturing ciphertext with which an offline
   dictionary attack can be mounted).

INTRODUCTION

   Perfect forward secrecy (PFS) is often a desirable property in
   security protocols; it means that an eavesdropper that has been able
   to decrypt previous traffic is not likely to be able to decrypt
   future traffic.

   In Kerberos [CLARIFICATIONS], one consequence of the lack of perfect
   secrecy is that anyone who has access to the keys in the KDC's



Weber               Kerberos Perfect Forward Secrecy            [Page 1]
\f





draft-weber-krb-wg-kerberos-pfs-00.txt                      July 24 2003


   database can decrypt all traffic in a Kerberos authenticated session,
   unless the application protocol happens to provide perfect forward
   secrecy independently of Kerberos.  This lack of perfect forward
   secrecy for sessions also means that a password change authenticated
   only by a compromised key may not suffice to remove the vulnerability
   caused by the compromised key, if an attacker is able to eavesdrop
   the password changing session and decrypt it using the compromised
   key.

   This document defines perfect forward secrecy for the AP-REQ/AP-REP
   exchange in Kerberos using the Diffie-Hellman exchange.

   This document also defines a preauthentication method that prevents a
   passive attacker from capturing ciphertext from which an offline
   dictionary attack can be mounted.

   This document draws heavily on the way Diffie-Hellman is used in
   [SECSH-TRANSPORT], which in turn is based upon work done for the
   IPsec protocol.

DH-GROUP1 EXCHANGE

   The client generates a random number x, where 1 < x < q.  The entropy
   in x MUST include entropy generated locally by the client; it SHOULD
   NOT include entropy from the KDC.

   The client then calculates e = g^x mod p.  The client creates an
   EncryptionKey with a keytype of DH-GROUP1 and a keyvalue of the
   integer e encoded as an ASN.1 DER INTEGER.

   The server generates a random number y, where 0 < y < q.  The entropy
   in y MUST include entropy generated locally by the server; it SHOULD
   NOT include entropy from a message received from the KDC.

   The server calculates f = g^y mod p.  The server creates an
   EncryptionKey with a keytype of DH-GROUP1 and a keyvalue of the
   integer f encoded as an ASN.1 DER INTEGER.

   Any value of e or f received that is not a positive integer, or that
   is greater than p - 1, MUST be rejected.

   The server computes K using K = e^y mod p.  The client computes K
   using K = f^x mod p.

   K is then encoded as an ASN.1 DER INTEGER, and fed through the MD5
   hash described in [KCRYPTO].  The resulting 128 bit value is the
   output of the Diffie-Hellman exchange.




Weber               Kerberos Perfect Forward Secrecy            [Page 2]
\f





draft-weber-krb-wg-kerberos-pfs-00.txt                      July 24 2003


GROUP 1 NUMBERS

   This is the same generator and prime as is used in [SECSH-TRANSPORT].

   The generator g used is the number 2.  q is (p - 1) / 2.

   The prime p is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
   Its decimal value is
        179769313486231590770839156793787453197860296048756011706444
        423684197180216158519368947833795864925541502180565485980503
        646440548199239100050792877003355816639229553136239076508735
        759914822574862575007425302077447712589550957937778424442426
        617334727629299387668709205606050270810842907692932019128194
        467627007

PFS in AP-REQ/AP-REP

   To request a subkey with perfect forward secrecy in the AP-REQ/AP-REP
   exchange, the client includes in the authenticator of the AP-REQ an
   authorization-data element of type AD-AP-PFS, with an ad-data field
   containing an EncryptionKey of keytype DH-GROUP1 and a keyvalue of the
   number e encoded as an ASN.1 DER INTEGER, as described above.

   The client MAY place the AD-AP-PFS element inside an AD-IF-RELEVANT if it
   wishes to operate without PFS if the server does not support PFS.

   If the server receives an AD-AP-PFS element with a key with an enctype of
   DH-GROUP1, and also receives one or more AD-AP-PFS elements with other
   enctype values, it MUST ignore the AD-AP-PFS elements whose enctypes are
   not DH-GROUP1.

   If the server receives one or more AD-AP-PFS elements, all of which are
   inside one or more AD-IF-RELEVANT elements, and none of which have an
   enctype of DH-GROUP1, it MUST ignore all of them.

   If the server receives one or more AD-AP-PFS elements, one or more of
   which are not inside an AD-IF-RELEVANT element, and none of which have
   an enctype of DH-GROUP1, it MUST report an error as appropriate for
   an unrecognized enctype.

   When the server receives an AD-AP-PFS element with a key with an enctype
   of DH-GROUP1, it generates a value f as described above which it sends
   as a DH-GROUP1 key in the subkey field of the EncAPRepPart which is
   sent in the AP-REP.

   When no AD-IF-RELEVANT is used, the client SHOULD abort the connection
   if no DH-GROUP1 key is received in the subkey field of the
   EncAPRepPart of the AP-REP.  When AD-IF-RELEVANT is used, the client



Weber               Kerberos Perfect Forward Secrecy            [Page 3]
\f





draft-weber-krb-wg-kerberos-pfs-00.txt                      July 24 2003


   MUST fall back to not using perfect forward secrecy if the subkey is
   omitted from the AP-REP or not of type DH-GROUP1.

   When DH-GROUP1 keys are successfully exchanged, the MD5 hash
   generated as the output of the Diffie-Hellman exchange as described
   above is combined with the session key from the KDC in some fashion
   which is currently underspecified, and used as the sub-session key
   for the following KRB-SAFE, KRB-PRIV, and/or KRB-CRED messages.

PFS PREAUTHENTICATION

   The client sends an AS-REQ which contains a PA-DATA element with a
   padata-type value of PA-PFS-F-REQ and a padata-value of type
   PA-PFS-F-REQ-ENTRY.

   PA-PFS-F-REQ-ENTRY    ::= SEQUENCE {
           enctypes        [0] SEQUENCE OF Int32
   }

   A client conforming to this version of the specification MUST send an
   enctype of DH-GROUP1, and only that enctype.  A server conforming to
   this version of this specification MUST use the DH-GROUP1 enctype if
   it is present in the PA-PFS-F-REQ, and otherwise report the error
   KDC_ERR_ETYPE_NOSUPP.

   When sending PA-PFS-F-REQ, the cname field of the KDC-REQ-BODY MAY be
   omitted.

   The KDC replies with with a KRB-ERROR message of type
   KDC_ERROR_PREAUTH_REQUIRED containing a PA-DATA element with a
   padata-type of PA-PFS-F-REP and a padata-value of type PA-PFS-F-REP-
   ENTRY:

   PA-PFS-F-REP-ENTRY    ::= SEQUENCE {
           f               [0] EncryptionKey
   }

   Where f is a DH-GROUP1 key as described above.

   The KDC MAY include additional preauthentication data elements in
   this KRB-ERROR, such as PA-ETYPE-INFO2.

   The client then sends an AS-REQ which contains a PA-DATA element with
   a padata-type of PA-PFS-REQ and a padata-value of type PA-PFS-ENTRY:

   PA-PFS-ENTRY          ::= SEQUENCE {
           e               [0] EncryptionKey,
           cookie          [1] OCTET STRING



Weber               Kerberos Perfect Forward Secrecy            [Page 4]
\f





draft-weber-krb-wg-kerberos-pfs-00.txt                      July 24 2003


           cname           [2] EncryptedData OPTIONAL, -- PrincipalName
           timestamp       [3] EncryptedData -- PA-ENC-TS-ENC
   }

   Where e has an keytype of DH-GROUP1 and contents as described above,
   and cookie is the MD5 hash of the ASN.1 DER encoding of the INTEGER
   f.

   If cname is included in the PA-PFS-ENTRY, it is encrypted using a key
   derived in some underspecified fashion from the output of the Diffie-
   Hellman exchange, and the cname field of the KDC-REQ-BODY structure
   is omitted from the AS-REQ.

   The timestamp field of the PA-PFS-ENTRY is encrypted using a key
   derived from the output of the Diffie-Hellman exchange and the user's
   password, combined in some underspecified fashion.

   The KDC then sends an AS-REP, encrypting the ticket using a key
   derived from of the output of the Diffie-Hellman exchange and the
   user's password, combined in some underspecified fashion.

 MitM Detection

   Once the KDC sends a value of f, it MUST to accept the corresponding
   cookie value in an unlimited number of PA-PFS-REQ requests for at
   least a half hour plus allowable clock skew.  The KDC SHOULD log the
   MD5 hash of each value of f it sends, in order to facilitate
   determining which values the real KDC sent.

   Clients SHOULD record the hash of f and principal name used in cases
   where authentication fails, so that a determination can be made of
   which principals may have had ciphertext based upon their possibly
   weak passwords sent to an attacker.

TODO

   For the preauthentication mechanism described here, a message type
   should be defined so that after successful authentication, a client
   can send a list of values of f and principal names that have failed
   to successfully authenticate on that particular workstation to the
   KDC.  Or perhaps there is a better solution to the problem of
   detecting man in the middle attacks.

   A numeric value for the authorization data type AD-AP-PFS needs to be
   assigned.

   A numeric value for the enctype DH-GROUP1 needs to be assigned.




Weber               Kerberos Perfect Forward Secrecy            [Page 5]
\f





draft-weber-krb-wg-kerberos-pfs-00.txt                      July 24 2003


   Numeric values need to be assigned for the padata-types PA-PFS-F-REQ,
   PA-PFS-F-REP, and PA-PFS-REQ.

   Key combining needs to be better specified.

SECURITY CONSIDERATIONS

   With AP-REQ/AP-REP, if an attacker which knows the client principal's
   or the application server's long term key, PFS will prevent the
   attacker from carrying out a passive eavesdropping attack, but
   provides no protection against and offers no detection of a man in
   the middle attack.

   PA-PFS-REQ will prevent a passive eavesdropper from capturing
   ciphertext encrypted only with a user's weak password.  However, an
   active attacker can easily capture such ciphertext even when PA-PFS-
   REQ is used.  On the other hand, the use of this preauthentication
   method may make the detection of such attackers significantly more
   likely.

   The use of Diffie-Hellman is only effective if the client and server
   use quality sources of entropy to generate x and y.

   Having the server consistently send the same value of f for multiple
   sessions has advantages in reducing the amount of memory an attacker
   could consume by sending many requests for f, and facilitates
   detection of man in the middle attacks.  However, the author is not
   aware of implementations of the Diffie-Hellman exchange which
   deliberately reuse a random number for multiple sessions, and is not
   entirely confident that there aren't hidden problems lurking which
   make this a bad idea.

   [SECSH-TRANSPORT] derives several keys from the output of the Diffie-
   Hellman exchange, rather than just one.  It may be a bug that this
   version of this spec does not do likewise.

AUTHOR'S ADDRESS

   Joel N. Weber II
   185 Lowell St #2
   Somerville MA 02144-2629
   Email: weber@joelweber.com

NORMATIVE REFERENCES

   [CLARIFICATIONS] To be replaced with the RFC number for draft-ietf-
   krb-wg-kerberos-clarifications




Weber               Kerberos Perfect Forward Secrecy            [Page 6]
\f





draft-weber-krb-wg-kerberos-pfs-00.txt                      July 24 2003


   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
   Kerberos 5", draft-ietf-krb-wg-crypto-01.txt, May, 2002.  Work in
   progress.

   [RFC2026] S. Bradner, RFC2026, BCP 9:  "The Internet Standard Process
   - Revision 3," October 1996, Obsoletes - RFC 1602, Status: Best
   Current Practice.

   [RFC2119] S. Bradner, RFC 2119, BCP 14: "Key words for use in RFCs to
   Indicate Requirement Levels", March 1997.

INFORMATIVE REFERENCES

   [SECSH-TRANSPORT] To be replaced with the RFC number for draft-ietf-
   secsh-transport

IPR NOTICES

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

COPYRIGHT NOTICE

   Copyright (C) The Internet Society 2003. All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this



Weber               Kerberos Perfect Forward Secrecy            [Page 7]
\f





draft-weber-krb-wg-kerberos-pfs-00.txt                      July 24 2003


   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


































Weber               Kerberos Perfect Forward Secrecy            [Page 8]
\f