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] 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] 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] 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] 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] 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] 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] 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]