merge from 1.2 branch

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@12471 dc483132-0cff-0310-8789-dd5450dbe970

1 files changed, 274 insertions, 0 deletions

diff --git a/src/lib/gssapi/krb5/3des.txt b/src/lib/gssapi/krb5/3des.txt
new file mode 100644
index 0000000000..f39c6fce6e
--- /dev/null
+++ b/src/lib/gssapi/krb5/3des.txt
@@ -0,0 +1,274 @@
+CAT Working Group                                           K. Raeburn
+Internet-draft                                                     MIT
+Category:                                                June xx, 2000
+Updates: RFC 1964
+Document: draft-raeburn-gssapi-krb5-3des-XX.txt
+
+        Triple-DES Support for the Kerberos 5 GSSAPI Mechanism
+
+Status of this Memo
+ 
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026 [1]. 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/ietf/1id-abstracts.txt  
+
+   The list of Internet-Draft Shadow Directories can be accessed at 
+   http://www.ietf.org/shadow.html. 
+    
+1. Abstract 
+
+   The MIT Kerberos 5 release version 1.2 includes support for
+   triple-DES with key derivation [KrbRev].  Recent work by the EFF
+   [EFF] has demonstrated the vulnerability of single-DES mechanisms
+   to brute-force attacks by sufficiently motivated and well-funded
+   parties.
+
+   The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5]
+   specifically enumerates encryption and checksum types,
+   independently of how such schemes may be used in Kerberos.  In the
+   long run, a new Kerberos-based mechanism, which does not require
+   separately enumerating for the GSSAPI mechanism each of the various
+   encryption types defined by Kerberos, is a better approach.
+   Efforts to produce such a specification are under way.
+
+   In the interest of providing increased security in the near term,
+   however, MIT is adding support for triple-DES to the existing
+   mechanism implementation we ship, as described here.
+
+2. New Algorithm Identifiers
+
+   One new sealing algorithm is defined, for use in WRAP tokens:
+
+   02 00 - DES3-KD
+
+   This algorithm uses triple-DES with key derivation, with a usage
+   value KG_USAGE_SEAL.  Padding is still to 8-byte multiples, and the
+   IV for encrypting application data is zero.
+
+   One new signing algorithm is defined, for use in MIC, Wrap, and
+   Delete tokens:
+
+   04 00 - HMAC SHA1 DES3-KD
+
+   This algorithm generates an HMAC using SHA-1 and a derived DES3 key
+   with usage KG_USAGE_SIGN, as (should be described) in [KrbRev].
+   [XXX: The current [KrbRev] description refers to out-of-date I-Ds
+   from Marc Horowitz.  The text in [KrbRev] may be inadequate to
+   produce an interoperable implementation.]
+
+   The checksum size for this algorithm is 20 octets.  See section 4.3
+   below for the use of checksum lengths of other than eight bytes.
+
+3. Key Derivation
+
+   For purposes of key derivation, we add three new usage values to the
+   list defined in [KrbRev]; one for signing messages, one for
+   sealing messages, and one for encrypting sequence numbers:
+
+   #define KG_USAGE_SEAL 22
+   #define KG_USAGE_SIGN 23
+   #define KG_USAGE_SEQ  24
+
+4. Adjustments to Previous Definitions
+
+4.1. Quality of Protection
+
+   The GSSAPI specification [GSSAPI] says that a zero QOP value
+   indicates the "default".  The original specification for the
+   Kerberos 5 mechanism says that a zero QOP value (or a QOP value
+   with the appropriate bits clear) means DES encryption.
+
+   Rather than continue to force the use of plain DES when the
+   application doesn't use mechanism-specific QOP values, the better
+   choice appears to be to redefine the DES QOP value as some non-zero
+   value, and define a triple-DES value as well.  Then a zero value
+   continues to imply the default, which would be triple-DES
+   protection when given a triple-DES session key.
+
+   Our values are:
+
+   GSS_KRB5_INTEG_C_QOP_HMAC_SHA1        0x0004
+            /* SHA-1 checksum encrypted with key derivation */
+
+   GSS_KRB5_CONF_C_QOP_DES               0x0100
+            /* plain DES encryption */
+   GSS_KRB5_CONF_C_QOP_DES3_KD           0x0200
+            /* triple-DES with key derivation */
+
+   Rather than open the question of whether to specify means for
+   deriving a key of one type given a key of another type, and the
+   security implications of whether to generate a long key from a
+   shorter one, our implementation will simply return an error if the
+   QOP value specified does not correspond to the session key type.
+
+   [XXX: Not implemented yet.  Currently an error is reported for all
+   non-zero values.  This should be changed before the release, so an
+   application can insist on getting no less than triple-DES
+   protection.]
+
+4.2. MIC Sequence Number Encryption
+
+   The sequence numbers are encrypted in the context key (as defined
+   in [GSSAPI-KRB5] -- this will be either the Kerberos session key or
+   asubkey provided by the context initiator), using whatever
+   encryption system is designated by the type of that context key.
+   The IV is formed from the first N bytes of the SGN_CKSUM field,
+   where N is the number of bytes needed for the IV.  (With all
+   algorithms described here and in [GSSAPI-KRB5], the checksum is at
+   least as large as the IV.)
+
+4.3. Message Layout
+
+   Both MIC and Wrap tokens, as defined in [GSSAPI-KRB5], contain an
+   checksum field SGN_CKSUM.  In [GSSAPI-KRB5], this field was
+   specified as being 8 bytes long.  We now change this size to be
+   "defined by the checksum algorithm", and retroactively amend the
+   descriptions of all the checksum algorithms described in
+   [GSSAPI-KRB5] to explicitly specify 8-byte output.  Application
+   data continues to immediately follow the checksum field in the Wrap
+   token.
+
+   The revised message descriptions are thus:
+
+   MIC:
+
+   Byte no          Name           Description
+    0..1           TOK_ID          Identification field.
+    2..3           SGN_ALG         Integrity algorithm indicator.
+    4..7           Filler          Contains ff ff ff ff
+    8..15          SND_SEQ         Sequence number field.
+    16..s+15       SGN_CKSUM       Checksum of "to-be-signed data",
+                                   calculated according to algorithm
+                                   specified in SGN_ALG field.
+
+   Wrap:
+
+   Byte no          Name           Description
+    0..1           TOK_ID          Identification field.
+                                   Tokens emitted by GSS_Wrap() contain
+                                   the hex value 02 01 in this field.
+    2..3           SGN_ALG         Checksum algorithm indicator.
+    4..5           SEAL_ALG        Sealing algorithm indicator.
+    6..7           Filler          Contains ff ff
+    8..15          SND_SEQ         Encrypted sequence number field.
+    16..s+15       SGN_CKSUM       Checksum of plaintext padded data,
+                                   calculated according to algorithm
+                                   specified in SGN_ALG field.
+    s+16..last     Data            encrypted or plaintext padded data
+
+   Where "s" indicates the size of the checksum.
+
+   As indicated above in section 2, we define the HMAC SHA1 DES3-KD
+   checksum algorithm to produce a 20-byte output, so encrypted data
+   begins at byte 36.
+
+5. Backwards Compatibility Considerations
+
+   The context initiator should request of the KDC credentials using
+   session-key cryptosystem types supported by that implementation; if
+   the only types returned by the KDC are not supported by the
+   mechanism implementation, it should indicate a failure.  This may
+   seem obvious, but early implementations of both Kerberos and the
+   GSSAPI Kerberos mechanism supported only DES keys, so the
+   cryptosystem compatibility question was easy to overlook.
+
+   Under the current mechanism, no negotiation of algorithm types
+   occurs, so server-side (acceptor) implementations cannot request
+   that clients not use algorithm types not understood by the server.
+   However, administration of the server's Kerberos data has to be
+   done in communication with the KDC, and it is from the KDC that the
+   client will request credentials.  The KDC could therefore be tasked
+   with limiting session keys for a given service to types actually
+   supported by the Kerberos and GSSAPI software on the server.
+
+   This does have a drawback for cases where a service principal name
+   is used both for GSSAPI-based and non-GSSAPI-based communication,
+   if the GSSAPI implementation does not understand triple-DES but the
+   Kerberos implementation does.  It means that triple-DES session
+   keys cannot be issued for that service principal, which keeps the
+   protection of non-GSSAPI services weaker than necessary.  However,
+   in the most recent MIT releases thus far, while triple-DES support
+   has been present, it has required additional work to enable, so it
+   should not be in use for many services.
+
+   It would also be possible to have clients attempt to get single-DES
+   session keys before trying to get triple-DES session keys, and have
+   the KDC refuse to issue the single-DES keys only for the most
+   critical of services, for which single-DES protection is considered
+   inadequate.  However, that would eliminate the possibility of
+   connecting with the more secure cryptosystem to any service that
+   can be accessed with the weaker cryptosystem.
+
+   We have chosen to go with the former approach, putting the burden
+   on the KDC administration and gaining the best protection possible
+   for GSSAPI services, possibly at the cost of protection of
+   non-GSSAPI Kerberos services running earlier versions of the
+   software.
+   [XXX: Actually, we haven't entirely decided and cast it in stone
+   yet, it's just what I've implemented; it's easy to change.]
+
+6. Security Considerations
+
+   Various tradeoffs arise regarding the mixing of new and old
+   software, or GSSAPI-based and non-GSSAPI Kerberos authentication.
+   They are discussed in section 4.
+
+7. References
+
+   [EFF] Electronic Frontier Foundation, "Cracking DES: Secrets of
+   Encryption Research, Wiretap Politics, and Chip Design", O'Reilly &
+   Associates, Inc., May, 1998.
+
+   [GSSAPI] Linn, J., "Generic Security Service Application Program
+   Interface Version 2, Update 1", RFC 2743, January, 2000.
+
+   [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+   RFC 1964, June, 1996.
+
+   [KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
+   Authentication Service (V5)",
+   draft-ietf-cat-kerberos-revisions-05.txt, March 10, 2000.
+
+8. Author's Address
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+
+9. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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 implementation 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   
+   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."