25 files changed, 26111 insertions, 0 deletions

diff --git a/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt
new file mode 100644
index 000000000000..85d745684b2a
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt
@@ -0,0 +1,5 @@
+This Internet-Draft has expired and is no longer available.
+
+Unrevised documents placed in the Internet-Drafts directories have a
+maximum life of six months. After that time, they must be updated, or
+they will be deleted. This document was deleted on July 17, 2000.
diff --git a/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt
new file mode 100644
index 000000000000..202d44e8639c
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt
@@ -0,0 +1,587 @@
+CAT working group                                              M. Swift 
+Internet Draft                                                J. Brezak 
+Document: draft-brezak-win2k-krb-rc4-hmac-03.txt              Microsoft 
+Category: Informational                                       June 2000 
+ 
+ 
+           The Windows 2000 RC4-HMAC Kerberos encryption type 
+ 
+ 
+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 Windows 2000 implementation of Kerberos introduces a new 
+   encryption type based on the RC4 encryption algorithm and using an 
+   MD5 HMAC for checksum. This is offered as an alternative to using 
+   the existing DES based encryption types. 
+    
+   The RC4-HMAC encryption types are used to ease upgrade of existing 
+   Windows NT environments, provide strong crypto (128-bit key 
+   lengths), and provide exportable (meet United States government 
+   export restriction requirements) encryption. 
+    
+   The Windows 2000 implementation of Kerberos contains new encryption 
+   and checksum types for two reasons: for export reasons early in the 
+   development process, 56 bit DES encryption could not be exported, 
+   and because upon upgrade from Windows NT 4.0 to Windows 2000, 
+   accounts will not have the appropriate DES keying material to do the 
+   standard DES encryption. Furthermore, 3DES is not available for 
+   export, and there was a desire to use a single flavor of encryption 
+   in the product for both US and international products. 
+    
+   As a result, there are two new encryption types and one new checksum 
+   type introduced in Windows 2000. 
+    
+    
+2. Conventions used in this document 
+    
+
+  
+Swift                  Category - Informational                      1 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC-2119 [2]. 
+    
+3. Key Generation 
+    
+   On upgrade from existing Windows NT domains, the user accounts would 
+   not have a DES based key available to enable the use of DES base 
+   encryption types specified in RFC 1510. The key used for RC4-HMAC is 
+   the same as the existing Windows NT key (NT Password Hash) for 
+   compatibility reasons. Once the account password is changed, the DES 
+   based keys are created and maintained. Once the DES keys are 
+   available DES based encryption types can be used with Kerberos.  
+    
+   The RC4-HMAC String to key function is defined as follow: 
+    
+   String2Key(password) 
+    
+        K = MD4(UNICODE(password)) 
+         
+   The RC4-HMAC keys are generated by using the Windows UNICODE version 
+   of the password. Each Windows UNICODE character is encoded in 
+   little-endian format of 2 octets each. Then performing an MD4 [6] 
+   hash operation on just the UNICODE characters of the password (not 
+   including the terminating zero octets). 
+    
+   For an account with a password of "foo", this String2Key("foo") will 
+   return: 
+    
+        0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, 
+        0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc 
+    
+4. Basic Operations 
+    
+   The MD5 HMAC function is defined in [3]. It is used in this 
+   encryption type for checksum operations. Refer to [3] for details on 
+   its operation. In this document this function is referred to as 
+   HMAC(Key, Data) returning the checksum using the specified key on 
+   the data. 
+    
+   The basic MD5 hash operation is used in this encryption type and 
+   defined in [7]. In this document this function is referred to as 
+   MD5(Data) returning the checksum of the data. 
+    
+   RC4 is a stream cipher licensed by RSA Data Security [RSADSI]. A       
+   compatible cipher is described in [8]. In this document the function 
+   is referred to as RC4(Key, Data) returning the encrypted data using 
+   the specified key on the data. 
+    
+   These encryption types use key derivation as defined in [9] (RFC-
+   1510BIS) in Section titled "Key Derivation". With each message, the 
+   message type (T) is used as a component of the keying material. This 
+   summarizes the different key derivation values used in the various 
+  
+Swift                  Category - Informational                      2 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+   operations. Note that these differ from the key derivations used in 
+   other Kerberos encryption types. 
+    
+        T = 1 for TS-ENC-TS in the AS-Request 
+        T = 8 for the AS-Reply  
+        T = 7 for the Authenticator in the TGS-Request 
+        T = 8 for the TGS-Reply  
+        T = 2 for the Server Ticket in the AP-Request 
+        T = 11 for the Authenticator in the AP-Request 
+        T = 12 for the Server returned AP-Reply 
+        T = 15 in the generation of checksum for the MIC token 
+        T = 0 in the generation of sequence number for the MIC token  
+        T = 13 in the generation of checksum for the WRAP token 
+        T = 0 in the generation of sequence number for the WRAP token  
+        T = 0 in the generation of encrypted data for the WRAPPED token 
+    
+   All strings in this document are ASCII unless otherwise specified. 
+   The lengths of ASCII encoded character strings include the trailing 
+   terminator character (0). 
+    
+   The concat(a,b,c,...) function will return the logical concatenation 
+   (left to right) of the values of the arguments. 
+    
+   The nonce(n) function returns a pseudo-random number of "n" octets. 
+    
+5. Checksum Types 
+    
+   There is one checksum type used in this encryption type. The 
+   Kerberos constant for this type is: 
+        #define KERB_CHECKSUM_HMAC_MD5 (-138) 
+    
+   The function is defined as follows: 
+    
+   K - is the Key 
+   T - the message type, encoded as a little-endian four byte integer 
+    
+   CHKSUM(K, T, data) 
+    
+        Ksign = HMAC(K, "signaturekey")  //includes zero octet at end 
+        tmp = MD5(concat(T, data)) 
+        CHKSUM = HMAC(Ksign, tmp) 
+    
+    
+6. Encryption Types 
+    
+   There are two encryption types used in these encryption types. The 
+   Kerberos constants for these types are: 
+        #define KERB_ETYPE_RC4_HMAC             23 
+        #define KERB_ETYPE_RC4_HMAC_EXP         24 
+    
+   The basic encryption function is defined as follow: 
+    
+   T = the message type, encoded as a little-endian four byte integer. 
+  
+Swift                  Category - Informational                      3 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+    
+        BYTE L40[14] = "fortybits"; 
+        BYTE SK = "signaturekey"; 
+         
+        ENCRYPT (K, fRC4_EXP, T, data, data_len, edata, edata_len) 
+        { 
+            if (fRC4_EXP){ 
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 10 + 4, K1); 
+            }else{ 
+                HMAC (K, &T, 4, K1); 
+            } 
+            memcpy (K2, K1, 16); 
+            if (fRC4_EXP) memset (K1+7, 0xAB, 9); 
+            add_8_random_bytes(data, data_len, conf_plus_data); 
+            HMAC (K2, conf_plus_data, 8 + data_len, checksum); 
+            HMAC (K1, checksum, 16, K3); 
+            RC4(K3, conf_plus_data, 8 + data_len, edata + 16); 
+            memcpy (edata, checksum, 16); 
+            edata_len = 16 + 8 + data_len; 
+        }         
+         
+        DECRYPT (K, fRC4_EXP, T, edata, edata_len, data, data_len) 
+        { 
+            if (fRC4_EXP){ 
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 14, K1); 
+            }else{ 
+                HMAC (K, &T, 4, K1); 
+            } 
+            memcpy (K2, K1, 16); 
+            if (fRC4_EXP) memset (K1+7, 0xAB, 9); 
+            HMAC (K1, edata, 16, K3); // checksum is at edata 
+            RC4(K3, edata + 16, edata_len - 16, edata + 16); 
+            data_len = edata_len - 16 - 8; 
+            memcpy (data, edata + 16 + 8, data_len); 
+             
+            // verify generated and received checksums 
+            HMAC (K2, edata + 16, edata_len - 16, checksum); 
+            if (memcmp(edata, checksum, 16) != 0)  
+                printf("CHECKSUM ERROR  !!!!!!\n"); 
+        } 
+    
+   The header field on the encrypted data in KDC messages is: 
+    
+        typedef struct _RC4_MDx_HEADER { 
+            UCHAR Checksum[16]; 
+            UCHAR Confounder[8]; 
+        } RC4_MDx_HEADER, *PRC4_MDx_HEADER; 
+         
+   The KDC message is encrypted using the ENCRYPT function not 
+   including the Checksum in the RC4_MDx_HEADER. 
+    
+  
+Swift                  Category - Informational                      4 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+   The character constant "fortybits" evolved from the time when a 40-
+   bit key length was all that was exportable from the United States. 
+   It is now used to recognize that the key length is of "exportable" 
+   length. In this description, the key size is actually 56-bits. 
+    
+7. Key Strength Negotiation 
+    
+   A Kerberos client and server can negotiate over key length if they 
+   are using mutual authentication. If the client is unable to perform 
+   full strength encryption, it may propose a key in the "subkey" field 
+   of the authenticator, using a weaker encryption type. The server 
+   must then either return the same key or suggest its own key in the 
+   subkey field of the AP reply message. The key used to encrypt data 
+   is derived from the key returned by the server. If the client is 
+   able to perform strong encryption but the server is not, it may 
+   propose a subkey in the AP reply without first being sent a subkey 
+   in the authenticator. 
+ 
+8. GSSAPI Kerberos V5 Mechanism Type  
+ 
+8.1 Mechanism Specific Changes 
+    
+   The GSSAPI per-message tokens also require new checksum and 
+   encryption types. The GSS-API per-message tokens must be changed to 
+   support these new encryption types (See [5] Section 1.2.2). The 
+   sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption 
+   is: 
+        Byte 4..5 SEAL_ALG      0x10 0x00 - RC4 
+    
+   The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: 
+        Byte 2..3 SGN ALG       0x11 0x00 - HMAC 
+    
+   The only support quality of protection is: 
+        #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0 
+    
+   In addition, when using an RC4 based encryption type, the sequence 
+   number is sent in big-endian rather than little-endian order. 
+    
+   The Windows 2000 implementation also defines new GSSAPI flags in the 
+   initial token passed when initializing a security context. These 
+   flags are passed in the checksum field of the authenticator (See [5] 
+   Section 1.1.1). 
+    
+   GSS_C_DCE_STYLE - This flag was added for use with Microsoft’s 
+   implementation of DCE RPC, which initially expected three legs of 
+   authentication. Setting this flag causes an extra AP reply to be 
+   sent from the client back to the server after receiving the server’s 
+   AP reply. In addition, the context negotiation tokens do not have 
+   GSSAPI framing - they are raw AP message and do not include object 
+   identifiers. 
+        #define GSS_C_DCE_STYLE                 0x1000 
+    
+
+  
+Swift                  Category - Informational                      5 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+   GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the 
+   server that it should only allow the server application to identify 
+   the client by name and ID, but not to impersonate the client. 
+        #define GSS_C_IDENTIFY_FLAG             0x2000 
+         
+   GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the 
+   client wants to be informed of extended error information. In 
+   particular, Windows 2000 status codes may be returned in the data 
+   field of a Kerberos error message. This allows the client to 
+   understand a server failure more precisely. In addition, the server 
+   may return errors to the client that are normally handled at the 
+   application layer in the server, in order to let the client try to 
+   recover. After receiving an error message, the client may attempt to 
+   resubmit an AP request. 
+        #define GSS_C_EXTENDED_ERROR_FLAG       0x4000 
+    
+   These flags are only used if a client is aware of these conventions 
+   when using the SSPI on the Windows platform, they are not generally 
+   used by default. 
+    
+   When NetBIOS addresses are used in the GSSAPI, they are identified 
+   by the GSS_C_AF_NETBIOS value. This value is defined as: 
+        #define GSS_C_AF_NETBIOS                0x14 
+   NetBios addresses are 16-octet addresses typically composed of 1 to 
                                                                 th
   15 characters, trailing blank (ascii char 20) filled, with a 16  
+   octet of 0x0. 
+    
+8.2 GSSAPI Checksum Type 
+    
+   The GSSAPI checksum type and algorithm is defined in Section 5. Only 
+   the first 8 octets of the checksum are used. The resulting checksum 
+   is stored in the SGN_CKSUM field (See [5] Section 1.2) for 
+   GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). 
+    
+        MIC (K, fRC4_EXP, seq_num, MIC_hdr, msg, msg_len, 
+             MIC_seq, MIC_checksum) 
+        { 
+            HMAC (K, SK, 13, K4); 
+            T = 15; 
+            memcpy (T_plus_hdr_plus_msg + 00, &T, 4); 
+            memcpy (T_plus_hdr_plus_msg + 04, MIC_hdr, 8);  
+                                                // 0101 1100 FFFFFFFF 
+            memcpy (T_plus_hdr_plus_msg + 12, msg, msg_len); 
+            MD5 (T_hdr_msg, 4 + 8 + msg_len, MD5_of_T_hdr_msg); 
+            HMAC (K4, MD5_of_T_hdr_msg, CHKSUM); 
+            memcpy (MIC_checksum, CHKSUM, 8); // use only first 8 bytes 
+          
+            T = 0; 
+            if (fRC4_EXP){  
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 14, K5); 
+            }else{ 
+                HMAC (K, &T, 4, K5); 
+  
+Swift                  Category - Informational                      6 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+            } 
+            if (fRC4_EXP) memset(K5+7, 0xAB, 9); 
+            HMAC(K5, MIT_checksum, 8, K6); 
+            copy_seq_num_in_big_endian(seq_num, seq_plus_direction); 
+        //0x12345678 
+            copy_direction_flag (direction_flag, seq_plus_direction + 
+        4); //0x12345678FFFFFFFF 
+            RC4(K6, seq_plus_direction, 8, MIC_seq); 
+        } 
+    
+8.3 GSSAPI Encryption Types 
+    
+   There are two encryption types for GSSAPI message tokens, one that 
+   is 128 bits in strength, and one that is 56 bits in strength as 
+   defined in Section 6. 
+    
+   All padding is rounded up to 1 byte. One byte is needed to say that 
+   there is 1 byte of padding. The DES based mechanism type uses 8 byte 
+   padding. See [5] Section 1.2.2.3. 
+    
+   The encryption mechanism used for GSS wrap based messages is as 
+   follow: 
+    
+    
+        WRAP (K, fRC4_EXP, seq_num, WRAP_hdr, msg, msg_len, 
+              WRAP_seq, WRAP_checksum, edata, edata_len) 
+        { 
+            HMAC (K, SK, 13, K7); 
+            T = 13; 
+            PAD = 1; 
+            memcpy (T_hdr_conf_msg_pad + 00, &T, 4); 
+            memcpy (T_hdr_conf_msg_pad + 04, WRAP_hdr, 8); // 0101 1100 
+        FFFFFFFF 
+            memcpy (T_hdr_conf_msg_pad + 12, msg, msg_len); 
+            memcpy (T_hdr_conf_msg_pad + 12 + msg_len, &PAD, 1); 
+            MD5 (T_hdr_conf_msg_pad, 
+                 4 + 8 + 8 + msg_len + 1, 
+                 MD5_of_T_hdr_conf_msg_pad); 
+            HMAC (K7, MD5_of_T_hdr_conf_msg_pad, CHKSUM); 
+            memcpy (WRAP_checksum, CHKSUM, 8); // use only first 8 
+        bytes 
+          
+            T = 0; 
+            if (fRC4_EXP){  
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 14, K8); 
+            }else{ 
+                HMAC (K, &T, 4, K8); 
+            } 
+            if (fRC4_EXP) memset(K8+7, 0xAB, 9); 
+            HMAC(K8, WRAP_checksum, 8, K9); 
+            copy_seq_num_in_big_endian(seq_num, seq_plus_direction); 
+        //0x12345678 
+  
+Swift                  Category - Informational                      7 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+            copy_direction_flag (direction_flag, seq_plus_direction + 
+        4); //0x12345678FFFFFFFF 
+            RC4(K9, seq_plus_direction, 8, WRAP_seq); 
+          
+            for (i = 0; i < 16; i++) K10 [i] ^= 0xF0; // XOR each byte 
+        of key with 0xF0 
+            T = 0; 
+            if (fRC4_EXP){ 
+                *(DWORD *)(L40+10) = T; 
+                HMAC(K10, L40, 14, K11); 
+                memset(K11+7, 0xAB, 9); 
+            }else{ 
+                HMAC(K10, &T, 4, K11);  
+            } 
+            HMAC(K11, seq_num, 4, K12); 
+            RC4(K12, T_hdr_conf_msg_pad + 4 + 8, 8 + msg_len + 1, 
+        edata); /* skip T & hdr */ 
+            edata_len = 8 + msg_len + 1; // conf + msg_len + pad 
+         } 
+          
+    
+   The character constant "fortybits" evolved from the time when a 40-
+   bit key length was all that was exportable from the United States. 
+   It is now used to recognize that the key length is of "exportable" 
+   length. In this description, the key size is actually 56-bits. 
+    
+9. Security Considerations 
+ 
+   Care must be taken in implementing this encryption type because it 
+   uses a stream cipher. If a different IV isn’t used in each direction 
+   when using a session key, the encryption is weak. By using the 
+   sequence number as an IV, this is avoided. 
+    
+10. Acknowledgements 
+    
+   We would like to thank Salil Dangi for the valuable input in 
+   refining the descriptions of the functions and review input. 
+     
+11. References 
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997 
+    
+   3  Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for 
+      Message Authentication", RFC 2104, February 1997 
+    
+   4  Kohl, J., Neuman, C., "The Kerberos Network Authentication 
+      Service (V5)", RFC 1510, September 1993 
+ 
+ 
+  
+Swift                  Category - Informational                      8 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+ 
+   5  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, 
+      June 1996 
+ 
+   6  R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April 
+      1992 
+ 
+   7  R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April 
+      1992 
+ 
+   8  Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption             
+      Algorithm", Work in Progress. 
+ 
+   9  RC4 is a proprietary encryption algorithm available under license 
+      from RSA Data Security Inc.  For licensing information, contact: 
+       
+         RSA Data Security, Inc. 
+         100 Marine Parkway 
+         Redwood City, CA 94065-1031 
+ 
+   10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 
+      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
+      04.txt, June 25, 1999 
+ 
+    
+12. Author's Addresses 
+    
+   Mike Swift 
+   Dept. of Computer Science 
+   Sieg Hall 
+   University of Washington 
+   Seattle, WA 98105 
+   Email: mikesw@cs.washington.edu  
+    
+   John Brezak 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@microsoft.com 
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                      9 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
+ 
+ 
+    
+13. 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. 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                     10 
+
diff --git a/crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt b/crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt
new file mode 100644
index 000000000000..89e64524c475
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt
@@ -0,0 +1,1594 @@
+
+DHC Working Group                                          Ken Hornstein
+INTERNET-DRAFT                                                       NRL
+Category: Standards Track                                      Ted Lemon
+<draft-hornstein-dhc-kerbauth-02.txt>             Internet Engines, Inc.
+20 February 2000                                           Bernard Aboba
+Expires: September 1, 2000                                     Microsoft
+                                                        Jonathan Trostle
+                                                           Cisco Systems
+
+                   DHCP Authentication Via Kerberos V
+
+This document is an Internet-Draft and is in full conformance with all
+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/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+The distribution of this memo is unlimited.
+
+1.  Copyright Notice
+
+Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+2.  Abstract
+
+The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for
+host configuration. In some circumstances, it is useful for the DHCP
+client and server to be able to mutually authenticate as well as to
+guarantee the integrity of DHCP packets in transit.  This document
+describes how Kerberos V may be used in order to allow a DHCP client and
+server to mutually authenticate as well as to protect the integrity of
+the DHCP exchange. The protocol described in this document is capable of
+handling both intra-realm and inter-realm authentication.
+
+
+
+
+
+
+Hornstein, et al.            Standards Track                    [Page 1]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+3.  Introduction
+
+The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for
+host configuration. In some circumstances, it is useful for the DHCP
+client and server to be able to mutually authenticate as well as to
+guarantee the integrity of DHCP packets in transit.  This document
+describes how Kerberos V may be used in order to allow a DHCP client and
+server to mutually authenticate as well as to protect the integrity of
+the DHCP exchange.  The protocol described in this document is capable
+of handling both intra-realm and inter-realm authentication.
+
+3.1.  Terminology
+
+This document uses the following terms:
+
+DHCP client
+          A DHCP client or "client" is an Internet host using DHCP to
+          obtain configuration parameters such as a network address.
+
+DHCP server
+          A DHCP server or "server" is an Internet host that returns
+          configuration parameters to DHCP clients.
+
+Home KDC  The KDC corresponding to the DHCP client's realm.
+
+Local KDC The KDC corresponding to the DHCP server's realm.
+
+3.2.  Requirements language
+
+In this document, the key words "MAY", "MUST,  "MUST  NOT",  "optional",
+"recommended",  "SHOULD",  and  "SHOULD  NOT",  are to be interpreted as
+described in [1].
+
+4.  Protocol overview
+
+In DHCP authentication via Kerberos V, DHCP clients and servers utilize
+a Kerberos session key in order to compute a message integrity check
+value included within the DHCP authentication option. The message
+integrity check serves to authenticate as well as integrity protect the
+messages, while remaining compatible with the operation of a DHCP relay.
+Replay protection is also provided by a replay counter within the
+authentication option, as described in [3].
+
+Each server maintains a list of session keys and identifiers for
+clients, so that the server can retrieve the session key and identifier
+used by a client to which the server has provided previous configuration
+information.  Each server MUST save the replay counter from the previous
+authenticated message. To avoid replay attacks, the server MUST discard
+
+
+
+Hornstein, et al.            Standards Track                    [Page 2]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+any incoming message whose replay counter is not strictly greater than
+the replay counter from the previous message.
+
+DHCP authentication, described in [3], must work within the existing
+DHCP state machine described in [4].  For a client in INIT state, this
+means that the client must obtain a valid TGT, as well as a session key,
+within the two round-trips provided by the
+DHCPDISCOVER/OFFER/REQUEST/ACK sequence.
+
+In INIT state, the DHCP client submits an incomplete AS_REQ to the DHCP
+server within the DHCPDISCOVER message.  The DHCP server then completes
+the AS_REQ using the IP address to be assigned to the client, and
+submits this to the client's home KDC in order to obtain a TGT on the
+client's behalf. Once the home KDC responds with an AS_REP, the DHCP
+server extracts the client TGT and submits this along with its own TGT
+to the home KDC, in order to obtain a user-to-user ticket to the DHCP
+client. The AS_REP as well as the AP_REQ are included by the DHCP server
+in the DHCPOFFER. The DHCP client can then decrypt the AS_REP to obtain
+a home realm TGT and TGT session key, using the latter to decrypt the
+user-to-user ticket to obtain the user-to-user session key. It is the
+user-to-user session key that is used to authenticate and integrity
+protect the client's DHCPREQUEST, and DHCPDECLINE messages. Similarly,
+this same session key is used to compute the integrity attribute in the
+server's DHCPOFFER, DHCPACK and DHCPNAK messages, as described in [3].
+
+In the INIT-REBOOT, REBINDING, or RENEWING states, the server can submit
+the home realm TGT in the DHCPREQUEST, along with authenticating and
+integrity protecting the message using an integrity attribute within the
+authentication option. The integrity attribute is computed using the
+existing session key.  The DHCP server can then return a renewed user-
+to-user ticket within the DHCPACK message. The authenticated DHCPREQUEST
+message from a client in INIT-REBOOT state can only be validated by
+servers that used the same session key to compute the integrity
+attribute in their DHCPOFFER messages.
+
+Other servers will discard the DHCPREQUEST messages. Thus, only servers
+that used the user-to-user session key selected by the client will be
+able to determine that their offered configuration information was not
+selected, returning the offered network address to the server's pool of
+available addresses.  The servers that cannot validate the DHCPREQUEST
+message will eventually return their offered network addresses to their
+pool of available addresses as described in section 3.1 of the DHCP
+specification [4].
+
+When sending a DHCPINFORM, there are two possible procedures.  If the
+client knows the DHCP server it will be interacting with, then it can
+obtain a ticket to the DHCP server from the local realm KDC. This will
+require obtaining a TGT to its home realm, as well as possibly a cross-
+
+
+
+Hornstein, et al.            Standards Track                    [Page 3]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+realm TGT to the local realm if the local and home realms differ. Once
+the DHCP client has a local realm TGT, it can then request a DHCP server
+ticket in a TGS_REQ. The DHCP client can then include AP_REQ and
+integrity attributes within the DHCPINFORM. The integrity attribute is
+computed as described in [3], using the session key obtained from the
+TGS_REP. The DHCP server replies with a DHCPACK/DHCPNAK, authenticated
+using the same session key.
+
+If the DHCP client does not know the DHCP server it is interacting with
+then it will not be able to obtain a ticket to it and a different
+procedure is needed.  In this case, the client will include in the
+DHCPINFORM an authentication option with a ticket attribute containing
+its home realm TGT. The DHCP server will then use this TGT in order to
+request a user-to-user ticket from the home KDC in a TGS_REQ.  The DHCP
+server will return the user-to-user ticket and will authenticate and
+integrity protect the DHCPACK/DHCPNAK message. This is accomplished by
+including AP_REQ and integrity attributes within the authentication
+option included with the DHCPACK/DHCPNAK messages.
+
+In order to support the DHCP client's ability to authenticate the DHCP
+server in the case where the server name is unknown, the Kerberos
+principal name for the DHCP server must be of type KRB_NT_SRV_HST with
+the service name component equal to 'dhcp'. For example, the DHCP server
+principal name for the host srv.foo.org would be of the form
+dhcp/srv.foo.org.  The client MUST validate that the DHCP server
+principal name has the above format. This convention requires that the
+administrator ensure that non-DHCP server principals do not have names
+that match the above format.
+
+4.1.  Authentication Option Format
+
+A summary of the authentication option  format for DHCP authentication
+via Kerberos V is shown below.  The fields are transmitted from left to
+right.
+
+0                   1                   2                   3
+0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|     Code      |     Length    |   Protocol    | Algorithm     |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                      Global Replay Counter                    |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                      Global Replay Counter                    |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                           Attributes...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+Code
+
+
+
+Hornstein, et al.            Standards Track                    [Page 4]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+   TBD - DHCP Authentication
+
+Length
+
+   The length field is a single octet and indicates the length of the
+   Protocol, Algorith, and Authentication Information fields.  Octets
+   outside the range of the length field should be ignored on reception.
+
+Protocol
+
+   TBD - DHCP Kerberos V authentication
+
+Algorithm
+
+   The algorithm field is a single octet and defines the specific
+   algorithm to be used for computation of the authentication option.
+   Values for the field are as follows:
+
+   0 - reserved
+   1 - HMAC-MD5
+   2 - HMAC-SHA
+   3 - 255 reserved
+
+Global Replay Counter
+
+   As described in [3], the global replay counter field is 8 octets in
+   length. It MUST be set to the value of a monotonically increasing
+   counter. Using a counter value such as the current time of day (e.g.,
+   an NTP-format timestamp [10]) can reduce the danger of replay
+   attacks.
+
+Attributes
+
+   The attributes field consists of type-length-value attributes of the
+   following format:
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |  Reserved     |       Payload Length          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           Attribute value...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+Type
+   The type field is a single octet and is defined as follows:
+
+   0  - Integrity check
+
+
+
+Hornstein, et al.            Standards Track                    [Page 5]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+   1  - TICKET
+   2  - Authenticator
+   3  - EncTicketPart
+   10 - AS_REQ
+   11 - AS_REP
+   12 - TGS_REQ
+   13 - TGS_REP
+   14 - AP_REQ
+   15 - AP_REP
+   20 - KRB_SAFE
+   21 - KRB_PRIV
+   22 - KRB_CRED
+   25 - EncASRepPart
+   26 - EncTGSRepPart
+   27 - EncAPRepPart
+   28 - EncKrbPrvPart
+   29 - EncKrbCredPart
+   30 - KRB_ERROR
+
+   Note that the values of the Type field are the same as in the
+   Kerberos MSG-TYPE field. As a result, no new number spaces are
+   created for IANA administration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornstein, et al.            Standards Track                    [Page 6]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+   The following attribute types are allowed within the following
+   messages:
+
+   DISCOVER  OFFER  REQUEST  DECLINE   #    Attribute
+   --------------------------------------------------------
+      0        1       1        1      0    Integrity check
+      0        0      0-1       0      1    Ticket
+      1        0       0        0     10    AS_REQ
+      0        1       0        0     11    AS_REP
+      0        1       0        0     14    AP_REQ
+      0       0-1      0        0     30    KRB_ERROR
+
+   RELEASE   ACK   NAK    INFORM   INFORM      #    Attribute
+                          w/known  w/unknown
+                          server   server
+   ---------------------------------------------------------------
+      1       1     1        1        0        0    Integrity check
+      0       0     0        0        1        1    Ticket
+      0       0     0        0        0       10    AS_REQ
+      0       0     0        0        0       11    AS_REP
+      0      0-1    0        1        0       14    AP_REQ
+      0       0    0-1       0        0       30    KRB_ERROR
+
+4.2.  Client behavior
+
+The following section, which incorporates material from [3], describes
+client behavior in detail.
+
+4.2.1.  INIT state
+
+When in INIT state, the client behaves as follows:
+
+
+[1]  As described in [3], the client MUST include the authentication
+     request option in its DHCPDISCOVER message along with option 61
+     [11] to identify itself uniquely to the server. An AS_REQ attribute
+     MUST be included within the authentication request option. This
+     (incomplete) AS_REQ will set the FORWARDABLE and RENEWABLE flags
+     and MAY include pre-authentication data (PADATA) if the client
+     knows what PADATA its home KDC will require. The ADDRESSES field in
+     the AS_REQ will be ommitted since the client does not yet know its
+     IP address. The ETYPE field will be set to an encryption type that
+     the client can accept.
+
+[2]  The client MUST validate DHCPOFFER messages that include an
+     authentication option. Messages including an authentication option
+     with a KRB_ERROR attribute and no integrity attribute are treated
+     as though they are unauthenticated. More typically, authentication
+
+
+
+Hornstein, et al.            Standards Track                    [Page 7]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+     options within the DHCPOFFER message will include AS_REP, AP_REQ,
+     and integrity attributes. To validate the authentication option,
+     the client decrypts the enc-part of the AS_REP in order to obtain
+     the TGT session key. This is used to decrypt the enc-part of the
+     AP_REQ in order to obtain the user-to-user session key. The user-
+     to-user session key is then used to compute the message integrity
+     check as described in [3], and the computed value is compared to
+     the value within the integrity attribute. The client MUST discard
+     any messages which fail to pass validation and MAY log the
+     validation failure.
+
+     As described in [3], the client selects one DHCPOFFER message as
+     its selected configuration. If none of the DHCPOFFER messages
+     received by the client include an authentication option, the client
+     MAY choose an unauthenticated message as its selected
+     configuration.  DHCPOFFER messages including an authentication
+     option with a KRB_ERROR attribute and no integrity attribute are
+     treated as though they are unauthenticated.  The client SHOULD be
+     configurable to accept or reject unauthenticated DHCPOFFER
+     messages.
+
+[3]  The client replies with a DHCPREQUEST message that MUST include an
+     authentication option. The authentication option MUST include an
+     integrity attribute, computed as described in [3], using the user
+     to user session key recovered in step 2.
+
+[4]  As noted in [3], the client MUST validate a DHCPACK message from
+     the server that includes an authentication option. DHCPACK or
+     DHCPNAK messages including an authentication option with a
+     KRB_ERROR attribute and no integrity attribute are treated as
+     though they are unauthenticated. The client MUST silently discard
+     the DHCPACK if the message fails to pass validation and MAY log the
+     validation failure. If the DHCPACK fails to pass validation, the
+     client MUST revert to the INIT state and return to step 1. The
+     client MAY choose to remember which server replied with an invalid
+     DHCPACK message and discard subsequent messages from that server.
+
+4.2.2.  INIT-REBOOT state
+
+When in INIT-REBOOT state, if the user-to-user ticket is still valid,
+the client MUST re-use the session key from the DHCP server user-to-user
+ticket in its DHCPREQUEST message. This is used to generate the
+integrity attribute contained within the authentication option, as
+described in [3]. In the DHCPREQUEST, the DHCP client also includes its
+home realm TGT in a ticket attribute in the authentication option in
+order to assist the DHCP server in renewing the user-to-user ticket.  To
+ensure that the user-to-user ticket remains valid throughout the DHCP
+lease period so that the renewal process can proceed, the Kerberos
+
+
+
+Hornstein, et al.            Standards Track                    [Page 8]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+ticket lifetime SHOULD be set to exceed the DHCP lease time.  If the
+user-to-user ticket is expired, then the client MUST return to the INIT
+state.
+
+The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages
+if no authenticated messages were received. DHCPACK/DHCPNAK messages
+with an authentication option containing a KRB_ERROR attribute and no
+integrity attribute are treated as though they are unauthenticated. The
+client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK
+messages as specified in section 3.2 of the DHCP specification [4].
+
+4.2.3.  RENEWING state
+
+When in RENEWING state, the DHCP client can be assumed to have a valid
+IP address, as well as a TGT to the home realm, a user-to-user ticket
+provided by the DHCP server, and a session key with the DHCP server, all
+obtained during the original DHCP conversation.  If the user-to-user
+ticket is still valid, the client MUST re-use the session key from the
+user-to-user ticket in its DHCPREQUEST message to generate the integrity
+attribute contained within the authentication option.
+
+Since the DHCP client can renew the TGT to the home realm, it is
+possible for it to continue to hold a valid home realm TGT.  However,
+since the DHCP client did not obtain the user-to-user ticket on its own,
+it will need to rely on the DHCP server to renew this ticket. In the
+DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket
+attribute in the authentication option in order to assist the DHCP
+server in renewing the user-to-user ticket.
+
+If the DHCP server user-to-user ticket is expired, then the client MUST
+return to INIT state.  To ensure that the user-to-user ticket remains
+valid throughout the DHCP lease period so that the renewal process can
+proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP
+lease time.  If client receives no DHCPACK messages or none of the
+DHCPACK messages pass validation, the client behaves as if it had not
+received a DHCPACK message in section 4.4.5 of the DHCP specification
+[4].
+
+4.2.4.  REBINDING state
+
+When in REBINDING state, the DHCP client can be assumed to have a valid
+IP address, as well as a TGT to the home realm, a user-to-user ticket
+and a session key with the DHCP server, all obtained during the original
+DHCP conversation.  If the user-to-user ticket is still valid, the
+client MUST re-use the session key from the user-to-user ticket in its
+DHCPREQUEST message to generate the integrity attribute contained within
+the authentication option, as described in [3].
+
+
+
+
+Hornstein, et al.            Standards Track                    [Page 9]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+Since the DHCP client can renew the TGT to the home realm, it is
+possible for it to continue to hold a valid home realm TGT.  However,
+since the DHCP client did not obtain the user-to-user ticket on its own,
+it will need to rely on the DHCP server to renew this ticket. In the
+DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket
+attribute in the authentication option in order to assist the DHCP
+server in renewing the user-to-user ticket.
+
+If the user-to-user ticket is expired, then the client MUST return to
+INIT state.  To ensure that the user-to-user ticket remains valid
+throughout the DHCP lease period so that the renewal process can
+proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP
+lease time.  If client receives no DHCPACK messages or none of the
+DHCPACK messages pass validation, the client behaves as if it had not
+received a DHCPACK message in section 4.4.5 of the DHCP specification
+[4].
+
+4.2.5.  DHCPRELEASE message
+
+Clients sending a DHCPRELEASE MUST include an authentication option. The
+authentication option MUST include an integrity attribute, computed as
+described in [3], using the user to user session key.
+
+4.2.6.  DHCPDECLINE message
+
+Clients sending a DHCPDECLINE MUST include an authentication option. The
+authentication option MUST include an integrity attribute, computed as
+described in [3], using the user to user session key.
+
+4.2.7.  DHCPINFORM message
+
+Since the client already has some configuration information, it can be
+assumed that it has the ability to obtain a home or local realm TGT
+prior to sending the DHCPINFORM.
+
+If the DHCP client knows which DHCP server it will be interacting with,
+then it SHOULD include an authentication option containing AP_REQ and
+integrity attributes within the DHCPINFORM.  The DHCP client first
+requests a TGT to the local realm via an AS_REQ and then using the TGT
+returned in the AS_REP to request a ticket to the DHCP server from the
+local KDC in a TGS_REQ. The session key obtained from the TGS_REP will
+be used to generate the integrity attribute as described in [3].
+
+If the DHCP client does not know what DHCP server it will be talking to,
+then it cannot obtain a ticket to the DHCP server. In this case, the
+DHCP client MAY send an unauthenticated DHCPINFORM or it MAY include an
+authentication option including a ticket attribute only.  The ticket
+attribute includes a TGT for the home realm. The client MUST validate
+
+
+
+Hornstein, et al.            Standards Track                   [Page 10]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+that the DHCP server name in the received Kerberos AP_REQ message is of
+the form dhcp/.... as described in section 4.
+
+The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages
+if no authenticated messages were received. DHCPACK/DHCPNAK messages
+with an authentication option containing a KRB_ERROR attribute and no
+integrity attribute are treated as though they are unauthenticated. The
+client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK
+messages as specified in section 3.2 of the DHCP specification [4].
+
+4.3.  Server behavior
+
+This section, which relies on material from [3], describes the behavior
+of a server in response to client messages.
+
+4.3.1.  After receiving a DHCPDISCOVER message
+
+For installations where IP addresses are required within tickets, the
+DHCP server MAY complete the AS_REQ by filling in the ADDRESSES field
+based on the IP address that it will include in the DHCPOFFER.  The DHCP
+server sends the AS_REQ to the home KDC with the FORWARDABLE flag set.
+The home KDC then replies to the DHCP server with an AS_REP.  The DHCP
+server extracts the client TGT from the AS_REP and forms a TGS_REQ,
+which it sends to  the home KDC.
+
+If the DHCP server and client are in different realms, then the DHCP
+server will need to obtain a TGT to the home realm from the KDC of its
+own (local) realm prior to sending the TGS_REQ. The TGS_REQ includes the
+DHCP server's TGT within the home realm, has the ENC-TKT-IN-SKEY flag
+set and includes the client home realm TGT in the ADDITIONAL-TICKETS
+field, thus requesting a user-to ticket to the DHCP client.  The home
+KDC then returns a user-to-user ticket in a TGS_REP. The user-to-user
+ticket is encrypted in the client's home realm TGT session key.
+
+In order to recover the user-to-user session key, the DHCP server
+decrypts the enc-part of the TGS_REP. To accomplish this, the DHCP
+server uses the session key that it shares with the home realm, obtained
+in the AS_REQ/AS_REP conversation that it used to obtain its own TGT to
+the home realm.
+
+The DHCP server then sends a DHCPOFFER to the client, including AS_REP,
+AP_REQ and integrity attributes within the authentication option.  The
+AS_REP attribute encapsulates the AS_REP sent to the DHCP server by the
+home KDC. The AP_REQ attribute includes an AP_REQ constructed by the
+DHCP server based on the TGS_REP sent to it by the home KDC. The server
+also includes an integrity attribute generated as specified in [3] from
+the user-to-user session key.  The server MUST record the user-to-user
+session key selected for the client and use that session key for
+
+
+
+Hornstein, et al.            Standards Track                   [Page 11]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+validating subsequent messages with the client.
+
+4.3.2.  After receiving a DHCPREQUEST message
+
+The DHCP server uses the user-to-user session key in order to validate
+the integrity attribute contained within the authentication option,
+using the method specified in [3]. If the message fails to pass
+validation, it MUST discard the message and MAY choose to log the
+validation failure.
+
+If the message passes the validation procedure, the server responds as
+described in [4], including an integrity attribute computed as specified
+in [3] within the DHCPACK or DHCPNAK message.
+
+If the authentication option included within the DHCPREQUEST message
+contains a ticket attribute then the DHCP server will use the home realm
+TGT included in the ticket attribute in order to renew the user-to-user
+ticket, which it returns in an AP_REQ attribute within the DHCPACK.
+DHCPACK or DHCPNAK messages then include an integrity attribute
+generated as specified in [3], using the new user-to-user session key
+included within the AP_REQ.
+
+4.3.3.  After receiving a DHCPINFORM message
+
+The server MAY choose to accept unauthenticated DHCPINFORM messages, or
+only accept authenticated DHCPINFORM messages based on a site policy.
+
+When a client includes an authentication option in a DHCPINFORM message,
+the server MUST respond with an authenticated DHCPACK or DHCPNAK
+message. If the DHCPINFORM message includes an authentication option
+including AP_REQ and integrity attributes, the DHCP server decrypts the
+AP_REQ attribute and then recovers the session key. The DHCP server than
+validates the integrity attribute included in the authentication option
+using the session key. If the integrity attribute is invalid then the
+DHCP server MUST silently discard the DHCPINFORM message.
+
+If the authentication option only includes a ticket attribute and no
+integrity or AP_REQ attributes, then the DHCP server should assume that
+the client needs the server to obtain a user-to-user ticket from the
+home realm KDC.  In this case, the DHCP server includes the client home
+realm TGT and its own home realm TGT in a TGS_REQ to the home realm KDC.
+It then receives a user-to-user ticket from the home realm KDC in a
+TGS_REP. The DHCP server will then include AP_REQ and integrity
+attributes within the DHCPACK/DHCPNAK.
+
+If the client does not include an authentication option in the
+DHCPINFORM, the server can either respond with an unauthenticated
+DHCPACK message, or a DHCPNAK if the server does not accept
+
+
+
+Hornstein, et al.            Standards Track                   [Page 12]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+unauthenticated clients.
+
+4.3.4.  After receiving a DHCPRELEASE message
+
+The DHCP server uses the session key in order to validate the integrity
+attribute contained within the authentication option, using the method
+specified in [3]. If the message fails to pass validation, it MUST
+discard the message and MAY choose to log the validation failure.
+
+If the message passes the validation procedure, the server responds as
+described in [4], marking the client's network address as not allocated.
+
+4.3.5.  After receiving a DHCPDECLINE message
+
+The DHCP server uses the session key in order to validate the integrity
+attribute contained within the authentication option, using the method
+specified in [3]. If the message fails to pass validation, it MUST
+discard the message and MAY choose to log the validation failure.
+
+If the message passes the validation procedure, the server proceeds as
+described in [4].
+
+4.4.  Error handling
+
+When an error condition occurs during a Kerberos exchange, Kerberos
+error messages can be returned by either side.  These Kerberos error
+messages MAY be logged by the receiving and sending parties.
+
+In some cases, it may be possible for these error messages to be
+included within the authentication option via the KRB_ERROR attribute.
+However, in most cases, errors will result in messages being silently
+discarded and so no response will be returned.
+
+For example, if the home KDC returns a KRB_ERROR in response to the
+AS_REQ submitted by the DHCP server on the client's behalf, then the
+DHCP server will conclude that the DHCPDISCOVER was not authentic, and
+will silently discard it.
+
+However, if the AS_REQ included PADATA and the home KDC responds with an
+AS_REP, then the DHCP server can conclude that the client is authentic.
+If the subsequent TGS_REQ is unsuccessful, with a KRB_ERROR returned by
+the home KDC in the TGS_REP, then the fault may lie with the DHCP server
+rather than with the client. In this case, the DHCP server MAY choose to
+return a KRB_ERROR within the authentication option included in the
+DHCPOFFER. The client will then treat this as an unauthenticated
+DHCPOFFER.
+
+
+
+
+
+Hornstein, et al.            Standards Track                   [Page 13]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+Similarly, if the integrity attribute contained in the DHCPOFFER proves
+invalid, the client will silently discard the DHCPOFFER and instead
+accept an offer from another server if one is available. If the
+integrity attribute included in the DHCPACK/DHCPNAK proves invalid, then
+the client behaves as if it did not receive a DHCPACK/DHCPNAK.
+
+When in INIT-REBOOT, REBINDING or RENEWING state, the client will
+include a ticket attribute and integrity attribute within the
+authentication option of the DHCPREQUEST, in order to assist the DHCP
+server in renewing the user-to-user ticket.  If the integrity attribute
+is invalid, then the DHCP server MUST silently discard the DHCPREQUEST.
+
+However, if the integrity attribute is successfully validated by the
+DHCP server, but the home realm TGT included in the ticket attribute is
+invalid (e.g. expired), then the DHCP server will receive a KRB_ERROR in
+response to its TGS_REQ to the home KDC.  In this case, the DHCP server
+MAY respond with a DHCPNAK including a KRB_ERROR attribute and no
+integrity attribute within the authentication option. This will force
+the client back to the INIT state, where it can receive a valid home
+realm TGT.
+
+Where the client included PADATA in the AS_REQ attribute of the
+authentication option within the DHCPDISCOVER and the AS_REQ was
+successfully validated by the KDC, the DHCP server will conclude that
+the DHCP client is authentic. In this case if the client successfully
+validates the integrity attribute in the DHCPOFFER, but the server does
+not validate the integrity attribute in the client's DHCPREQUEST, the
+server MAY choose to respond with an authenticated DHCPNAK containing a
+KRB_ERROR attribute.
+
+4.5.  PKINIT issues
+
+When public key authentication is supported with Kerberos as described
+in [8], the client certificate and a signature accompany the initial
+request in the preauthentication fields.  As a result, it is conceivable
+that the incomplete AS_REQ included in the DHCPDISCOVER packet may
+exceed the size of a single DHCP option, or even the MTU size.  As noted
+in [4], a single option may be as large as 255 octets. If the value to
+be passed is larger than this the client concatenates together the
+values of multiple instances of the same option.
+
+4.6.  Examples
+
+4.6.1.  INIT state
+
+In the intra-realm case where the DHCP Kerberos mutual authentication is
+successful, the conversation will appear as follows:
+
+
+
+
+Hornstein, et al.            Standards Track                   [Page 14]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ)  ->
+                   AS_REQ ->
+                                      <- AS_REP
+                   TGS_REQ
+                    U-2-U ->
+                                      <- TGS_REP
+                <- DHCPOFFER,
+                    (AS_REP,
+                    AP_REQ,
+                    Integrity)
+DHCPREQUEST
+ (Integrity) ->
+                <- DHCPACK
+                    (Integrity)
+
+In the case where the KDC returns a KRB_ERROR in response to the AS_REQ,
+the server will silently discard the DHCPDISCOVER and the conversation
+will appear as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ)  ->
+                   AS_REQ ->
+                                     <- KRB_ERROR
+
+In the inter-realm case where the DHCP Kerberos mutual authentication is
+successful, the conversation will appear as follows:
+
+   DHCP            DHCP           Home      Local
+   Client          Server         KDC        KDC
+--------------  -------------  ---------  ---------
+DHCPDISCOVER
+(Incomplete
+ AS_REQ)  ->
+                   AS_REQ ->
+                                <- AS_REP
+                   TGS_REQ ->
+                   (cross realm,
+                   for home
+                   KDC)
+
+
+
+Hornstein, et al.            Standards Track                   [Page 15]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+                                           <- TGS_REP
+
+                   TGS_REQ
+                    U-2-U ->
+                                <- TGS_REP
+                <- DHCPOFFER,
+                    (AS_REP,
+                    AP_REQ,
+                    Integrity)
+DHCPREQUEST
+ (Integrity) ->
+                <- DHCPACK
+                    (Integrity)
+
+In the case where the client includes PADATA in the AS_REQ attribute
+within the authentication option of the DHCPDISCOVER and the KDC returns
+an error-free AS_REP indicating successful validation of the PADATA, the
+DHCP server will conclude that the DHCP client is authentic.  If the KDC
+then returns a KRB_ERROR in response to the TGS_REQ, indicating a fault
+that lies with the DHCP server, the server MAY choose not to silently
+discard the DHCPDISCOVER.  Instead it MAY respond with a DHCPOFFER
+including a KRB_ERROR attribute within the authentication option. The
+client will then treat this as an unauthenticated DHCPOFFER.  The
+conversation will appear as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ
+ w/PADATA)  ->
+                   AS_REQ ->
+                                     <- AS_REP
+                   TGS_REQ
+                    U-2-U ->
+                                     <- KRB_ERROR
+                <- DHCPOFFER,
+                    (KRB_ERROR)
+DHCPREQUEST ->
+                <- DHCPACK
+
+In the intra-realm case where the client included PADATA in the AS_REQ
+attribute of the authentication option and the AS_REQ was successfully
+validated by the KDC, the DHCP server will conclude that the DHCP client
+is authentic. In this case if the client successfully validates the
+integrity attribute in the DHCPOFFER, but the server does not validate
+the integrity attribute in the client's DHCPREQUEST, the server MAY
+
+
+
+Hornstein, et al.            Standards Track                   [Page 16]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+choose to respond with an authenticated DHCPNAK containing a KRB_ERROR
+attribute.  The conversation will appear as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ
+ w/PADATA)  ->
+                   AS_REQ ->
+                                     <- AS_REP
+                   TGS_REQ
+                    U-2-U ->
+                                     <- TGS_REP
+                <- DHCPOFFER,
+                    (AS_REP,
+                    AP_REQ,
+                    Integrity)
+DHCPREQUEST
+ (Integrity) ->
+                <- DHCNAK
+                    (KRB_ERROR,
+                     Integrity)
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ)  ->
+
+In the intra-realm case where the DHCP client cannot validate the
+integrity attribute in the DHCPOFFER, the client silently discards the
+DHCPOFFER. The conversation will appear as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ)  ->
+                   AS_REQ ->
+                                     <- AS_REP
+                   TGS_REQ
+                    U-2-U ->
+                                     <- TGS_REP
+                <- DHCPOFFER,
+                   (AS_REP,
+                   AP_REQ,
+                   Integrity)
+DHCPREQUEST
+
+
+
+Hornstein, et al.            Standards Track                   [Page 17]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+ [To another server]
+ (Integrity) ->
+
+In the intra-realm case where the DHCP client cannot validate the
+integrity attribute in the DHCPACK, the client reverts to INIT state.
+The conversation will appear as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+DHCPDISCOVER
+(Incomplete
+ AS_REQ)  ->
+                   AS_REQ ->
+                                     <- AS_REP
+                   TGS_REQ
+                    U-2-U ->
+                                     <- TGS_REP
+                <- DHCPOFFER,
+                    (AS_REP,
+                    AP_REQ,
+                    Integrity)
+DHCPREQUEST
+ (Integrity) ->
+                <- DHCPACK
+                    (Integrity)
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ)  ->
+
+4.6.2.  INIT-REBOOT, RENEWING or REBINDING
+
+In the intra-realm or inter-realm case where the original user-to-user
+ticket is still valid, and the DHCP server still has a valid TGT to the
+home realm, the conversation will appear as follows:
+
+   DHCP               DHCP             Home
+   Client             Server            KDC
+--------------     -------------     ---------
+
+DHCPREQUEST
+ (TGT,
+ Integrity)  ->
+                   TGS_REQ
+                    U-2-U ->
+                                     <- TGS_REP
+                <- DHCPACK
+                    (AP_REQ,
+
+
+
+Hornstein, et al.            Standards Track                   [Page 18]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+                    Integrity)
+
+In the intra-realm or inter-realm case where the DHCP server validates
+the integrity attribute in the DHCPREQUEST, but receives a KRB_ERROR in
+response to the TGS_REQ to the KDC, the DHCP sever MAY choose not to
+silently discard the DHCPREQUEST and MAY return an authenticated DHCPNAK
+to the client instead, using the user-to-user session key previously
+established with the client. The conversation appears as follows:
+
+   DHCP               DHCP             Home
+   Client             Server            KDC
+--------------     -------------     ---------
+
+DHCPREQUEST
+ (TGT,
+ Integrity)  ->
+                   TGS_REQ
+                    U-2-U ->
+                                     <- KRB_ERROR
+                <- DHCPNAK
+                    (KRB_ERROR,
+                    Integrity)
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ)  ->
+
+In the intra-realm or inter-realm case where the DHCP server cannot
+validate the integrity attribute in the DHCPREQUEST, the DHCP server
+MUST silently discard the DHCPREQUEST and the conversation will appear
+as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+
+DHCPREQUEST
+ (TGT,
+ Integrity)  ->
+                   Silent discard
+[Sequence repeats
+ until timeout]
+
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ)  ->
+
+In the intra-realm or inter-realm case where the original user-to-user
+ticket is still valid, the server validates the integrity attribute in
+
+
+
+Hornstein, et al.            Standards Track                   [Page 19]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+the DHCPREQUEST, but the client fails to validate the integrity
+attribute in the DHCPACK, the client will silently discard the DHCPACK.
+The conversation will appear as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+
+DHCPREQUEST
+ (TGT,
+ Integrity)  ->
+
+                <- DHCPACK
+                    (AP_REQ,
+                    Integrity)
+DHCPDISCOVER
+ (Incomplete
+ AS_REQ)  ->
+
+4.6.3.  DHCPINFORM (with known DHCP server)
+
+In the case where the DHCP client knows the DHCP server it will be
+interacting with, the DHCP client will obtain a ticket to the DHCP
+server and will include AP_REQ and integrity attributes within the
+DHCPINFORM.
+
+Where the DHCP Kerberos mutual authentication is successful, the
+conversation will appear as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+AS_REQ ->
+                                     <- AS_REP
+TGS_REQ ->
+                                     <- TGS_REP
+DHCPINFORM
+ (AP_REQ,
+ Integrity) ->
+                <- DHCPACK
+                    (Integrity)
+
+In the inter-realm case where the DHCP Kerberos mutual authentication is
+successful, the conversation will appear as follows:
+
+   DHCP            DHCP           Home      Local
+   Client          Server         KDC        KDC
+--------------  -------------  ---------  ---------
+
+
+
+Hornstein, et al.            Standards Track                   [Page 20]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+AS_REQ ->
+                                          <- AS_REP
+TGS_REQ ->
+                                          <- TGS_REP
+TGS_REQ ->
+                               <- TGS_REP
+DHCPINFORM
+ (AP_REQ,
+ Integrity) ->
+                <- DHCPACK
+                    (Integrity)
+
+In the inter-realm case where the DHCP server fails to validate the
+integrity attribute in the DHCPINFORM, the server MUST silently discard
+the DHCPINFORM. The conversation will appear as follows:
+
+   DHCP            DHCP           Home      Local
+   Client          Server         KDC        KDC
+--------------  -------------  ---------  ---------
+AS_REQ ->
+                                          <- AS_REP
+TGS_REQ ->
+                                          <- TGS_REP
+TGS_REQ ->
+                               <- TGS_REP
+DHCPINFORM
+ (AP_REQ,
+ Integrity) ->
+                <- DHCPACK
+                    (Integrity)
+DHCPINFORM
+ (AP_REQ,
+ Integrity) ->
+
+In the inter-realm case where the DHCP client fails to validate the
+integrity attribute in the DHCPACK, the client MUST silently discard the
+DHCPACK.  The conversation will appear as follows:
+
+   DHCP            DHCP           Home      Local
+   Client          Server         KDC        KDC
+--------------  -------------  ---------  ---------
+AS_REQ ->
+                                          <- AS_REP
+TGS_REQ ->
+                                          <- TGS_REP
+TGS_REQ ->
+                               <- TGS_REP
+DHCPINFORM
+
+
+
+Hornstein, et al.            Standards Track                   [Page 21]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+ (AP_REQ,
+ Integrity) ->
+
+4.6.4.  DHCPINFORM (with unknown DHCP server)
+
+In the case where the DHCP client does not know the DHCP server it will
+be interacting with, the DHCP client will only include a ticket
+attribute within the DHCPINFORM.  Thus the DHCP server will not be able
+to validate the authentication option.
+
+Where the DHCP client is able to validate the DHCPACK and no error
+occur, the onversation will appear as follows:
+
+   DHCP               DHCP
+   Client             Server            KDC
+--------------     -------------     ---------
+AS_REQ ->
+                                     <- AS_REP
+DHCPINFORM
+ (Ticket) ->
+                   TGS_REQ
+                    U-2-U ->
+                                     <- TGS_REP
+                <- DHCPACK
+                    (AP_REQ,
+                    Integrity)
+
+In the inter-realm case where the DHCP server needs to obtain a TGT to
+the home realm, and where the client successfully validates the DHCPACK,
+the conversation will appear as follows:
+
+   DHCP            DHCP           Home      Local
+   Client          Server         KDC        KDC
+--------------  -------------  ---------  ---------
+AS_REQ ->
+                                          <- AS_REP
+DHCPINFORM
+ (Ticket) ->
+                   AS_REQ ->
+                                <- AS_REP
+                   TGS_REQ ->
+                   (cross realm,
+                   for home
+                   KDC)
+                                           <- TGS_REP
+
+                   TGS_REQ
+                    U-2-U ->
+
+
+
+Hornstein, et al.            Standards Track                   [Page 22]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+                                <- TGS_REP
+                <- DHCPACK
+                    (AP_REQ,
+                    Integrity)
+
+In the inter-realm case where the local KDC returns a KRB_ERROR in
+response to the TGS_REQ from the DHCP server, the DHCP server MAY return
+a KRB_ERROR within the DHCP authentication option included in a DHCPNAK.
+The conversation will appear as follows:
+
+   DHCP            DHCP           Home      Local
+   Client          Server         KDC        KDC
+--------------  -------------  ---------  ---------
+AS_REQ ->
+                                          <- AS_REP
+DHCPINFORM
+ (Ticket) ->
+                   AS_REQ ->
+                                <- AS_REP
+                   TGS_REQ ->
+                   (cross realm,
+                   for home
+                   KDC)
+                                           <- KRB_ERROR
+                <- DHCPNAK
+                    (KRB_ERROR)
+
+
+In the inter-realm case where the DHCP client fails to validate the
+integrity attribute in the DHCPACK, the client MUST silently discard the
+DHCPACK.  The conversation will appear as follows:
+
+   DHCP            DHCP           Home      Local
+   Client          Server         KDC        KDC
+--------------  -------------  ---------  ---------
+AS_REQ ->
+                                          <- AS_REP
+DHCPINFORM
+ (Ticket) ->
+                   AS_REQ ->
+                                <- AS_REP
+                   TGS_REQ ->
+                   (cross realm,
+                   for home
+                   KDC)
+                                           <- TGS_REP
+
+                   TGS_REQ
+
+
+
+Hornstein, et al.            Standards Track                   [Page 23]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+                    U-2-U ->
+                                <- TGS_REP
+                <- DHCPACK
+                    (AP_REQ,
+                    Integrity)
+DHCPINFORM
+ (Ticket) ->
+
+5.  References
+
+
+[1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+     Levels", BCP 14, RFC 2119, March 1997.
+
+[2]  Kohl, J., Neuman, C., "The Kerberos Network Authentication Service
+     (V5)", RFC 1510, September 1993.
+
+[3]  Droms, R., Arbaugh, W., "Authentication for DHCP Messages",
+     Internet draft (work in progress), draft-ietf-dhc-
+     authentication-11.txt, June 1999.
+
+[4]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
+     1997.
+
+[5]  Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
+     Extensions", RFC 2132, March 1997.
+
+[6]  Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
+
+[7]  Jain, V., Congdon, P., Roese, J., "Network Port Authentication",
+     IEEE 802.1 PAR submission, June 1999.
+
+[8]  Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray,
+     J., Trostle, J., "Public Key Cryptography for Initial
+     Authentication in Kerberos", Internet draft (work in progress),
+     draft-ietf-cat-kerberos-pk-init-09.txt, June 1999.
+
+[9]  Tung, B., Ryutov, T., Neuman, C., Tsudik, G., Sommerfeld, B.,
+     Medvinsky, A., Hur, M.,  "Public Key Cryptography for Cross-Realm
+     Authentication in Kerberos", Internet draft (work in progress),
+     draft-ietf-cat-kerberos-pk-cross-04.txt, June 1999.
+
+[10] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March
+     1992.
+
+[11] Henry, M., "DHCP Option 61 UUID Type Definition", Internet draft
+     (work in progress), draft-henry-DHCP-opt61-UUID-type-00.txt,
+     November 1998.
+
+
+
+Hornstein, et al.            Standards Track                   [Page 24]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+6.  Security Considerations
+
+DHCP authentication, described in [3], addresses the following threats:
+
+     Modification of messages
+     Rogue servers
+     Unauthorized clients
+
+This section describes how DHCP authentication via Kerberos V addresses
+each of these threats.
+
+6.1.  Client security
+
+As noted in [3], it may be desirable to ensure that IP addresses are
+only allocated to authorized clients. This can serve to protect against
+denial of service attacks. To address this issue it is necessary for
+DHCP client messages to be authenticated. In order to guard against
+message modification, it is also necessary for DHCP client messages to
+be integrity protected.
+
+Note that this protocol does not make use of KRB_SAFE, so as to allow
+modification of mutable fields by the DHCP relay. Replay protection is
+therefore provided within the DHCP authentication option itself.
+
+In DHCP authentication via Kerberos V the DHCP client will authenticate,
+integrity and replay-protect the DHCPREQUEST, DHCPDECLINE and
+DHCPRELEASE messages using a user-to-user session key obtained by the
+DHCP server from the home KDC. If the DHCP client knows the DHCP server
+it will be interacting with, then the DHCP client MAY also authenticate,
+integrity and replay-protect the DHCPINFORM message using a session key
+obtained from the local realm KDC for the DHCP server it expects to
+converse with.
+
+Since the client has not yet obtained a session key, DHCPDISCOVER
+packets cannot be authenticated using the session key. However, the
+client MAY include pre-authentication data in the PADATA field included
+in the DHCPDISCOVER packet. Since the PADATA will then be used by the
+DHCP server to request a ticket on the client's behalf, the DHCP server
+will learn from the AS_REP whether the PADATA was acceptable or not.
+Therefore in this case, the DHCPDISCOVER will be authenticated but not
+integrity protected.
+
+Where the DHCP client does not know the DHCP server it will be
+interacting with ahead of time, the DHCPINFORM message will not be
+authenticated, integrity or replay protected.
+
+Note that snooping of PADATA and TGTs on the wire may provide an
+attacker with a means of mounting a dictionary attack, since these items
+
+
+
+Hornstein, et al.            Standards Track                   [Page 25]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+are typically encrypted with a key derived from the user's password.
+Thus use of strong passwords and/or pre-authentication methods utilizing
+strong cryptography (see [8]) are recommended.
+
+6.2.  Network access control
+
+DHCP authentication has been proposed as a method of limiting access to
+network media that are not physically secured such as wireless LANs and
+ports in college residence halls.  However, it is not particularly well
+suited to this purpose since even if address allocation is denied an
+inauthentic client may use a statically assigned IP address instead, or
+may attempt to access the network using non-IP protocols.  As a result,
+other methods, described in [6]-[7], have been proposed for controlling
+access to wireless media and switched LANs.
+
+6.3.  Server security
+
+As noted in [3], it may be desirable to protect against rogue DHCP
+servers put on the network either intentionally or by accident.  To
+address this issue it is necessary for DHCP server messages to be
+authenticated. In order to guard against message modification, it is
+also necessary for DHCP server messages to be integrity protected.
+Replay protection is also provided within the DHCP authentication
+option.
+
+All messages sent by the DHCP server are authenticated and integrity and
+replaly protected using a session key.  This includes the DHCPOFFER,
+DHCPACK, and DHCPNAK messages.  The session key is used to compute the
+DHCP authentication option, which is verified by the client.
+
+In order to provide protection against rogue servers it is necessary to
+prevent rogue servers from obtaining the credentials necessary to act as
+a DHCP server. As noted in Section 4, the Kerberos principal name for
+the DHCP server  must be of type KRB_NT_SRV_HST with  the service name
+component equal to 'dhcp'. The client MUST validate that the DHCP server
+principal name has the above  format. This convention requires that the
+administrator ensure that non-DHCP  server principals do not have names
+that match the above format.
+
+7.  IANA Considerations
+
+This draft does not create any new number spaces for IANA
+administration.
+
+8.  Acknowledgements
+
+The authors would like to acknowledge Ralph Droms and William Arbaugh,
+authors of the DHCP authentication draft [3]. This draft incorporates
+
+
+
+Hornstein, et al.            Standards Track                   [Page 26]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+material from their work; however, any mistakes in this document are
+solely the responsibility of the authors.
+
+9.  Authors' Addresses
+
+Ken Hornstein
+US Naval Research Laboratory
+Bldg A-49, Room 2
+4555 Overlook Avenue
+Washington DC  20375 USA
+
+Phone: +1 (202) 404-4765
+EMail: kenh@cmf.nrl.navy.mil
+
+Ted Lemon
+Internet Engines, Inc.
+950 Charter Street
+Redwood City, CA 94063
+
+Phone: +1 (650) 779 6031
+Email: mellon@iengines.net
+
+Bernard Aboba
+Microsoft Corporation
+One Microsoft Way
+Redmond, WA 98052
+
+Phone: +1 (425) 936-6605
+EMail: bernarda@microsoft.com
+
+Jonathan Trostle
+170 W. Tasman Dr.
+San Jose, CA 95134, U.S.A.
+
+Email: jtrostle@cisco.com
+Phone: +1 (408) 527-6201
+
+
+10.  Intellectual Property Statement
+
+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
+
+
+
+Hornstein, et al.            Standards Track                   [Page 27]
+
+
+INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
+
+
+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.
+
+11.  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 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 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."
+
+12.  Expiration Date
+
+This memo is filed as <draft-hornstein-dhc-kerbauth-02.txt>,  and
+expires October 1, 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+Hornstein, et al.            Standards Track                   [Page 28]
+
+
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-iakerb-04.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-iakerb-04.txt
new file mode 100644
index 000000000000..208d057f24c8
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-iakerb-04.txt
@@ -0,0 +1,301 @@
+INTERNET-DRAFT                                        Mike Swift
+draft-ietf-cat-iakerb-04.txt                          Microsoft
+Updates: RFC 1510                                     Jonathan Trostle
+July 2000					      Cisco Systems
+                                  
+
+         Initial Authentication and Pass Through Authentication 
+                Using Kerberos V5 and the GSS-API (IAKERB)
+
+
+0. Status Of This Memo
+
+   This document is an Internet-Draft and is in full conformance
+   with all 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/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This draft expires on January 31st, 2001.
+
+
+1. Abstract
+
+   This document defines an extension to the Kerberos protocol
+   specification (RFC 1510 [1]) and GSSAPI Kerberos mechanism (RFC 
+   1964 [2]) that enables a client to obtain Kerberos tickets for 
+   services where:
+
+   (1) The client knows its principal name and password, but not
+   its realm name (applicable in the situation where a user is already 
+   on the network but needs to authenticate to an ISP, and the user  
+   does not know his ISP realm name).
+   (2) The client is able to obtain the IP address of the service in 
+   a realm which it wants to send a request to, but is otherwise unable 
+   to locate or communicate with a KDC in the service realm or one of 
+   the intermediate realms. (One example would be a dial up user who 
+   does not have direct IP connectivity).
+   (3) The client does not know the realm name of the service.
+
+
+2. Motivation
+
+   When authenticating using Kerberos V5, clients obtain tickets from
+   a KDC and present them to services. This method of operation works
+
+   well in many situations, but is not always applicable since it
+   requires the client to know its own realm, the realm of the target 
+   service, the names of the KDC's, and to be able to connect to the 
+   KDC's. 
+  
+   This document defines an extension to the Kerberos protocol
+   specification (RFC 1510) [1] that enables a client to obtain
+   Kerberos tickets for services where:
+
+   (1) The client knows its principal name and password, but not
+   its realm name (applicable in the situation where a user is already 
+   on the network but needs to authenticate to an ISP, and the user 
+   does not know his ISP realm name).
+   (2) The client is able to obtain the IP address of the service in 
+   a realm which it wants to send a request to, but is otherwise unable 
+   to locate or communicate with a KDC in the service realm or one of 
+   the intermediate realms. (One example would be a dial up user who 
+   does not have direct IP connectivity).
+   (3) The client does not know the realm name of the service.
+
+   In this proposal, the client sends KDC request messages directly 
+   to application servers if one of the above failure cases develops. 
+   The application server acts as a proxy, forwarding messages back
+   and forth between the client and various KDC's (see Figure 1).
+
+
+           Client <---------> App Server <----------> KDC
+                               proxies
+
+
+                     Figure 1: IAKERB proxying
+
+
+   In the case where the client has sent a TGS_REQ message to the 
+   application server without a realm name in the request, the 
+   application server will forward an error message to the client 
+   with its realm name in the e-data field of the error message. 
+   The client will attempt to proceed using conventional Kerberos. 
+
+3. When Clients Should Use IAKERB
+
+   We list several, but possibly not all, cases where the client
+   should use IAKERB. In general, the existing Kerberos paradigm
+   where clients contact the KDC to obtain service tickets should
+   be preserved where possible.
+
+   (a) AS_REQ cases:
+
+   (i) The client is unable to locate the user's KDC or the KDC's
+   in the user's realm are not responding, or
+   (ii) The user has not entered a name which can be converted 
+   into a realm name (and the realm name cannot be derived from
+   a certificate). 
+
+   (b) TGS_REQ cases:
+
+   (i) the client determines that the KDC(s) in either an 
+   intermediate realm or the service realm are not responding or
+
+   the client is unable to locate a KDC, 
+
+   (ii) the client is not able to generate the application server 
+   realm name. 
+
+
+4. GSSAPI Encapsulation
+
+   The mechanism ID for IAKERB GSS-API Kerberos, in accordance with the 
+   mechanism proposed by SPNEGO for negotiating protocol variations, is:
+   {iso(1) member-body(2) United States(840) mit(113554) infosys(1) 
+   gssapi(2) krb5(2) initialauth(4)}
+
+   The AS request, AS reply, TGS request, and TGS reply messages are all 
+   encapsulated using the format defined by RFC1964 [2].  This consists 
+   of the GSS-API token framing defined in appendix B of RFC1508 [3]: 
+
+   InitialContextToken ::= 
+   [APPLICATION 0] IMPLICIT SEQUENCE { 
+           thisMech        MechType 
+                   -- MechType is OBJECT IDENTIFIER 
+                   -- representing "Kerberos V5" 
+           innerContextToken ANY DEFINED BY thisMech
+                   -- contents mechanism-specific;
+                   -- ASN.1 usage within innerContextToken
+                   -- is not required
+           }
+
+   The innerContextToken consists of a 2-byte TOK_ID field (defined 
+   below), followed by the Kerberos V5 KRB-AS-REQ, KRB-AS-REP, 
+   KRB-TGS-REQ, or KRB-TGS-REP messages, as appropriate. The TOK_ID field
+   shall be one of the following values, to denote that the message is 
+   either a request to the KDC or a response from the KDC.
+
+   Message         TOK_ID
+   KRB-KDC-REQ      00 03
+   KRB-KDC-REP      01 03
+   
+
+5. The Protocol
+
+   a. The user supplies a password (AS_REQ): Here the Kerberos client
+      will send an AS_REQ message to the application server if it cannot
+      locate a KDC for the user's realm, or such KDC's do not respond,
+      or the user does not enter a name from which the client can derive
+      the user's realm name. The client sets the realm field of the 
+      request equal to its own realm if the realm name is known, 
+      otherwise the realm length is set to 0. Upon receipt of the AS_REQ 
+      message, the application server checks if the client has included 
+      a realm. 
+
+      If the realm was not included in the original request, the 
+      application server must determine the realm and add it to the 
+      AS_REQ message before forwarding it. If the application server 
+      cannot determine the client realm, it returns the 
+      KRB_AP_ERR_REALM_REQUIRED error-code in an error message to 
+      the client:
+
+            KRB_AP_ERR_REALM_REQUIRED         77  
+
+      The error message can be sent in response to either an AS_REQ
+      message, or in response to a TGS_REQ message, in which case the 
+      realm and principal name of the application server are placed
+      into the realm and sname fields respectively, of the KRB-ERROR 
+      message. In the AS_REQ case, once the realm is filled in, the 
+      application server forwards the request to a KDC in the user's 
+      realm. It will retry the request if necessary, and forward the 
+      KDC response back to the client.
+
+      At the time the user enters a username and password, the client
+      should create a new credential with an INTERNAL NAME [3] that can
+      be used as an input into the GSS_Acquire_cred function call.
+
+      This functionality is useful when there is no trust relationship
+      between the user's logon realm and the target realm (Figure 2).
+
+
+                                     User Realm KDC        
+                                      /                
+                                     /                
+                                    /                
+                                   / 2,3   
+                      1,4         /      
+           Client<-------------->App Server
+
+
+      1 Client sends AS_REQ to App Server
+      2 App server forwards AS_REQ to User Realm KDC
+      3 App server receives AS_REP from User Realm KDC
+      4 App server sends AS_REP back to Client
+
+
+                      Figure 2: IAKERB AS_REQ
+
+
+
+   b. The user does not supply a password (TGS_REQ): The user includes a 
+      TGT targetted at the user's realm, or an intermediate realm, in a 
+      TGS_REQ message. The TGS_REQ message is sent to the application 
+      server. 
+
+      If the client has included the realm name in the TGS request, then
+      the application server will forward the request to a KDC in the
+      request TGT srealm. It will forward the response back to the client.
+
+      If the client has not included the realm name in the TGS request,
+      then the application server will return its realm name and principal 
+      name to the client using the KRB_AP_ERR_REALM_REQUIRED error 
+      described above. Sending a TGS_REQ message to the application server 
+      without a realm name in the request, followed by a TGS request using 
+      the returned realm name and then sending an AP request with a mutual 
+      authentication flag should be subject to a local policy decision 
+      (see security considerations below). Using the returned server 
+      principal name in a TGS request followed by sending an AP request 
+      message using the received ticket MUST NOT set any mutual 
+      authentication flags.
+
+
+6. Addresses in Tickets
+
+   In IAKERB, the machine sending requests to the KDC is the server and 
+   not the client. As a result, the client should not include its 
+   addresses in any KDC requests for two reasons. First, the KDC may
+   reject the forwarded request as being from the wrong client. Second,
+   in the case of initial authentication for a dial-up client, the client
+   machine may not yet possess a network address. Hence, as allowed by 
+   RFC1510 [1], the addresses field of the AS and TGS requests should be
+   blank and the caddr field of the ticket should similarly be left blank. 
+
+
+7. Combining IAKERB with Other Kerberos Extensions
+   
+   This protocol is usable with other proposed Kerberos extensions such as 
+   PKINIT (Public Key Cryptography for Initial Authentication in Kerberos 
+   [4]). In such cases, the messages which would normally be sent to the 
+   KDC by the GSS runtime are instead sent by the client application to the 
+   server, which then forwards them to a KDC.
+
+
+8. Security Considerations
+
+   A principal is identified by its principal name and realm. A client
+   that sends a TGS request to an application server without the request
+   realm name will only be able to mutually authenticate the server
+   up to its principal name. Thus when requesting mutual authentication, 
+   it is preferable if clients can either determine the server realm name 
+   beforehand, or apply some policy checks to the realm name obtained from 
+   the returned error message.
+   
+
+9. Bibliography
+ 
+   [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
+   Service (V5). Request for Comments 1510.
+
+   [2]  J. Linn.  The Kerberos Version 5 GSS-API Mechanism. Request 
+   for Comments 1964 
+
+   [3]  J. Linn. Generic Security Service Application Program Interface.  
+   Request for Comments 1508 
+
+   [4] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, 
+   J. Trostle, Public Key Cryptography for Initial Authentication in 
+   Kerberos, http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-
+   pkinit-10.txt.
+
+
+10. This draft expires on January 31st, 2001. 
+
+
+11. Authors' Addresses
+
+   Michael Swift
+   Microsoft
+   One Microsoft Way
+   Redmond, Washington, 98052, U.S.A.
+   Email: mikesw@microsoft.com
+
+   Jonathan Trostle
+   170 W. Tasman Dr. 
+   San Jose, CA 95134, U.S.A.
+   Email: jtrostle@cisco.com
+   Phone: (408) 527-6201
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt
new file mode 100644
index 000000000000..b3ec336b6513
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt
@@ -0,0 +1,174 @@
+INTERNET-DRAFT                                        Jonathan Trostle
+draft-ietf-cat-kerberos-extra-tgt-02.txt              Cisco Systems
+Updates: RFC 1510                                     Michael M. Swift
+expires January 30, 2000                              University of WA
+
+
+    Extension to Kerberos V5 For Additional Initial Encryption
+
+0. Status Of This Memo
+
+   This document is an Internet-Draft and is in full conformance
+   with all 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/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+1. Abstract
+
+   This document defines an extension to the Kerberos protocol
+   specification (RFC 1510) [1] to enable a preauthentication field in
+   the AS_REQ message to carry a ticket granting ticket. The session
+   key from this ticket granting ticket will be used to
+   cryptographically strengthen the initial exchange in either the
+   conventional Kerberos V5 case or in the case the user stores their
+   encrypted private key on the KDC [2].
+
+
+2. Motivation
+
+   In Kerberos V5, the initial exchange with the KDC consists of the
+   AS_REQ and AS_REP messages. For users, the encrypted part of the
+   AS_REP message is encrypted in a key derived from a password.
+   Although a password policy may be in place to prevent dictionary
+   attacks, brute force attacks may still be a concern due to
+   insufficient key length.
+
+   This draft specifies an extension to the Kerberos V5 protocol to
+   allow a ticket granting ticket to be included in an AS_REQ message
+   preauthentication field. The session key from this ticket granting
+   ticket will be used to cryptographically strengthen the initial
+
+   exchange in either the conventional Kerberos V5 case or in the case
+   the user stores their encrypted private key on the KDC [2]. The
+   session key from the ticket granting ticket is combined with the
+   user password key (key K2 in the encrypted private key on KDC
+   option) using HMAC to obtain a new triple des key that is used in
+   place of the user key in the initial exchange. The ticket granting
+   ticket could be obtained by the workstation using its host key.
+
+3. The Extension
+
+   The following new preauthentication type is proposed:
+
+      PA-EXTRA-TGT                         22
+
+   The preauthentication-data field contains a ticket granting ticket
+   encoded as an ASN.1 octet string. The server realm of the ticket
+   granting ticket must be equal to the realm in the KDC-REQ-BODY of
+   the AS_REQ message. In the absence of a trust relationship, the
+   local Kerberos client should send the AS_REQ message without this
+   extension.
+
+   In the conventional (non-pkinit) case, we require the RFC 1510
+   PA-ENC-TIMESTAMP preauthentication field in the AS_REQ message.
+   If neither it or the PA-PK-KEY-REQ preauthentication field is
+   included in the AS_REQ message, the KDC will reply with a
+   KDC_ERR_PREAUTH_FAILED error message.
+
+   We propose the following new etypes:
+
+     des3-cbc-md5-xor                              16
+     des3-cbc-sha1-xor                             17
+
+   The encryption key is obtained by:
+
+   (1) Obtaining an output M from the HMAC-SHA1 function [3] using
+       the user password key (the key K2 in the encrypted private
+       key on KDC option of pkinit) as the text and the triple des
+       session key as the K input in HMAC:
+
+       M = H(K XOR opad, H(K XOR ipad, text)) where H = SHA1.
+
+       The session key from the accompanying ticket granting ticket
+       must be a triple des key when one of the triple des xor
+       encryption types is used.
+   (2) Concatenate the output M (20 bytes) with the first 8 non-parity
+       bits of the triple-des ticket granting ticket session key to
+       get 168 bits that will be used for the new triple-des encryption
+       key.
+   (3) Set the parity bits of the resulting key.
+
+   The resulting triple des key is used to encrypt the timestamp
+   for the PA-ENC-TIMESTAMP preauthentication value (or in the
+   encrypted private key on KDC option of pkinit, it is used in
+   place of the key K2 to both sign in the PA-PK-KEY-REQ and for
+   encryption in the PA-PK-KEY-REP preauthentication types).
+
+   If the KDC decrypts the encrypted timestamp and it is not within
+   the appropriate clock skew period, the KDC will reply with the
+   KDC_ERR_PREAUTH_FAILED error. The same error will also be sent if
+   the above ticket granting ticket fails to decrypt properly, or if
+   it is not a valid ticket.
+
+   The KDC will create the shared triple des key from the ticket
+   granting ticket session key and the user password key (the key K2
+   in the encrypted private key on KDC case) using HMAC as specified
+   above and use it to validate the AS_REQ message and then to
+   encrypt the encrypted part of the AS_REP message (use it in place
+   of the key K2 for encryption in the PA-PK-KEY-REP preauthentication
+   field).
+
+   Local workstation policy will determine the exact behaviour of
+   the Kerberos client with respect to the extension protocol. For
+   example, the client should consult policy to decide when to use
+   use the extension. This policy could be dependent on the user
+   identity, or whether the workstation is in the same realm as the
+   user. One possibility is for the workstation logon to fail if
+   the extension is not used. Another possibility is for the KDC
+   to set a flag in tickets issued when this extension is used.
+
+   A similar idea was proposed in OSF DCE RFC 26.0 [4]; there a
+   preauthentication field containing a ticket granting ticket,
+   a randomly generated subkey encrypted in the session key from
+   the ticket, and a timestamp structure encrypted in the user
+   password and then the randomly generated subkey was proposed.
+   Some advantages of the current proposal are that the KDC has two
+   fewer decryptions to perform per request and the client does not
+   have to generate a random key.
+
+4. Bibliography
+
+   [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
+   Service (V5). Request for Comments 1510.
+
+   [2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle.
+   Public Key Cryptography for Initial Authentication in Kerberos.
+   ftp://ds.internic.net/internet-drafts/
+   draft-ietf-cat-kerberos-pkinit-08.txt
+
+   [3] H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for
+   Message Authentication. Request for Comments 2104.
+
+   [4] J. Pato. Using Pre-authentication to Avoid Password Guessing
+   Attacks. OSF DCE SIG Request for Comments 26.0.
+
+5. Acknowledgement: We thank Ken Hornstein for some helpful comments.
+
+6. Expires January 30, 2000.
+
+7. Authors' Addresses
+
+   Jonathan Trostle
+   170 W. Tasman Dr.
+   San Jose, CA 95134, U.S.A.
+
+   Email: jtrostle@cisco.com
+   Phone: (408) 527-6201
+
+   Michael Swift
+   Email: mikesw@cs.washington.edu
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt
new file mode 100644
index 000000000000..d09a2ded5bc5
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt
@@ -0,0 +1,5 @@
+This Internet-Draft has expired and is no longer available.
+
+Unrevised documents placed in the Internet-Drafts directories have a
+maximum life of six months. After that time, they must be updated, or
+they will be deleted. This document was deleted on March 20, 2000.
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt
new file mode 100644
index 000000000000..1ab2b03e079d
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt
@@ -0,0 +1,523 @@
+
+INTERNET-DRAFT                                               Matthew Hur
+draft-ietf-cat-kerberos-pk-cross-06.txt            CyberSafe Corporation
+Updates: RFC 1510                                             Brian Tung
+expires October 10, 2000                                  Tatyana Ryutov
+                                                         Clifford Neuman
+                                                             Gene Tsudik
+                                                                     ISI
+                                                           Ari Medvinsky
+                                                                Keen.com
+                                                         Bill Sommerfeld
+                                                         Hewlett-Packard
+
+
+    Public Key Cryptography for Cross-Realm Authentication in Kerberos
+
+
+0.  Status Of this Memo
+
+    This document is an Internet-Draft and is in full conformance with
+    all provisions of Section 10 of RFC 2026.  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.
+
+
+
+    To learn the current status of any Internet-Draft, please check
+    the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
+    Shadow Directories on ftp.ietf.org (US East Coast),
+    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
+    munnari.oz.au (Pacific Rim).
+
+    The distribution of this memo is unlimited.  It is filed as
+    draft-ietf-cat-kerberos-pk-cross-06.txt, and expires May 15, 1999.
+    Please send comments to the authors.
+
+
+1.  Abstract
+
+    This document defines extensions to the Kerberos protocol 
+    specification [1] to provide a method for using public key 
+    cryptography to enable cross-realm authentication.  The methods 
+    defined here specify the way in which message exchanges are to be 
+    used to transport cross-realm secret keys protected by encryption 
+    under public keys certified as belonging to KDCs.
+
+
+2.  Introduction
+
+    The Kerberos authentication protocol [2]  can leverage the 
+    advantages provided by public key cryptography.  PKINIT [3] 
+    describes the use of public key cryptography in the initial 
+    authentication exchange in Kerberos.  PKTAPP [4] describes how an 
+    application service can essentially issue a kerberos ticket to 
+    itself after utilizing public key cryptography for authentication. 
+    Another informational document species the use of public key 
+    crypography for anonymous authentication in Kerberos [5].  This 
+    specification describes the use of public key crpytography in cross- 
+    realm authentication.
+
+    Without the use of public key cryptography, administrators must 
+    maintain separate keys for every realm which wishes to exchange 
+    authentication information with another realm (which implies n(n-1) 
+    keys), or they must utilize a hierachichal arrangement of realms, 
+    which may complicate the trust model by requiring evaluation of 
+    transited realms.
+
+    Even with the multi-hop cross-realm authentication, there must be 
+    some way to locate the path by which separate realms are to be 
+    transited.  The current method, which makes use of the DNS-like 
+    realm names typical to Kerberos, requires trust of the intermediate 
+    KDCs.
+
+    PKCROSS utilizes a public key infrastructure (PKI) [6] to simplify 
+    the administrative burden of maintaining cross-realm keys.  Such 
+    usage leverages a PKI for a non-centrally-administratable environment 
+    (namely, inter-realm).  Thus, a shared key for cross-realm 
+    authentication can be established for a set period of time, and a 
+    remote realm is able to issue policy information that is returned to 
+    itself when a client requests cross-realm authentication. Such policy 
+    information may be in the form of restrictions [7].  Furthermore, 
+    these methods are transparent to the client; therefore, only the KDCs 
+    need to be modified to use them.  In this way, we take advantage of 
+    the the distributed trust management capabilities of public key 
+    crypography while maintaining the advantages of localized trust 
+    management provided by Kerberos.
+
+
+    Although this specification utilizes the protocol specfied in the 
+    PKINIT specification, it is not necessary to implement client 
+    changes in order to make use of the changes in this document.
+
+
+3.  Objectives
+
+    The objectives of this specification are as follows:
+    
+      1.  Simplify the administration required to establish Kerberos
+          cross-realm keys.
+          
+      2.  Avoid modification of clients and application servers.
+
+      3.  Allow remote KDC to control its policy on cross-realm
+          keys shared between KDCs, and on cross-realm tickets
+          presented by clients.
+
+      4.  Remove any need for KDCs to maintain state about keys
+          shared with other KDCs.
+
+      5.  Leverage the work done for PKINIT to provide the public key
+          protocol for establishing symmetric cross realm keys.
+
+
+4.  Definitions
+
+    The following notation is used throughout this specification:
+    KDC_l ........... local KDC
+    KDC_r ........... remote KDC
+    XTKT_(l,r) ...... PKCROSS ticket that the remote KDC issues to the
+                      local KDC
+    TGT_(c,r) ....... cross-realm TGT that the local KDC issues to the
+                      client for presentation to the remote KDC
+
+    This specification defines the following new types to be added to the 
+    Kerberos specification:
+      PKCROSS kdc-options field in the AS_REQ is bit 9
+      TE-TYPE-PKCROSS-KDC       2
+      TE-TYPE-PKCROSS-CLIENT    3
+
+    This specification defines the following ASN.1 type for conveying
+    policy information:
+    CrossRealmTktData ::= SEQUENCE OF TypedData
+
+    This specification defines the following types for policy information 
+    conveyed in CrossRealmTktData:
+      PLC_LIFETIME              1
+      PLC_SET_TKT_FLAGS         2
+      PLC_NOSET_TKT_FLAGS       3
+
+    TicketExtensions are defined per the Kerberos specification [8]:
+    TicketExtensions ::= SEQUENCE OF TypedData
+      Where
+        TypedData ::=   SEQUENCE {
+            data-type[0]   INTEGER,
+            data-value[1]  OCTET STRING OPTIONAL
+        }
+
+
+5.  Protocol Specification
+
+    We assume that the client has already obtained a TGT.  To perform
+    cross-realm authentication, the client does exactly what it does
+    with ordinary (i.e. non-public-key-enabled) Kerberos; the only
+    changes are in the KDC; although the ticket which the client
+    forwards to the remote realm may be changed.  This is acceptable
+    since the client treats the ticket as opaque.
+
+
+5.1.  Overview of Protocol
+
+    The basic operation of the PKCROSS protocol is as follows:
+
+        1.  The client submits a request to the local KDC for
+            credentials for the remote realm.  This is just a typical
+            cross realm request that may occur with or without PKCROSS. 
+
+        2.  The local KDC submits a PKINIT request to the remote KDC to
+            obtain a "special" PKCROSS ticket.  This is a standard
+            PKINIT request, except that PKCROSS flag (bit 9) is set in
+            the kdc-options field in the AS_REQ.
+
+        3.  The remote KDC responds as per PKINIT, except that
+            the ticket contains a TicketExtension, which contains
+            policy information such as lifetime of cross realm tickets
+            issued by KDC_l to a client.  The local KDC must reflect
+            this policy information in the credentials it forwards to
+            the client.  Call this ticket XTKT_(l,r) to indicate that
+            this ticket is used to authenticate the local KDC to the
+            remote KDC.
+
+        4.  The local KDC passes a ticket, TGT_(c,r) (the cross realm
+            TGT between the client and remote KDC), to the client.
+            This ticket contains in its TicketExtension field the
+            ticket, XTKT_(l,r), which contains the cross-realm key.
+            The TGT_(c,r) ticket is encrypted using the key sealed in
+            XTKT_(l,r).  (The TicketExtension field is not encrypted.)
+            The local KDC may optionally include another TicketExtension
+            type that indicates the hostname and/or IP address for the
+            remote KDC.
+
+        5.  The client submits the request directly to the remote
+            KDC, as before.
+            
+        6.  The remote KDC extracts XTKT_(l,r) from the TicketExtension
+            in order to decrypt the encrypted part of TGT_(c,r).
+
+    --------------------------------------------------------------------
+    
+    Client                Local KDC (KDC_l)           Remote KDC (KDC_r)
+    ------                -----------------           ------------------
+    Normal Kerberos
+    request for
+    cross-realm
+    ticket for KDC_r
+    ---------------------->
+    
+                          PKINIT request for
+                          XTKT(l,r) - PKCROSS flag
+                          set in the AS-REQ
+                          * ------------------------->
+                          
+                                                      PKINIT reply with
+                                                      XTKT_(l,r) and
+                                                      policy info in
+                                                      ticket extension
+                                           <-------------------------- *
+
+                          Normal Kerberos reply
+                          with TGT_(c,r) and
+                          XTKT(l,r) in ticket
+                          extension
+         <--------------------------------- 
+
+    Normal Kerberos
+    cross-realm TGS-REQ
+    for remote
+    application
+    service with
+    TGT_(c,r) and
+    XTKT(l,r) in ticket
+    extension
+    ------------------------------------------------->
+
+                                                      Normal Kerberos
+                                                      cross-realm
+                                                      TGS-REP
+        <---------------------------------------------------------------
+
+    * Note that the KDC to KDC messages occur only periodically, since
+      the local KDC caches the XTKT_(l,r).
+    --------------------------------------------------------------------
+    
+
+    Sections 5.2 through 5.4 describe in detail steps 2 through 4
+    above.  Section 5.6 describes the conditions under which steps
+    2 and 3 may be skipped.
+
+    Note that the mechanism presented above requires infrequent KDC to 
+    KDC communication (as dictated by policy - this is discussed
+    later).  Without such an exchange, there are the following issues:
+    1) KDC_l would have to issue a ticket with the expectation that
+       KDC_r will accept it.
+    2) In the message that the client sends to KDC_r, KDC_l would have
+       to authenticate KDC_r with credentials that KDC_r trusts.
+    3) There is no way for KDC_r to convey policy information to KDC_l.
+    4) If, based on local policy, KDC_r does not accept a ticket from
+       KDC_l, then the client gets stuck in the middle.  To address such
+       an issue would require modifications to standard client
+       processing behavior.
+    Therefore, the infreqeunt use of KDC to KDC communication assures
+    that inter-realm KDC keys may be established in accordance with local
+    policies and that clients may continue to operate without
+    modification.
+
+
+5.2.  Local KDC's Request to Remote KDC
+
+    When the local KDC receives a request for cross-realm authentication, 
+    it first checks its ticket cache to see if it has a valid PKCROSS 
+    ticket, XTKT_(l,r).  If it has a valid XTKT_(l,r), then it does not 
+    need to send a request to the remote KDC (see section 5.5).
+
+    If the local KDC does not have a valid XTKT_(l,r), it sends a     
+    request to the remote KDC in order to establish a cross realm key and 
+    obtain the XTKT_(l,r).  This request is in fact a PKINIT request as 
+    described in the PKINIT specification; i.e., it consists of an AS-REQ 
+    with a PA-PK-AS-REQ included as a preauthentication field.  Note, 
+    that the AS-REQ MUST have the PKCROSS flag (bit 9) set in the 
+    kdc_options field of the AS-REQ.  Otherwise, this exchange exactly 
+    follows the description given in the PKINIT specification.  In 
+    addition, the naming
+
+
+5.3.  Remote KDC's Response to Local KDC
+
+    When the remote KDC receives the PKINIT/PKCROSS request from the
+    local KDC, it sends back a PKINIT response as described in
+    the PKINIT specification with the following exception: the encrypted
+    part of the Kerberos ticket is not encrypted with the krbtgt key;
+    instead, it is encrypted with the ticket granting server's PKCROSS
+    key.  This key, rather than the krbtgt key, is used because it
+    encrypts a ticket used for verifying a cross realm request rather
+    than for issuing an application service ticket.  Note that, as a
+    matter of policy, the session key for the XTKT_(l,r) MAY be of
+    greater strength than that of a session key for a normal PKINIT
+    reply, since the XTKT_(l,r) SHOULD be much longer lived than a
+    normal application service ticket.
+
+    In addition, the remote KDC SHOULD include policy information in the 
+    XTKT_(l,r).  This policy information would then be reflected in the 
+    cross-realm TGT, TGT_(c,r).  Otherwise, the policy for TGT_(c,r) 
+    would be dictated by KDC_l rather than by KDC_r.  The local KDC MAY 
+    enforce a more restrictive local policy when creating a cross-realm 
+    ticket, TGT_(c,r).  For example, KDC_r  may dictate a lifetime 
+    policy of eight hours, but KDC_l may create TKT_(c,r) with a 
+    lifetime of four hours, as dictated by local policy.  Also, the 
+    remote KDC MAY include other information about itself along with the 
+    PKCROSS ticket.  These items are further discussed in section 6 
+    below.
+
+
+5.4.  Local KDC's Response to Client
+
+    Upon receipt of the PKINIT/CROSS response from the remote KDC,
+    the local KDC formulates a response to the client.  This reply
+    is constructed exactly as in the Kerberos specification, except
+    for the following:
+
+    A) The local KDC places XTKT_(l,r) in the TicketExtension field of
+       the client's cross-realm, ticket, TGT_(c,r), for the remote realm.
+       Where
+          data-type   equals 3 for TE-TYPE-PKCROSS-CLIENT
+          data-value  is ASN.1 encoding of XTKT_(l,r)
+     
+    B) The local KDC adds the name of its CA to the transited field of
+       TGT_(c,r).
+
+
+5.5   Remote KDC's Processing of Client Request
+
+    When the remote KDC, KDC_r, receives a cross-realm ticket, 
+    TGT_(c,r), and it detects that the ticket contains a ticket 
+    extension of type TE-TYPE-PKCROSS-CLIENT, KDC_r must first decrypt 
+    the ticket, XTKT_(l,r), that is encoded in the ticket extension.  
+    KDC_r uses its PKCROSS key in order to decrypt XTKT_(l,r).  KDC_r 
+    then uses the key obtained from XTKT_(l,r) in order to decrypt the 
+    cross-realm ticket, TGT_(c,r).
+
+    KDC_r MUST verify that the cross-realm ticket, TGT_(c,r) is in 
+    compliance with any policy information contained in XTKT_(l,r) (see 
+    section 6).  If the TGT_(c,r) is not in compliance with policy, then 
+    the KDC_r responds to the client with a KRB-ERROR message of type 
+    KDC_ERR_POLICY.
+
+    
+5.6.  Short-Circuiting the KDC-to-KDC Exchange
+
+    As we described earlier, the KDC to KDC exchange is required only 
+    for establishing a symmetric, inter-realm key.  Once this key is 
+    established (via the PKINIT exchange), no KDC to KDC communication 
+    is required until that key needs to be renewed.  This section 
+    describes the circumstances under which the KDC to KDC exchange 
+    described in Sections 5.2 and 5.3 may be skipped.
+
+    The local KDC has a known lifetime for TGT_(c,r).  This lifetime may 
+    be determined by policy information included in XTKT_(l,r), and/or 
+    it may be determined by local KDC policy.  If the local KDC already 
+    has a ticket XTKT(l,r), and the start time plus the lifetime for 
+    TGT_(c,r) does not exceed the expiration time for XTGT_(l,r), then 
+    the local KDC may skip the exchange with the remote KDC, and issue a 
+    cross-realm ticket to the client as described in Section 5.4.
+
+    Since the remote KDC may change its PKCROSS key (referred to in 
+    Section 5.2) while there are PKCROSS tickets still active, it SHOULD 
+    cache the old PKCROSS keys until the last issued PKCROSS ticket 
+    expires.  Otherwise, the remote KDC will respond to a client with a 
+    KRB-ERROR message of type KDC_ERR_TGT_REVOKED.
+
+
+6.  Extensions for the PKCROSS Ticket
+
+    As stated in section 5.3, the remote KDC SHOULD include policy 
+    information in XTKT_(l,r).  This policy information is contained in 
+    a TicketExtension, as defined by the Kerberos specification, and the 
+    authorization data of the ticket will contain an authorization 
+    record of type AD-IN-Ticket-Extensions.  The TicketExtension defined 
+    for use by PKCROSS is TE-TYPE-PKCROSS-KDC.
+      Where
+        data-type   equals 2 for TE-TYPE-PKCROSS-KDC
+        data-value  is ASN.1 encoding of CrossRealmTktData
+
+      CrossRealmTktData ::= SEQUENCE OF TypedData
+
+
+      ------------------------------------------------------------------
+      CrossRealmTktData types and the corresponding data are interpreted 
+      as follows:
+
+                                                            ASN.1 data
+      type                value   interpretation            encoding
+      ----------------    -----   --------------            ----------
+      PLC_LIFETIME          1     lifetime (in seconds)     INTEGER
+                                  for TGT_(c,r) 
+                                  - cross-realm tickets
+                                    issued for clients by
+                                    TGT_l
+
+      PLC_SET_TKT_FLAGS     2     TicketFlags that must     BITSTRING
+                                  be set
+                                  - format defined by
+                                    Kerberos specification
+
+      PLC_NOSET_TKT_FLAGS   3     TicketFlags that must     BITSTRING
+                                  not be set
+                                  - format defined by
+                                    Kerberos specification
+
+      Further types may be added to this table.
+      ------------------------------------------------------------------
+
+
+7.  Usage of Certificates
+
+    In the cases of PKINIT and PKCROSS, the trust in a certification 
+    authority is equivalent to Kerberos cross realm trust.  For this 
+    reason, an implementation MAY choose to use the same KDC certificate 
+    when the KDC is acting in any of the following three roles:
+      1) KDC is authenticating clients via PKINIT
+      2) KDC is authenticating another KDC for PKCROSS 
+      3) KDC is the client in a PKCROSS exchange with another KDC
+
+    Note that per PKINIT, the KDC X.509 certificate (the server in a 
+    PKINIT exchange) MUST contain the principal name of the KDC in the 
+    subjectAltName field.
+
+
+8.  Transport Issues
+
+    Because the messages between the KDCs involve PKINIT exchanges, and 
+    PKINIT recommends TCP as a transport mechanism (due to the length of 
+    the messages and the likelihood that they will fragment), the same 
+    recommendation for TCP applies to PKCROSS as well.
+
+    
+9. Security Considerations
+
+   Since PKCROSS utilizes PKINIT, it is subject to the same security
+   considerations as PKINIT.  Administrators should assure adherence 
+   to security policy - for example, this affects the PKCROSS policies
+   for cross realm key lifetime and for policy propogation from the 
+   PKCROSS ticket, issued from a remote KDC to a local KDC, to
+   cross realm tickets that are issued by a local KDC to a client.
+
+
+10. Bibliography
+
+  [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service 
+  (V5).  Request for Comments 1510.
+
+  [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
+  for Computer Networks, IEEE Communications, 32(9):33-38.  September
+  1994.
+
+  [3] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S.Medvinsky, J. Wray
+  J. Trostle.  Public Key Cryptography for Initial Authentication
+  in Kerberos.
+  draft-ietf-cat-kerberos-pk-init-11.txt
+
+  [4] A. Medvinsky, M. Hur, S. Medvinsky, B. Clifford Neuman.  Public 
+  Key Utilizing Tickets for Application Servers (PKTAPP). draft-ietf-
+  cat-pktapp-02.txt
+
+  [5] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
+  Kerberos. draft-ietf-cat-kerberos-anoncred-01.txt
+
+  [6] ITU-T (formerly CCITT) Information technology - Open Systems
+  Interconnection - The Directory: Authentication Framework
+  Recommendation X.509 ISO/IEC 9594-8
+    
+  [7] B.C. Neuman, Proxy-Based Authorization and Accounting for 
+  Distributed Systems.  In Proceedings of the 13th International 
+  Conference on Distributed Computing Systems, May 1993.
+
+  [8] C.Neuman, J. Kohl, T. Ts'o.  The Kerberos Network Authentication 
+  Service (V5). draft-ietf-cat-kerberos-revisions-05.txt
+
+
+11. Authors' Addresses
+
+    Matthew Hur
+    CyberSafe Corporation
+    1605 NW Sammamish Road
+    Issaquah WA 98027-5378
+    Phone: +1 425 391 6000
+    E-mail: matt.hur@cybersafe.com
+
+    Brian Tung
+    Tatyana Ryutov
+    Clifford Neuman
+    Gene Tsudik
+    USC/Information Sciences Institute
+    4676 Admiralty Way Suite 1001
+    Marina del Rey, CA 90292-6695
+    Phone: +1 310 822 1511
+    E-Mail: {brian, tryutov, bcn, gts}@isi.edu
+
+    Ari Medvinsky
+    Keen.com
+    2480 Sand Hill Road, Suite 200
+    Menlo Park, CA 94025
+    Phone +1 650 289 3134
+    E-mail: ari@keen.com
+
+    Bill Sommerfeld
+    Hewlett Packard
+    300 Apollo Drive
+    Chelmsford MA 01824
+    Phone: +1 508 436 4352
+    E-Mail: sommerfeld@apollo.hp.com
+
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt
new file mode 100644
index 000000000000..9b0e76adad98
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt
@@ -0,0 +1,1059 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-11.txt                   Clifford Neuman
+Updates: RFC 1510                                                USC/ISI
+expires September 15, 2000                                   Matthew Hur
+                                                   CyberSafe Corporation
+                                                           Ari Medvinsky
+                                                          Keen.com, Inc.
+                                                         Sasha Medvinsky
+                                                                Motorola
+                                                               John Wray
+                                                   Iris Associates, Inc.
+                                                        Jonathan Trostle
+                                                                   Cisco
+
+    Public Key Cryptography for Initial Authentication in Kerberos
+
+0.  Status Of This Memo
+
+    This document is an Internet-Draft and is in full conformance with
+    all provisions of Section 10 of RFC 2026.  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.
+
+    To learn the current status of any Internet-Draft, please check
+    the "1id-abstracts.txt" listing contained in the Internet-Drafts
+    Shadow Directories on ftp.ietf.org (US East Coast),
+    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
+    munnari.oz.au (Pacific Rim).
+
+    The distribution of this memo is unlimited.  It is filed as
+    draft-ietf-cat-kerberos-pk-init-11.txt, and expires September 15,
+    2000.  Please send comments to the authors.
+
+1.  Abstract
+
+    This document defines extensions (PKINIT) to the Kerberos protocol
+    specification (RFC 1510 [1]) to provide a method for using public
+    key cryptography during initial authentication.  The methods
+    defined specify the ways in which preauthentication data fields and
+    error data fields in Kerberos messages are to be used to transport
+    public key data.
+
+2.  Introduction
+
+    The popularity of public key cryptography has produced a desire for
+    its support in Kerberos [2].  The advantages provided by public key
+    cryptography include simplified key management (from the Kerberos
+    perspective) and the ability to leverage existing and developing
+    public key certification infrastructures.
+
+    Public key cryptography can be integrated into Kerberos in a number
+    of ways.  One is to associate a key pair with each realm, which can
+    then be used to facilitate cross-realm authentication; this is the
+    topic of another draft proposal.  Another way is to allow users with
+    public key certificates to use them in initial authentication.  This
+    is the concern of the current document.
+
+    PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
+    combination with digital signature keys as the primary, required
+    mechanism.  It also allows for the use of RSA keys and/or (static)
+    Diffie-Hellman certificates.  Note in particular that PKINIT supports
+    the use of separate signature and encryption keys.
+
+    PKINIT enables access to Kerberos-secured services based on initial
+    authentication utilizing public key cryptography.  PKINIT utilizes
+    standard public key signature and encryption data formats within the
+    standard Kerberos messages.  The basic mechanism is as follows:  The
+    user sends an AS-REQ message to the KDC as before, except that if that
+    user is to use public key cryptography in the initial authentication
+    step, his certificate and a signature accompany the initial request
+    in the preauthentication fields.  Upon receipt of this request, the
+    KDC verifies the certificate and issues a ticket granting ticket
+    (TGT) as before, except that the encPart from the AS-REP message
+    carrying the TGT is now encrypted utilizing either a Diffie-Hellman
+    derived key or the user's public key.  This message is authenticated
+    utilizing the public key signature of the KDC.
+
+    Note that PKINIT does not require the use of certificates.  A KDC
+    may store the public key of a principal as part of that principal's
+    record.  In this scenario, the KDC is the trusted party that vouches
+    for the principal (as in a standard, non-cross realm, Kerberos
+    environment).  Thus, for any principal, the KDC may maintain a
+    secret key, a public key, or both.
+
+    The PKINIT specification may also be used as a building block for
+    other specifications.  PKCROSS [3] utilizes PKINIT for establishing
+    the inter-realm key and associated inter-realm policy to be applied
+    in issuing cross realm service tickets.  As specified in [4],
+    anonymous Kerberos tickets can be issued by applying a NULL
+    signature in combination with Diffie-Hellman in the PKINIT exchange.
+    Additionally, the PKINIT specification may be used for direct peer
+    to peer authentication without contacting a central KDC. This
+    application of PKINIT is described in PKTAPP [5] and is based on
+    concepts introduced in [6, 7]. For direct client-to-server
+    authentication, the client uses PKINIT to authenticate to the end
+    server (instead of a central KDC), which then issues a ticket for
+    itself.  This approach has an advantage over TLS [8] in that the
+    server does not need to save state (cache session keys).
+    Furthermore, an additional benefit is that Kerberos tickets can
+    facilitate delegation (see [9]).
+
+3.  Proposed Extensions
+
+    This section describes extensions to RFC 1510 for supporting the
+    use of public key cryptography in the initial request for a ticket
+    granting ticket (TGT).
+
+    In summary, the following change to RFC 1510 is proposed:
+
+        * Users may authenticate using either a public key pair or a
+          conventional (symmetric) key.  If public key cryptography is
+          used, public key data is transported in preauthentication
+          data fields to help establish identity.  The user presents
+          a public key certificate and obtains an ordinary TGT that may
+          be used for subsequent authentication, with such
+          authentication using only conventional cryptography.
+
+    Section 3.1 provides definitions to help specify message formats.
+    Section 3.2 describes the extensions for the initial authentication
+    method.
+
+3.1.  Definitions
+
+    The extensions involve new preauthentication fields; we introduce
+    the following preauthentication types:
+
+        PA-PK-AS-REQ                            14
+        PA-PK-AS-REP                            15
+
+    The extensions also involve new error types; we introduce the
+    following types:
+
+        KDC_ERR_CLIENT_NOT_TRUSTED              62
+        KDC_ERR_KDC_NOT_TRUSTED                 63
+        KDC_ERR_INVALID_SIG                     64
+        KDC_ERR_KEY_TOO_WEAK                    65
+        KDC_ERR_CERTIFICATE_MISMATCH            66
+        KDC_ERR_CANT_VERIFY_CERTIFICATE         70
+        KDC_ERR_INVALID_CERTIFICATE             71
+        KDC_ERR_REVOKED_CERTIFICATE             72
+        KDC_ERR_REVOCATION_STATUS_UNKNOWN       73
+        KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74
+        KDC_ERR_CLIENT_NAME_MISMATCH            75
+        KDC_ERR_KDC_NAME_MISMATCH               76
+
+    We utilize the following typed data for errors:
+
+        TD-PKINIT-CMS-CERTIFICATES             101
+        TD-KRB-PRINCIPAL                       102
+        TD-KRB-REALM                           103
+        TD-TRUSTED-CERTIFIERS                  104
+        TD-CERTIFICATE-INDEX                   105
+
+    We utilize the following encryption types (which map directly to
+    OIDs):
+
+        dsaWithSHA1-CmsOID                       9
+        md5WithRSAEncryption-CmsOID             10
+        sha1WithRSAEncryption-CmsOID            11
+        rc2CBC-EnvOID                           12
+        rsaEncryption-EnvOID (PKCS#1 v1.5)      13
+        rsaES-OAEP-ENV-OID   (PKCS#1 v2.0)      14
+        des-ede3-cbc-Env-OID                    15
+
+    These mappings are provided so that a client may send the
+    appropriate enctypes in the AS-REQ message in order to indicate
+    support for the corresponding OIDs (for performing PKINIT).
+
+    In many cases, PKINIT requires the encoding of the X.500 name of a
+    certificate authority as a Realm.  When such a name appears as
+    a realm it will be represented using the "other" form of the realm
+    name as specified in the naming constraints section of RFC1510.
+    For a realm derived from an X.500 name, NAMETYPE will have the value
+    X500-RFC2253.  The full realm name will appear as follows:
+
+        <nametype> + ":" + <string>
+
+    where nametype is "X500-RFC2253" and string is the result of doing
+    an RFC2253 encoding of the distinguished name, i.e.
+
+        "X500-RFC2253:" + RFC2253Encode(DistinguishedName)
+
+    where DistinguishedName is an X.500 name, and RFC2253Encode is a
+    function returing a readable UTF encoding of an X.500 name, as
+    defined by RFC 2253 [14] (part of LDAPv3 [18]).
+
+    To ensure that this encoding is unique, we add the following rule
+    to those specified by RFC 2253:
+
+        The order in which the attributes appear in the RFC 2253
+        encoding must be the reverse of the order in the ASN.1
+        encoding of the X.500 name that appears in the public key
+        certificate. The order of the relative distinguished names
+        (RDNs), as well as the order of the AttributeTypeAndValues
+        within each RDN, will be reversed. (This is despite the fact
+        that an RDN is defined as a SET of AttributeTypeAndValues, where
+        an order is normally not important.)
+
+    Similarly, in cases where the KDC does not provide a specific
+    policy based mapping from the X.500 name or X.509 Version 3
+    SubjectAltName extension in the user's certificate to a Kerberos
+    principal name, PKINIT requires the direct encoding of the X.500
+    name as a PrincipalName.  In this case, the name-type of the
+    principal name shall be set to KRB_NT-X500-PRINCIPAL.  This new
+    name type is defined in RFC 1510 as:
+
+        KRB_NT_X500_PRINCIPAL    6
+
+    The name-string shall be set as follows:
+
+        RFC2253Encode(DistinguishedName)
+
+    as described above.  When this name type is used, the principal's
+    realm shall be set to the certificate authority's distinguished
+    name using the X500-RFC2253 realm name format described earlier in
+    this section
+
+    RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
+
+        PrincipalName ::=   SEQUENCE {
+                        name-type[0]     INTEGER,
+                        name-string[1]   SEQUENCE OF GeneralString
+        }
+
+    For the purposes of encoding an X.500 name as a Kerberos name for
+    use in Kerberos structures, the name-string shall be encoded as a
+    single GeneralString.  The name-type should be KRB_NT_X500_PRINCIPAL,
+    as noted above.  All Kerberos names must conform to validity
+    requirements as given in RFC 1510.  Note that name mapping may be
+    required or optional, based on policy.
+
+    We also define the following similar ASN.1 structure:
+
+        CertPrincipalName ::= SEQUENCE {
+                        name-type[0]     INTEGER,
+                        name-string[1]   SEQUENCE OF UTF8String
+        }
+
+    When a Kerberos PrincipalName is to be placed within an X.509 data
+    structure, the CertPrincipalName structure is to be used, with the
+    name-string encoded as a single UTF8String.  The name-type should be
+    as identified in the original PrincipalName structure.  The mapping
+    between the GeneralString and UTF8String formats can be found in
+    [19].
+
+    The following rules relate to the the matching of PrincipalNames (or
+    corresponding CertPrincipalNames) with regard to the PKI name
+    constraints for CAs as laid out in RFC 2459 [15].  In order to be
+    regarded as a match (for permitted and excluded name trees), the
+    following must be satisfied.
+
+        1.  If the constraint is given as a user plus realm name, or
+            as a user plus instance plus realm name (as specified in
+            RFC 1510), the realm name must be valid (see 2.a-d below)
+            and the match must be exact, byte for byte.
+
+        2.  If the constraint is given only as a realm name, matching
+            depends on the type of the realm:
+
+            a.  If the realm contains a colon (':') before any equal
+                sign ('='), it is treated as a realm of type Other,
+                and must match exactly, byte for byte.
+
+            b.  Otherwise, if the realm contains an equal sign, it
+                is treated as an X.500 name.  In order to match, every
+                component in the constraint MUST be in the principal
+                name, and have the same value.  For example, 'C=US'
+                matches 'C=US/O=ISI' but not 'C=UK'.
+
+            c.  Otherwise, if the realm name conforms to rules regarding
+                the format of DNS names, it is considered a realm name of
+                type Domain.  The constraint may be given as a realm
+                name 'FOO.BAR', which matches any PrincipalName within
+                the realm 'FOO.BAR' but not those in subrealms such as
+                'CAR.FOO.BAR'.  A constraint of the form '.FOO.BAR'
+                matches PrincipalNames in subrealms of the form
+                'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.
+
+            d.  Otherwise, the realm name is invalid and does not match
+                under any conditions.
+
+3.1.1.  Encryption and Key Formats
+
+    In the exposition below, we use the terms public key and private
+    key generically.  It should be understood that the term "public
+    key" may be used to refer to either a public encryption key or a
+    signature verification key, and that the term "private key" may be
+    used to refer to either a private decryption key or a signature
+    generation key.  The fact that these are logically distinct does
+    not preclude the assignment of bitwise identical keys for RSA
+    keys.
+
+    In the case of Diffie-Hellman, the key shall be produced from the
+    agreed bit string as follows:
+
+        * Truncate the bit string to the appropriate length.
+        * Rectify parity in each byte (if necessary) to obtain the key.
+
+    For instance, in the case of a DES key, we take the first eight
+    bytes of the bit stream, and then adjust the least significant bit
+    of each byte to ensure that each byte has odd parity.
+
+3.1.2. Algorithm Identifiers
+
+    PKINIT does not define, but does permit, the algorithm identifiers
+    listed below.
+
+3.1.2.1. Signature Algorithm Identifiers
+
+    The following signature algorithm identifiers specified in [11] and
+    in [15] shall be used with PKINIT:
+
+    id-dsa-with-sha1       (DSA with SHA1)
+    md5WithRSAEncryption   (RSA with MD5)
+    sha-1WithRSAEncryption (RSA with SHA1)
+
+3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
+
+    The following algorithm identifier shall be used within the
+    SubjectPublicKeyInfo data structure: dhpublicnumber
+
+    This identifier and the associated algorithm parameters are
+    specified in RFC 2459 [15].
+
+3.1.2.3. Algorithm Identifiers for RSA Encryption
+
+    These algorithm identifiers are used inside the EnvelopedData data
+    structure, for encrypting the temporary key with a public key:
+
+        rsaEncryption (RSA encryption, PKCS#1 v1.5)
+        id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
+
+    Both of the above RSA encryption schemes are specified in [16].
+    Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
+    CMS specification says that it will likely include PKCS#1 v2.0 in
+    the future.  (PKCS#1 v2.0 addresses adaptive chosen ciphertext
+    vulnerability discovered in PKCS#1 v1.5.)
+
+3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
+
+    These algorithm identifiers are used inside the EnvelopedData data
+    structure in the PKINIT Reply, for encrypting the reply key with the
+    temporary key:
+        des-ede3-cbc (3-key 3-DES, CBC mode)
+        rc2-cbc      (RC2, CBC mode)
+
+    The full definition of the above algorithm identifiers and their
+    corresponding parameters (an IV for block chaining) is provided in
+    the CMS specification [11].
+
+3.2.  Public Key Authentication
+
+    Implementation of the changes in this section is REQUIRED for
+    compliance with PKINIT.
+
+3.2.1.  Client Request
+
+    Public keys may be signed by some certification authority (CA), or
+    they may be maintained by the KDC in which case the KDC is the
+    trusted authority.  Note that the latter mode does not require the
+    use of certificates.
+
+    The initial authentication request is sent as per RFC 1510, except
+    that a preauthentication field containing data signed by the user's
+    private key accompanies the request:
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+                                -- PA TYPE 14
+        signedAuthPack          [0] SignedData
+                                    -- Defined in CMS [11];
+                                    -- AuthPack (below) defines the
+                                    -- data that is signed.
+        trustedCertifiers       [1] SEQUENCE OF TrustedCas OPTIONAL,
+                                    -- This is a list of CAs that the
+                                    -- client trusts and that certify
+                                    -- KDCs.
+        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
+                                    -- As defined in CMS [11];
+                                    -- specifies a particular KDC
+                                    -- certificate if the client
+                                    -- already has it.
+        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL
+                                    -- For example, this may be the
+                                    -- client's Diffie-Hellman
+                                    -- certificate, or it may be the
+                                    -- client's RSA encryption
+                                    -- certificate.
+    }
+
+    TrustedCas ::= CHOICE {
+        principalName         [0] KerberosName,
+                                  -- as defined below
+        caName                [1] Name
+                                  -- fully qualified X.500 name
+                                  -- as defined by X.509
+        issuerAndSerial       [2] IssuerAndSerialNumber
+                                  -- Since a CA may have a number of
+                                  -- certificates, only one of which
+                                  -- a client trusts
+    }
+
+    Usage of SignedData:
+
+        The SignedData data type is specified in the Cryptographic
+        Message Syntax, a product of the S/MIME working group of the
+        IETF.  The following describes how to fill in the fields of
+        this data:
+
+        1.  The encapContentInfo field must contain the PKAuthenticator
+            and, optionally, the client's Diffie Hellman public value.
+
+            a.  The eContentType field shall contain the OID value for
+                pkdata: iso (1) org (3) dod (6) internet (1) security (5)
+                kerberosv5 (2) pkinit (3) pkdata (1)
+
+            b.  The eContent field is data of the type AuthPack (below).
+
+        2.  The signerInfos field contains the signature of AuthPack.
+
+        3.  The Certificates field, when non-empty, contains the client's
+            certificate chain.  If present, the KDC uses the public key
+            from the client's certificate to verify the signature in the
+            request.  Note that the client may pass different certificate
+            chains that are used for signing or for encrypting.  Thus,
+            the KDC may utilize a different client certificate for
+            signature verification than the one it uses to encrypt the
+            reply to the client.  For example, the client may place a
+            Diffie-Hellman certificate in this field in order to convey
+            its static Diffie Hellman certificate to the KDC to enable
+            static-ephemeral Diffie-Hellman mode for the reply; in this
+            case, the client does NOT place its public value in the
+            AuthPack (defined below).  As another example, the client may
+            place an RSA encryption certificate in this field.  However,
+            there must always be (at least) a signature certificate.
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
+                                    -- if client is using Diffie-Hellman
+                                    -- (ephemeral-ephemeral only)
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        kdcName                 [0] PrincipalName,
+        kdcRealm                [1] Realm,
+        cusec                   [2] INTEGER,
+                                    -- for replay prevention as in RFC1510
+        ctime                   [3] KerberosTime,
+                                    -- for replay prevention as in RFC1510
+        nonce                   [4] INTEGER
+    }
+
+    SubjectPublicKeyInfo ::= SEQUENCE {
+        algorithm                   AlgorithmIdentifier,
+                                    -- dhKeyAgreement
+        subjectPublicKey            BIT STRING
+                                    -- for DH, equals
+                                    -- public exponent (INTEGER encoded
+                                    -- as payload of BIT STRING)
+    }   -- as specified by the X.509 recommendation [10]
+
+    AlgorithmIdentifier ::= SEQUENCE {
+        algorithm                   ALGORITHM.&id,
+        parameters                  ALGORITHM.&type
+    }   -- as specified by the X.509 recommendation [10]
+
+    If the client passes an issuer and serial number in the request,
+    the KDC is requested to use the referred-to certificate.  If none
+    exists, then the KDC returns an error of type
+    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
+    other hand, the client does not pass any trustedCertifiers,
+    believing that it has the KDC's certificate, but the KDC has more
+    than one certificate.  The KDC should include information in the
+    KRB-ERROR message that indicates the KDC certificate(s) that a
+    client may utilize.  This data is specified in the e-data, which
+    is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
+
+    TypedData ::=  SEQUENCE {
+                    data-type      [0] INTEGER,
+                    data-value     [1] OCTET STRING,
+    } -- per Kerberos RFC 1510 revisions
+
+    where:
+    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
+    data-value = CertificateSet // as specified by CMS [11]
+
+    The PKAuthenticator carries information to foil replay attacks, and
+    to bind the request and response.  The PKAuthenticator is signed
+    with the client's signature key.
+
+3.2.2.  KDC Response
+
+    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
+    type, the KDC attempts to verify the user's certificate chain
+    (userCert), if one is provided in the request.  This is done by
+    verifying the certification path against the KDC's policy of
+    legitimate certifiers.  This may be based on a certification
+    hierarchy, or it may be simply a list of recognized certifiers in a
+    system like PGP.
+
+    If the client's certificate chain contains no certificate signed by
+    a CA trusted by the KDC, then the KDC sends back an error message
+    of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data
+    is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
+    whose data-value is an OCTET STRING which is the DER encoding of
+
+        TrustedCertifiers ::= SEQUENCE OF PrincipalName
+                              -- X.500 name encoded as a principal name
+                              -- see Section 3.1
+
+    If while verifying a certificate chain the KDC determines that the
+    signature on one of the certificates in the CertificateSet from
+    the signedAuthPack fails verification, then the KDC returns an
+    error of type KDC_ERR_INVALID_CERTIFICATE.  The accompanying
+    e-data is a SEQUENCE of one TypedData (with type
+    TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING
+    which is the DER encoding of the index into the CertificateSet
+    ordered as sent by the client.
+
+        CertificateIndex  ::= INTEGER
+                              -- 0 = 1st certificate,
+                              --     (in order of encoding)
+                              -- 1 = 2nd certificate, etc
+
+    The KDC may also check whether any of the certificates in the
+    client's chain has been revoked.  If one of the certificates has
+    been revoked, then the KDC returns an error of type
+    KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
+    the certificate's revocation status is unknown or not
+    available, then if required by policy, the KDC returns the
+    appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
+    KDC_ERR_REVOCATION_STATUS_UNAVAILABLE.  In any of these three
+    cases, the affected certificate is identified by the accompanying
+    e-data, which contains a CertificateIndex as described for
+    KDC_ERR_INVALID_CERTIFICATE.
+
+    If the certificate chain can be verified, but the name of the
+    client in the certificate does not match the client's name in the
+    request, then the KDC returns an error of type
+    KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
+    field in this case.
+
+    Finally, if the certificate chain is verified, but the KDC's name
+    or realm as given in the PKAuthenticator does not match the KDC's
+    actual principal name, then the KDC returns an error of type
+    KDC_ERR_KDC_NAME_MISMATCH.  The accompanying e-data field is again
+    a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
+    TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
+    STRING whose data-value is the DER encoding of a PrincipalName or
+    Realm as defined in RFC 1510 revisions.
+
+    Even if all succeeds, the KDC may--for policy reasons--decide not
+    to trust the client.  In this case, the KDC returns an error message
+    of type KDC_ERR_CLIENT_NOT_TRUSTED.  One specific case of this is
+    the presence or absence of an Enhanced Key Usage (EKU) OID within
+    the certificate extensions.  The rules regarding acceptability of
+    an EKU sequence (or the absence of any sequence) are a matter of
+    local policy.  For the benefit of implementers, we define a PKINIT
+    EKU OID as the following: iso (1) org (3) dod (6) internet (1)
+    security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).
+
+    If a trust relationship exists, the KDC then verifies the client's
+    signature on AuthPack.  If that fails, the KDC returns an error
+    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
+    timestamp (ctime and cusec) in the PKAuthenticator to assure that
+    the request is not a replay.  The KDC also verifies that its name
+    is specified in the PKAuthenticator.
+
+    If the clientPublicValue field is filled in, indicating that the
+    client wishes to use Diffie-Hellman key agreement, then the KDC
+    checks to see that the parameters satisfy its policy.  If they do
+    not (e.g., the prime size is insufficient for the expected
+    encryption type), then the KDC sends back an error message of type
+    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it generates its own public and
+    private values for the response.
+
+    The KDC also checks that the timestamp in the PKAuthenticator is
+    within the allowable window and that the principal name and realm
+    are correct.  If the local (server) time and the client time in the
+    authenticator differ by more than the allowable clock skew, then the
+    KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510.
+
+    Assuming no errors, the KDC replies as per RFC 1510, except as
+    follows.  The user's name in the ticket is determined by the
+    following decision algorithm:
+
+        1.  If the KDC has a mapping from the name in the certificate
+            to a Kerberos name, then use that name.
+            Else
+        2.  If the certificate contains the SubjectAltName extention
+            and the local KDC policy defines a mapping from the
+            SubjectAltName to a Kerberos name, then use that name.
+            Else
+        3.  Use the name as represented in the certificate, mapping
+            mapping as necessary (e.g., as per RFC 2253 for X.500
+            names).  In this case the realm in the ticket shall be the
+            name of the certifier that issued the user's certificate.
+
+    Note that a principal name may be carried in the subject alt name
+    field of a certificate. This name may be mapped to a principal
+    record in a security database based on local policy, for example
+    the subject alt name may be kerberos/principal@realm format.  In
+    this case the realm name is not that of the CA but that of the
+    local realm doing the mapping (or some realm name chosen by that
+    realm).
+
+    If a non-KDC X.509 certificate contains the principal name within
+    the subjectAltName version 3 extension , that name may utilize
+    KerberosName as defined below, or, in the case of an S/MIME
+    certificate [17], may utilize the email address.  If the KDC
+    is presented with an S/MIME certificate, then the email address
+    within subjectAltName will be interpreted as a principal and realm
+    separated by the "@" sign, or as a name that needs to be
+    canonicalized.  If the resulting name does not correspond to a
+    registered principal name, then the principal name is formed as
+    defined in section 3.1.
+
+    The trustedCertifiers field contains a list of certification
+    authorities trusted by the client, in the case that the client does
+    not possess the KDC's public key certificate.  If the KDC has no
+    certificate signed by any of the trustedCertifiers, then it returns
+    an error of type KDC_ERR_KDC_NOT_TRUSTED.
+
+    KDCs should try to (in order of preference):
+    1. Use the KDC certificate identified by the serialNumber included
+       in the client's request.
+    2. Use a certificate issued to the KDC by the client's CA (if in the
+       middle of a CA key roll-over, use the KDC cert issued under same
+       CA key as user cert used to verify request).
+    3. Use a certificate issued to the KDC by one of the client's
+       trustedCertifier(s);
+    If the KDC is unable to comply with any of these options, then the
+    KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
+    client.
+
+    The KDC encrypts the reply not with the user's long-term key, but
+    with the Diffie Hellman derived key or a random key generated
+    for this particular response which is carried in the padata field of
+    the TGS-REP message.
+
+    PA-PK-AS-REP ::= CHOICE {
+                            -- PA TYPE 15
+        dhSignedData       [0] SignedData,
+                            -- Defined in CMS and used only with
+                            -- Diffie-Hellman key exchange (if the
+                            -- client public value was present in the
+                            -- request).
+                            -- This choice MUST be supported
+                            -- by compliant implementations.
+        encKeyPack         [1] EnvelopedData,
+                            -- Defined in CMS
+                            -- The temporary key is encrypted
+                            -- using the client public key
+                            -- key
+                            -- SignedReplyKeyPack, encrypted
+                            -- with the temporary key, is also
+                            -- included.
+    }
+
+    Usage of SignedData:
+
+        When the Diffie-Hellman option is used, dhSignedData in
+        PA-PK-AS-REP provides authenticated Diffie-Hellman parameters
+        of the KDC.  The reply key used to encrypt part of the KDC reply
+        message is derived from the Diffie-Hellman exchange:
+
+        1.  Both the KDC and the client calculate a secret value
+            (g^ab mod p), where a is the client's private exponent and
+            b is the KDC's private exponent.
+
+        2.  Both the KDC and the client take the first N bits of this
+            secret value and convert it into a reply key.  N depends on
+            the reply key type.
+
+        3.  If the reply key is DES, N=64 bits, where some of the bits
+            are replaced with parity bits, according to FIPS PUB 74.
+
+        4.  If the reply key is (3-key) 3-DES, N=192 bits, where some
+            of the bits are replaced with parity bits, according to
+            FIPS PUB 74.
+
+        5.  The encapContentInfo field must contain the KdcDHKeyInfo as
+            defined below.
+
+            a.  The eContentType field shall contain the OID value for
+                pkdata: iso (1) org (3) dod (6) internet (1) security (5)
+                kerberosv5 (2) pkinit (3) pkdata (1)
+
+            b.  The eContent field is data of the type KdcDHKeyInfo
+                (below).
+
+        6.  The certificates field must contain the certificates
+            necessary for the client to establish trust in the KDC's
+            certificate based on the list of trusted certifiers sent by
+            the client in the PA-PK-AS-REQ.  This field may be empty if
+            the client did not send to the KDC a list of trusted
+            certifiers (the trustedCertifiers field was empty, meaning
+            that the client already possesses the KDC's certificate).
+
+        7.  The signerInfos field is a SET that must contain at least
+            one member, since it contains the actual signature.
+
+    KdcDHKeyInfo ::= SEQUENCE {
+                              -- used only when utilizing Diffie-Hellman
+      nonce                 [0] INTEGER,
+                                -- binds responce to the request
+      subjectPublicKey      [2] BIT STRING
+                                -- Equals public exponent (g^a mod p)
+                                -- INTEGER encoded as payload of
+                                -- BIT STRING
+    }
+
+    Usage of EnvelopedData:
+
+        The EnvelopedData data type is specified in the Cryptographic
+        Message Syntax, a product of the S/MIME working group of the
+        IETF.  It contains a temporary key encrypted with the PKINIT
+        client's public key.  It also contains a signed and encrypted
+        reply key.
+
+        1.  The originatorInfo field is not required, since that
+            information may be presented in the signedData structure
+            that is encrypted within the encryptedContentInfo field.
+
+        2.  The optional unprotectedAttrs field is not required for
+            PKINIT.
+
+        3.  The recipientInfos field is a SET which must contain exactly
+            one member of the KeyTransRecipientInfo type for encryption
+            with an RSA public key.
+
+            a.  The encryptedKey field (in KeyTransRecipientInfo)
+                contains the temporary key which is encrypted with the
+                PKINIT client's public key.
+
+        4.  The encryptedContentInfo field contains the signed and
+            encrypted reply key.
+
+            a.  The contentType field shall contain the OID value for
+                id-signedData: iso (1) member-body (2) us (840)
+                rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
+
+            b.  The encryptedContent field is encrypted data of the CMS
+                type signedData as specified below.
+
+                i.  The encapContentInfo field must contains the
+                    ReplyKeyPack.
+
+                    * The eContentType field shall contain the OID value
+                      for pkdata: iso (1) org (3) dod (6) internet (1)
+                      security (5) kerberosv5 (2) pkinit (3) pkdata (1)
+
+                    * The eContent field is data of the type ReplyKeyPack
+                      (below).
+
+                ii.  The certificates field must contain the certificates
+                     necessary for the client to establish trust in the
+                     KDC's certificate based on the list of trusted
+                     certifiers sent by the client in the PA-PK-AS-REQ.
+                     This field may be empty if the client did not send
+                     to the KDC a list of trusted certifiers (the
+                     trustedCertifiers field was empty, meaning that the
+                     client already possesses the KDC's certificate).
+
+                iii.  The signerInfos field is a SET that must contain at
+                      least one member, since it contains the actual
+                      signature.
+
+    ReplyKeyPack ::= SEQUENCE {
+                              -- not used for Diffie-Hellman
+        replyKey             [0] EncryptionKey,
+                                 -- used to encrypt main reply
+                                 -- ENCTYPE is at least as strong as
+                                 -- ENCTYPE of session key
+        nonce                [1] INTEGER,
+                                 -- binds response to the request
+                                 -- must be same as the nonce
+                                 -- passed in the PKAuthenticator
+    }
+
+    Since each certifier in the certification path of a user's
+    certificate is equivalent to a separate Kerberos realm, the name
+    of each certifier in the certificate chain must be added to the
+    transited field of the ticket.  The format of these realm names is
+    defined in Section 3.1 of this document.  If applicable, the
+    transit-policy-checked flag should be set in the issued ticket.
+
+    The KDC's certificate(s) must bind the public key(s) of the KDC to
+    a name derivable from the name of the realm for that KDC.  X.509
+    certificates shall contain the principal name of the KDC
+    (defined in section 8.2 of RFC 1510) as the SubjectAltName version
+    3 extension. Below is the definition of this version 3 extension,
+    as specified by the X.509 standard:
+
+        subjectAltName EXTENSION ::= {
+            SYNTAX GeneralNames
+            IDENTIFIED BY id-ce-subjectAltName
+        }
+
+        GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
+
+        GeneralName ::= CHOICE {
+            otherName       [0] OtherName,
+            ...
+        }
+
+        OtherName ::= SEQUENCE {
+            type-id         OBJECT IDENTIFIER,
+            value           [0] EXPLICIT ANY DEFINED BY type-id
+        }
+
+    For the purpose of specifying a Kerberos principal name, the value
+    in OtherName shall be a KerberosName as defined in RFC 1510, but with
+    the PrincipalName replaced by CertPrincipalName as mentioned in
+    Section 3.1:
+
+        KerberosName ::= SEQUENCE {
+            realm           [0] Realm,
+            principalName   [1] CertPrincipalName  -- defined above
+        }
+
+    This specific syntax is identified within subjectAltName by setting
+    the type-id in OtherName to krb5PrincipalName, where (from the
+    Kerberos specification) we have
+
+        krb5 OBJECT IDENTIFIER ::= { iso (1)
+                                     org (3)
+                                     dod (6)
+                                     internet (1)
+                                     security (5)
+                                     kerberosv5 (2) }
+
+        krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
+
+    (This specification may also be used to specify a Kerberos name
+    within the user's certificate.)  The KDC's certificate may be signed
+    directly by a CA, or there may be intermediaries if the server resides
+    within a large organization, or it may be unsigned if the client
+    indicates possession (and trust) of the KDC's certificate.
+
+    The client then extracts the random key used to encrypt the main
+    reply.  This random key (in encPaReply) is encrypted with either the
+    client's public key or with a key derived from the DH values
+    exchanged between the client and the KDC.  The client uses this
+    random key to decrypt the main reply, and subsequently proceeds as
+    described in RFC 1510.
+
+3.2.3. Required Algorithms
+
+    Not all of the algorithms in the PKINIT protocol specification have
+    to be implemented in order to comply with the proposed standard.
+    Below is a list of the required algorithms:
+
+    * Diffie-Hellman public/private key pairs
+        * utilizing Diffie-Hellman ephemeral-ephemeral mode
+    * SHA1 digest and DSA for signatures
+    * 3-key triple DES keys derived from the Diffie-Hellman Exchange
+    * 3-key triple DES Temporary and Reply keys
+
+4.  Logistics and Policy
+
+    This section describes a way to define the policy on the use of
+    PKINIT for each principal and request.
+
+    The KDC is not required to contain a database record for users
+    who use public key authentication.  However, if these users are
+    registered with the KDC, it is recommended that the database record
+    for these users be modified to an additional flag in the attributes
+    field to indicate that the user should authenticate using PKINIT.
+    If this flag is set and a request message does not contain the
+    PKINIT preauthentication field, then the KDC sends back as error of
+    type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
+    field of type PA-PK-AS-REQ must be included in the request.
+
+5.  Security Considerations
+
+    PKINIT raises a few security considerations, which we will address
+    in this section.
+
+    First of all, PKINIT introduces a new trust model, where KDCs do not
+    (necessarily) certify the identity of those for whom they issue
+    tickets.  PKINIT does allow KDCs to act as their own CAs, in the
+    limited capacity of self-signing their certificates, but one of the
+    additional benefits is to align Kerberos authentication with a global
+    public key infrastructure.  Anyone using PKINIT in this way must be
+    aware of how the certification infrastructure they are linking to
+    works.
+
+    Secondly, PKINIT also introduces the possibility of interactions
+    between different cryptosystems, which may be of widely varying
+    strengths.  Many systems, for instance, allow the use of 512-bit
+    public keys.  Using such keys to wrap data encrypted under strong
+    conventional cryptosystems, such as triple-DES, is inappropriate;
+    it adds a weak link to a strong one at extra cost.  Implementors
+    and administrators should take care to avoid such wasteful and
+    deceptive interactions.
+
+    Lastly, PKINIT calls for randomly generated keys for conventional
+    cryptosystems.  Many such systems contain systematically "weak"
+    keys.  PKINIT implementations MUST avoid use of these keys, either
+    by discarding those keys when they are generated, or by fixing them
+    in some way (e.g., by XORing them with a given mask).  These
+    precautions vary from system to system; it is not our intention to
+    give an explicit recipe for them here.
+
+6.  Transport Issues
+
+    Certificate chains can potentially grow quite large and span several
+    UDP packets; this in turn increases the probability that a Kerberos
+    message involving PKINIT extensions will be broken in transit.  In
+    light of the possibility that the Kerberos specification will
+    require KDCs to accept requests using TCP as a transport mechanism,
+    we make the same recommendation with respect to the PKINIT
+    extensions as well.
+
+7.  Bibliography
+
+    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
+    (V5).  Request for Comments 1510.
+
+    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
+    for Computer Networks, IEEE Communications, 32(9):33-38.  September
+    1994.
+
+    [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
+    A. Medvinsky, M. Hur.  Public Key Cryptography for Cross-Realm
+    Authentication in Kerberos.  draft-ietf-cat-kerberos-pk-cross-04.txt
+
+    [4] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
+    Kerberos.  draft-ietf-cat-kerberos-anoncred-00.txt
+
+    [5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman.
+    Public Key Utilizing Tickets for Application Servers (PKTAPP).
+    draft-ietf-cat-pktapp-02.txt
+
+    [6] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
+    Using Public Key Cryptography.  Symposium On Network and Distributed
+    System Security, 1997.
+
+    [7] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
+    Protocol.  In Proceedings of the USENIX Workshop on Electronic
+    Commerce, July 1995.
+
+    [8] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
+    Request for Comments 2246, January 1999.
+
+    [9] B.C. Neuman, Proxy-Based Authorization and Accounting for
+    Distributed Systems.  In Proceedings of the 13th International
+    Conference on Distributed Computing Systems, May 1993.
+
+    [10] ITU-T (formerly CCITT) Information technology - Open Systems
+    Interconnection - The Directory: Authentication Framework
+    Recommendation X.509 ISO/IEC 9594-8
+
+    [11] R. Housley. Cryptographic Message Syntax.
+    draft-ietf-smime-cms-13.txt, April 1999, approved for publication
+    as RFC.
+
+    [12] PKCS #7: Cryptographic Message Syntax Standard,
+    An RSA Laboratories Technical Note Version 1.5
+    Revised November 1, 1993
+
+    [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
+    Security, Inc. A Description of the RC2(r) Encryption Algorithm
+    March 1998.
+    Request for Comments 2268.
+
+    [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
+    Protocol (v3): UTF-8 String Representation of Distinguished Names.
+    Request for Comments 2253.
+
+    [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
+    Key Infrastructure, Certificate and CRL Profile, January 1999.
+    Request for Comments 2459.
+
+    [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
+    Specifications, October 1998.  Request for Comments 2437.
+
+    [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.  S/MIME
+    Version 2 Certificate Handling, March 1998.  Request for
+    Comments 2312.
+
+    [18] M. Wahl, T. Howes, S. Kille.  Lightweight Directory Access
+    Protocol (v3), December 1997.  Request for Comments 2251.
+
+    [19] ITU-T (formerly CCITT) Information Processing Systems - Open
+    Systems Interconnection - Specification of Abstract Syntax Notation
+    One (ASN.1) Rec. X.680 ISO/IEC 8824-1
+
+8.  Acknowledgements
+
+    Some of the ideas on which this proposal is based arose during
+    discussions over several years between members of the SAAG, the IETF
+    CAT working group, and the PSRG, regarding integration of Kerberos
+    and SPX.  Some ideas have also been drawn from the DASS system.
+    These changes are by no means endorsed by these groups.  This is an
+    attempt to revive some of the goals of those groups, and this
+    proposal approaches those goals primarily from the Kerberos
+    perspective.  Lastly, comments from groups working on similar ideas
+    in DCE have been invaluable.
+
+9.  Expiration Date
+
+    This draft expires September 15, 2000.
+
+10. Authors
+
+    Brian Tung
+    Clifford Neuman
+    USC Information Sciences Institute
+    4676 Admiralty Way Suite 1001
+    Marina del Rey CA 90292-6695
+    Phone: +1 310 822 1511
+    E-mail: {brian, bcn}@isi.edu
+
+    Matthew Hur
+    CyberSafe Corporation
+    1605 NW Sammamish Road
+    Issaquah WA 98027-5378
+    Phone: +1 425 391 6000
+    E-mail: matt.hur@cybersafe.com
+
+    Ari Medvinsky
+    Keen.com, Inc.
+    150 Independence Drive
+    Menlo Park CA 94025
+    Phone: +1 650 289 3134
+    E-mail: ari@keen.com
+
+    Sasha Medvinsky
+    Motorola
+    6450 Sequence Drive
+    San Diego, CA 92121
+    Phone +1 619 404 2825
+    E-mail: smedvinsky@gi.com
+
+    John Wray
+    Iris Associates, Inc.
+    5 Technology Park Dr.
+    Westford, MA 01886
+    E-mail: John_Wray@iris.com
+
+    Jonathan Trostle
+    170 W. Tasman Dr.
+    San Jose, CA 95134
+    E-mail: jtrostle@cisco.com
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt
new file mode 100644
index 000000000000..b1e596836eb8
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt
@@ -0,0 +1,1080 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-12.txt                   Clifford Neuman
+Updates: RFC 1510                                                USC/ISI
+expires January 15, 2001                                     Matthew Hur
+                                                   CyberSafe Corporation
+                                                           Ari Medvinsky
+                                                          Keen.com, Inc.
+                                                         Sasha Medvinsky
+                                                                Motorola
+                                                               John Wray
+                                                   Iris Associates, Inc.
+                                                        Jonathan Trostle
+                                                                   Cisco
+
+    Public Key Cryptography for Initial Authentication in Kerberos
+
+0.  Status Of This Memo
+
+    This document is an Internet-Draft and is in full conformance with
+    all provisions of Section 10 of RFC 2026.  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.
+
+    To learn the current status of any Internet-Draft, please check
+    the "1id-abstracts.txt" listing contained in the Internet-Drafts
+    Shadow Directories on ftp.ietf.org (US East Coast),
+    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
+    munnari.oz.au (Pacific Rim).
+
+    The distribution of this memo is unlimited.  It is filed as
+    draft-ietf-cat-kerberos-pk-init-11.txt, and expires January 15,
+    2001.  Please send comments to the authors.
+
+1.  Abstract
+
+    This document defines extensions (PKINIT) to the Kerberos protocol
+    specification (RFC 1510 [1]) to provide a method for using public
+    key cryptography during initial authentication.  The methods
+    defined specify the ways in which preauthentication data fields and
+    error data fields in Kerberos messages are to be used to transport
+    public key data.
+
+2.  Introduction
+
+    The popularity of public key cryptography has produced a desire for
+    its support in Kerberos [2].  The advantages provided by public key
+    cryptography include simplified key management (from the Kerberos
+    perspective) and the ability to leverage existing and developing
+    public key certification infrastructures.
+
+    Public key cryptography can be integrated into Kerberos in a number
+    of ways.  One is to associate a key pair with each realm, which can
+    then be used to facilitate cross-realm authentication; this is the
+    topic of another draft proposal.  Another way is to allow users with
+    public key certificates to use them in initial authentication.  This
+    is the concern of the current document.
+
+    PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
+    combination with digital signature keys as the primary, required
+    mechanism.  It also allows for the use of RSA keys and/or (static)
+    Diffie-Hellman certificates.  Note in particular that PKINIT supports
+    the use of separate signature and encryption keys.
+
+    PKINIT enables access to Kerberos-secured services based on initial
+    authentication utilizing public key cryptography.  PKINIT utilizes
+    standard public key signature and encryption data formats within the
+    standard Kerberos messages.  The basic mechanism is as follows:  The
+    user sends an AS-REQ message to the KDC as before, except that if that
+    user is to use public key cryptography in the initial authentication
+    step, his certificate and a signature accompany the initial request
+    in the preauthentication fields.  Upon receipt of this request, the
+    KDC verifies the certificate and issues a ticket granting ticket
+    (TGT) as before, except that the encPart from the AS-REP message
+    carrying the TGT is now encrypted utilizing either a Diffie-Hellman
+    derived key or the user's public key.  This message is authenticated
+    utilizing the public key signature of the KDC.
+
+    Note that PKINIT does not require the use of certificates.  A KDC
+    may store the public key of a principal as part of that principal's
+    record.  In this scenario, the KDC is the trusted party that vouches
+    for the principal (as in a standard, non-cross realm, Kerberos
+    environment).  Thus, for any principal, the KDC may maintain a
+    secret key, a public key, or both.
+
+    The PKINIT specification may also be used as a building block for
+    other specifications.  PKCROSS [3] utilizes PKINIT for establishing
+    the inter-realm key and associated inter-realm policy to be applied
+    in issuing cross realm service tickets.  As specified in [4],
+    anonymous Kerberos tickets can be issued by applying a NULL
+    signature in combination with Diffie-Hellman in the PKINIT exchange.
+    Additionally, the PKINIT specification may be used for direct peer
+    to peer authentication without contacting a central KDC. This
+    application of PKINIT is described in PKTAPP [5] and is based on
+    concepts introduced in [6, 7]. For direct client-to-server
+    authentication, the client uses PKINIT to authenticate to the end
+    server (instead of a central KDC), which then issues a ticket for
+    itself.  This approach has an advantage over TLS [8] in that the
+    server does not need to save state (cache session keys).
+    Furthermore, an additional benefit is that Kerberos tickets can
+    facilitate delegation (see [9]).
+
+3.  Proposed Extensions
+
+    This section describes extensions to RFC 1510 for supporting the
+    use of public key cryptography in the initial request for a ticket
+    granting ticket (TGT).
+
+    In summary, the following change to RFC 1510 is proposed:
+
+        * Users may authenticate using either a public key pair or a
+          conventional (symmetric) key.  If public key cryptography is
+          used, public key data is transported in preauthentication
+          data fields to help establish identity.  The user presents
+          a public key certificate and obtains an ordinary TGT that may
+          be used for subsequent authentication, with such
+          authentication using only conventional cryptography.
+
+    Section 3.1 provides definitions to help specify message formats.
+    Section 3.2 describes the extensions for the initial authentication
+    method.
+
+3.1.  Definitions
+
+    The extensions involve new preauthentication fields; we introduce
+    the following preauthentication types:
+
+        PA-PK-AS-REQ                            14
+        PA-PK-AS-REP                            15
+
+    The extensions also involve new error types; we introduce the
+    following types:
+
+        KDC_ERR_CLIENT_NOT_TRUSTED              62
+        KDC_ERR_KDC_NOT_TRUSTED                 63
+        KDC_ERR_INVALID_SIG                     64
+        KDC_ERR_KEY_TOO_WEAK                    65
+        KDC_ERR_CERTIFICATE_MISMATCH            66
+        KDC_ERR_CANT_VERIFY_CERTIFICATE         70
+        KDC_ERR_INVALID_CERTIFICATE             71
+        KDC_ERR_REVOKED_CERTIFICATE             72
+        KDC_ERR_REVOCATION_STATUS_UNKNOWN       73
+        KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74
+        KDC_ERR_CLIENT_NAME_MISMATCH            75
+        KDC_ERR_KDC_NAME_MISMATCH               76
+
+    We utilize the following typed data for errors:
+
+        TD-PKINIT-CMS-CERTIFICATES             101
+        TD-KRB-PRINCIPAL                       102
+        TD-KRB-REALM                           103
+        TD-TRUSTED-CERTIFIERS                  104
+        TD-CERTIFICATE-INDEX                   105
+
+    We utilize the following encryption types (which map directly to
+    OIDs):
+
+        dsaWithSHA1-CmsOID                       9
+        md5WithRSAEncryption-CmsOID             10
+        sha1WithRSAEncryption-CmsOID            11
+        rc2CBC-EnvOID                           12
+        rsaEncryption-EnvOID (PKCS#1 v1.5)      13
+        rsaES-OAEP-ENV-OID   (PKCS#1 v2.0)      14
+        des-ede3-cbc-Env-OID                    15
+
+    These mappings are provided so that a client may send the
+    appropriate enctypes in the AS-REQ message in order to indicate
+    support for the corresponding OIDs (for performing PKINIT).
+
+    In many cases, PKINIT requires the encoding of the X.500 name of a
+    certificate authority as a Realm.  When such a name appears as
+    a realm it will be represented using the "other" form of the realm
+    name as specified in the naming constraints section of RFC1510.
+    For a realm derived from an X.500 name, NAMETYPE will have the value
+    X500-RFC2253.  The full realm name will appear as follows:
+
+        <nametype> + ":" + <string>
+
+    where nametype is "X500-RFC2253" and string is the result of doing
+    an RFC2253 encoding of the distinguished name, i.e.
+
+        "X500-RFC2253:" + RFC2253Encode(DistinguishedName)
+
+    where DistinguishedName is an X.500 name, and RFC2253Encode is a
+    function returing a readable UTF encoding of an X.500 name, as
+    defined by RFC 2253 [14] (part of LDAPv3 [18]).
+
+    To ensure that this encoding is unique, we add the following rule
+    to those specified by RFC 2253:
+
+        The order in which the attributes appear in the RFC 2253
+        encoding must be the reverse of the order in the ASN.1
+        encoding of the X.500 name that appears in the public key
+        certificate. The order of the relative distinguished names
+        (RDNs), as well as the order of the AttributeTypeAndValues
+        within each RDN, will be reversed. (This is despite the fact
+        that an RDN is defined as a SET of AttributeTypeAndValues, where
+        an order is normally not important.)
+
+    Similarly, in cases where the KDC does not provide a specific
+    policy based mapping from the X.500 name or X.509 Version 3
+    SubjectAltName extension in the user's certificate to a Kerberos
+    principal name, PKINIT requires the direct encoding of the X.500
+    name as a PrincipalName.  In this case, the name-type of the
+    principal name shall be set to KRB_NT-X500-PRINCIPAL.  This new
+    name type is defined in RFC 1510 as:
+
+        KRB_NT_X500_PRINCIPAL    6
+
+    The name-string shall be set as follows:
+
+        RFC2253Encode(DistinguishedName)
+
+    as described above.  When this name type is used, the principal's
+    realm shall be set to the certificate authority's distinguished
+    name using the X500-RFC2253 realm name format described earlier in
+    this section
+
+    RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
+
+        PrincipalName ::=   SEQUENCE {
+                        name-type[0]     INTEGER,
+                        name-string[1]   SEQUENCE OF GeneralString
+        }
+
+    For the purposes of encoding an X.500 name as a Kerberos name for
+    use in Kerberos structures, the name-string shall be encoded as a
+    single GeneralString.  The name-type should be KRB_NT_X500_PRINCIPAL,
+    as noted above.  All Kerberos names must conform to validity
+    requirements as given in RFC 1510.  Note that name mapping may be
+    required or optional, based on policy.
+
+    We also define the following similar ASN.1 structure:
+
+        CertPrincipalName ::= SEQUENCE {
+                        name-type[0]     INTEGER,
+                        name-string[1]   SEQUENCE OF UTF8String
+        }
+
+    When a Kerberos PrincipalName is to be placed within an X.509 data
+    structure, the CertPrincipalName structure is to be used, with the
+    name-string encoded as a single UTF8String.  The name-type should be
+    as identified in the original PrincipalName structure.  The mapping
+    between the GeneralString and UTF8String formats can be found in
+    [19].
+
+    The following rules relate to the the matching of PrincipalNames (or
+    corresponding CertPrincipalNames) with regard to the PKI name
+    constraints for CAs as laid out in RFC 2459 [15].  In order to be
+    regarded as a match (for permitted and excluded name trees), the
+    following must be satisfied.
+
+        1.  If the constraint is given as a user plus realm name, or
+            as a user plus instance plus realm name (as specified in
+            RFC 1510), the realm name must be valid (see 2.a-d below)
+            and the match must be exact, byte for byte.
+
+        2.  If the constraint is given only as a realm name, matching
+            depends on the type of the realm:
+
+            a.  If the realm contains a colon (':') before any equal
+                sign ('='), it is treated as a realm of type Other,
+                and must match exactly, byte for byte.
+
+            b.  Otherwise, if the realm contains an equal sign, it
+                is treated as an X.500 name.  In order to match, every
+                component in the constraint MUST be in the principal
+                name, and have the same value.  For example, 'C=US'
+                matches 'C=US/O=ISI' but not 'C=UK'.
+
+            c.  Otherwise, if the realm name conforms to rules regarding
+                the format of DNS names, it is considered a realm name of
+                type Domain.  The constraint may be given as a realm
+                name 'FOO.BAR', which matches any PrincipalName within
+                the realm 'FOO.BAR' but not those in subrealms such as
+                'CAR.FOO.BAR'.  A constraint of the form '.FOO.BAR'
+                matches PrincipalNames in subrealms of the form
+                'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.
+
+            d.  Otherwise, the realm name is invalid and does not match
+                under any conditions.
+
+3.1.1.  Encryption and Key Formats
+
+    In the exposition below, we use the terms public key and private
+    key generically.  It should be understood that the term "public
+    key" may be used to refer to either a public encryption key or a
+    signature verification key, and that the term "private key" may be
+    used to refer to either a private decryption key or a signature
+    generation key.  The fact that these are logically distinct does
+    not preclude the assignment of bitwise identical keys for RSA
+    keys.
+
+    In the case of Diffie-Hellman, the key shall be produced from the
+    agreed bit string as follows:
+
+        * Truncate the bit string to the appropriate length.
+        * Rectify parity in each byte (if necessary) to obtain the key.
+
+    For instance, in the case of a DES key, we take the first eight
+    bytes of the bit stream, and then adjust the least significant bit
+    of each byte to ensure that each byte has odd parity.
+
+3.1.2. Algorithm Identifiers
+
+    PKINIT does not define, but does permit, the algorithm identifiers
+    listed below.
+
+3.1.2.1. Signature Algorithm Identifiers
+
+    The following signature algorithm identifiers specified in [11] and
+    in [15] shall be used with PKINIT:
+
+    id-dsa-with-sha1       (DSA with SHA1)
+    md5WithRSAEncryption   (RSA with MD5)
+    sha-1WithRSAEncryption (RSA with SHA1)
+
+3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
+
+    The following algorithm identifier shall be used within the
+    SubjectPublicKeyInfo data structure: dhpublicnumber
+
+    This identifier and the associated algorithm parameters are
+    specified in RFC 2459 [15].
+
+3.1.2.3. Algorithm Identifiers for RSA Encryption
+
+    These algorithm identifiers are used inside the EnvelopedData data
+    structure, for encrypting the temporary key with a public key:
+
+        rsaEncryption (RSA encryption, PKCS#1 v1.5)
+        id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
+
+    Both of the above RSA encryption schemes are specified in [16].
+    Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
+    CMS specification says that it will likely include PKCS#1 v2.0 in
+    the future.  (PKCS#1 v2.0 addresses adaptive chosen ciphertext
+    vulnerability discovered in PKCS#1 v1.5.)
+
+3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
+
+    These algorithm identifiers are used inside the EnvelopedData data
+    structure in the PKINIT Reply, for encrypting the reply key with the
+    temporary key:
+        des-ede3-cbc (3-key 3-DES, CBC mode)
+        rc2-cbc      (RC2, CBC mode)
+
+    The full definition of the above algorithm identifiers and their
+    corresponding parameters (an IV for block chaining) is provided in
+    the CMS specification [11].
+
+3.2.  Public Key Authentication
+
+    Implementation of the changes in this section is REQUIRED for
+    compliance with PKINIT.
+
+3.2.1.  Client Request
+
+    Public keys may be signed by some certification authority (CA), or
+    they may be maintained by the KDC in which case the KDC is the
+    trusted authority.  Note that the latter mode does not require the
+    use of certificates.
+
+    The initial authentication request is sent as per RFC 1510, except
+    that a preauthentication field containing data signed by the user's
+    private key accompanies the request:
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+                                -- PA TYPE 14
+        signedAuthPack          [0] SignedData
+                                    -- Defined in CMS [11];
+                                    -- AuthPack (below) defines the
+                                    -- data that is signed.
+        trustedCertifiers       [1] SEQUENCE OF TrustedCas OPTIONAL,
+                                    -- This is a list of CAs that the
+                                    -- client trusts and that certify
+                                    -- KDCs.
+        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
+                                    -- As defined in CMS [11];
+                                    -- specifies a particular KDC
+                                    -- certificate if the client
+                                    -- already has it.
+        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL
+                                    -- For example, this may be the
+                                    -- client's Diffie-Hellman
+                                    -- certificate, or it may be the
+                                    -- client's RSA encryption
+                                    -- certificate.
+    }
+
+    TrustedCas ::= CHOICE {
+        principalName         [0] KerberosName,
+                                  -- as defined below
+        caName                [1] Name
+                                  -- fully qualified X.500 name
+                                  -- as defined by X.509
+        issuerAndSerial       [2] IssuerAndSerialNumber
+                                  -- Since a CA may have a number of
+                                  -- certificates, only one of which
+                                  -- a client trusts
+    }
+
+    Usage of SignedData:
+
+        The SignedData data type is specified in the Cryptographic
+        Message Syntax, a product of the S/MIME working group of the
+        IETF.  The following describes how to fill in the fields of
+        this data:
+
+        1.  The encapContentInfo field must contain the PKAuthenticator
+            and, optionally, the client's Diffie Hellman public value.
+
+            a.  The eContentType field shall contain the OID value for
+                pkauthdata: iso (1) org (3) dod (6) internet (1)
+                security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)
+
+            b.  The eContent field is data of the type AuthPack (below).
+
+        2.  The signerInfos field contains the signature of AuthPack.
+
+        3.  The Certificates field, when non-empty, contains the client's
+            certificate chain.  If present, the KDC uses the public key
+            from the client's certificate to verify the signature in the
+            request.  Note that the client may pass different certificate
+            chains that are used for signing or for encrypting.  Thus,
+            the KDC may utilize a different client certificate for
+            signature verification than the one it uses to encrypt the
+            reply to the client.  For example, the client may place a
+            Diffie-Hellman certificate in this field in order to convey
+            its static Diffie Hellman certificate to the KDC to enable
+            static-ephemeral Diffie-Hellman mode for the reply; in this
+            case, the client does NOT place its public value in the
+            AuthPack (defined below).  As another example, the client may
+            place an RSA encryption certificate in this field.  However,
+            there must always be (at least) a signature certificate.
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
+                                    -- if client is using Diffie-Hellman
+                                    -- (ephemeral-ephemeral only)
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        cusec                   [0] INTEGER,
+                                    -- for replay prevention as in RFC1510
+        ctime                   [1] KerberosTime,
+                                    -- for replay prevention as in RFC1510
+        nonce                   [2] INTEGER,
+        pachecksum              [3] Checksum
+                                    -- Checksum over KDC-REQ-BODY
+                                    -- Defined by Kerberos spec
+    }
+
+    SubjectPublicKeyInfo ::= SEQUENCE {
+        algorithm                   AlgorithmIdentifier,
+                                    -- dhKeyAgreement
+        subjectPublicKey            BIT STRING
+                                    -- for DH, equals
+                                    -- public exponent (INTEGER encoded
+                                    -- as payload of BIT STRING)
+    }   -- as specified by the X.509 recommendation [10]
+
+    AlgorithmIdentifier ::= SEQUENCE {
+        algorithm                   OBJECT IDENTIFIER,
+                                    -- for dhKeyAgreement, this is
+                                    -- { iso (1) member-body (2) US (840)
+                                    -- rsadsi (113459) pkcs (1) 3 1 }
+                                    -- from PKCS #3 [20]
+        parameters                  ANY DEFINED by algorithm OPTIONAL
+                                    -- for dhKeyAgreement, this is
+                                    -- DHParameter
+    }   -- as specified by the X.509 recommendation [10]
+
+    DHParameter ::= SEQUENCE {
+        prime                       INTEGER,
+                                    -- p
+        base                        INTEGER,
+                                    -- g
+        privateValueLength          INTEGER OPTIONAL
+                                    -- l
+    }   -- as defined in PKCS #3 [20]
+
+    If the client passes an issuer and serial number in the request,
+    the KDC is requested to use the referred-to certificate.  If none
+    exists, then the KDC returns an error of type
+    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
+    other hand, the client does not pass any trustedCertifiers,
+    believing that it has the KDC's certificate, but the KDC has more
+    than one certificate.  The KDC should include information in the
+    KRB-ERROR message that indicates the KDC certificate(s) that a
+    client may utilize.  This data is specified in the e-data, which
+    is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
+
+    TypedData ::=  SEQUENCE {
+                    data-type      [0] INTEGER,
+                    data-value     [1] OCTET STRING,
+    } -- per Kerberos RFC 1510 revisions
+
+    where:
+    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
+    data-value = CertificateSet // as specified by CMS [11]
+
+    The PKAuthenticator carries information to foil replay attacks, to
+    bind the pre-authentication data to the KDC-REQ-BODY, and to bind the
+    request and response.  The PKAuthenticator is signed with the client's
+    signature key.
+
+3.2.2.  KDC Response
+
+    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
+    type, the KDC attempts to verify the user's certificate chain
+    (userCert), if one is provided in the request.  This is done by
+    verifying the certification path against the KDC's policy of
+    legitimate certifiers.  This may be based on a certification
+    hierarchy, or it may be simply a list of recognized certifiers in a
+    system like PGP.
+
+    If the client's certificate chain contains no certificate signed by
+    a CA trusted by the KDC, then the KDC sends back an error message
+    of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data
+    is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
+    whose data-value is an OCTET STRING which is the DER encoding of
+
+        TrustedCertifiers ::= SEQUENCE OF PrincipalName
+                              -- X.500 name encoded as a principal name
+                              -- see Section 3.1
+
+    If while verifying a certificate chain the KDC determines that the
+    signature on one of the certificates in the CertificateSet from
+    the signedAuthPack fails verification, then the KDC returns an
+    error of type KDC_ERR_INVALID_CERTIFICATE.  The accompanying
+    e-data is a SEQUENCE of one TypedData (with type
+    TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING
+    which is the DER encoding of the index into the CertificateSet
+    ordered as sent by the client.
+
+        CertificateIndex  ::= INTEGER
+                              -- 0 = 1st certificate,
+                              --     (in order of encoding)
+                              -- 1 = 2nd certificate, etc
+
+    The KDC may also check whether any of the certificates in the
+    client's chain has been revoked.  If one of the certificates has
+    been revoked, then the KDC returns an error of type
+    KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
+    the certificate's revocation status is unknown or not
+    available, then if required by policy, the KDC returns the
+    appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
+    KDC_ERR_REVOCATION_STATUS_UNAVAILABLE.  In any of these three
+    cases, the affected certificate is identified by the accompanying
+    e-data, which contains a CertificateIndex as described for
+    KDC_ERR_INVALID_CERTIFICATE.
+
+    If the certificate chain can be verified, but the name of the
+    client in the certificate does not match the client's name in the
+    request, then the KDC returns an error of type
+    KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
+    field in this case.
+
+    Finally, if the certificate chain is verified, but the KDC's name
+    or realm as given in the PKAuthenticator does not match the KDC's
+    actual principal name, then the KDC returns an error of type
+    KDC_ERR_KDC_NAME_MISMATCH.  The accompanying e-data field is again
+    a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
+    TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
+    STRING whose data-value is the DER encoding of a PrincipalName or
+    Realm as defined in RFC 1510 revisions.
+
+    Even if all succeeds, the KDC may--for policy reasons--decide not
+    to trust the client.  In this case, the KDC returns an error message
+    of type KDC_ERR_CLIENT_NOT_TRUSTED.  One specific case of this is
+    the presence or absence of an Enhanced Key Usage (EKU) OID within
+    the certificate extensions.  The rules regarding acceptability of
+    an EKU sequence (or the absence of any sequence) are a matter of
+    local policy.  For the benefit of implementers, we define a PKINIT
+    EKU OID as the following: iso (1) org (3) dod (6) internet (1)
+    security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).
+
+    If a trust relationship exists, the KDC then verifies the client's
+    signature on AuthPack.  If that fails, the KDC returns an error
+    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
+    timestamp (ctime and cusec) in the PKAuthenticator to assure that
+    the request is not a replay.  The KDC also verifies that its name
+    is specified in the PKAuthenticator.
+
+    If the clientPublicValue field is filled in, indicating that the
+    client wishes to use Diffie-Hellman key agreement, then the KDC
+    checks to see that the parameters satisfy its policy.  If they do
+    not (e.g., the prime size is insufficient for the expected
+    encryption type), then the KDC sends back an error message of type
+    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it generates its own public and
+    private values for the response.
+
+    The KDC also checks that the timestamp in the PKAuthenticator is
+    within the allowable window and that the principal name and realm
+    are correct.  If the local (server) time and the client time in the
+    authenticator differ by more than the allowable clock skew, then the
+    KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510.
+
+    Assuming no errors, the KDC replies as per RFC 1510, except as
+    follows.  The user's name in the ticket is determined by the
+    following decision algorithm:
+
+        1.  If the KDC has a mapping from the name in the certificate
+            to a Kerberos name, then use that name.
+            Else
+        2.  If the certificate contains the SubjectAltName extention
+            and the local KDC policy defines a mapping from the
+            SubjectAltName to a Kerberos name, then use that name.
+            Else
+        3.  Use the name as represented in the certificate, mapping
+            mapping as necessary (e.g., as per RFC 2253 for X.500
+            names).  In this case the realm in the ticket shall be the
+            name of the certifier that issued the user's certificate.
+
+    Note that a principal name may be carried in the subject alt name
+    field of a certificate. This name may be mapped to a principal
+    record in a security database based on local policy, for example
+    the subject alt name may be kerberos/principal@realm format.  In
+    this case the realm name is not that of the CA but that of the
+    local realm doing the mapping (or some realm name chosen by that
+    realm).
+
+    If a non-KDC X.509 certificate contains the principal name within
+    the subjectAltName version 3 extension , that name may utilize
+    KerberosName as defined below, or, in the case of an S/MIME
+    certificate [17], may utilize the email address.  If the KDC
+    is presented with an S/MIME certificate, then the email address
+    within subjectAltName will be interpreted as a principal and realm
+    separated by the "@" sign, or as a name that needs to be
+    canonicalized.  If the resulting name does not correspond to a
+    registered principal name, then the principal name is formed as
+    defined in section 3.1.
+
+    The trustedCertifiers field contains a list of certification
+    authorities trusted by the client, in the case that the client does
+    not possess the KDC's public key certificate.  If the KDC has no
+    certificate signed by any of the trustedCertifiers, then it returns
+    an error of type KDC_ERR_KDC_NOT_TRUSTED.
+
+    KDCs should try to (in order of preference):
+    1. Use the KDC certificate identified by the serialNumber included
+       in the client's request.
+    2. Use a certificate issued to the KDC by the client's CA (if in the
+       middle of a CA key roll-over, use the KDC cert issued under same
+       CA key as user cert used to verify request).
+    3. Use a certificate issued to the KDC by one of the client's
+       trustedCertifier(s);
+    If the KDC is unable to comply with any of these options, then the
+    KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
+    client.
+
+    The KDC encrypts the reply not with the user's long-term key, but
+    with the Diffie Hellman derived key or a random key generated
+    for this particular response which is carried in the padata field of
+    the TGS-REP message.
+
+    PA-PK-AS-REP ::= CHOICE {
+                            -- PA TYPE 15
+        dhSignedData       [0] SignedData,
+                            -- Defined in CMS and used only with
+                            -- Diffie-Hellman key exchange (if the
+                            -- client public value was present in the
+                            -- request).
+                            -- This choice MUST be supported
+                            -- by compliant implementations.
+        encKeyPack         [1] EnvelopedData,
+                            -- Defined in CMS
+                            -- The temporary key is encrypted
+                            -- using the client public key
+                            -- key
+                            -- SignedReplyKeyPack, encrypted
+                            -- with the temporary key, is also
+                            -- included.
+    }
+
+    Usage of SignedData:
+
+        When the Diffie-Hellman option is used, dhSignedData in
+        PA-PK-AS-REP provides authenticated Diffie-Hellman parameters
+        of the KDC.  The reply key used to encrypt part of the KDC reply
+        message is derived from the Diffie-Hellman exchange:
+
+        1.  Both the KDC and the client calculate a secret value
+            (g^ab mod p), where a is the client's private exponent and
+            b is the KDC's private exponent.
+
+        2.  Both the KDC and the client take the first N bits of this
+            secret value and convert it into a reply key.  N depends on
+            the reply key type.
+
+        3.  If the reply key is DES, N=64 bits, where some of the bits
+            are replaced with parity bits, according to FIPS PUB 74.
+
+        4.  If the reply key is (3-key) 3-DES, N=192 bits, where some
+            of the bits are replaced with parity bits, according to
+            FIPS PUB 74.
+
+        5.  The encapContentInfo field must contain the KdcDHKeyInfo as
+            defined below.
+
+            a.  The eContentType field shall contain the OID value for
+                pkdhkeydata: iso (1) org (3) dod (6) internet (1)
+                security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2)
+
+            b.  The eContent field is data of the type KdcDHKeyInfo
+                (below).
+
+        6.  The certificates field must contain the certificates
+            necessary for the client to establish trust in the KDC's
+            certificate based on the list of trusted certifiers sent by
+            the client in the PA-PK-AS-REQ.  This field may be empty if
+            the client did not send to the KDC a list of trusted
+            certifiers (the trustedCertifiers field was empty, meaning
+            that the client already possesses the KDC's certificate).
+
+        7.  The signerInfos field is a SET that must contain at least
+            one member, since it contains the actual signature.
+
+    KdcDHKeyInfo ::= SEQUENCE {
+                              -- used only when utilizing Diffie-Hellman
+      nonce                 [0] INTEGER,
+                                -- binds responce to the request
+      subjectPublicKey      [2] BIT STRING
+                                -- Equals public exponent (g^a mod p)
+                                -- INTEGER encoded as payload of
+                                -- BIT STRING
+    }
+
+    Usage of EnvelopedData:
+
+        The EnvelopedData data type is specified in the Cryptographic
+        Message Syntax, a product of the S/MIME working group of the
+        IETF.  It contains a temporary key encrypted with the PKINIT
+        client's public key.  It also contains a signed and encrypted
+        reply key.
+
+        1.  The originatorInfo field is not required, since that
+            information may be presented in the signedData structure
+            that is encrypted within the encryptedContentInfo field.
+
+        2.  The optional unprotectedAttrs field is not required for
+            PKINIT.
+
+        3.  The recipientInfos field is a SET which must contain exactly
+            one member of the KeyTransRecipientInfo type for encryption
+            with an RSA public key.
+
+            a.  The encryptedKey field (in KeyTransRecipientInfo)
+                contains the temporary key which is encrypted with the
+                PKINIT client's public key.
+
+        4.  The encryptedContentInfo field contains the signed and
+            encrypted reply key.
+
+            a.  The contentType field shall contain the OID value for
+                id-signedData: iso (1) member-body (2) us (840)
+                rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
+
+            b.  The encryptedContent field is encrypted data of the CMS
+                type signedData as specified below.
+
+                i.  The encapContentInfo field must contains the
+                    ReplyKeyPack.
+
+                    * The eContentType field shall contain the OID value
+                      for pkrkeydata: iso (1) org (3) dod (6) internet (1)
+                      security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3)
+
+                    * The eContent field is data of the type ReplyKeyPack
+                      (below).
+
+                ii.  The certificates field must contain the certificates
+                     necessary for the client to establish trust in the
+                     KDC's certificate based on the list of trusted
+                     certifiers sent by the client in the PA-PK-AS-REQ.
+                     This field may be empty if the client did not send
+                     to the KDC a list of trusted certifiers (the
+                     trustedCertifiers field was empty, meaning that the
+                     client already possesses the KDC's certificate).
+
+                iii.  The signerInfos field is a SET that must contain at
+                      least one member, since it contains the actual
+                      signature.
+
+    ReplyKeyPack ::= SEQUENCE {
+                              -- not used for Diffie-Hellman
+        replyKey             [0] EncryptionKey,
+                                 -- used to encrypt main reply
+                                 -- ENCTYPE is at least as strong as
+                                 -- ENCTYPE of session key
+        nonce                [1] INTEGER,
+                                 -- binds response to the request
+                                 -- must be same as the nonce
+                                 -- passed in the PKAuthenticator
+    }
+
+    Since each certifier in the certification path of a user's
+    certificate is equivalent to a separate Kerberos realm, the name
+    of each certifier in the certificate chain must be added to the
+    transited field of the ticket.  The format of these realm names is
+    defined in Section 3.1 of this document.  If applicable, the
+    transit-policy-checked flag should be set in the issued ticket.
+
+    The KDC's certificate(s) must bind the public key(s) of the KDC to
+    a name derivable from the name of the realm for that KDC.  X.509
+    certificates shall contain the principal name of the KDC
+    (defined in section 8.2 of RFC 1510) as the SubjectAltName version
+    3 extension. Below is the definition of this version 3 extension,
+    as specified by the X.509 standard:
+
+        subjectAltName EXTENSION ::= {
+            SYNTAX GeneralNames
+            IDENTIFIED BY id-ce-subjectAltName
+        }
+
+        GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
+
+        GeneralName ::= CHOICE {
+            otherName       [0] OtherName,
+            ...
+        }
+
+        OtherName ::= SEQUENCE {
+            type-id         OBJECT IDENTIFIER,
+            value           [0] EXPLICIT ANY DEFINED BY type-id
+        }
+
+    For the purpose of specifying a Kerberos principal name, the value
+    in OtherName shall be a KerberosName as defined in RFC 1510, but with
+    the PrincipalName replaced by CertPrincipalName as mentioned in
+    Section 3.1:
+
+        KerberosName ::= SEQUENCE {
+            realm           [0] Realm,
+            principalName   [1] CertPrincipalName  -- defined above
+        }
+
+    This specific syntax is identified within subjectAltName by setting
+    the type-id in OtherName to krb5PrincipalName, where (from the
+    Kerberos specification) we have
+
+        krb5 OBJECT IDENTIFIER ::= { iso (1)
+                                     org (3)
+                                     dod (6)
+                                     internet (1)
+                                     security (5)
+                                     kerberosv5 (2) }
+
+        krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
+
+    (This specification may also be used to specify a Kerberos name
+    within the user's certificate.)  The KDC's certificate may be signed
+    directly by a CA, or there may be intermediaries if the server resides
+    within a large organization, or it may be unsigned if the client
+    indicates possession (and trust) of the KDC's certificate.
+
+    The client then extracts the random key used to encrypt the main
+    reply.  This random key (in encPaReply) is encrypted with either the
+    client's public key or with a key derived from the DH values
+    exchanged between the client and the KDC.  The client uses this
+    random key to decrypt the main reply, and subsequently proceeds as
+    described in RFC 1510.
+
+3.2.3. Required Algorithms
+
+    Not all of the algorithms in the PKINIT protocol specification have
+    to be implemented in order to comply with the proposed standard.
+    Below is a list of the required algorithms:
+
+    * Diffie-Hellman public/private key pairs
+        * utilizing Diffie-Hellman ephemeral-ephemeral mode
+    * SHA1 digest and DSA for signatures
+    * SHA1 digest also for the Checksum in the PKAuthenticator
+    * 3-key triple DES keys derived from the Diffie-Hellman Exchange
+    * 3-key triple DES Temporary and Reply keys
+
+4.  Logistics and Policy
+
+    This section describes a way to define the policy on the use of
+    PKINIT for each principal and request.
+
+    The KDC is not required to contain a database record for users
+    who use public key authentication.  However, if these users are
+    registered with the KDC, it is recommended that the database record
+    for these users be modified to an additional flag in the attributes
+    field to indicate that the user should authenticate using PKINIT.
+    If this flag is set and a request message does not contain the
+    PKINIT preauthentication field, then the KDC sends back as error of
+    type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
+    field of type PA-PK-AS-REQ must be included in the request.
+
+5.  Security Considerations
+
+    PKINIT raises a few security considerations, which we will address
+    in this section.
+
+    First of all, PKINIT introduces a new trust model, where KDCs do not
+    (necessarily) certify the identity of those for whom they issue
+    tickets.  PKINIT does allow KDCs to act as their own CAs, in the
+    limited capacity of self-signing their certificates, but one of the
+    additional benefits is to align Kerberos authentication with a global
+    public key infrastructure.  Anyone using PKINIT in this way must be
+    aware of how the certification infrastructure they are linking to
+    works.
+
+    Secondly, PKINIT also introduces the possibility of interactions
+    between different cryptosystems, which may be of widely varying
+    strengths.  Many systems, for instance, allow the use of 512-bit
+    public keys.  Using such keys to wrap data encrypted under strong
+    conventional cryptosystems, such as triple-DES, is inappropriate;
+    it adds a weak link to a strong one at extra cost.  Implementors
+    and administrators should take care to avoid such wasteful and
+    deceptive interactions.
+
+    Lastly, PKINIT calls for randomly generated keys for conventional
+    cryptosystems.  Many such systems contain systematically "weak"
+    keys.  PKINIT implementations MUST avoid use of these keys, either
+    by discarding those keys when they are generated, or by fixing them
+    in some way (e.g., by XORing them with a given mask).  These
+    precautions vary from system to system; it is not our intention to
+    give an explicit recipe for them here.
+
+6.  Transport Issues
+
+    Certificate chains can potentially grow quite large and span several
+    UDP packets; this in turn increases the probability that a Kerberos
+    message involving PKINIT extensions will be broken in transit.  In
+    light of the possibility that the Kerberos specification will
+    require KDCs to accept requests using TCP as a transport mechanism,
+    we make the same recommendation with respect to the PKINIT
+    extensions as well.
+
+7.  Bibliography
+
+    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
+    (V5).  Request for Comments 1510.
+
+    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
+    for Computer Networks, IEEE Communications, 32(9):33-38.  September
+    1994.
+
+    [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
+    A. Medvinsky, M. Hur.  Public Key Cryptography for Cross-Realm
+    Authentication in Kerberos.  draft-ietf-cat-kerberos-pk-cross-04.txt
+
+    [4] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
+    Kerberos.  draft-ietf-cat-kerberos-anoncred-00.txt
+
+    [5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman.
+    Public Key Utilizing Tickets for Application Servers (PKTAPP).
+    draft-ietf-cat-pktapp-02.txt
+
+    [6] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
+    Using Public Key Cryptography.  Symposium On Network and Distributed
+    System Security, 1997.
+
+    [7] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
+    Protocol.  In Proceedings of the USENIX Workshop on Electronic
+    Commerce, July 1995.
+
+    [8] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
+    Request for Comments 2246, January 1999.
+
+    [9] B.C. Neuman, Proxy-Based Authorization and Accounting for
+    Distributed Systems.  In Proceedings of the 13th International
+    Conference on Distributed Computing Systems, May 1993.
+
+    [10] ITU-T (formerly CCITT) Information technology - Open Systems
+    Interconnection - The Directory: Authentication Framework
+    Recommendation X.509 ISO/IEC 9594-8
+
+    [11] R. Housley. Cryptographic Message Syntax.
+    draft-ietf-smime-cms-13.txt, April 1999, approved for publication
+    as RFC.
+
+    [12] PKCS #7: Cryptographic Message Syntax Standard,
+    An RSA Laboratories Technical Note Version 1.5
+    Revised November 1, 1993
+
+    [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
+    Security, Inc. A Description of the RC2(r) Encryption Algorithm
+    March 1998.
+    Request for Comments 2268.
+
+    [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
+    Protocol (v3): UTF-8 String Representation of Distinguished Names.
+    Request for Comments 2253.
+
+    [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
+    Key Infrastructure, Certificate and CRL Profile, January 1999.
+    Request for Comments 2459.
+
+    [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
+    Specifications, October 1998.  Request for Comments 2437.
+
+    [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.  S/MIME
+    Version 2 Certificate Handling, March 1998.  Request for
+    Comments 2312.
+
+    [18] M. Wahl, T. Howes, S. Kille.  Lightweight Directory Access
+    Protocol (v3), December 1997.  Request for Comments 2251.
+
+    [19] ITU-T (formerly CCITT) Information Processing Systems - Open
+    Systems Interconnection - Specification of Abstract Syntax Notation
+    One (ASN.1) Rec. X.680 ISO/IEC 8824-1
+
+    [20] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
+    Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
+
+8.  Acknowledgements
+
+    Some of the ideas on which this proposal is based arose during
+    discussions over several years between members of the SAAG, the IETF
+    CAT working group, and the PSRG, regarding integration of Kerberos
+    and SPX.  Some ideas have also been drawn from the DASS system.
+    These changes are by no means endorsed by these groups.  This is an
+    attempt to revive some of the goals of those groups, and this
+    proposal approaches those goals primarily from the Kerberos
+    perspective.  Lastly, comments from groups working on similar ideas
+    in DCE have been invaluable.
+
+9.  Expiration Date
+
+    This draft expires January 15, 2001.
+
+10. Authors
+
+    Brian Tung
+    Clifford Neuman
+    USC Information Sciences Institute
+    4676 Admiralty Way Suite 1001
+    Marina del Rey CA 90292-6695
+    Phone: +1 310 822 1511
+    E-mail: {brian, bcn}@isi.edu
+
+    Matthew Hur
+    CyberSafe Corporation
+    1605 NW Sammamish Road
+    Issaquah WA 98027-5378
+    Phone: +1 425 391 6000
+    E-mail: matt.hur@cybersafe.com
+
+    Ari Medvinsky
+    Keen.com, Inc.
+    150 Independence Drive
+    Menlo Park CA 94025
+    Phone: +1 650 289 3134
+    E-mail: ari@keen.com
+
+    Sasha Medvinsky
+    Motorola
+    6450 Sequence Drive
+    San Diego, CA 92121
+    +1 858 404 2367
+    E-mail: smedvinsky@gi.com
+
+    John Wray
+    Iris Associates, Inc.
+    5 Technology Park Dr.
+    Westford, MA 01886
+    E-mail: John_Wray@iris.com
+
+    Jonathan Trostle
+    170 W. Tasman Dr.
+    San Jose, CA 95134
+    E-mail: jtrostle@cisco.com
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt
new file mode 100644
index 000000000000..6581dd5810a5
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt
@@ -0,0 +1,378 @@
+INTERNET-DRAFT                                    Ari Medvinsky
+draft-ietf-cat-kerberos-pk-tapp-03.txt            Keen.com, Inc.
+Expires January 14, 2001                          Matthew Hur
+Informational					  CyberSafe Corporation
+						  Sasha Medvinsky
+						  Motorola
+                                                  Clifford Neuman
+                                                  USC/ISI
+
+Public Key Utilizing Tickets for Application Servers (PKTAPP)
+
+
+0. Status Of this Memo
+
+This document is an Internet-Draft and is in full conformance with
+all provisions of Section 10 of RFC 2026.  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.
+
+To learn the current status of any Internet-Draft, please check
+the "1id-abstracts.txt" listing contained in the Internet-Drafts
+Shadow Directories on ftp.ietf.org (US East Coast),
+nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
+munnari.oz.au (Pacific Rim).
+
+The distribution of this memo is unlimited.  It is filed as
+draft-ietf-cat-kerberos-pk-init-10.txt, and expires April 30,
+2000.  Please send comments to the authors.
+
+1. Abstract
+
+Public key based Kerberos for Distributed Authentication[1], (PKDA) 
+proposed by Sirbu & Chuang, describes PK based authentication that 
+eliminates the use of a centralized key distribution center while 
+retaining the advantages of Kerberos tickets.  This draft describes how, 
+without any modification, the PKINIT specification[2] may be used to 
+implement the ideas introduced in PKDA.  The benefit is that only a 
+single PK Kerberos extension is needed to address the goals of PKINIT & 
+PKDA.
+
+
+
+2. Introduction
+
+With the proliferation of public key cryptography, a number of public 
+key extensions to Kerberos have been proposed to provide 
+interoperability with the PK infrastructure and to improve the Kerberos 
+authentication system [4].  Among these are PKINIT[2] (under development
+in the CAT working group) and more recently PKDA [1] proposed by Sirbu & 
+Chuang of CMU.  One of the principal goals of PKINIT is to provide for 
+interoperability between a PK infrastructure and Kerberos.  Using 
+PKINIT, a user can authenticate to the KDC via a public key certificate.  
+A ticket granting ticket (TGT), returned by the KDC, enables a PK user 
+to obtain tickets and authenticate to kerberized services.  The PKDA 
+proposal goes a step further.  It supports direct client to server 
+authentication, eliminating the need for an online key distribution 
+center.  In this draft, we describe how, without any modification, the 
+PKINIT protocol may be applied to achieve the goals of PKDA. For direct 
+client to server authentication, the client will use PKINIT to 
+authenticate to the end server (instead of a central KDC), which then, 
+will issue a ticket for itself.  The benefit of this proposal, is that a 
+single PK extension to Kerberos can addresses the goals of PKINIT and 
+PKDA.
+
+
+3. PKDA background
+
+The PKDA proposal provides direct client to server authentication, thus 
+eliminating the need for an online key distribution center.  A client 
+and server take part in an initial PK based authentication exchange, 
+with an added caveat that the server acts as a Kerberos ticket granting 
+service and issues a traditional Kerberos ticket for itself.  In 
+subsequent communication, the client makes use of the Kerberos ticket, 
+thus eliminating the need for public key operations on the server.  This 
+approach has an advantage over SSL in that the server does not need to 
+save state (cache session keys).  Furthermore, an additional benefit, is 
+that Kerberos tickets can facilitate delegation (see Neuman[3]). 
+
+Below is a brief overview of the PKDA protocol.  For a more detailed 
+description see [1]. 
+
+SCERT_REQ: Client to Server
+The client requests a certificate from the server.  If the serverÆs 
+certificate is cached locally, SCERT_REQ and SCERT_REP are omitted.
+
+SCERT_REP:  Server to Client
+The server returns its certificate to the client.
+
+PKTGS_REQ: Client to Server
+The client sends a request for a service ticket to the server.  To 
+authenticate the request, the client signs, among other fields, a time 
+stamp and a newly generated symmetric key .  The time stamp is used to 
+foil replay attacks;  the symmetric key is used by the server to secure 
+the PKTGS_REP message. 
+The client provides a certificate in the request (the certificate 
+enables the server to verify the validity of the clientÆs signature) and 
+seals it along with the signed information using the serverÆs public 
+key.  
+
+ 
+PKTGS_REP:  Server to Client
+The server returns a service ticket (which it issued for itself) along 
+with the session key for the ticket.  The session key is protected by 
+the client-generated key from the PKTGS_REQ message.  
+
+AP_REQ:  Client to Server
+After the above exchange, the client can proceed in a normal fashion, 
+using the conventional Kerberos ticket in an AP_REQ message.
+
+
+4. PKINIT background
+
+One of the principal goals of PKINIT is to provide for interoperability 
+between a public key infrastructure and Kerberos.  Using a public key 
+certificate, a client can authenticate to the KDC and receive a TGT 
+which enables the client to obtain service tickets to kerberized 
+services..  In PKINIT, the AS-REQ and AS-REP messages remain the same; 
+new preauthentication data types are used to conduct the PK exchange.  
+Client and server certificates are exchanged via the preauthentication 
+data.  Thus, the exchange of certificates , PK authentication, and 
+delivery of a TGT can occur in two messages.
+
+Below is a brief overview of the PKINIT protocol.  For a more detailed 
+description see [2]. 
+
+PreAuthentication data of AS-REQ:  Client to Server
+The client sends a list of trusted certifiers, a signed PK 
+authenticator, and its certificate.  The PK authenticator, based on the 
+Kerberos authenticator, contains the name of the KDC, a timestamp, and a 
+nonce.
+
+PreAuthentication data of AS-REP:  Server to Client
+The server responds with its certificate and the key used for decrypting 
+the encrypted part of the AS-REQ.  This key is encrypted with the 
+clientÆs public key.
+
+AP_REQ:  Client to Server
+After the above exchange, the client can proceed in a normal fashion, 
+using the conventional Kerberos ticket in an AP_REQ message.
+
+
+5. Application of PKINIT to achieve equivalence to PKDA
+
+While PKINIT is normally used to retrieve a ticket granting ticket 
+(TGT), it may also be used to request an end service ticket.  When used 
+in this fashion, PKINIT is functionally equivalent to PKDA.  We 
+introduce the concept of a local ticket granting server (LTGS) to 
+illustrate how PKINIT may be used for issuing end service tickets based 
+on public key authentication.  It is important to note that the LTGS may 
+be built into an application server, or it may be a stand-alone server 
+used for issuing tickets within a well-defined realm, such as a single 
+machine.  We will discuss both of these options.
+
+
+5.1. The LTGS
+
+The LTGS processes the Kerberos AS-REQ and AS-REP messages with PKINIT 
+preauthentication data.  When a client submits an AS-REQ to the LTGS, it
+specifies an application server, in order to receive an end service 
+ticket instead of a TGT.
+
+
+5.1.1. The LTGS as a standalone server
+
+The LTGS may run as a separate process that serves applications which 
+reside on the same machine. This serves to consolidate administrative 
+functions and provide an easier migration path for a heterogeneous 
+environment consisting of both public key and Kerberos.  The LTGS would 
+use one well-known port (port #88 - same as the KDC) for all message 
+traffic and would share a symmetric with each service.  After the client 
+receives a service ticket, it then contacts the application server 
+directly.  This approach is similar to the one suggested by Sirbu , et 
+al [1].
+
+5.1.1.1. Ticket Policy for PKTAPP Clients
+
+It is desirable for the LTGS to have access to a PKTAPP client ticket
+policy. This policy will contain information for each client, such as 
+the maximum lifetime of a ticket, whether or not a ticket can be 
+forwardable, etc. PKTAPP clients, however, use the PKINIT protocol for
+authentication and are not required to be registered as Kerberos 
+principals.
+
+As one possible solution, each public key Certification Authority could
+be registered in a secure database, along with the ticket policy 
+information for all PKTAPP clients that are certified by this
+Certification Authority.
+
+5.1.1.2. LTGS as a Kerberos Principal
+
+Since the LTGS serves only PKTAPP clients and returns only end service
+tickets for other services, it does not require a Kerberos service key 
+or a Kerberos principal identity. It is therefore not necessary for the
+LTGS to even be registered as a Kerberos principal.
+
+The LTGS still requires public key credentials for the PKINIT exchange,
+and it may be desired to have some global restrictions on the Kerberos
+tickets that it can issue. It is recommended (but not required) that
+this information be associated with a Kerberos principal entry for the
+LTGS.
+
+
+5.1.1.3. Kerberos Principal Database
+
+Since the LTGS issues tickets for Kerberos services, it will require
+access to a Kerberos principal database containing entries for at least
+the end services. Each entry must contain a service key and may also
+contain restrictions on the service tickets that are issued to clients.
+It is recommended that (for ease of administration) this principal
+database be centrally administered and distributed (replicated) to all
+hosts where an LTGS may be running.
+
+In the case that there are other clients that do not support PKINIT
+protocol, but still need access to the same Kerberos services, this
+principal database will also require entries for Kerberos clients and
+for the TGS entries.
+
+5.1.2. The LTGS as part of an application server
+
+The LTGS may be combined with an application server.  This accomplishes 
+direct client to application server authentication; however, it requires 
+that applications be modified to process AS-REQ and AS-REP messages.  
+The LTGS would communicate over the port assigned to the application 
+server or over the well known Kerberos port for that particular 
+application.
+
+5.1.2.2. Ticket Policy for PKTAPP Clients
+
+Application servers normally do not have access to a distributed 
+principal database. Therefore, they will have to find another means of
+keeping track of the ticket policy information for PKTAPP clients. It is
+recommended that this ticket policy be kept in a directory service (such
+as LDAP).  
+
+It is critical, however, that both read and write access to this ticket
+policy is restricted with strong authentication and encryption to only
+the correct application server.  An unauthorized party should not have
+the authority to modify the ticket policy. Disclosing the ticket policy
+to a 3rd party may aid an adversary in determining the best way to
+compromise the network.
+
+It is just as critical for the application server to authenticate the
+directory service. Otherwise an adversary could use a man-in-the-middle
+attack to substitute a false ticket policy with a false directory
+service.
+
+5.1.2.3. LTGS Credentials
+
+Each LTGS (combined with an application service) will require public key
+credentials in order to use the PKINIT protocol. These credentials can 
+be stored in a single file that is both encrypted with a password-
+derived symmetric key and also secured by an operating system. This
+symmetric key may be stashed somewhere on the machine for convenience,
+although such practice potentially weakens the overall system security
+and is strongly discouraged.
+
+For added security, it is recommended that the LTGS private keys are
+stored inside a temper-resistant hardware module that requires a pin
+code for access.
+
+
+5.1.2.4. Compatibility With Standard Kerberos
+
+Even though an application server is combined with the LTGS, for
+backward compatibility it should still accept service tickets that have
+been issued by the KDC. This will allow Kerberos clients that do not
+support PKTAPP to authenticate to the same application server (with the
+help of a KDC).
+
+5.1.3. Cross-Realm Authentication
+
+According to the PKINIT draft, the client's realm is the X.500 name of
+the Certification Authority that issued the client certificate. A 
+Kerberos application service will be in a standard Kerberos realm, which
+implies that the LTGS will need to issue cross-realm end service 
+tickets. This is the only case, where cross-realm end service tickets
+are issued. In a standard Kerberos model, a client first acquires a
+cross-realm TGT, and then gets an end service ticket from the KDC that
+is in the same realm as the application service.
+
+6. Protocol differences between PKINIT and PKDA
+
+Both PKINIT and PKDA will accomplish the same goal of issuing end 
+service tickets, based on initial public key authentication.  A PKINIT-
+based implementation and a PKDA implementation would be functionally 
+equivalent.  The primary differences are that 1)PKDA requires the client 
+to create the symmetric key while PKINIT requires the server to create 
+the key and 2)PKINIT accomplishes in two messages what PKDA accomplishes 
+in four messages.
+
+7. Summary
+
+The PKINIT protocol can be used, without modification to facilitate 
+client to server authentication without the use of a central KDC.  The 
+approach described in this draft  (and originally proposed in PKDA[1]) 
+is essentially a public key authentication protocol that retains the 
+advantages of Kerberos tickets.
+
+Given that PKINIT has progressed through the CAT working group of the 
+IETF, with plans for non-commercial distribution (via MITÆs v5 Kerberos)  
+as well as commercial support, it is worthwhile to provide PKDA 
+functionality, under the PKINIT umbrella.
+
+8. Security Considerations
+
+PKTAPP is based on the PKINIT protocol and all security considerations
+already listed in [2] apply here.
+
+When the LTGS is implemented as part of each application server, the
+secure storage of its public key credentials and of its ticket policy
+are both a concern.  The respective security considerations are already
+covered in sections 5.1.2.3 and 5.1.2.2 of this document.  
+
+
+9. Bibliography
+
+[1] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos Using 
+Public Key Cryptography.  Symposium On Network and Distributed System 
+Security, 1997.
+
+[2] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
+J. Trostle.  Public Key Cryptography for Initial Authentication in
+Kerberos.  Internet Draft, October 1999. 
+(ftp://ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-10.txt)
+
+[3] C. Neuman, Proxy-Based Authorization and Accounting for 
+Distributed Systems.  In Proceedings of the 13th International 
+Conference on Distributed Computing Systems, May 1993.
+
+[4] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
+(V5).  Request for Comments 1510.
+
+10.  Expiration Date
+
+This draft expires April 24, 2000.
+
+11. Authors
+
+Ari Medvinsky
+Keen.com, Inc.
+150 Independence Dr.
+Menlo Park, CA 94025
+Phone +1 650 289 3134
+E-mail: ari@keen.com
+
+Matthew Hur
+CyberSafe Corporation
+1605 NW Sammamish Road
+Issaquah, WA 98027-5378
+Phone: +1 425 391 6000
+E-mail: matt.hur@cybersafe.com
+
+Alexander Medvinsky
+Motorola
+6450 Sequence Dr.
+San Diego, CA 92121
+Phone: +1 858 404 2367
+E-mail: smedvinsky@gi.com
+
+Clifford Neuman
+USC Information Sciences Institute
+4676 Admiralty Way Suite 1001
+Marina del Rey CA 90292-6695
+Phone: +1 310 822 1511
+E-mail: bcn@isi.edu
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt
new file mode 100644
index 000000000000..15921248c117
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt
@@ -0,0 +1,6866 @@
+INTERNET-DRAFT                                           Clifford Neuman
+                                                               John Kohl
+                                                           Theodore Ts'o
+                                                          March 10, 2000
+                                              Expires September 10, 2000
+
+The Kerberos Network Authentication Service (V5)
+draft-ietf-cat-kerberos-revisions-05.txt
+
+STATUS OF THIS MEMO
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC 2026. 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.
+
+To learn the current status of any Internet-Draft, please check the
+"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
+ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
+
+The distribution of this memo is unlimited. It is filed as
+draft-ietf-cat-kerberos-revisions-05.txt, and expires September 10, 2000.
+Please send comments to: krb-protocol@MIT.EDU
+
+ABSTRACT
+
+This document provides an overview and specification of Version 5 of the
+Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol
+and its intended use that require more detailed or clearer explanation than
+was provided in RFC1510. This document is intended to provide a detailed
+description of the protocol, suitable for implementation, together with
+descriptions of the appropriate use of protocol messages and fields within
+those messages.
+
+This document is not intended to describe Kerberos to the end user, system
+administrator, or application developer. Higher level papers describing
+Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88],
+are available elsewhere.
+
+OVERVIEW
+
+This INTERNET-DRAFT describes the concepts and model upon which the Kerberos
+network authentication system is based. It also specifies Version 5 of the
+Kerberos protocol.
+
+The motivations, goals, assumptions, and rationale behind most design
+decisions are treated cursorily; they are more fully described in a paper
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+available in IEEE communications [NT94] and earlier in the Kerberos portion
+of the Athena Technical Plan [MNSS87]. The protocols have been a proposed
+standard and are being considered for advancement for draft standard through
+the IETF standard process. Comments are encouraged on the presentation, but
+only minor refinements to the protocol as implemented or extensions that fit
+within current protocol framework will be considered at this time.
+
+Requests for addition to an electronic mailing list for discussion of
+Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU.
+This mailing list is gatewayed onto the Usenet as the group
+comp.protocols.kerberos. Requests for further information, including
+documents and code availability, may be sent to info-kerberos@MIT.EDU.
+
+BACKGROUND
+
+The Kerberos model is based in part on Needham and Schroeder's trusted
+third-party authentication protocol [NS78] and on modifications suggested by
+Denning and Sacco [DS81]. The original design and implementation of Kerberos
+Versions 1 through 4 was the work of two former Project Athena staff
+members, Steve Miller of Digital Equipment Corporation and Clifford Neuman
+(now at the Information Sciences Institute of the University of Southern
+California), along with Jerome Saltzer, Technical Director of Project
+Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other members
+of Project Athena have also contributed to the work on Kerberos.
+
+Version 5 of the Kerberos protocol (described in this document) has evolved
+from Version 4 based on new requirements and desires for features not
+available in Version 4. The design of Version 5 of the Kerberos protocol was
+led by Clifford Neuman and John Kohl with much input from the community. The
+development of the MIT reference implementation was led at MIT by John Kohl
+and Theodore T'so, with help and contributed code from many others. Since
+RFC1510 was issued, extensions and revisions to the protocol have been
+proposed by many individuals. Some of these proposals are reflected in this
+document. Where such changes involved significant effort, the document cites
+the contribution of the proposer.
+
+Reference implementations of both version 4 and version 5 of Kerberos are
+publicly available and commercial implementations have been developed and
+are widely used. Details on the differences between Kerberos Versions 4 and
+5 can be found in [KNT92].
+
+1. Introduction
+
+Kerberos provides a means of verifying the identities of principals, (e.g. a
+workstation user or a network server) on an open (unprotected) network. This
+is accomplished without relying on assertions by the host operating system,
+without basing trust on host addresses, without requiring physical security
+of all the hosts on the network, and under the assumption that packets
+traveling along the network can be read, modified, and inserted at will[1].
+Kerberos performs authentication under these conditions as a trusted
+third-party authentication service by using conventional (shared secret key
+[2] cryptography. Kerberos extensions have been proposed and implemented
+that provide for the use of public key cryptography during certain phases of
+the authentication protocol. These extensions provide for authentication of
+users registered with public key certification authorities, and allow the
+system to provide certain benefits of public key cryptography in situations
+where they are needed.
+
+The basic Kerberos authentication process proceeds as follows: A client
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+sends a request to the authentication server (AS) requesting 'credentials'
+for a given server. The AS responds with these credentials, encrypted in the
+client's key. The credentials consist of 1) a 'ticket' for the server and 2)
+a temporary encryption key (often called a "session key"). The client
+transmits the ticket (which contains the client's identity and a copy of the
+session key, all encrypted in the server's key) to the server. The session
+key (now shared by the client and server) is used to authenticate the
+client, and may optionally be used to authenticate the server. It may also
+be used to encrypt further communication between the two parties or to
+exchange a separate sub-session key to be used to encrypt further
+communication.
+
+Implementation of the basic protocol consists of one or more authentication
+servers running on physically secure hosts. The authentication servers
+maintain a database of principals (i.e., users and servers) and their secret
+keys. Code libraries provide encryption and implement the Kerberos protocol.
+In order to add authentication to its transactions, a typical network
+application adds one or two calls to the Kerberos library directly or
+through the Generic Security Services Application Programming Interface,
+GSSAPI, described in separate document. These calls result in the
+transmission of the necessary messages to achieve authentication.
+
+The Kerberos protocol consists of several sub-protocols (or exchanges).
+There are two basic methods by which a client can ask a Kerberos server for
+credentials. In the first approach, the client sends a cleartext request for
+a ticket for the desired server to the AS. The reply is sent encrypted in
+the client's secret key. Usually this request is for a ticket-granting
+ticket (TGT) which can later be used with the ticket-granting server (TGS).
+In the second method, the client sends a request to the TGS. The client uses
+the TGT to authenticate itself to the TGS in the same manner as if it were
+contacting any other application server that requires Kerberos
+authentication. The reply is encrypted in the session key from the TGT.
+Though the protocol specification describes the AS and the TGS as separate
+servers, they are implemented in practice as different protocol entry points
+within a single Kerberos server.
+
+Once obtained, credentials may be used to verify the identity of the
+principals in a transaction, to ensure the integrity of messages exchanged
+between them, or to preserve privacy of the messages. The application is
+free to choose whatever protection may be necessary.
+
+To verify the identities of the principals in a transaction, the client
+transmits the ticket to the application server. Since the ticket is sent "in
+the clear" (parts of it are encrypted, but this encryption doesn't thwart
+replay) and might be intercepted and reused by an attacker, additional
+information is sent to prove that the message originated with the principal
+to whom the ticket was issued. This information (called the authenticator)
+is encrypted in the session key, and includes a timestamp. The timestamp
+proves that the message was recently generated and is not a replay.
+Encrypting the authenticator in the session key proves that it was generated
+by a party possessing the session key. Since no one except the requesting
+principal and the server know the session key (it is never sent over the
+network in the clear) this guarantees the identity of the client.
+
+The integrity of the messages exchanged between principals can also be
+guaranteed using the session key (passed in the ticket and contained in the
+credentials). This approach provides detection of both replay attacks and
+message stream modification attacks. It is accomplished by generating and
+transmitting a collision-proof checksum (elsewhere called a hash or digest
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+function) of the client's message, keyed with the session key. Privacy and
+integrity of the messages exchanged between principals can be secured by
+encrypting the data to be passed using the session key contained in the
+ticket or the subsession key found in the authenticator.
+
+The authentication exchanges mentioned above require read-only access to the
+Kerberos database. Sometimes, however, the entries in the database must be
+modified, such as when adding new principals or changing a principal's key.
+This is done using a protocol between a client and a third Kerberos server,
+the Kerberos Administration Server (KADM). There is also a protocol for
+maintaining multiple copies of the Kerberos database. Neither of these
+protocols are described in this document.
+
+1.1. Cross-Realm Operation
+
+The Kerberos protocol is designed to operate across organizational
+boundaries. A client in one organization can be authenticated to a server in
+another. Each organization wishing to run a Kerberos server establishes its
+own 'realm'. The name of the realm in which a client is registered is part
+of the client's name, and can be used by the end-service to decide whether
+to honor a request.
+
+By establishing 'inter-realm' keys, the administrators of two realms can
+allow a client authenticated in the local realm to prove its identity to
+servers in other realms[3]. The exchange of inter-realm keys (a separate key
+may be used for each direction) registers the ticket-granting service of
+each realm as a principal in the other realm. A client is then able to
+obtain a ticket-granting ticket for the remote realm's ticket-granting
+service from its local realm. When that ticket-granting ticket is used, the
+remote ticket-granting service uses the inter-realm key (which usually
+differs from its own normal TGS key) to decrypt the ticket-granting ticket,
+and is thus certain that it was issued by the client's own TGS. Tickets
+issued by the remote ticket-granting service will indicate to the
+end-service that the client was authenticated from another realm.
+
+A realm is said to communicate with another realm if the two realms share an
+inter-realm key, or if the local realm shares an inter-realm key with an
+intermediate realm that communicates with the remote realm. An
+authentication path is the sequence of intermediate realms that are
+transited in communicating from one realm to another.
+
+Realms are typically organized hierarchically. Each realm shares a key with
+its parent and a different key with each child. If an inter-realm key is not
+directly shared by two realms, the hierarchical organization allows an
+authentication path to be easily constructed. If a hierarchical organization
+is not used, it may be necessary to consult a database in order to construct
+an authentication path between realms.
+
+Although realms are typically hierarchical, intermediate realms may be
+bypassed to achieve cross-realm authentication through alternate
+authentication paths (these might be established to make communication
+between two realms more efficient). It is important for the end-service to
+know which realms were transited when deciding how much faith to place in
+the authentication process. To facilitate this decision, a field in each
+ticket contains the names of the realms that were involved in authenticating
+the client.
+
+The application server is ultimately responsible for accepting or rejecting
+authentication and should check the transited field. The application server
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+may choose to rely on the KDC for the application server's realm to check
+the transited field. The application server's KDC will set the
+TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate
+realms may also check the transited field as they issue
+ticket-granting-tickets for other realms, but they are encouraged not to do
+so. A client may request that the KDC's not check the transited field by
+setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not
+required to honor this flag.
+
+1.2. Authorization
+
+As an authentication service, Kerberos provides a means of verifying the
+identity of principals on a network. Authentication is usually useful
+primarily as a first step in the process of authorization, determining
+whether a client may use a service, which objects the client is allowed to
+access, and the type of access allowed for each. Kerberos does not, by
+itself, provide authorization. Possession of a client ticket for a service
+provides only for authentication of the client to that service, and in the
+absence of a separate authorization procedure, it should not be considered
+by an application as authorizing the use of that service.
+
+Such separate authorization methods may be implemented as application
+specific access control functions and may be based on files such as the
+application server, or on separately issued authorization credentials such
+as those based on proxies [Neu93], or on other authorization services.
+Separately authenticated authorization credentials may be embedded in a
+tickets authorization data when encapsulated by the kdc-issued authorization
+data element.
+
+Applications should not be modified to accept the mere issuance of a service
+ticket by the Kerberos server (even by a modified Kerberos server) as
+granting authority to use the service, since such applications may become
+vulnerable to the bypass of this authorization check in an environment if
+they interoperate with other KDCs or where other options for application
+authentication (e.g. the PKTAPP proposal) are provided.
+
+1.3. Environmental assumptions
+
+Kerberos imposes a few assumptions on the environment in which it can
+properly function:
+
+   * 'Denial of service' attacks are not solved with Kerberos. There are
+     places in these protocols where an intruder can prevent an application
+     from participating in the proper authentication steps. Detection and
+     solution of such attacks (some of which can appear to be nnot-uncommon
+     'normal' failure modes for the system) is usually best left to the
+     human administrators and users.
+   * Principals must keep their secret keys secret. If an intruder somehow
+     steals a principal's key, it will be able to masquerade as that
+     principal or impersonate any server to the legitimate principal.
+   * 'Password guessing' attacks are not solved by Kerberos. If a user
+     chooses a poor password, it is possible for an attacker to successfully
+     mount an offline dictionary attack by repeatedly attempting to decrypt,
+     with successive entries from a dictionary, messages obtained which are
+     encrypted under a key derived from the user's password.
+   * Each host on the network must have a clock which is 'loosely
+     synchronized' to the time of the other hosts; this synchronization is
+     used to reduce the bookkeeping needs of application servers when they
+     do replay detection. The degree of "looseness" can be configured on a
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     per-server basis, but is typically on the order of 5 minutes. If the
+     clocks are synchronized over the network, the clock synchronization
+     protocol must itself be secured from network attackers.
+   * Principal identifiers are not recycled on a short-term basis. A typical
+     mode of access control will use access control lists (ACLs) to grant
+     permissions to particular principals. If a stale ACL entry remains for
+     a deleted principal and the principal identifier is reused, the new
+     principal will inherit rights specified in the stale ACL entry. By not
+     re-using principal identifiers, the danger of inadvertent access is
+     removed.
+
+1.4. Glossary of terms
+
+Below is a list of terms used throughout this document.
+
+Authentication
+     Verifying the claimed identity of a principal.
+Authentication header
+     A record containing a Ticket and an Authenticator to be presented to a
+     server as part of the authentication process.
+Authentication path
+     A sequence of intermediate realms transited in the authentication
+     process when communicating from one realm to another.
+Authenticator
+     A record containing information that can be shown to have been recently
+     generated using the session key known only by the client and server.
+Authorization
+     The process of determining whether a client may use a service, which
+     objects the client is allowed to access, and the type of access allowed
+     for each.
+Capability
+     A token that grants the bearer permission to access an object or
+     service. In Kerberos, this might be a ticket whose use is restricted by
+     the contents of the authorization data field, but which lists no
+     network addresses, together with the session key necessary to use the
+     ticket.
+Ciphertext
+     The output of an encryption function. Encryption transforms plaintext
+     into ciphertext.
+Client
+     A process that makes use of a network service on behalf of a user. Note
+     that in some cases a Server may itself be a client of some other server
+     (e.g. a print server may be a client of a file server).
+Credentials
+     A ticket plus the secret session key necessary to successfully use that
+     ticket in an authentication exchange.
+KDC
+     Key Distribution Center, a network service that supplies tickets and
+     temporary session keys; or an instance of that service or the host on
+     which it runs. The KDC services both initial ticket and ticket-granting
+     ticket requests. The initial ticket portion is sometimes referred to as
+     the Authentication Server (or service). The ticket-granting ticket
+     portion is sometimes referred to as the ticket-granting server (or
+     service).
+Kerberos
+     Aside from the 3-headed dog guarding Hades, the name given to Project
+     Athena's authentication service, the protocol used by that service, or
+     the code used to implement the authentication service.
+Plaintext
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     The input to an encryption function or the output of a decryption
+     function. Decryption transforms ciphertext into plaintext.
+Principal
+     A uniquely named client or server instance that participates in a
+     network communication.
+Principal identifier
+     The name used to uniquely identify each different principal.
+Seal
+     To encipher a record containing several fields in such a way that the
+     fields cannot be individually replaced without either knowledge of the
+     encryption key or leaving evidence of tampering.
+Secret key
+     An encryption key shared by a principal and the KDC, distributed
+     outside the bounds of the system, with a long lifetime. In the case of
+     a human user's principal, the secret key is derived from a password.
+Server
+     A particular Principal which provides a resource to network clients.
+     The server is sometimes refered to as the Application Server.
+Service
+     A resource provided to network clients; often provided by more than one
+     server (for example, remote file service).
+Session key
+     A temporary encryption key used between two principals, with a lifetime
+     limited to the duration of a single login "session".
+Sub-session key
+     A temporary encryption key used between two principals, selected and
+     exchanged by the principals using the session key, and with a lifetime
+     limited to the duration of a single association.
+Ticket
+     A record that helps a client authenticate itself to a server; it
+     contains the client's identity, a session key, a timestamp, and other
+     information, all sealed using the server's secret key. It only serves
+     to authenticate a client when presented along with a fresh
+     Authenticator.
+
+2. Ticket flag uses and requests
+
+Each Kerberos ticket contains a set of flags which are used to indicate
+various attributes of that ticket. Most flags may be requested by a client
+when the ticket is obtained; some are automatically turned on and off by a
+Kerberos server as required. The following sections explain what the various
+flags mean, and gives examples of reasons to use such a flag.
+
+2.1. Initial and pre-authenticated tickets
+
+The INITIAL flag indicates that a ticket was issued using the AS protocol
+and not issued based on a ticket-granting ticket. Application servers that
+want to require the demonstrated knowledge of a client's secret key (e.g. a
+password-changing program) can insist that this flag be set in any tickets
+they accept, and thus be assured that the client's key was recently
+presented to the application client.
+
+The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the
+initial authentication, regardless of whether the current ticket was issued
+directly (in which case INITIAL will also be set) or issued on the basis of
+a ticket-granting ticket (in which case the INITIAL flag is clear, but the
+PRE-AUTHENT and HW-AUTHENT flags are carried forward from the
+ticket-granting ticket).
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+2.2. Invalid tickets
+
+The INVALID flag indicates that a ticket is invalid. Application servers
+must reject tickets which have this flag set. A postdated ticket will
+usually be issued in this form. Invalid tickets must be validated by the KDC
+before use, by presenting them to the KDC in a TGS request with the VALIDATE
+option specified. The KDC will only validate tickets after their starttime
+has passed. The validation is required so that postdated tickets which have
+been stolen before their starttime can be rendered permanently invalid
+(through a hot-list mechanism) (see section 3.3.3.1).
+
+2.3. Renewable tickets
+
+Applications may desire to hold tickets which can be valid for long periods
+of time. However, this can expose their credentials to potential theft for
+equally long periods, and those stolen credentials would be valid until the
+expiration time of the ticket(s). Simply using short-lived tickets and
+obtaining new ones periodically would require the client to have long-term
+access to its secret key, an even greater risk. Renewable tickets can be
+used to mitigate the consequences of theft. Renewable tickets have two
+"expiration times": the first is when the current instance of the ticket
+expires, and the second is the latest permissible value for an individual
+expiration time. An application client must periodically (i.e. before it
+expires) present a renewable ticket to the KDC, with the RENEW option set in
+the KDC request. The KDC will issue a new ticket with a new session key and
+a later expiration time. All other fields of the ticket are left unmodified
+by the renewal process. When the latest permissible expiration time arrives,
+the ticket expires permanently. At each renewal, the KDC may consult a
+hot-list to determine if the ticket had been reported stolen since its last
+renewal; it will refuse to renew such stolen tickets, and thus the usable
+lifetime of stolen tickets is reduced.
+
+The RENEWABLE flag in a ticket is normally only interpreted by the
+ticket-granting service (discussed below in section 3.3). It can usually be
+ignored by application servers. However, some particularly careful
+application servers may wish to disallow renewable tickets.
+
+If a renewable ticket is not renewed by its expiration time, the KDC will
+not renew the ticket. The RENEWABLE flag is reset by default, but a client
+may request it be set by setting the RENEWABLE option in the KRB_AS_REQ
+message. If it is set, then the renew-till field in the ticket contains the
+time after which the ticket may not be renewed.
+
+2.4. Postdated tickets
+
+Applications may occasionally need to obtain tickets for use much later,
+e.g. a batch submission system would need tickets to be valid at the time
+the batch job is serviced. However, it is dangerous to hold valid tickets in
+a batch queue, since they will be on-line longer and more prone to theft.
+Postdated tickets provide a way to obtain these tickets from the KDC at job
+submission time, but to leave them "dormant" until they are activated and
+validated by a further request of the KDC. If a ticket theft were reported
+in the interim, the KDC would refuse to validate the ticket, and the thief
+would be foiled.
+
+The MAY-POSTDATE flag in a ticket is normally only interpreted by the
+ticket-granting service. It can be ignored by application servers. This flag
+must be set in a ticket-granting ticket in order to issue a postdated ticket
+based on the presented ticket. It is reset by default; it may be requested
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+by a client by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message.
+This flag does not allow a client to obtain a postdated ticket-granting
+ticket; postdated ticket-granting tickets can only by obtained by requesting
+the postdating in the KRB_AS_REQ message. The life (endtime-starttime) of a
+postdated ticket will be the remaining life of the ticket-granting ticket at
+the time of the request, unless the RENEWABLE option is also set, in which
+case it can be the full life (endtime-starttime) of the ticket-granting
+ticket. The KDC may limit how far in the future a ticket may be postdated.
+
+The POSTDATED flag indicates that a ticket has been postdated. The
+application server can check the authtime field in the ticket to see when
+the original authentication occurred. Some services may choose to reject
+postdated tickets, or they may only accept them within a certain period
+after the original authentication. When the KDC issues a POSTDATED ticket,
+it will also be marked as INVALID, so that the application client must
+present the ticket to the KDC to be validated before use.
+
+2.5. Proxiable and proxy tickets
+
+At times it may be necessary for a principal to allow a service to perform
+an operation on its behalf. The service must be able to take on the identity
+of the client, but only for a particular purpose. A principal can allow a
+service to take on the principal's identity for a particular purpose by
+granting it a proxy.
+
+The process of granting a proxy using the proxy and proxiable flags is used
+to provide credentials for use with specific services. Though conceptually
+also a proxy, user's wishing to delegate their identity for ANY purpose must
+use the ticket forwarding mechanism described in the next section to forward
+a ticket granting ticket.
+
+The PROXIABLE flag in a ticket is normally only interpreted by the
+ticket-granting service. It can be ignored by application servers. When set,
+this flag tells the ticket-granting server that it is OK to issue a new
+ticket (but not a ticket-granting ticket) with a different network address
+based on this ticket. This flag is set if requested by the client on initial
+authentication. By default, the client will request that it be set when
+requesting a ticket granting ticket, and reset when requesting any other
+ticket.
+
+This flag allows a client to pass a proxy to a server to perform a remote
+request on its behalf, e.g. a print service client can give the print server
+a proxy to access the client's files on a particular file server in order to
+satisfy a print request.
+
+In order to complicate the use of stolen credentials, Kerberos tickets are
+usually valid from only those network addresses specifically included in the
+ticket[4]. When granting a proxy, the client must specify the new network
+address from which the proxy is to be used, or indicate that the proxy is to
+be issued for use from any address.
+
+The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket.
+Application servers may check this flag and at their option they may require
+additional authentication from the agent presenting the proxy in order to
+provide an audit trail.
+
+2.6. Forwardable tickets
+
+Authentication forwarding is an instance of a proxy where the service is
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+granted complete use of the client's identity. An example where it might be
+used is when a user logs in to a remote system and wants authentication to
+work from that system as if the login were local.
+
+The FORWARDABLE flag in a ticket is normally only interpreted by the
+ticket-granting service. It can be ignored by application servers. The
+FORWARDABLE flag has an interpretation similar to that of the PROXIABLE
+flag, except ticket-granting tickets may also be issued with different
+network addresses. This flag is reset by default, but users may request that
+it be set by setting the FORWARDABLE option in the AS request when they
+request their initial ticket- granting ticket.
+
+This flag allows for authentication forwarding without requiring the user to
+enter a password again. If the flag is not set, then authentication
+forwarding is not permitted, but the same result can still be achieved if
+the user engages in the AS exchange specifying the requested network
+addresses and supplies a password.
+
+The FORWARDED flag is set by the TGS when a client presents a ticket with
+the FORWARDABLE flag set and requests a forwarded ticket by specifying the
+FORWARDED KDC option and supplying a set of addresses for the new ticket. It
+is also set in all tickets issued based on tickets with the FORWARDED flag
+set. Application servers may choose to process FORWARDED tickets differently
+than non-FORWARDED tickets.
+
+2.7. Other KDC options
+
+There are two additional options which may be set in a client's request of
+the KDC. The RENEWABLE-OK option indicates that the client will accept a
+renewable ticket if a ticket with the requested life cannot otherwise be
+provided. If a ticket with the requested life cannot be provided, then the
+KDC may issue a renewable ticket with a renew-till equal to the the
+requested endtime. The value of the renew-till field may still be adjusted
+by site-determined limits or limits imposed by the individual principal or
+server.
+
+The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service.
+It indicates that the ticket to be issued for the end server is to be
+encrypted in the session key from the a additional second ticket-granting
+ticket provided with the request. See section 3.3.3 for specific details.
+
+3. Message Exchanges
+
+The following sections describe the interactions between network clients and
+servers and the messages involved in those exchanges.
+
+3.1. The Authentication Service Exchange
+
+                          Summary
+      Message direction       Message type    Section
+      1. Client to Kerberos   KRB_AS_REQ      5.4.1
+      2. Kerberos to client   KRB_AS_REP or   5.4.2
+                              KRB_ERROR       5.9.1
+
+The Authentication Service (AS) Exchange between the client and the Kerberos
+Authentication Server is initiated by a client when it wishes to obtain
+authentication credentials for a given server but currently holds no
+credentials. In its basic form, the client's secret key is used for
+encryption and decryption. This exchange is typically used at the initiation
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+of a login session to obtain credentials for a Ticket-Granting Server which
+will subsequently be used to obtain credentials for other servers (see
+section 3.3) without requiring further use of the client's secret key. This
+exchange is also used to request credentials for services which must not be
+mediated through the Ticket-Granting Service, but rather require a
+principal's secret key, such as the password-changing service[5]. This
+exchange does not by itself provide any assurance of the the identity of the
+user[6].
+
+The exchange consists of two messages: KRB_AS_REQ from the client to
+Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
+messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
+
+In the request, the client sends (in cleartext) its own identity and the
+identity of the server for which it is requesting credentials. The response,
+KRB_AS_REP, contains a ticket for the client to present to the server, and a
+session key that will be shared by the client and the server. The session
+key and additional information are encrypted in the client's secret key. The
+KRB_AS_REP message contains information which can be used to detect replays,
+and to associate it with the message to which it replies. Various errors can
+occur; these are indicated by an error response (KRB_ERROR) instead of the
+KRB_AS_REP response. The error message is not encrypted. The KRB_ERROR
+message contains information which can be used to associate it with the
+message to which it replies. The lack of encryption in the KRB_ERROR message
+precludes the ability to detect replays, fabrications, or modifications of
+such messages.
+
+Without preautentication, the authentication server does not know whether
+the client is actually the principal named in the request. It simply sends a
+reply without knowing or caring whether they are the same. This is
+acceptable because nobody but the principal whose identity was given in the
+request will be able to use the reply. Its critical information is encrypted
+in that principal's key. The initial request supports an optional field that
+can be used to pass additional information that might be needed for the
+initial exchange. This field may be used for preauthentication as described
+in section [hl<>].
+
+3.1.1. Generation of KRB_AS_REQ message
+
+The client may specify a number of options in the initial request. Among
+these options are whether pre-authentication is to be performed; whether the
+requested ticket is to be renewable, proxiable, or forwardable; whether it
+should be postdated or allow postdating of derivative tickets; and whether a
+renewable ticket will be accepted in lieu of a non-renewable ticket if the
+requested ticket expiration date cannot be satisfied by a non-renewable
+ticket (due to configuration constraints; see section 4). See section A.1
+for pseudocode.
+
+The client prepares the KRB_AS_REQ message and sends it to the KDC.
+
+3.1.2. Receipt of KRB_AS_REQ message
+
+If all goes well, processing the KRB_AS_REQ message will result in the
+creation of a ticket for the client to present to the server. The format for
+the ticket is described in section 5.3.1. The contents of the ticket are
+determined as follows.
+
+3.1.3. Generation of KRB_AS_REP message
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+The authentication server looks up the client and server principals named in
+the KRB_AS_REQ in its database, extracting their respective keys. If
+required, the server pre-authenticates the request, and if the
+pre-authentication check fails, an error message with the code
+KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the
+requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP
+is returned. Otherwise it generates a 'random' session key[7].
+
+If there are multiple encryption keys registered for a client in the
+Kerberos database (or if the key registered supports multiple encryption
+types; e.g. DES-CBC-CRC and DES-CBC-MD5), then the etype field from the AS
+request is used by the KDC to select the encryption method to be used for
+encrypting the response to the client. If there is more than one supported,
+strong encryption type in the etype list, the first valid etype for which an
+encryption key is available is used. The encryption method used to respond
+to a TGS request is taken from the keytype of the session key found in the
+ticket granting ticket. [***I will change the example keytypes to be 3DES
+based examples 7/14***]
+
+When the etype field is present in a KDC request, whether an AS or TGS
+request, the KDC will attempt to assign the type of the random session key
+from the list of methods in the etype field. The KDC will select the
+appropriate type using the list of methods provided together with
+information from the Kerberos database indicating acceptable encryption
+methods for the application server. The KDC will not issue tickets with a
+weak session key encryption type.
+
+If the requested start time is absent, indicates a time in the past, or is
+within the window of acceptable clock skew for the KDC and the POSTDATE
+option has not been specified, then the start time of the ticket is set to
+the authentication server's current time. If it indicates a time in the
+future beyond the acceptable clock skew, but the POSTDATED option has not
+been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise
+the requested start time is checked against the policy of the local realm
+(the administrator might decide to prohibit certain types or ranges of
+postdated tickets), and if acceptable, the ticket's start time is set as
+requested and the INVALID flag is set in the new ticket. The postdated
+ticket must be validated before use by presenting it to the KDC after the
+start time has been reached.
+
+The expiration time of the ticket will be set to the minimum of the
+following:
+
+   * The expiration time (endtime) requested in the KRB_AS_REQ message.
+   * The ticket's start time plus the maximum allowable lifetime associated
+     with the client principal (the authentication server's database
+     includes a maximum ticket lifetime field in each principal's record;
+     see section 4).
+   * The ticket's start time plus the maximum allowable lifetime associated
+     with the server principal.
+   * The ticket's start time plus the maximum lifetime set by the policy of
+     the local realm.
+
+If the requested expiration time minus the start time (as determined above)
+is less than a site-determined minimum lifetime, an error message with code
+KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the
+ticket exceeds what was determined as above, and if the 'RENEWABLE-OK'
+option was requested, then the 'RENEWABLE' flag is set in the new ticket,
+and the renew-till value is set as if the 'RENEWABLE' option were requested
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+(the field and option names are described fully in section 5.4.1).
+
+If the RENEWABLE option has been requested or if the RENEWABLE-OK option has
+been set and a renewable ticket is to be issued, then the renew-till field
+is set to the minimum of:
+
+   * Its requested value.
+   * The start time of the ticket plus the minimum of the two maximum
+     renewable lifetimes associated with the principals' database entries.
+   * The start time of the ticket plus the maximum renewable lifetime set by
+     the policy of the local realm.
+
+The flags field of the new ticket will have the following options set if
+they have been requested and if the policy of the local realm allows:
+FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new
+ticket is post-dated (the start time is in the future), its INVALID flag
+will also be set.
+
+If all of the above succeed, the server formats a KRB_AS_REP message (see
+section 5.4.2), copying the addresses in the request into the caddr of the
+response, placing any required pre-authentication data into the padata of
+the response, and encrypts the ciphertext part in the client's key using the
+requested encryption method, and sends it to the client. See section A.2 for
+pseudocode.
+
+3.1.4. Generation of KRB_ERROR message
+
+Several errors can occur, and the Authentication Server responds by
+returning an error message, KRB_ERROR, to the client, with the error-code
+and e-text fields set to appropriate values. The error message contents and
+details are described in Section 5.9.1.
+
+3.1.5. Receipt of KRB_AS_REP message
+
+If the reply message type is KRB_AS_REP, then the client verifies that the
+cname and crealm fields in the cleartext portion of the reply match what it
+requested. If any padata fields are present, they may be used to derive the
+proper secret key to decrypt the message. The client decrypts the encrypted
+part of the response using its secret key, verifies that the nonce in the
+encrypted part matches the nonce it supplied in its request (to detect
+replays). It also verifies that the sname and srealm in the response match
+those in the request (or are otherwise expected values), and that the host
+address field is also correct. It then stores the ticket, session key, start
+and expiration times, and other information for later use. The
+key-expiration field from the encrypted part of the response may be checked
+to notify the user of impending key expiration (the client program could
+then suggest remedial action, such as a password change). See section A.3
+for pseudocode.
+
+Proper decryption of the KRB_AS_REP message is not sufficient to verify the
+identity of the user; the user and an attacker could cooperate to generate a
+KRB_AS_REP format message which decrypts properly but is not from the proper
+KDC. If the host wishes to verify the identity of the user, it must require
+the user to present application credentials which can be verified using a
+securely-stored secret key for the host. If those credentials can be
+verified, then the identity of the user can be assured.
+
+3.1.6. Receipt of KRB_ERROR message
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+If the reply message type is KRB_ERROR, then the client interprets it as an
+error and performs whatever application-specific tasks are necessary to
+recover.
+
+3.2. The Client/Server Authentication Exchange
+
+                             Summary
+Message direction                         Message type    Section
+Client to Application server              KRB_AP_REQ      5.5.1
+[optional] Application server to client   KRB_AP_REP or   5.5.2
+                                          KRB_ERROR       5.9.1
+
+The client/server authentication (CS) exchange is used by network
+applications to authenticate the client to the server and vice versa. The
+client must have already acquired credentials for the server using the AS or
+TGS exchange.
+
+3.2.1. The KRB_AP_REQ message
+
+The KRB_AP_REQ contains authentication information which should be part of
+the first message in an authenticated transaction. It contains a ticket, an
+authenticator, and some additional bookkeeping information (see section
+5.5.1 for the exact format). The ticket by itself is insufficient to
+authenticate a client, since tickets are passed across the network in
+cleartext[DS90], so the authenticator is used to prevent invalid replay of
+tickets by proving to the server that the client knows the session key of
+the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message is
+referred to elsewhere as the 'authentication header.'
+
+3.2.2. Generation of a KRB_AP_REQ message
+
+When a client wishes to initiate authentication to a server, it obtains
+(either through a credentials cache, the AS exchange, or the TGS exchange) a
+ticket and session key for the desired service. The client may re-use any
+tickets it holds until they expire. To use a ticket the client constructs a
+new Authenticator from the the system time, its name, and optionally an
+application specific checksum, an initial sequence number to be used in
+KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in
+negotiations for a session key unique to this particular session.
+Authenticators may not be re-used and will be rejected if replayed to a
+server[LGDSR87]. If a sequence number is to be included, it should be
+randomly chosen so that even after many messages have been exchanged it is
+not likely to collide with other sequence numbers in use.
+
+The client may indicate a requirement of mutual authentication or the use of
+a session-key based ticket by setting the appropriate flag(s) in the
+ap-options field of the message.
+
+The Authenticator is encrypted in the session key and combined with the
+ticket to form the KRB_AP_REQ message which is then sent to the end server
+along with any additional application-specific information. See section A.9
+for pseudocode.
+
+3.2.3. Receipt of KRB_AP_REQ message
+
+Authentication is based on the server's current time of day (clocks must be
+loosely synchronized), the authenticator, and the ticket. Several errors are
+possible. If an error occurs, the server is expected to reply to the client
+with a KRB_ERROR message. This message may be encapsulated in the
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+application protocol if its 'raw' form is not acceptable to the protocol.
+The format of error messages is described in section 5.9.1.
+
+The algorithm for verifying authentication information is as follows. If the
+message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE
+error. If the key version indicated by the Ticket in the KRB_AP_REQ is not
+one the server can use (e.g., it indicates an old key, and the server no
+longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is
+returned. If the USE-SESSION-KEY flag is set in the ap-options field, it
+indicates to the server that the ticket is encrypted in the session key from
+the server's ticket-granting ticket rather than its secret key[10]. Since it
+is possible for the server to be registered in multiple realms, with
+different keys in each, the srealm field in the unencrypted portion of the
+ticket in the KRB_AP_REQ is used to specify which secret key the server
+should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is
+returned if the server doesn't have the proper key to decipher the ticket.
+
+The ticket is decrypted using the version of the server's key specified by
+the ticket. If the decryption routines detect a modification of the ticket
+(each encryption system must provide safeguards to detect modified
+ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned
+(chances are good that different keys were used to encrypt and decrypt).
+
+The authenticator is decrypted using the session key extracted from the
+decrypted ticket. If decryption shows it to have been modified, the
+KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client
+from the ticket are compared against the same fields in the authenticator.
+If they don't match, the KRB_AP_ERR_BADMATCH error is returned (they might
+not match, for example, if the wrong session key was used to encrypt the
+authenticator). The addresses in the ticket (if any) are then searched for
+an address matching the operating-system reported address of the client. If
+no match is found or the server insists on ticket addresses but none are
+present in the ticket, the KRB_AP_ERR_BADADDR error is returned.
+
+If the local (server) time and the client time in the authenticator differ
+by more than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW
+error is returned. If the server name, along with the client name, time and
+microsecond fields from the Authenticator match any recently-seen such
+tuples, the KRB_AP_ERR_REPEAT error is returned[11]. The server must
+remember any authenticator presented within the allowable clock skew, so
+that a replay attempt is guaranteed to fail. If a server loses track of any
+authenticator presented within the allowable clock skew, it must reject all
+requests until the clock skew interval has passed. This assures that any
+lost or re-played authenticators will fall outside the allowable clock skew
+and can no longer be successfully replayed (If this is not done, an attacker
+could conceivably record the ticket and authenticator sent over the network
+to a server, then disable the client's host, pose as the disabled host, and
+replay the ticket and authenticator to subvert the authentication.). If a
+sequence number is provided in the authenticator, the server saves it for
+later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey is
+present, the server either saves it for later use or uses it to help
+generate its own choice for a subkey to be returned in a KRB_AP_REP message.
+
+The server computes the age of the ticket: local (server) time minus the
+start time inside the Ticket. If the start time is later than the current
+time by more than the allowable clock skew or if the INVALID flag is set in
+the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the
+current time is later than end time by more than the allowable clock skew,
+the KRB_AP_ERR_TKT_EXPIRED error is returned.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+If all these checks succeed without an error, the server is assured that the
+client possesses the credentials of the principal named in the ticket and
+thus, the client has been authenticated to the server. See section A.10 for
+pseudocode.
+
+Passing these checks provides only authentication of the named principal; it
+does not imply authorization to use the named service. Applications must
+make a separate authorization decisions based upon the authenticated name of
+the user, the requested operation, local acces control information such as
+that contained in a .k5login or .k5users file, and possibly a separate
+distributed authorization service.
+
+3.2.4. Generation of a KRB_AP_REP message
+
+Typically, a client's request will include both the authentication
+information and its initial request in the same message, and the server need
+not explicitly reply to the KRB_AP_REQ. However, if mutual authentication
+(not only authenticating the client to the server, but also the server to
+the client) is being performed, the KRB_AP_REQ message will have
+MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is
+required in response. As with the error message, this message may be
+encapsulated in the application protocol if its "raw" form is not acceptable
+to the application's protocol. The timestamp and microsecond field used in
+the reply must be the client's timestamp and microsecond field (as provided
+in the authenticator)[12]. If a sequence number is to be included, it should
+be randomly chosen as described above for the authenticator. A subkey may be
+included if the server desires to negotiate a different subkey. The
+KRB_AP_REP message is encrypted in the session key extracted from the
+ticket. See section A.11 for pseudocode.
+
+3.2.5. Receipt of KRB_AP_REP message
+
+If a KRB_AP_REP message is returned, the client uses the session key from
+the credentials obtained for the server[13] to decrypt the message, and
+verifies that the timestamp and microsecond fields match those in the
+Authenticator it sent to the server. If they match, then the client is
+assured that the server is genuine. The sequence number and subkey (if
+present) are retained for later use. See section A.12 for pseudocode.
+
+3.2.6. Using the encryption key
+
+After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server
+share an encryption key which can be used by the application. The 'true
+session key' to be used for KRB_PRIV, KRB_SAFE, or other
+application-specific uses may be chosen by the application based on the
+subkeys in the KRB_AP_REP message and the authenticator[14]. In some cases,
+the use of this session key will be implicit in the protocol; in others the
+method of use must be chosen from several alternatives. We leave the
+protocol negotiations of how to use the key (e.g. selecting an encryption or
+checksum type) to the application programmer; the Kerberos protocol does not
+constrain the implementation options, but an example of how this might be
+done follows.
+
+One way that an application may choose to negotiate a key to be used for
+subequent integrity and privacy protection is for the client to propose a
+key in the subkey field of the authenticator. The server can then choose a
+key using the proposed key from the client as input, returning the new
+subkey in the subkey field of the application reply. This key could then be
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+used for subsequent communication. To make this example more concrete, if
+the encryption method in use required a 56 bit key, and for whatever reason,
+one of the parties was prevented from using a key with more than 40 unknown
+bits, this method would allow the the party which is prevented from using
+more than 40 bits to either propose (if the client) an initial key with a
+known quantity for 16 of those bits, or to mask 16 of the bits (if the
+server) with the known quantity. The application implementor is warned,
+however, that this is only an example, and that an analysis of the
+particular crytosystem to be used, and the reasons for limiting the key
+length, must be made before deciding whether it is acceptable to mask bits
+of the key.
+
+With both the one-way and mutual authentication exchanges, the peers should
+take care not to send sensitive information to each other without proper
+assurances. In particular, applications that require privacy or integrity
+should use the KRB_AP_REP response from the server to client to assure both
+client and server of their peer's identity. If an application protocol
+requires privacy of its messages, it can use the KRB_PRIV message (section
+3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity.
+
+3.3. The Ticket-Granting Service (TGS) Exchange
+
+                          Summary
+      Message direction       Message type     Section
+      1. Client to Kerberos   KRB_TGS_REQ      5.4.1
+      2. Kerberos to client   KRB_TGS_REP or   5.4.2
+                              KRB_ERROR        5.9.1
+
+The TGS exchange between a client and the Kerberos Ticket-Granting Server is
+initiated by a client when it wishes to obtain authentication credentials
+for a given server (which might be registered in a remote realm), when it
+wishes to renew or validate an existing ticket, or when it wishes to obtain
+a proxy ticket. In the first case, the client must already have acquired a
+ticket for the Ticket-Granting Service using the AS exchange (the
+ticket-granting ticket is usually obtained when a client initially
+authenticates to the system, such as when a user logs in). The message
+format for the TGS exchange is almost identical to that for the AS exchange.
+The primary difference is that encryption and decryption in the TGS exchange
+does not take place under the client's key. Instead, the session key from
+the ticket-granting ticket or renewable ticket, or sub-session key from an
+Authenticator is used. As is the case for all application servers, expired
+tickets are not accepted by the TGS, so once a renewable or ticket-granting
+ticket expires, the client must use a separate exchange to obtain valid
+tickets.
+
+The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the
+client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or
+KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the
+client plus a request for credentials. The authentication information
+consists of the authentication header (KRB_AP_REQ) which includes the
+client's previously obtained ticket-granting, renewable, or invalid ticket.
+In the ticket-granting ticket and proxy cases, the request may include one
+or more of: a list of network addresses, a collection of typed authorization
+data to be sealed in the ticket for authorization use by the application
+server, or additional tickets (the use of which are described later). The
+TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the
+session key from the ticket-granting ticket or renewable ticket, or if
+present, in the sub-session key from the Authenticator (part of the
+authentication header). The KRB_ERROR message contains an error code and
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+text explaining what went wrong. The KRB_ERROR message is not encrypted. The
+KRB_TGS_REP message contains information which can be used to detect
+replays, and to associate it with the message to which it replies. The
+KRB_ERROR message also contains information which can be used to associate
+it with the message to which it replies, but the lack of encryption in the
+KRB_ERROR message precludes the ability to detect replays or fabrications of
+such messages.
+
+3.3.1. Generation of KRB_TGS_REQ message
+
+Before sending a request to the ticket-granting service, the client must
+determine in which realm the application server is registered[15]. If the
+client does not already possess a ticket-granting ticket for the appropriate
+realm, then one must be obtained. This is first attempted by requesting a
+ticket-granting ticket for the destination realm from a Kerberos server for
+which the client does posess a ticket-granting ticket (using the KRB_TGS_REQ
+message recursively). The Kerberos server may return a TGT for the desired
+realm in which case one can proceed. Alternatively, the Kerberos server may
+return a TGT for a realm which is 'closer' to the desired realm (further
+along the standard hierarchical path), in which case this step must be
+repeated with a Kerberos server in the realm specified in the returned TGT.
+If neither are returned, then the request must be retried with a Kerberos
+server for a realm higher in the hierarchy. This request will itself require
+a ticket-granting ticket for the higher realm which must be obtained by
+recursively applying these directions.
+
+Once the client obtains a ticket-granting ticket for the appropriate realm,
+it determines which Kerberos servers serve that realm, and contacts one. The
+list might be obtained through a configuration file or network service or it
+may be generated from the name of the realm; as long as the secret keys
+exchanged by realms are kept secret, only denial of service results from
+using a false Kerberos server.
+
+As in the AS exchange, the client may specify a number of options in the
+KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing
+an authentication header as an element of the padata field, and including
+the same fields as used in the KRB_AS_REQ message along with several
+optional fields: the enc-authorization-data field for application server use
+and additional tickets required by some options.
+
+In preparing the authentication header, the client can select a sub-session
+key under which the response from the Kerberos server will be encrypted[16].
+If the sub-session key is not specified, the session key from the
+ticket-granting ticket will be used. If the enc-authorization-data is
+present, it must be encrypted in the sub-session key, if present, from the
+authenticator portion of the authentication header, or if not present, using
+the session key from the ticket-granting ticket.
+
+Once prepared, the message is sent to a Kerberos server for the destination
+realm. See section A.5 for pseudocode.
+
+3.3.2. Receipt of KRB_TGS_REQ message
+
+The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ
+message, but there are many additional checks to be performed. First, the
+Kerberos server must determine which server the accompanying ticket is for
+and it must select the appropriate key to decrypt it. For a normal
+KRB_TGS_REQ message, it will be for the ticket granting service, and the
+TGS's key will be used. If the TGT was issued by another realm, then the
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+appropriate inter-realm key must be used. If the accompanying ticket is not
+a ticket granting ticket for the current realm, but is for an application
+server in the current realm, the RENEW, VALIDATE, or PROXY options are
+specified in the request, and the server for which a ticket is requested is
+the server named in the accompanying ticket, then the KDC will decrypt the
+ticket in the authentication header using the key of the server for which it
+was issued. If no ticket can be found in the padata field, the
+KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
+
+Once the accompanying ticket has been decrypted, the user-supplied checksum
+in the Authenticator must be verified against the contents of the request,
+and the message rejected if the checksums do not match (with an error code
+of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not
+collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the
+checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is
+returned. If the authorization-data are present, they are decrypted using
+the sub-session key from the Authenticator.
+
+If any of the decryptions indicate failed integrity checks, the
+KRB_AP_ERR_BAD_INTEGRITY error is returned.
+
+3.3.3. Generation of KRB_TGS_REP message
+
+The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP),
+but with its type field set to KRB_TGS_REP. The detailed specification is in
+section 5.4.2.
+
+The response will include a ticket for the requested server. The Kerberos
+database is queried to retrieve the record for the requested server
+(including the key with which the ticket will be encrypted). If the request
+is for a ticket granting ticket for a remote realm, and if no key is shared
+with the requested realm, then the Kerberos server will select the realm
+"closest" to the requested realm with which it does share a key, and use
+that realm instead. This is the only case where the response from the KDC
+will be for a different server than that requested by the client.
+
+By default, the address field, the client's name and realm, the list of
+transited realms, the time of initial authentication, the expiration time,
+and the authorization data of the newly-issued ticket will be copied from
+the ticket-granting ticket (TGT) or renewable ticket. If the transited field
+needs to be updated, but the transited type is not supported, the
+KDC_ERR_TRTYPE_NOSUPP error is returned.
+
+If the request specifies an endtime, then the endtime of the new ticket is
+set to the minimum of (a) that request, (b) the endtime from the TGT, and
+(c) the starttime of the TGT plus the minimum of the maximum life for the
+application server and the maximum life for the local realm (the maximum
+life for the requesting principal was already applied when the TGT was
+issued). If the new ticket is to be a renewal, then the endtime above is
+replaced by the minimum of (a) the value of the renew_till field of the
+ticket and (b) the starttime for the new ticket plus the life
+(endtime-starttime) of the old ticket.
+
+If the FORWARDED option has been requested, then the resulting ticket will
+contain the addresses specified by the client. This option will only be
+honored if the FORWARDABLE flag is set in the TGT. The PROXY option is
+similar; the resulting ticket will contain the addresses specified by the
+client. It will be honored only if the PROXIABLE flag in the TGT is set. The
+PROXY option will not be honored on requests for additional ticket-granting
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+tickets.
+
+If the requested start time is absent, indicates a time in the past, or is
+within the window of acceptable clock skew for the KDC and the POSTDATE
+option has not been specified, then the start time of the ticket is set to
+the authentication server's current time. If it indicates a time in the
+future beyond the acceptable clock skew, but the POSTDATED option has not
+been specified or the MAY-POSTDATE flag is not set in the TGT, then the
+error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting
+ticket has the MAY-POSTDATE flag set, then the resulting ticket will be
+postdated and the requested starttime is checked against the policy of the
+local realm. If acceptable, the ticket's start time is set as requested, and
+the INVALID flag is set. The postdated ticket must be validated before use
+by presenting it to the KDC after the starttime has been reached. However,
+in no case may the starttime, endtime, or renew-till time of a newly-issued
+postdated ticket extend beyond the renew-till time of the ticket-granting
+ticket.
+
+If the ENC-TKT-IN-SKEY option has been specified and an additional ticket
+has been included in the request, the KDC will decrypt the additional ticket
+using the key for the server to which the additional ticket was issued and
+verify that it is a ticket-granting ticket. If the name of the requested
+server is missing from the request, the name of the client in the additional
+ticket will be used. Otherwise the name of the requested server will be
+compared to the name of the client in the additional ticket and if
+different, the request will be rejected. If the request succeeds, the
+session key from the additional ticket will be used to encrypt the new
+ticket that is issued instead of using the key of the server for which the
+new ticket will be used[17].
+
+If the name of the server in the ticket that is presented to the KDC as part
+of the authentication header is not that of the ticket-granting server
+itself, the server is registered in the realm of the KDC, and the RENEW
+option is requested, then the KDC will verify that the RENEWABLE flag is set
+in the ticket, that the INVALID flag is not set in the ticket, and that the
+renew_till time is still in the future. If the VALIDATE option is rqeuested,
+the KDC will check that the starttime has passed and the INVALID flag is
+set. If the PROXY option is requested, then the KDC will check that the
+PROXIABLE flag is set in the ticket. If the tests succeed, and the ticket
+passes the hotlist check described in the next paragraph, the KDC will issue
+the appropriate new ticket.
+
+3.3.3.1. Checking for revoked tickets
+
+Whenever a request is made to the ticket-granting server, the presented
+ticket(s) is(are) checked against a hot-list of tickets which have been
+canceled. This hot-list might be implemented by storing a range of issue
+timestamps for 'suspect tickets'; if a presented ticket had an authtime in
+that range, it would be rejected. In this way, a stolen ticket-granting
+ticket or renewable ticket cannot be used to gain additional tickets
+(renewals or otherwise) once the theft has been reported. Any normal ticket
+obtained before it was reported stolen will still be valid (because they
+require no interaction with the KDC), but only until their normal expiration
+time.
+
+The ciphertext part of the response in the KRB_TGS_REP message is encrypted
+in the sub-session key from the Authenticator, if present, or the session
+key key from the ticket-granting ticket. It is not encrypted using the
+client's secret key. Furthermore, the client's key's expiration date and the
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+key version number fields are left out since these values are stored along
+with the client's database record, and that record is not needed to satisfy
+a request based on a ticket-granting ticket. See section A.6 for pseudocode.
+
+3.3.3.2. Encoding the transited field
+
+If the identity of the server in the TGT that is presented to the KDC as
+part of the authentication header is that of the ticket-granting service,
+but the TGT was issued from another realm, the KDC will look up the
+inter-realm key shared with that realm and use that key to decrypt the
+ticket. If the ticket is valid, then the KDC will honor the request, subject
+to the constraints outlined above in the section describing the AS exchange.
+The realm part of the client's identity will be taken from the
+ticket-granting ticket. The name of the realm that issued the
+ticket-granting ticket will be added to the transited field of the ticket to
+be issued. This is accomplished by reading the transited field from the
+ticket-granting ticket (which is treated as an unordered set of realm
+names), adding the new realm to the set, then constructing and writing out
+its encoded (shorthand) form (this may involve a rearrangement of the
+existing encoding).
+
+Note that the ticket-granting service does not add the name of its own
+realm. Instead, its responsibility is to add the name of the previous realm.
+This prevents a malicious Kerberos server from intentionally leaving out its
+own name (it could, however, omit other realms' names).
+
+The names of neither the local realm nor the principal's realm are to be
+included in the transited field. They appear elsewhere in the ticket and
+both are known to have taken part in authenticating the principal. Since the
+endpoints are not included, both local and single-hop inter-realm
+authentication result in a transited field that is empty.
+
+Because the name of each realm transited is added to this field, it might
+potentially be very long. To decrease the length of this field, its contents
+are encoded. The initially supported encoding is optimized for the normal
+case of inter-realm communication: a hierarchical arrangement of realms
+using either domain or X.500 style realm names. This encoding (called
+DOMAIN-X500-COMPRESS) is now described.
+
+Realm names in the transited field are separated by a ",". The ",", "\",
+trailing "."s, and leading spaces (" ") are special characters, and if they
+are part of a realm name, they must be quoted in the transited field by
+preced- ing them with a "\".
+
+A realm name ending with a "." is interpreted as being prepended to the
+previous realm. For example, we can encode traversal of EDU, MIT.EDU,
+ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
+
+     "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
+
+Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that they
+would not be included in this field, and we would have:
+
+     "EDU,MIT.,WASHINGTON.EDU"
+
+A realm name beginning with a "/" is interpreted as being appended to the
+previous realm[18]. If it is to stand by itself, then it should be preceded
+by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO,
+/COM/HP, /COM, and /COM/DEC as:
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+     "/COM,/HP,/APOLLO, /COM/DEC".
+
+Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they
+they would not be included in this field, and we would have:
+
+     "/COM,/HP"
+
+A null subfield preceding or following a "," indicates that all realms
+between the previous realm and the next realm have been traversed[19]. Thus,
+"," means that all realms along the path between the client and the server
+have been traversed. ",EDU, /COM," means that that all realms from the
+client's realm up to EDU (in a domain style hierarchy) have been traversed,
+and that everything from /COM down to the server's realm in an X.500 style
+has also been traversed. This could occur if the EDU realm in one hierarchy
+shares an inter-realm key directly with the /COM realm in another hierarchy.
+
+3.3.4. Receipt of KRB_TGS_REP message
+
+When the KRB_TGS_REP is received by the client, it is processed in the same
+manner as the KRB_AS_REP processing described above. The primary difference
+is that the ciphertext part of the response must be decrypted using the
+session key from the ticket-granting ticket rather than the client's secret
+key. See section A.7 for pseudocode.
+
+3.4. The KRB_SAFE Exchange
+
+The KRB_SAFE message may be used by clients requiring the ability to detect
+modifications of messages they exchange. It achieves this by including a
+keyed collision-proof checksum of the user data and some control
+information. The checksum is keyed with an encryption key (usually the last
+key negotiated via subkeys, or the session key if no negotiation has
+occured).
+
+3.4.1. Generation of a KRB_SAFE message
+
+When an application wishes to send a KRB_SAFE message, it collects its data
+and the appropriate control information and computes a checksum over them.
+The checksum algorithm should be a keyed one-way hash function (such as the
+RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES MAC),
+generated using the sub-session key if present, or the session key.
+Different algorithms may be selected by changing the checksum type in the
+message. Unkeyed or non-collision-proof checksums are not suitable for this
+use.
+
+The control information for the KRB_SAFE message includes both a timestamp
+and a sequence number. The designer of an application using the KRB_SAFE
+message must choose at least one of the two mechanisms. This choice should
+be based on the needs of the application protocol.
+
+Sequence numbers are useful when all messages sent will be received by one's
+peer. Connection state is presently required to maintain the session key, so
+maintaining the next sequence number should not present an additional
+problem.
+
+If the application protocol is expected to tolerate lost messages without
+them being resent, the use of the timestamp is the appropriate replay
+detection mechanism. Using timestamps is also the appropriate mechanism for
+multi-cast protocols where all of one's peers share a common sub-session
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+key, but some messages will be sent to a subset of one's peers.
+
+After computing the checksum, the client then transmits the information and
+checksum to the recipient in the message format specified in section 5.6.1.
+
+3.4.2. Receipt of KRB_SAFE message
+
+When an application receives a KRB_SAFE message, it verifies it as follows.
+If any error occurs, an error code is reported for use by the application.
+
+The message is first checked by verifying that the protocol version and type
+fields match the current version and KRB_SAFE, respectively. A mismatch
+generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
+application verifies that the checksum used is a collision-proof keyed
+checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If
+the sender's address was included in the control information, the recipient
+verifies that the operating system's report of the sender's address matches
+the sender's address in the message, and (if a recipient address is
+specified or the recipient requires an address) that one of the recipient's
+addresses appears as the recipient's address in the message. A failed match
+for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and
+usec and/or the sequence number fields are checked. If timestamp and usec
+are expected and not present, or they are present but not current, the
+KRB_AP_ERR_SKEW error is generated. If the server name, along with the
+client name, time and microsecond fields from the Authenticator match any
+recently-seen (sent or received[20] ) such tuples, the KRB_AP_ERR_REPEAT
+error is generated. If an incorrect sequence number is included, or a
+sequence number is expected but not present, the KRB_AP_ERR_BADORDER error
+is generated. If neither a time-stamp and usec or a sequence number is
+present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the checksum is
+computed over the data and control information, and if it doesn't match the
+received checksum, a KRB_AP_ERR_MODIFIED error is generated.
+
+If all the checks succeed, the application is assured that the message was
+generated by its peer and was not modi- fied in transit.
+
+3.5. The KRB_PRIV Exchange
+
+The KRB_PRIV message may be used by clients requiring confidentiality and
+the ability to detect modifications of exchanged messages. It achieves this
+by encrypting the messages and adding control information.
+
+3.5.1. Generation of a KRB_PRIV message
+
+When an application wishes to send a KRB_PRIV message, it collects its data
+and the appropriate control information (specified in section 5.7.1) and
+encrypts them under an encryption key (usually the last key negotiated via
+subkeys, or the session key if no negotiation has occured). As part of the
+control information, the client must choose to use either a timestamp or a
+sequence number (or both); see the discussion in section 3.4.1 for
+guidelines on which to use. After the user data and control information are
+encrypted, the client transmits the ciphertext and some 'envelope'
+information to the recipient.
+
+3.5.2. Receipt of KRB_PRIV message
+
+When an application receives a KRB_PRIV message, it verifies it as follows.
+If any error occurs, an error code is reported for use by the application.
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+The message is first checked by verifying that the protocol version and type
+fields match the current version and KRB_PRIV, respectively. A mismatch
+generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
+application then decrypts the ciphertext and processes the resultant
+plaintext. If decryption shows the data to have been modified, a
+KRB_AP_ERR_BAD_INTEGRITY error is generated. If the sender's address was
+included in the control information, the recipient verifies that the
+operating system's report of the sender's address matches the sender's
+address in the message, and (if a recipient address is specified or the
+recipient requires an address) that one of the recipient's addresses appears
+as the recipient's address in the message. A failed match for either case
+generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the
+sequence number fields are checked. If timestamp and usec are expected and
+not present, or they are present but not current, the KRB_AP_ERR_SKEW error
+is generated. If the server name, along with the client name, time and
+microsecond fields from the Authenticator match any recently-seen such
+tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence
+number is included, or a sequence number is expected but not present, the
+KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or
+a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated.
+
+If all the checks succeed, the application can assume the message was
+generated by its peer, and was securely transmitted (without intruders able
+to see the unencrypted contents).
+
+3.6. The KRB_CRED Exchange
+
+The KRB_CRED message may be used by clients requiring the ability to send
+Kerberos credentials from one host to another. It achieves this by sending
+the tickets together with encrypted data containing the session keys and
+other information associated with the tickets.
+
+3.6.1. Generation of a KRB_CRED message
+
+When an application wishes to send a KRB_CRED message it first (using the
+KRB_TGS exchange) obtains credentials to be sent to the remote host. It then
+constructs a KRB_CRED message using the ticket or tickets so obtained,
+placing the session key needed to use each ticket in the key field of the
+corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED
+message.
+
+Other information associated with each ticket and obtained during the
+KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in
+the encrypted part of the KRB_CRED message. The current time and, if
+specifically required by the application the nonce, s-address, and r-address
+fields, are placed in the encrypted part of the KRB_CRED message which is
+then encrypted under an encryption key previosuly exchanged in the KRB_AP
+exchange (usually the last key negotiated via subkeys, or the session key if
+no negotiation has occured).
+
+3.6.2. Receipt of KRB_CRED message
+
+When an application receives a KRB_CRED message, it verifies it. If any
+error occurs, an error code is reported for use by the application. The
+message is verified by checking that the protocol version and type fields
+match the current version and KRB_CRED, respectively. A mismatch generates a
+KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then
+decrypts the ciphertext and processes the resultant plaintext. If decryption
+shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+generated.
+
+If present or required, the recipient verifies that the operating system's
+report of the sender's address matches the sender's address in the message,
+and that one of the recipient's addresses appears as the recipient's address
+in the message. A failed match for either case generates a
+KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce field
+if required) are checked next. If the timestamp and usec are not present, or
+they are present but not current, the KRB_AP_ERR_SKEW error is generated.
+
+If all the checks succeed, the application stores each of the new tickets in
+its ticket cache together with the session key and other information in the
+corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED
+message.
+
+4. The Kerberos Database
+
+The Kerberos server must have access to a database containing the principal
+identifiers and secret keys of principals to be authenticated[21].
+
+4.1. Database contents
+
+A database entry should contain at least the following fields:
+
+Field                Value
+
+name                 Principal's identifier
+key                  Principal's secret key
+p_kvno               Principal's key version
+max_life             Maximum lifetime for Tickets
+max_renewable_life   Maximum total lifetime for renewable Tickets
+
+The name field is an encoding of the principal's identifier. The key field
+contains an encryption key. This key is the principal's secret key. (The key
+can be encrypted before storage under a Kerberos "master key" to protect it
+in case the database is compromised but the master key is not. In that case,
+an extra field must be added to indicate the master key version used, see
+below.) The p_kvno field is the key version number of the principal's secret
+key. The max_life field contains the maximum allowable lifetime (endtime -
+starttime) for any Ticket issued for this principal. The max_renewable_life
+field contains the maximum allowable total lifetime for any renewable Ticket
+issued for this principal. (See section 3.1 for a description of how these
+lifetimes are used in determining the lifetime of a given Ticket.)
+
+A server may provide KDC service to several realms, as long as the database
+representation provides a mechanism to distinguish between principal records
+with identifiers which differ only in the realm name.
+
+When an application server's key changes, if the change is routine (i.e. not
+the result of disclosure of the old key), the old key should be retained by
+the server until all tickets that had been issued using that key have
+expired. Because of this, it is possible for several keys to be active for a
+single principal. Ciphertext encrypted in a principal's key is always tagged
+with the version of the key that was used for encryption, to help the
+recipient find the proper key for decryption.
+
+When more than one key is active for a particular principal, the principal
+will have more than one record in the Kerberos database. The keys and key
+version numbers will differ between the records (the rest of the fields may
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+or may not be the same). Whenever Kerberos issues a ticket, or responds to a
+request for initial authentication, the most recent key (known by the
+Kerberos server) will be used for encryption. This is the key with the
+highest key version number.
+
+4.2. Additional fields
+
+Project Athena's KDC implementation uses additional fields in its database:
+
+Field        Value
+
+K_kvno       Kerberos' key version
+expiration   Expiration date for entry
+attributes   Bit field of attributes
+mod_date     Timestamp of last modification
+mod_name     Modifying principal's identifier
+
+The K_kvno field indicates the key version of the Kerberos master key under
+which the principal's secret key is encrypted.
+
+After an entry's expiration date has passed, the KDC will return an error to
+any client attempting to gain tickets as or for the principal. (A database
+may want to maintain two expiration dates: one for the principal, and one
+for the principal's current key. This allows password aging to work
+independently of the principal's expiration date. However, due to the
+limited space in the responses, the KDC must combine the key expiration and
+principal expiration date into a single value called 'key_exp', which is
+used as a hint to the user to take administrative action.)
+
+The attributes field is a bitfield used to govern the operations involving
+the principal. This field might be useful in conjunction with user
+registration procedures, for site-specific policy implementations (Project
+Athena currently uses it for their user registration process controlled by
+the system-wide database service, Moira [LGDSR87]), to identify whether a
+principal can play the role of a client or server or both, to note whether a
+server is appropriate trusted to recieve credentials delegated by a client,
+or to identify the 'string to key' conversion algorithm used for a
+principal's key[22]. Other bits are used to indicate that certain ticket
+options should not be allowed in tickets encrypted under a principal's key
+(one bit each): Disallow issuing postdated tickets, disallow issuing
+forwardable tickets, disallow issuing tickets based on TGT authentication,
+disallow issuing renewable tickets, disallow issuing proxiable tickets, and
+disallow issuing tickets for which the principal is the server.
+
+The mod_date field contains the time of last modification of the entry, and
+the mod_name field contains the name of the principal which last modified
+the entry.
+
+4.3. Frequently Changing Fields
+
+Some KDC implementations may wish to maintain the last time that a request
+was made by a particular principal. Information that might be maintained
+includes the time of the last request, the time of the last request for a
+ticket-granting ticket, the time of the last use of a ticket-granting
+ticket, or other times. This information can then be returned to the user in
+the last-req field (see section 5.2).
+
+Other frequently changing information that can be maintained is the latest
+expiration time for any tickets that have been issued using each key. This
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+field would be used to indicate how long old keys must remain valid to allow
+the continued use of outstanding tickets.
+
+4.4. Site Constants
+
+The KDC implementation should have the following configurable constants or
+options, to allow an administrator to make and enforce policy decisions:
+
+   * The minimum supported lifetime (used to determine whether the
+     KDC_ERR_NEVER_VALID error should be returned). This constant should
+     reflect reasonable expectations of round-trip time to the KDC,
+     encryption/decryption time, and processing time by the client and
+     target server, and it should allow for a minimum 'useful' lifetime.
+   * The maximum allowable total (renewable) lifetime of a ticket
+     (renew_till - starttime).
+   * The maximum allowable lifetime of a ticket (endtime - starttime).
+   * Whether to allow the issue of tickets with empty address fields
+     (including the ability to specify that such tickets may only be issued
+     if the request specifies some authorization_data).
+   * Whether proxiable, forwardable, renewable or post-datable tickets are
+     to be issued.
+
+5. Message Specifications
+
+The following sections describe the exact contents and encoding of protocol
+messages and objects. The ASN.1 base definitions are presented in the first
+subsection. The remaining subsections specify the protocol objects (tickets
+and authenticators) and messages. Specification of encryption and checksum
+techniques, and the fields related to them, appear in section 6.
+
+Optional field in ASN.1 sequences
+
+For optional integer value and date fields in ASN.1 sequences where a
+default value has been specified, certain default values will not be allowed
+in the encoding because these values will always be represented through
+defaulting by the absence of the optional field. For example, one will not
+send a microsecond zero value because one must make sure that there is only
+one way to encode this value.
+
+Additional fields in ASN.1 sequences
+
+Implementations receiving Kerberos messages with additional fields present
+in ASN.1 sequences should carry the those fields through, unmodified, when
+the message is forwarded. Implementations should not drop such fields if the
+sequence is reencoded.
+
+5.1. ASN.1 Distinguished Encoding Representation
+
+All uses of ASN.1 in Kerberos shall use the Distinguished Encoding
+Representation of the data elements as described in the X.509 specification,
+section 8.7 [X509-88].
+
+5.3. ASN.1 Base Definitions
+
+The following ASN.1 base definitions are used in the rest of this section.
+Note that since the underscore character (_) is not permitted in ASN.1
+names, the hyphen (-) is used in its place for the purposes of ASN.1 names.
+
+Realm ::=           GeneralString
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+PrincipalName ::=   SEQUENCE {
+                    name-type[0]     INTEGER,
+                    name-string[1]   SEQUENCE OF GeneralString
+}
+
+Kerberos realms are encoded as GeneralStrings. Realms shall not contain a
+character with the code 0 (the ASCII NUL). Most realms will usually consist
+of several components separated by periods (.), in the style of Internet
+Domain Names, or separated by slashes (/) in the style of X.500 names.
+Acceptable forms for realm names are specified in section 7. A PrincipalName
+is a typed sequence of components consisting of the following sub-fields:
+
+name-type
+     This field specifies the type of name that follows. Pre-defined values
+     for this field are specified in section 7.2. The name-type should be
+     treated as a hint. Ignoring the name type, no two names can be the same
+     (i.e. at least one of the components, or the realm, must be different).
+     This constraint may be eliminated in the future.
+name-string
+     This field encodes a sequence of components that form a name, each
+     component encoded as a GeneralString. Taken together, a PrincipalName
+     and a Realm form a principal identifier. Most PrincipalNames will have
+     only a few components (typically one or two).
+
+KerberosTime ::=   GeneralizedTime
+                   -- Specifying UTC time zone (Z)
+
+The timestamps used in Kerberos are encoded as GeneralizedTimes. An encoding
+shall specify the UTC time zone (Z) and shall not include any fractional
+portions of the seconds. It further shall not include any separators.
+Example: The only valid format for UTC time 6 minutes, 27 seconds after 9 pm
+on 6 November 1985 is 19851106210627Z.
+
+HostAddress ::=     SEQUENCE  {
+                    addr-type[0]             INTEGER,
+                    address[1]               OCTET STRING
+}
+
+HostAddresses ::=   SEQUENCE OF HostAddress
+
+The host adddress encodings consists of two fields:
+
+addr-type
+     This field specifies the type of address that follows. Pre-defined
+     values for this field are specified in section 8.1.
+address
+     This field encodes a single address of type addr-type.
+
+The two forms differ slightly. HostAddress contains exactly one address;
+HostAddresses contains a sequence of possibly many addresses.
+
+AuthorizationData ::=   SEQUENCE OF SEQUENCE {
+                        ad-type[0]               INTEGER,
+                        ad-data[1]               OCTET STRING
+}
+
+ad-data
+     This field contains authorization data to be interpreted according to
+     the value of the corresponding ad-type field.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+ad-type
+     This field specifies the format for the ad-data subfield. All negative
+     values are reserved for local use. Non-negative values are reserved for
+     registered use.
+
+Each sequence of type and data is refered to as an authorization element.
+Elements may be application specific, however, there is a common set of
+recursive elements that should be understood by all implementations. These
+elements contain other elements embedded within them, and the interpretation
+of the encapsulating element determines which of the embedded elements must
+be interpreted, and which may be ignored. Definitions for these common
+elements may be found in Appendix B.
+
+TicketExtensions ::= SEQUENCE OF SEQUENCE {
+           te-type[0]       INTEGER,
+           te-data[1]       OCTET STRING
+}
+
+
+
+te-data
+     This field contains opaque data that must be caried with the ticket to
+     support extensions to the Kerberos protocol including but not limited
+     to some forms of inter-realm key exchange and plaintext authorization
+     data. See appendix C for some common uses of this field.
+te-type
+     This field specifies the format for the te-data subfield. All negative
+     values are reserved for local use. Non-negative values are reserved for
+     registered use.
+
+APOptions ::=   BIT STRING
+                  -- reserved(0),
+                  -- use-session-key(1),
+                  -- mutual-required(2)
+
+TicketFlags ::= BIT STRING
+                  -- reserved(0),
+                  -- forwardable(1),
+                  -- forwarded(2),
+                  -- proxiable(3),
+                  -- proxy(4),
+                  -- may-postdate(5),
+                  -- postdated(6),
+                  -- invalid(7),
+                  -- renewable(8),
+                  -- initial(9),
+                  -- pre-authent(10),
+                  -- hw-authent(11),
+                  -- transited-policy-checked(12),
+                  -- ok-as-delegate(13)
+
+KDCOptions ::=   BIT STRING
+                  -- reserved(0),
+                  -- forwardable(1),
+                  -- forwarded(2),
+                  -- proxiable(3),
+                  -- proxy(4),
+                  -- allow-postdate(5),
+                  -- postdated(6),
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                  -- unused7(7),
+                  -- renewable(8),
+                  -- unused9(9),
+                  -- unused10(10),
+                  -- unused11(11),
+                  -- unused12(12),
+                  -- unused13(13),
+                  -- disable-transited-check(26),
+                  -- renewable-ok(27),
+                  -- enc-tkt-in-skey(28),
+                  -- renew(30),
+                  -- validate(31)
+
+ASN.1 Bit strings have a length and a value. When used in Kerberos for the
+APOptions, TicketFlags, and KDCOptions, the length of the bit string on
+generated values should be the smallest number of bits needed to include the
+highest order bit that is set (1), but in no case less than 32 bits. The
+ASN.1 representation of the bit strings uses unnamed bits, with the meaning
+of the individual bits defined by the comments in the specification above.
+Implementations should accept values of bit strings of any length and treat
+the value of flags corresponding to bits beyond the end of the bit string as
+if the bit were reset (0). Comparison of bit strings of different length
+should treat the smaller string as if it were padded with zeros beyond the
+high order bits to the length of the longer string[23].
+
+LastReq ::=   SEQUENCE OF SEQUENCE {
+               lr-type[0]               INTEGER,
+               lr-value[1]              KerberosTime
+}
+
+lr-type
+     This field indicates how the following lr-value field is to be
+     interpreted. Negative values indicate that the information pertains
+     only to the responding server. Non-negative values pertain to all
+     servers for the realm. If the lr-type field is zero (0), then no
+     information is conveyed by the lr-value subfield. If the absolute value
+     of the lr-type field is one (1), then the lr-value subfield is the time
+     of last initial request for a TGT. If it is two (2), then the lr-value
+     subfield is the time of last initial request. If it is three (3), then
+     the lr-value subfield is the time of issue for the newest
+     ticket-granting ticket used. If it is four (4), then the lr-value
+     subfield is the time of the last renewal. If it is five (5), then the
+     lr-value subfield is the time of last request (of any type). If it is
+     (6), then the lr-value subfield is the time when the password will
+     expire.
+lr-value
+     This field contains the time of the last request. the time must be
+     interpreted according to the contents of the accompanying lr-type
+     subfield.
+
+See section 6 for the definitions of Checksum, ChecksumType, EncryptedData,
+EncryptionKey, EncryptionType, and KeyType.
+
+5.3. Tickets and Authenticators
+
+This section describes the format and encryption parameters for tickets and
+authenticators. When a ticket or authenticator is included in a protocol
+message it is treated as an opaque object.
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+5.3.1. Tickets
+
+A ticket is a record that helps a client authenticate to a service. A Ticket
+contains the following information:
+
+Ticket ::=        [APPLICATION 1] SEQUENCE {
+                  tkt-vno[0]                   INTEGER,
+                  realm[1]                     Realm,
+                  sname[2]                     PrincipalName,
+                  enc-part[3]                  EncryptedData,
+                  extensions[4]                TicketExtensions OPTIONAL
+}
+
+-- Encrypted part of ticket
+EncTicketPart ::= [APPLICATION 3] SEQUENCE {
+                  flags[0]                     TicketFlags,
+                  key[1]                       EncryptionKey,
+                  crealm[2]                    Realm,
+                  cname[3]                     PrincipalName,
+                  transited[4]                 TransitedEncoding,
+                  authtime[5]                  KerberosTime,
+                  starttime[6]                 KerberosTime OPTIONAL,
+                  endtime[7]                   KerberosTime,
+                  renew-till[8]                KerberosTime OPTIONAL,
+                  caddr[9]                     HostAddresses OPTIONAL,
+                  authorization-data[10]       AuthorizationData OPTIONAL
+}
+-- encoded Transited field
+TransitedEncoding ::=   SEQUENCE {
+                        tr-type[0]             INTEGER, -- must be registered
+                        contents[1]            OCTET STRING
+}
+
+The encoding of EncTicketPart is encrypted in the key shared by Kerberos and
+the end server (the server's secret key). See section 6 for the format of
+the ciphertext.
+
+tkt-vno
+     This field specifies the version number for the ticket format. This
+     document describes version number 5.
+realm
+     This field specifies the realm that issued a ticket. It also serves to
+     identify the realm part of the server's principal identifier. Since a
+     Kerberos server can only issue tickets for servers within its realm,
+     the two will always be identical.
+sname
+     This field specifies all components of the name part of the server's
+     identity, including those parts that identify a specific instance of a
+     service.
+enc-part
+     This field holds the encrypted encoding of the EncTicketPart sequence.
+extensions
+     This optional field contains a sequence of extentions that may be used
+     to carry information that must be carried with the ticket to support
+     several extensions, including but not limited to plaintext
+     authorization data, tokens for exchanging inter-realm keys, and other
+     information that must be associated with a ticket for use by the
+     application server. See Appendix C for definitions of some common
+     extensions.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+     Note that some older versions of Kerberos did not support this field.
+     Because this is an optional field it will not break older clients, but
+     older clients might strip this field from the ticket before sending it
+     to the application server. This limits the usefulness of this ticket
+     field to environments where the ticket will not be parsed and
+     reconstructed by these older Kerberos clients.
+
+     If it is known that the client will strip this field from the ticket,
+     as an interim measure the KDC may append this field to the end of the
+     enc-part of the ticket and append a traler indicating the lenght of the
+     appended extensions field. (this paragraph is open for discussion,
+     including the form of the traler).
+flags
+     This field indicates which of various options were used or requested
+     when the ticket was issued. It is a bit-field, where the selected
+     options are indicated by the bit being set (1), and the unselected
+     options and reserved fields being reset (0). Bit 0 is the most
+     significant bit. The encoding of the bits is specified in section 5.2.
+     The flags are described in more detail above in section 2. The meanings
+     of the flags are:
+
+          Bit(s)      Name         Description
+
+          0           RESERVED
+                                   Reserved for future  expansion  of  this
+                                   field.
+
+          1           FORWARDABLE
+                                   The FORWARDABLE flag  is  normally  only
+                                   interpreted  by  the  TGS,  and  can  be
+                                   ignored by end servers.  When set,  this
+                                   flag  tells  the  ticket-granting server
+                                   that it is OK to  issue  a  new  ticket-
+                                   granting ticket with a different network
+                                   address based on the presented ticket.
+
+          2           FORWARDED
+                                   When set, this flag indicates  that  the
+                                   ticket  has either been forwarded or was
+                                   issued based on authentication involving
+                                   a forwarded ticket-granting ticket.
+
+          3           PROXIABLE
+                                   The  PROXIABLE  flag  is  normally  only
+                                   interpreted  by  the  TGS,  and  can  be
+                                   ignored by end servers.   The  PROXIABLE
+                                   flag  has an interpretation identical to
+                                   that of  the  FORWARDABLE  flag,  except
+                                   that   the   PROXIABLE  flag  tells  the
+                                   ticket-granting server  that  only  non-
+                                   ticket-granting  tickets  may  be issued
+                                   with different network addresses.
+
+          4           PROXY
+                                   When set, this  flag  indicates  that  a
+                                   ticket is a proxy.
+
+          5           MAY-POSTDATE
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                                   The MAY-POSTDATE flag is  normally  only
+                                   interpreted  by  the  TGS,  and  can  be
+                                   ignored by end servers.  This flag tells
+                                   the  ticket-granting server that a post-
+                                   dated ticket may be issued based on this
+                                   ticket-granting ticket.
+
+          6           POSTDATED
+                                   This flag indicates that this ticket has
+                                   been  postdated.   The  end-service  can
+                                   check the authtime field to see when the
+                                   original authentication occurred.
+
+          7           INVALID
+                                   This flag indicates  that  a  ticket  is
+                                   invalid, and it must be validated by the
+                                   KDC  before  use.   Application  servers
+                                   must reject tickets which have this flag
+                                   set.
+
+          8           RENEWABLE
+                                   The  RENEWABLE  flag  is  normally  only
+                                   interpreted  by the TGS, and can usually
+                                   be ignored by end servers (some particu-
+                                   larly careful servers may wish to disal-
+                                   low  renewable  tickets).   A  renewable
+                                   ticket  can be used to obtain a replace-
+                                   ment ticket  that  expires  at  a  later
+                                   date.
+
+          9           INITIAL
+                                   This flag indicates that this ticket was
+                                   issued  using  the  AS protocol, and not
+                                   issued  based   on   a   ticket-granting
+                                   ticket.
+
+          10          PRE-AUTHENT
+                                   This flag indicates that during  initial
+                                   authentication, the client was authenti-
+                                   cated by the KDC  before  a  ticket  was
+                                   issued.    The   strength  of  the  pre-
+                                   authentication method is not  indicated,
+                                   but is acceptable to the KDC.
+
+          11          HW-AUTHENT
+                                   This flag indicates  that  the  protocol
+                                   employed   for   initial  authentication
+                                   required the use of hardware expected to
+                                   be possessed solely by the named client.
+                                   The hardware  authentication  method  is
+                                   selected  by the KDC and the strength of
+                                   the method is not indicated.
+
+          12           TRANSITED   This flag indicates that the KDC for the
+                  POLICY-CHECKED   realm has checked the transited field
+                                   against a realm defined policy for
+                                   trusted certifiers.  If this flag is
+                                   reset (0), then the application server
+                                   must check the transited field itself,
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                                   and if unable to do so it must reject
+                                   the authentication.  If the flag is set
+                                   (1) then the application server may skip
+                                   its own validation of the transited
+                                   field, relying on the validation
+                                   performed by the KDC.  At its option the
+                                   application server may still apply its
+                                   own validation based on a separate
+                                   policy for acceptance.
+
+          13      OK-AS-DELEGATE   This flag indicates that the server (not
+                                   the client) specified in the ticket has
+                                   been determined by policy of the realm
+                                   to be a suitable recipient of
+                                   delegation.  A client can use the
+                                   presence of this flag to help it make a
+                                   decision whether to delegate credentials
+                                   (either grant a proxy or a forwarded
+                                   ticket granting ticket) to this server.
+                                   The client is free to ignore the value
+                                   of this flag.  When setting this flag,
+                                   an administrator should consider the
+                                   Security and placement of the server on
+                                   which the service will run, as well as
+                                   whether the service requires the use of
+                                   delegated credentials.
+
+          14          ANONYMOUS
+                                   This flag indicates that  the  principal
+                                   named in the ticket is a generic princi-
+                                   pal for the realm and does not  identify
+                                   the  individual  using  the ticket.  The
+                                   purpose  of  the  ticket  is   only   to
+                                   securely  distribute  a session key, and
+                                   not to identify  the  user.   Subsequent
+                                   requests  using the same ticket and ses-
+                                   sion may be  considered  as  originating
+                                   from  the  same  user, but requests with
+                                   the same username but a different ticket
+                                   are  likely  to originate from different
+                                   users.
+
+          15-31       RESERVED
+                                   Reserved for future use.
+
+key
+     This field exists in the ticket and the KDC response and is used to
+     pass the session key from Kerberos to the application server and the
+     client. The field's encoding is described in section 6.2.
+crealm
+     This field contains the name of the realm in which the client is
+     registered and in which initial authentication took place.
+cname
+     This field contains the name part of the client's principal identifier.
+transited
+     This field lists the names of the Kerberos realms that took part in
+     authenticating the user to whom this ticket was issued. It does not
+     specify the order in which the realms were transited. See section
+     3.3.3.2 for details on how this field encodes the traversed realms.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     When the names of CA's are to be embedded inthe transited field (as
+     specified for some extentions to the protocol), the X.500 names of the
+     CA's should be mapped into items in the transited field using the
+     mapping defined by RFC2253.
+authtime
+     This field indicates the time of initial authentication for the named
+     principal. It is the time of issue for the original ticket on which
+     this ticket is based. It is included in the ticket to provide
+     additional information to the end service, and to provide the necessary
+     information for implementation of a `hot list' service at the KDC. An
+     end service that is particularly paranoid could refuse to accept
+     tickets for which the initial authentication occurred "too far" in the
+     past. This field is also returned as part of the response from the KDC.
+     When returned as part of the response to initial authentication
+     (KRB_AS_REP), this is the current time on the Kerberos server[24].
+starttime
+     This field in the ticket specifies the time after which the ticket is
+     valid. Together with endtime, this field specifies the life of the
+     ticket. If it is absent from the ticket, its value should be treated as
+     that of the authtime field.
+endtime
+     This field contains the time after which the ticket will not be honored
+     (its expiration time). Note that individual services may place their
+     own limits on the life of a ticket and may reject tickets which have
+     not yet expired. As such, this is really an upper bound on the
+     expiration time for the ticket.
+renew-till
+     This field is only present in tickets that have the RENEWABLE flag set
+     in the flags field. It indicates the maximum endtime that may be
+     included in a renewal. It can be thought of as the absolute expiration
+     time for the ticket, including all renewals.
+caddr
+     This field in a ticket contains zero (if omitted) or more (if present)
+     host addresses. These are the addresses from which the ticket can be
+     used. If there are no addresses, the ticket can be used from any
+     location. The decision by the KDC to issue or by the end server to
+     accept zero-address tickets is a policy decision and is left to the
+     Kerberos and end-service administrators; they may refuse to issue or
+     accept such tickets. The suggested and default policy, however, is that
+     such tickets will only be issued or accepted when additional
+     information that can be used to restrict the use of the ticket is
+     included in the authorization_data field. Such a ticket is a
+     capability.
+
+     Network addresses are included in the ticket to make it harder for an
+     attacker to use stolen credentials. Because the session key is not sent
+     over the network in cleartext, credentials can't be stolen simply by
+     listening to the network; an attacker has to gain access to the session
+     key (perhaps through operating system security breaches or a careless
+     user's unattended session) to make use of stolen tickets.
+
+     It is important to note that the network address from which a
+     connection is received cannot be reliably determined. Even if it could
+     be, an attacker who has compromised the client's workstation could use
+     the credentials from there. Including the network addresses only makes
+     it more difficult, not impossible, for an attacker to walk off with
+     stolen credentials and then use them from a "safe" location.
+authorization-data
+     The authorization-data field is used to pass authorization data from
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     the principal on whose behalf a ticket was issued to the application
+     service. If no authorization data is included, this field will be left
+     out. Experience has shown that the name of this field is confusing, and
+     that a better name for this field would be restrictions. Unfortunately,
+     it is not possible to change the name of this field at this time.
+
+     This field contains restrictions on any authority obtained on the basis
+     of authentication using the ticket. It is possible for any principal in
+     posession of credentials to add entries to the authorization data field
+     since these entries further restrict what can be done with the ticket.
+     Such additions can be made by specifying the additional entries when a
+     new ticket is obtained during the TGS exchange, or they may be added
+     during chained delegation using the authorization data field of the
+     authenticator.
+
+     Because entries may be added to this field by the holder of
+     credentials, except when an entry is separately authenticated by
+     encapulation in the kdc-issued element, it is not allowable for the
+     presence of an entry in the authorization data field of a ticket to
+     amplify the priveleges one would obtain from using a ticket.
+
+     The data in this field may be specific to the end service; the field
+     will contain the names of service specific objects, and the rights to
+     those objects. The format for this field is described in section 5.2.
+     Although Kerberos is not concerned with the format of the contents of
+     the sub-fields, it does carry type information (ad-type).
+
+     By using the authorization_data field, a principal is able to issue a
+     proxy that is valid for a specific purpose. For example, a client
+     wishing to print a file can obtain a file server proxy to be passed to
+     the print server. By specifying the name of the file in the
+     authorization_data field, the file server knows that the print server
+     can only use the client's rights when accessing the particular file to
+     be printed.
+
+     A separate service providing authorization or certifying group
+     membership may be built using the authorization-data field. In this
+     case, the entity granting authorization (not the authorized entity),
+     may obtain a ticket in its own name (e.g. the ticket is issued in the
+     name of a privelege server), and this entity adds restrictions on its
+     own authority and delegates the restricted authority through a proxy to
+     the client. The client would then present this authorization credential
+     to the application server separately from the authentication exchange.
+     Alternatively, such authorization credentials may be embedded in the
+     ticket authenticating the authorized entity, when the authorization is
+     separately authenticated using the kdc-issued authorization data
+     element (see B.4).
+
+     Similarly, if one specifies the authorization-data field of a proxy and
+     leaves the host addresses blank, the resulting ticket and session key
+     can be treated as a capability. See [Neu93] for some suggested uses of
+     this field.
+
+     The authorization-data field is optional and does not have to be
+     included in a ticket.
+
+5.3.2. Authenticators
+
+An authenticator is a record sent with a ticket to a server to certify the
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+client's knowledge of the encryption key in the ticket, to help the server
+detect replays, and to help choose a "true session key" to use with the
+particular session. The encoding is encrypted in the ticket's session key
+shared by the client and the server:
+
+-- Unencrypted authenticator
+Authenticator ::= [APPLICATION 2] SEQUENCE  {
+                  authenticator-vno[0]          INTEGER,
+                  crealm[1]                     Realm,
+                  cname[2]                      PrincipalName,
+                  cksum[3]                      Checksum OPTIONAL,
+                  cusec[4]                      INTEGER,
+                  ctime[5]                      KerberosTime,
+                  subkey[6]                     EncryptionKey OPTIONAL,
+                  seq-number[7]                 INTEGER OPTIONAL,
+                  authorization-data[8]         AuthorizationData OPTIONAL
+}
+
+
+authenticator-vno
+     This field specifies the version number for the format of the
+     authenticator. This document specifies version 5.
+crealm and cname
+     These fields are the same as those described for the ticket in section
+     5.3.1.
+cksum
+     This field contains a checksum of the the applica- tion data that
+     accompanies the KRB_AP_REQ.
+cusec
+     This field contains the microsecond part of the client's timestamp. Its
+     value (before encryption) ranges from 0 to 999999. It often appears
+     along with ctime. The two fields are used together to specify a
+     reasonably accurate timestamp.
+ctime
+     This field contains the current time on the client's host.
+subkey
+     This field contains the client's choice for an encryption key which is
+     to be used to protect this specific application session. Unless an
+     application specifies otherwise, if this field is left out the session
+     key from the ticket will be used.
+seq-number
+     This optional field includes the initial sequence number to be used by
+     the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to
+     detect replays (It may also be used by application specific messages).
+     When included in the authenticator this field specifies the initial
+     sequence number for messages from the client to the server. When
+     included in the AP-REP message, the initial sequence number is that for
+     messages from the server to the client. When used in KRB_PRIV or
+     KRB_SAFE messages, it is incremented by one after each message is sent.
+     Sequence numbers fall in the range of 0 through 2^32 - 1 and wrap to
+     zero following the value 2^32 - 1.
+
+     For sequence numbers to adequately support the detection of replays
+     they should be non-repeating, even across connection boundaries. The
+     initial sequence number should be random and uniformly distributed
+     across the full space of possible sequence numbers, so that it cannot
+     be guessed by an attacker and so that it and the successive sequence
+     numbers do not repeat other sequences.
+authorization-data
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     This field is the same as described for the ticket in section 5.3.1. It
+     is optional and will only appear when additional restrictions are to be
+     placed on the use of a ticket, beyond those carried in the ticket
+     itself.
+
+5.4. Specifications for the AS and TGS exchanges
+
+This section specifies the format of the messages used in the exchange
+between the client and the Kerberos server. The format of possible error
+messages appears in section 5.9.1.
+
+5.4.1. KRB_KDC_REQ definition
+
+The KRB_KDC_REQ message has no type of its own. Instead, its type is one of
+KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an initial
+ticket or an additional ticket. In either case, the message is sent from the
+client to the Authentication Server to request credentials for a service.
+
+The message fields are:
+
+AS-REQ ::=         [APPLICATION 10] KDC-REQ
+TGS-REQ ::=        [APPLICATION 12] KDC-REQ
+
+KDC-REQ ::=        SEQUENCE {
+                   pvno[1]            INTEGER,
+                   msg-type[2]        INTEGER,
+                   padata[3]          SEQUENCE OF PA-DATA OPTIONAL,
+                   req-body[4]        KDC-REQ-BODY
+}
+
+PA-DATA ::=        SEQUENCE {
+                   padata-type[1]     INTEGER,
+                   padata-value[2]    OCTET STRING,
+                                      -- might be encoded AP-REQ
+}
+
+KDC-REQ-BODY ::=   SEQUENCE {
+                    kdc-options[0]         KDCOptions,
+                    cname[1]               PrincipalName OPTIONAL,
+                                           -- Used only in AS-REQ
+                    realm[2]               Realm, -- Server's realm
+                                           -- Also client's in AS-REQ
+                    sname[3]               PrincipalName OPTIONAL,
+                    from[4]                KerberosTime OPTIONAL,
+                    till[5]                KerberosTime OPTIONAL,
+                    rtime[6]               KerberosTime OPTIONAL,
+                    nonce[7]               INTEGER,
+                    etype[8]               SEQUENCE OF INTEGER,
+                                           -- EncryptionType,
+                                           -- in preference order
+                    addresses[9]           HostAddresses OPTIONAL,
+                enc-authorization-data[10] EncryptedData OPTIONAL,
+                                           -- Encrypted AuthorizationData
+                                           -- encoding
+                    additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
+}
+
+The fields in this message are:
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+pvno
+     This field is included in each message, and specifies the protocol
+     version number. This document specifies protocol version 5.
+msg-type
+     This field indicates the type of a protocol message. It will almost
+     always be the same as the application identifier associated with a
+     message. It is included to make the identifier more readily accessible
+     to the application. For the KDC-REQ message, this type will be
+     KRB_AS_REQ or KRB_TGS_REQ.
+padata
+     The padata (pre-authentication data) field contains a sequence of
+     authentication information which may be needed before credentials can
+     be issued or decrypted. In the case of requests for additional tickets
+     (KRB_TGS_REQ), this field will include an element with padata-type of
+     PA-TGS-REQ and data of an authentication header (ticket-granting ticket
+     and authenticator). The checksum in the authenticator (which must be
+     collision-proof) is to be computed over the KDC-REQ-BODY encoding. In
+     most requests for initial authentication (KRB_AS_REQ) and most replies
+     (KDC-REP), the padata field will be left out.
+
+     This field may also contain information needed by certain extensions to
+     the Kerberos protocol. For example, it might be used to initially
+     verify the identity of a client before any response is returned. This
+     is accomplished with a padata field with padata-type equal to
+     PA-ENC-TIMESTAMP and padata-value defined as follows:
+
+     padata-type     ::= PA-ENC-TIMESTAMP
+     padata-value    ::= EncryptedData -- PA-ENC-TS-ENC
+
+     PA-ENC-TS-ENC   ::= SEQUENCE {
+                     patimestamp[0]     KerberosTime, -- client's time
+                     pausec[1]          INTEGER OPTIONAL
+     }
+
+     with patimestamp containing the client's time and pausec containing the
+     microseconds which may be omitted if a client will not generate more
+     than one request per second. The ciphertext (padata-value) consists of
+     the PA-ENC-TS-ENC sequence, encrypted using the client's secret key.
+
+     [use-specified-kvno item is here for discussion and may be removed] It
+     may also be used by the client to specify the version of a key that is
+     being used for accompanying preauthentication, and/or which should be
+     used to encrypt the reply from the KDC.
+
+     PA-USE-SPECIFIED-KVNO  ::=  Integer
+
+     The KDC should only accept and abide by the value of the
+     use-specified-kvno preauthentication data field when the specified key
+     is still valid and until use of a new key is confirmed. This situation
+     is likely to occur primarily during the period during which an updated
+     key is propagating to other KDC's in a realm.
+
+     The padata field can also contain information needed to help the KDC or
+     the client select the key needed for generating or decrypting the
+     response. This form of the padata is useful for supporting the use of
+     certain token cards with Kerberos. The details of such extensions are
+     specified in separate documents. See [Pat92] for additional uses of
+     this field.
+padata-type
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     The padata-type element of the padata field indicates the way that the
+     padata-value element is to be interpreted. Negative values of
+     padata-type are reserved for unregistered use; non-negative values are
+     used for a registered interpretation of the element type.
+req-body
+     This field is a placeholder delimiting the extent of the remaining
+     fields. If a checksum is to be calculated over the request, it is
+     calculated over an encoding of the KDC-REQ-BODY sequence which is
+     enclosed within the req-body field.
+kdc-options
+     This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the
+     KDC and indicates the flags that the client wants set on the tickets as
+     well as other information that is to modify the behavior of the KDC.
+     Where appropriate, the name of an option may be the same as the flag
+     that is set by that option. Although in most case, the bit in the
+     options field will be the same as that in the flags field, this is not
+     guaranteed, so it is not acceptable to simply copy the options field to
+     the flags field. There are various checks that must be made before
+     honoring an option anyway.
+
+     The kdc_options field is a bit-field, where the selected options are
+     indicated by the bit being set (1), and the unselected options and
+     reserved fields being reset (0). The encoding of the bits is specified
+     in section 5.2. The options are described in more detail above in
+     section 2. The meanings of the options are:
+
+        Bit(s)    Name                Description
+         0        RESERVED
+                                      Reserved for future  expansion  of  this
+                                      field.
+
+         1        FORWARDABLE
+                                      The FORWARDABLE  option  indicates  that
+                                      the  ticket  to be issued is to have its
+                                      forwardable flag set.  It  may  only  be
+                                      set on the initial request, or in a sub-
+                                      sequent request if  the  ticket-granting
+                                      ticket on which it is based is also for-
+                                      wardable.
+
+         2        FORWARDED
+                                      The FORWARDED option is  only  specified
+                                      in  a  request  to  the  ticket-granting
+                                      server and will only be honored  if  the
+                                      ticket-granting  ticket  in  the request
+                                      has  its  FORWARDABLE  bit  set.    This
+                                      option  indicates that this is a request
+                                      for forwarding.  The address(es) of  the
+                                      host  from which the resulting ticket is
+                                      to  be  valid  are   included   in   the
+                                      addresses field of the request.
+
+         3        PROXIABLE
+                                      The PROXIABLE option indicates that  the
+                                      ticket to be issued is to have its prox-
+                                      iable flag set.  It may only be  set  on
+                                      the  initial request, or in a subsequent
+                                      request if the ticket-granting ticket on
+                                      which it is based is also proxiable.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+         4        PROXY
+                                      The PROXY option indicates that this  is
+                                      a request for a proxy.  This option will
+                                      only be honored if  the  ticket-granting
+                                      ticket  in the request has its PROXIABLE
+                                      bit set.  The address(es)  of  the  host
+                                      from which the resulting ticket is to be
+                                       valid  are  included  in  the  addresses
+                                      field of the request.
+
+         5        ALLOW-POSTDATE
+                                      The ALLOW-POSTDATE option indicates that
+                                      the  ticket  to be issued is to have its
+                                      MAY-POSTDATE flag set.  It may  only  be
+                                      set on the initial request, or in a sub-
+                                      sequent request if  the  ticket-granting
+                                      ticket on which it is based also has its
+                                      MAY-POSTDATE flag set.
+
+         6        POSTDATED
+                                      The POSTDATED option indicates that this
+                                      is  a  request  for  a postdated ticket.
+                                      This option will only be honored if  the
+                                      ticket-granting  ticket  on  which it is
+                                      based has  its  MAY-POSTDATE  flag  set.
+                                      The  resulting ticket will also have its
+                                      INVALID flag set, and that flag  may  be
+                                      reset by a subsequent request to the KDC
+                                      after the starttime in  the  ticket  has
+                                      been reached.
+
+         7        UNUSED
+                                      This option is presently unused.
+
+         8        RENEWABLE
+                                      The RENEWABLE option indicates that  the
+                                      ticket  to  be  issued  is  to  have its
+                                      RENEWABLE flag set.  It may only be  set
+                                      on  the  initial  request,  or  when the
+                                      ticket-granting  ticket  on  which   the
+                                      request  is based is also renewable.  If
+                                      this option is requested, then the rtime
+                                      field   in   the  request  contains  the
+                                      desired absolute expiration time for the
+                                      ticket.
+
+         9-13     UNUSED
+                                      These options are presently unused.
+
+         14       REQUEST-ANONYMOUS
+                                      The REQUEST-ANONYMOUS  option  indicates
+                                      that  the  ticket to be issued is not to
+                                      identify  the  user  to  which  it   was
+                                      issued.  Instead, the principal identif-
+                                      ier is to be generic,  as  specified  by
+                                      the  policy  of  the realm (e.g. usually
+                                      anonymous@realm).  The  purpose  of  the
+                                      ticket  is only to securely distribute a
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                                      session key, and  not  to  identify  the
+                                      user.   The ANONYMOUS flag on the ticket
+                                      to be returned should be  set.   If  the
+                                      local  realms  policy  does  not  permit
+                                      anonymous credentials, the request is to
+                                      be rejected.
+
+         15-25    RESERVED
+                                      Reserved for future use.
+
+         26       DISABLE-TRANSITED-CHECK
+                                      By default the KDC will check the
+                                      transited field of a ticket-granting-
+                                      ticket against the policy of the local
+                                      realm before it will issue derivative
+                                      tickets based on the ticket granting
+                                      ticket.  If this flag is set in the
+                                      request, checking of the transited field
+                                      is disabled.  Tickets issued without the
+                                      performance of this check will be noted
+                                      by the reset (0) value of the
+                                      TRANSITED-POLICY-CHECKED flag,
+                                      indicating to the application server
+                                      that the tranisted field must be checked
+                                      locally.  KDC's are encouraged but not
+                                      required to honor the
+                                      DISABLE-TRANSITED-CHECK option.
+
+         27       RENEWABLE-OK
+                                      The RENEWABLE-OK option indicates that a
+                                      renewable ticket will be acceptable if a
+                                      ticket with the  requested  life  cannot
+                                      otherwise be provided.  If a ticket with
+                                      the requested life cannot  be  provided,
+                                      then  a  renewable  ticket may be issued
+                                      with  a  renew-till  equal  to  the  the
+                                      requested  endtime.   The  value  of the
+                                      renew-till field may still be limited by
+                                      local  limits, or limits selected by the
+                                      individual principal or server.
+
+         28       ENC-TKT-IN-SKEY
+                                      This option is used only by the  ticket-
+                                      granting  service.   The ENC-TKT-IN-SKEY
+                                      option indicates that the ticket for the
+                                      end  server  is  to  be encrypted in the
+                                      session key from the additional  ticket-
+                                      granting ticket provided.
+
+         29       RESERVED
+                                      Reserved for future use.
+
+         30       RENEW
+                                      This option is used only by the  ticket-
+                                      granting   service.   The  RENEW  option
+                                      indicates that the  present  request  is
+                                      for  a  renewal.  The ticket provided is
+                                      encrypted in  the  secret  key  for  the
+                                      server  on  which  it  is  valid.   This
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                                      option  will  only  be  honored  if  the
+                                      ticket  to  be renewed has its RENEWABLE
+                                      flag set and if the time in  its  renew-
+                                      till  field  has not passed.  The ticket
+                                      to be renewed is passed  in  the  padata
+                                      field  as  part  of  the  authentication
+                                      header.
+
+         31       VALIDATE
+                                      This option is used only by the  ticket-
+                                      granting  service.   The VALIDATE option
+                                      indicates that the request is  to  vali-
+                                      date  a  postdated ticket.  It will only
+                                      be honored if the  ticket  presented  is
+                                      postdated,  presently  has  its  INVALID
+                                      flag set, and would be otherwise  usable
+                                      at  this time.  A ticket cannot be vali-
+                                      dated before its starttime.  The  ticket
+                                      presented for validation is encrypted in
+                                      the key of the server for  which  it  is
+                                      valid  and is passed in the padata field
+                                      as part of the authentication header.
+
+cname and sname
+     These fields are the same as those described for the ticket in section
+     5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is
+     specified. If absent, the name of the server is taken from the name of
+     the client in the ticket passed as additional-tickets.
+enc-authorization-data
+     The enc-authorization-data, if present (and it can only be present in
+     the TGS_REQ form), is an encoding of the desired authorization-data
+     encrypted under the sub-session key if present in the Authenticator, or
+     alternatively from the session key in the ticket-granting ticket, both
+     from the padata field in the KRB_AP_REQ.
+realm
+     This field specifies the realm part of the server's principal
+     identifier. In the AS exchange, this is also the realm part of the
+     client's principal identifier.
+from
+     This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
+     requests when the requested ticket is to be postdated. It specifies the
+     desired start time for the requested ticket. If this field is omitted
+     then the KDC should use the current time instead.
+till
+     This field contains the expiration date requested by the client in a
+     ticket request. It is optional and if omitted the requested ticket is
+     to have the maximum endtime permitted according to KDC policy for the
+     parties to the authentication exchange as limited by expiration date of
+     the ticket granting ticket or other preauthentication credentials.
+rtime
+     This field is the requested renew-till time sent from a client to the
+     KDC in a ticket request. It is optional.
+nonce
+     This field is part of the KDC request and response. It it intended to
+     hold a random number generated by the client. If the same number is
+     included in the encrypted response from the KDC, it provides evidence
+     that the response is fresh and has not been replayed by an attacker.
+     Nonces must never be re-used. Ideally, it should be generated randomly,
+     but if the correct time is known, it may suffice[25].
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+etype
+     This field specifies the desired encryption algorithm to be used in the
+     response.
+addresses
+     This field is included in the initial request for tickets, and
+     optionally included in requests for additional tickets from the
+     ticket-granting server. It specifies the addresses from which the
+     requested ticket is to be valid. Normally it includes the addresses for
+     the client's host. If a proxy is requested, this field will contain
+     other addresses. The contents of this field are usually copied by the
+     KDC into the caddr field of the resulting ticket.
+additional-tickets
+     Additional tickets may be optionally included in a request to the
+     ticket-granting server. If the ENC-TKT-IN-SKEY option has been
+     specified, then the session key from the additional ticket will be used
+     in place of the server's key to encrypt the new ticket. If more than
+     one option which requires additional tickets has been specified, then
+     the additional tickets are used in the order specified by the ordering
+     of the options bits (see kdc-options, above).
+
+The application code will be either ten (10) or twelve (12) depending on
+whether the request is for an initial ticket (AS-REQ) or for an additional
+ticket (TGS-REQ).
+
+The optional fields (addresses, authorization-data and additional-tickets)
+are only included if necessary to perform the operation specified in the
+kdc-options field.
+
+It should be noted that in KRB_TGS_REQ, the protocol version number appears
+twice and two different message types appear: the KRB_TGS_REQ message
+contains these fields as does the authentication header (KRB_AP_REQ) that is
+passed in the padata field.
+
+5.4.2. KRB_KDC_REP definition
+
+The KRB_KDC_REP message format is used for the reply from the KDC for either
+an initial (AS) request or a subsequent (TGS) request. There is no message
+type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or
+KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply
+depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in
+the client's secret key, and the client's key version number is included in
+the key version number for the encrypted data. For KRB_TGS_REP, the
+ciphertext is encrypted in the sub-session key from the Authenticator, or if
+absent, the session key from the ticket-granting ticket used in the request.
+In that case, no version number will be present in the EncryptedData
+sequence.
+
+The KRB_KDC_REP message contains the following fields:
+
+AS-REP ::=    [APPLICATION 11] KDC-REP
+TGS-REP ::=   [APPLICATION 13] KDC-REP
+
+KDC-REP ::=   SEQUENCE {
+              pvno[0]                    INTEGER,
+              msg-type[1]                INTEGER,
+              padata[2]                  SEQUENCE OF PA-DATA OPTIONAL,
+              crealm[3]                  Realm,
+              cname[4]                   PrincipalName,
+              ticket[5]                  Ticket,
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+              enc-part[6]                EncryptedData
+}
+
+EncASRepPart ::=    [APPLICATION 25[27]] EncKDCRepPart
+EncTGSRepPart ::=   [APPLICATION 26] EncKDCRepPart
+
+EncKDCRepPart ::=   SEQUENCE {
+                    key[0]               EncryptionKey,
+                    last-req[1]          LastReq,
+                    nonce[2]             INTEGER,
+                    key-expiration[3]    KerberosTime OPTIONAL,
+                    flags[4]             TicketFlags,
+                    authtime[5]          KerberosTime,
+                    starttime[6]         KerberosTime OPTIONAL,
+                    endtime[7]           KerberosTime,
+                    renew-till[8]        KerberosTime OPTIONAL,
+                    srealm[9]            Realm,
+                    sname[10]            PrincipalName,
+                    caddr[11]            HostAddresses OPTIONAL
+}
+
+pvno and msg-type
+     These fields are described above in section 5.4.1. msg-type is either
+     KRB_AS_REP or KRB_TGS_REP.
+padata
+     This field is described in detail in section 5.4.1. One possible use
+     for this field is to encode an alternate "mix-in" string to be used
+     with a string-to-key algorithm (such as is described in section 6.3.2).
+     This ability is useful to ease transitions if a realm name needs to
+     change (e.g. when a company is acquired); in such a case all existing
+     password-derived entries in the KDC database would be flagged as
+     needing a special mix-in string until the next password change.
+crealm, cname, srealm and sname
+     These fields are the same as those described for the ticket in section
+     5.3.1.
+ticket
+     The newly-issued ticket, from section 5.3.1.
+enc-part
+     This field is a place holder for the ciphertext and related information
+     that forms the encrypted part of a message. The description of the
+     encrypted part of the message follows each appearance of this field.
+     The encrypted part is encoded as described in section 6.1.
+key
+     This field is the same as described for the ticket in section 5.3.1.
+last-req
+     This field is returned by the KDC and specifies the time(s) of the last
+     request by a principal. Depending on what information is available,
+     this might be the last time that a request for a ticket-granting ticket
+     was made, or the last time that a request based on a ticket-granting
+     ticket was successful. It also might cover all servers for a realm, or
+     just the particular server. Some implementations may display this
+     information to the user to aid in discovering unauthorized use of one's
+     identity. It is similar in spirit to the last login time displayed when
+     logging into timesharing systems.
+nonce
+     This field is described above in section 5.4.1.
+key-expiration
+     The key-expiration field is part of the response from the KDC and
+     specifies the time that the client's secret key is due to expire. The
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     expiration might be the result of password aging or an account
+     expiration. This field will usually be left out of the TGS reply since
+     the response to the TGS request is encrypted in a session key and no
+     client information need be retrieved from the KDC database. It is up to
+     the application client (usually the login program) to take appropriate
+     action (such as notifying the user) if the expiration time is imminent.
+flags, authtime, starttime, endtime, renew-till and caddr
+     These fields are duplicates of those found in the encrypted portion of
+     the attached ticket (see section 5.3.1), provided so the client may
+     verify they match the intended request and to assist in proper ticket
+     caching. If the message is of type KRB_TGS_REP, the caddr field will
+     only be filled in if the request was for a proxy or forwarded ticket,
+     or if the user is substituting a subset of the addresses from the
+     ticket granting ticket. If the client-requested addresses are not
+     present or not used, then the addresses contained in the ticket will be
+     the same as those included in the ticket-granting ticket.
+
+5.5. Client/Server (CS) message specifications
+
+This section specifies the format of the messages used for the
+authentication of the client to the application server.
+
+5.5.1. KRB_AP_REQ definition
+
+The KRB_AP_REQ message contains the Kerberos protocol version number, the
+message type KRB_AP_REQ, an options field to indicate any options in use,
+and the ticket and authenticator themselves. The KRB_AP_REQ message is often
+referred to as the 'authentication header'.
+
+AP-REQ ::=      [APPLICATION 14] SEQUENCE {
+                pvno[0]                       INTEGER,
+                msg-type[1]                   INTEGER,
+                ap-options[2]                 APOptions,
+                ticket[3]                     Ticket,
+                authenticator[4]              EncryptedData
+}
+
+APOptions ::=   BIT STRING {
+                reserved(0),
+                use-session-key(1),
+                mutual-required(2)
+}
+
+
+
+pvno and msg-type
+     These fields are described above in section 5.4.1. msg-type is
+     KRB_AP_REQ.
+ap-options
+     This field appears in the application request (KRB_AP_REQ) and affects
+     the way the request is processed. It is a bit-field, where the selected
+     options are indicated by the bit being set (1), and the unselected
+     options and reserved fields being reset (0). The encoding of the bits
+     is specified in section 5.2. The meanings of the options are:
+
+       Bit(s)   Name              Description
+
+       0        RESERVED
+                                  Reserved for future  expansion  of  this
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                                  field.
+
+       1        USE-SESSION-KEY
+                                  The  USE-SESSION-KEY  option   indicates
+                                  that the ticket the client is presenting
+                                  to a server is encrypted in the  session
+                                  key  from  the  server's ticket-granting
+                                  ticket.  When this option is not  speci-
+                                  fied,  the  ticket  is  encrypted in the
+                                  server's secret key.
+
+       2        MUTUAL-REQUIRED
+                                  The  MUTUAL-REQUIRED  option  tells  the
+                                  server  that  the client requires mutual
+                                  authentication, and that it must respond
+                                  with a KRB_AP_REP message.
+
+       3-31     RESERVED
+                                  Reserved for future use.
+
+ticket
+     This field is a ticket authenticating the client to the server.
+authenticator
+     This contains the authenticator, which includes the client's choice of
+     a subkey. Its encoding is described in section 5.3.2.
+
+5.5.2. KRB_AP_REP definition
+
+The KRB_AP_REP message contains the Kerberos protocol version number, the
+message type, and an encrypted time- stamp. The message is sent in in
+response to an application request (KRB_AP_REQ) where the mutual
+authentication option has been selected in the ap-options field.
+
+AP-REP ::=         [APPLICATION 15] SEQUENCE {
+                   pvno[0]                           INTEGER,
+                   msg-type[1]                       INTEGER,
+                   enc-part[2]                       EncryptedData
+}
+
+EncAPRepPart ::=   [APPLICATION 27[29]] SEQUENCE {
+                   ctime[0]                          KerberosTime,
+                   cusec[1]                          INTEGER,
+                   subkey[2]                         EncryptionKey OPTIONAL,
+                   seq-number[3]                     INTEGER OPTIONAL
+}
+
+The encoded EncAPRepPart is encrypted in the shared session key of the
+ticket. The optional subkey field can be used in an application-arranged
+negotiation to choose a per association session key.
+
+pvno and msg-type
+     These fields are described above in section 5.4.1. msg-type is
+     KRB_AP_REP.
+enc-part
+     This field is described above in section 5.4.2.
+ctime
+     This field contains the current time on the client's host.
+cusec
+     This field contains the microsecond part of the client's timestamp.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+subkey
+     This field contains an encryption key which is to be used to protect
+     this specific application session. See section 3.2.6 for specifics on
+     how this field is used to negotiate a key. Unless an application
+     specifies otherwise, if this field is left out, the sub-session key
+     from the authenticator, or if also left out, the session key from the
+     ticket will be used.
+
+5.5.3. Error message reply
+
+If an error occurs while processing the application request, the KRB_ERROR
+message will be sent in response. See section 5.9.1 for the format of the
+error message. The cname and crealm fields may be left out if the server
+cannot determine their appropriate values from the corresponding KRB_AP_REQ
+message. If the authenticator was decipherable, the ctime and cusec fields
+will contain the values from it.
+
+5.6. KRB_SAFE message specification
+
+This section specifies the format of a message that can be used by either
+side (client or server) of an application to send a tamper-proof message to
+its peer. It presumes that a session key has previously been exchanged (for
+example, by using the KRB_AP_REQ/KRB_AP_REP messages).
+
+5.6.1. KRB_SAFE definition
+
+The KRB_SAFE message contains user data along with a collision-proof
+checksum keyed with the last encryption key negotiated via subkeys, or the
+session key if no negotiation has occured. The message fields are:
+
+KRB-SAFE ::=        [APPLICATION 20] SEQUENCE {
+                    pvno[0]                       INTEGER,
+                    msg-type[1]                   INTEGER,
+                    safe-body[2]                  KRB-SAFE-BODY,
+                    cksum[3]                      Checksum
+}
+
+KRB-SAFE-BODY ::=   SEQUENCE {
+                    user-data[0]                  OCTET STRING,
+                    timestamp[1]                  KerberosTime OPTIONAL,
+                    usec[2]                       INTEGER OPTIONAL,
+                    seq-number[3]                 INTEGER OPTIONAL,
+                    s-address[4]                  HostAddress OPTIONAL,
+                    r-address[5]                  HostAddress OPTIONAL
+}
+
+pvno and msg-type
+     These fields are described above in section 5.4.1. msg-type is
+     KRB_SAFE.
+safe-body
+     This field is a placeholder for the body of the KRB-SAFE message.
+cksum
+     This field contains the checksum of the application data. Checksum
+     details are described in section 6.4. The checksum is computed over the
+     encoding of the KRB-SAFE sequence. First, the cksum is zeroed and the
+     checksum is computed over the encoding of the KRB-SAFE sequence, then
+     the checksum is set to the result of that computation, and finally the
+     KRB-SAFE sequence is encoded again.
+user-data
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     This field is part of the KRB_SAFE and KRB_PRIV messages and contain
+     the application specific data that is being passed from the sender to
+     the recipient.
+timestamp
+     This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents
+     are the current time as known by the sender of the message. By checking
+     the timestamp, the recipient of the message is able to make sure that
+     it was recently generated, and is not a replay.
+usec
+     This field is part of the KRB_SAFE and KRB_PRIV headers. It contains
+     the microsecond part of the timestamp.
+seq-number
+     This field is described above in section 5.3.2.
+s-address
+     This field specifies the address in use by the sender of the message.
+     It may be omitted if not required by the application protocol. The
+     application designer considering omission of this field is warned, that
+     the inclusion of this address prevents some kinds of replay attacks
+     (e.g., reflection attacks) and that it is only acceptable to omit this
+     address if there is sufficient information in the integrity protected
+     part of the application message for the recipient to unambiguously
+     determine if it was the intended recipient.
+r-address
+     This field specifies the address in use by the recipient of the
+     message. It may be omitted for some uses (such as broadcast protocols),
+     but the recipient may arbitrarily reject such messages. This field
+     along with s-address can be used to help detect messages which have
+     been incorrectly or maliciously delivered to the wrong recipient.
+
+5.7. KRB_PRIV message specification
+
+This section specifies the format of a message that can be used by either
+side (client or server) of an application to securely and privately send a
+message to its peer. It presumes that a session key has previously been
+exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages).
+
+5.7.1. KRB_PRIV definition
+
+The KRB_PRIV message contains user data encrypted in the Session Key. The
+message fields are:
+
+KRB-PRIV ::=         [APPLICATION 21] SEQUENCE {
+                     pvno[0]                           INTEGER,
+                     msg-type[1]                       INTEGER,
+                     enc-part[3]                       EncryptedData
+}
+
+EncKrbPrivPart ::=   [APPLICATION 28[31]] SEQUENCE {
+                     user-data[0]        OCTET STRING,
+                     timestamp[1]        KerberosTime OPTIONAL,
+                     usec[2]             INTEGER OPTIONAL,
+                     seq-number[3]       INTEGER OPTIONAL,
+                     s-address[4]        HostAddress OPTIONAL, -- sender's addr
+                     r-address[5]        HostAddress OPTIONAL -- recip's addr
+}
+
+pvno and msg-type
+     These fields are described above in section 5.4.1. msg-type is
+     KRB_PRIV.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+enc-part
+     This field holds an encoding of the EncKrbPrivPart sequence encrypted
+     under the session key[32]. This encrypted encoding is used for the
+     enc-part field of the KRB-PRIV message. See section 6 for the format of
+     the ciphertext.
+user-data, timestamp, usec, s-address and r-address
+     These fields are described above in section 5.6.1.
+seq-number
+     This field is described above in section 5.3.2.
+
+5.8. KRB_CRED message specification
+
+This section specifies the format of a message that can be used to send
+Kerberos credentials from one principal to another. It is presented here to
+encourage a common mechanism to be used by applications when forwarding
+tickets or providing proxies to subordinate servers. It presumes that a
+session key has already been exchanged perhaps by using the
+KRB_AP_REQ/KRB_AP_REP messages.
+
+5.8.1. KRB_CRED definition
+
+The KRB_CRED message contains a sequence of tickets to be sent and
+information needed to use the tickets, including the session key from each.
+The information needed to use the tickets is encrypted under an encryption
+key previously exchanged or transferred alongside the KRB_CRED message. The
+message fields are:
+
+KRB-CRED         ::= [APPLICATION 22]   SEQUENCE {
+                 pvno[0]                INTEGER,
+                 msg-type[1]            INTEGER, -- KRB_CRED
+                 tickets[2]             SEQUENCE OF Ticket,
+                 enc-part[3]            EncryptedData
+}
+
+EncKrbCredPart   ::= [APPLICATION 29]   SEQUENCE {
+                 ticket-info[0]         SEQUENCE OF KrbCredInfo,
+                 nonce[1]               INTEGER OPTIONAL,
+                 timestamp[2]           KerberosTime OPTIONAL,
+                 usec[3]                INTEGER OPTIONAL,
+                 s-address[4]           HostAddress OPTIONAL,
+                 r-address[5]           HostAddress OPTIONAL
+}
+
+KrbCredInfo      ::=                    SEQUENCE {
+                 key[0]                 EncryptionKey,
+                 prealm[1]              Realm OPTIONAL,
+                 pname[2]               PrincipalName OPTIONAL,
+                 flags[3]               TicketFlags OPTIONAL,
+                 authtime[4]            KerberosTime OPTIONAL,
+                 starttime[5]           KerberosTime OPTIONAL,
+                 endtime[6]             KerberosTime OPTIONAL
+                 renew-till[7]          KerberosTime OPTIONAL,
+                 srealm[8]              Realm OPTIONAL,
+                 sname[9]               PrincipalName OPTIONAL,
+                 caddr[10]              HostAddresses OPTIONAL
+}
+
+pvno and msg-type
+     These fields are described above in section 5.4.1. msg-type is
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     KRB_CRED.
+tickets
+     These are the tickets obtained from the KDC specifically for use by the
+     intended recipient. Successive tickets are paired with the
+     corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED
+     message.
+enc-part
+     This field holds an encoding of the EncKrbCredPart sequence encrypted
+     under the session key shared between the sender and the intended
+     recipient. This encrypted encoding is used for the enc-part field of
+     the KRB-CRED message. See section 6 for the format of the ciphertext.
+nonce
+     If practical, an application may require the inclusion of a nonce
+     generated by the recipient of the message. If the same value is
+     included as the nonce in the message, it provides evidence that the
+     message is fresh and has not been replayed by an attacker. A nonce must
+     never be re-used; it should be generated randomly by the recipient of
+     the message and provided to the sender of the message in an application
+     specific manner.
+timestamp and usec
+     These fields specify the time that the KRB-CRED message was generated.
+     The time is used to provide assurance that the message is fresh.
+s-address and r-address
+     These fields are described above in section 5.6.1. They are used
+     optionally to provide additional assurance of the integrity of the
+     KRB-CRED message.
+key
+     This field exists in the corresponding ticket passed by the KRB-CRED
+     message and is used to pass the session key from the sender to the
+     intended recipient. The field's encoding is described in section 6.2.
+
+The following fields are optional. If present, they can be associated with
+the credentials in the remote ticket file. If left out, then it is assumed
+that the recipient of the credentials already knows their value.
+
+prealm and pname
+     The name and realm of the delegated principal identity.
+flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr
+     These fields contain the values of the correspond- ing fields from the
+     ticket found in the ticket field. Descriptions of the fields are
+     identical to the descriptions in the KDC-REP message.
+
+5.9. Error message specification
+
+This section specifies the format for the KRB_ERROR message. The fields
+included in the message are intended to return as much information as
+possible about an error. It is not expected that all the information
+required by the fields will be available for all types of errors. If the
+appropriate information is not available when the message is composed, the
+corresponding field will be left out of the message.
+
+Note that since the KRB_ERROR message is only optionally integrity
+protected, it is quite possible for an intruder to synthesize or modify such
+a message. In particular, this means that unless appropriate integrity
+protection mechanisms have been applied to the KRB_ERROR message, the client
+should not use any fields in this message for security-critical purposes,
+such as setting a system clock or generating a fresh authenticator. The
+message can be useful, however, for advising a user on the reason for some
+failure.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+5.9.1. KRB_ERROR definition
+
+The KRB_ERROR message consists of the following fields:
+
+KRB-ERROR ::=   [APPLICATION 30] SEQUENCE {
+                pvno[0]                       INTEGER,
+                msg-type[1]                   INTEGER,
+                ctime[2]                      KerberosTime OPTIONAL,
+                cusec[3]                      INTEGER OPTIONAL,
+                stime[4]                      KerberosTime,
+                susec[5]                      INTEGER,
+                error-code[6]                 INTEGER,
+                crealm[7]                     Realm OPTIONAL,
+                cname[8]                      PrincipalName OPTIONAL,
+                realm[9]                      Realm, -- Correct realm
+                sname[10]                     PrincipalName, -- Correct name
+                e-text[11]                    GeneralString OPTIONAL,
+                e-data[12]                    OCTET STRING OPTIONAL,
+                e-cksum[13]                   Checksum OPTIONAL,
+}
+
+
+
+pvno and msg-type
+     These fields are described above in section 5.4.1. msg-type is
+     KRB_ERROR.
+ctime
+     This field is described above in section 5.4.1.
+cusec
+     This field is described above in section 5.5.2.
+stime
+     This field contains the current time on the server. It is of type
+     KerberosTime.
+susec
+     This field contains the microsecond part of the server's timestamp. Its
+     value ranges from 0 to 999999. It appears along with stime. The two
+     fields are used in conjunction to specify a reasonably accurate
+     timestamp.
+error-code
+     This field contains the error code returned by Kerberos or the server
+     when a request fails. To interpret the value of this field see the list
+     of error codes in section 8. Implementations are encouraged to provide
+     for national language support in the display of error messages.
+crealm, cname, srealm and sname
+     These fields are described above in section 5.3.1.
+e-text
+     This field contains additional text to help explain the error code
+     associated with the failed request (for example, it might include a
+     principal name which was unknown).
+e-data
+     This field contains additional data about the error for use by the
+     application to help it recover from or handle the error. If present,
+     this field will contain the encoding of a sequence of TypedData
+     (TYPED-DATA below), unless the errorcode is KDC_ERR_PREAUTH_REQUIRED,
+     in which case it will contain the encoding of a sequence of of padata
+     fields (METHOD-DATA below), each corresponding to an acceptable
+     pre-authentication method and optionally containing data for the
+     method:
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+     TYPED-DATA   ::=   SEQUENCE of TypeData
+     METHOD-DATA  ::=   SEQUENCE of PA-DATA
+
+     TypedData ::=   SEQUENCE {
+                         data-type[0]   INTEGER,
+                         data-value[1]  OCTET STRING OPTIONAL
+     }
+
+     Note that e-data-types have been reserved for all PA data types defined
+     prior to July 1999. For the KDC_ERR_PREAUTH_REQUIRED message, when
+     using new PA data types defined in July 1999 or later, the METHOD-DATA
+     sequence must itself be encapsulated in an TypedData element of type
+     TD-PADATA. All new implementations interpreting the METHOD-DATA field
+     for the KDC_ERR_PREAUTH_REQUIRED message must accept a type of
+     TD-PADATA, extract the typed data field and interpret the use any
+     elements encapsulated in the TD-PADATA elements as if they were present
+     in the METHOD-DATA sequence.
+e-cksum
+     This field contains an optional checksum for the KRB-ERROR message. The
+     checksum is calculated over the Kerberos ASN.1 encoding of the
+     KRB-ERROR message with the checksum absent. The checksum is then added
+     to the KRB-ERROR structure and the message is re-encoded. The Checksum
+     should be calculated using the session key from the ticket granting
+     ticket or service ticket, where available. If the error is in response
+     to a TGS or AP request, the checksum should be calculated uing the the
+     session key from the client's ticket. If the error is in response to an
+     AS request, then the checksum should be calulated using the client's
+     secret key ONLY if there has been suitable preauthentication to prove
+     knowledge of the secret key by the client[33]. If a checksum can not be
+     computed because the key to be used is not available, no checksum will
+     be included.
+
+     6. Encryption and Checksum Specifications
+
+     The Kerberos protocols described in this document are designed to use
+     stream encryption ciphers, which can be simulated using commonly
+     available block encryption ciphers, such as the Data Encryption
+     Standard [DES77], and triple DES variants, in conjunction with block
+     chaining and checksum methods [DESM80]. Encryption is used to prove the
+     identities of the network entities participating in message exchanges.
+     The Key Distribution Center for each realm is trusted by all principals
+     registered in that realm to store a secret key in confidence. Proof of
+     knowledge of this secret key is used to verify the authenticity of a
+     principal.
+
+     The KDC uses the principal's secret key (in the AS exchange) or a
+     shared session key (in the TGS exchange) to encrypt responses to ticket
+     requests; the ability to obtain the secret key or session key implies
+     the knowledge of the appropriate keys and the identity of the KDC. The
+     ability of a principal to decrypt the KDC response and present a Ticket
+     and a properly formed Authenticator (generated with the session key
+     from the KDC response) to a service verifies the identity of the
+     principal; likewise the ability of the service to extract the session
+     key from the Ticket and prove its knowledge thereof in a response
+     verifies the identity of the service.
+
+     The Kerberos protocols generally assume that the encryption used is
+     secure from cryptanalysis; however, in some cases, the order of fields
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     in the encrypted portions of messages are arranged to minimize the
+     effects of poorly chosen keys. It is still important to choose good
+     keys. If keys are derived from user-typed passwords, those passwords
+     need to be well chosen to make brute force attacks more difficult.
+     Poorly chosen keys still make easy targets for intruders.
+
+     The following sections specify the encryption and checksum mechanisms
+     currently defined for Kerberos. The encodings, chaining, and padding
+     requirements for each are described. For encryption methods, it is
+     often desirable to place random information (often referred to as a
+     confounder) at the start of the message. The requirements for a
+     confounder are specified with each encryption mechanism.
+
+     Some encryption systems use a block-chaining method to improve the the
+     security characteristics of the ciphertext. However, these chaining
+     methods often don't provide an integrity check upon decryption. Such
+     systems (such as DES in CBC mode) must be augmented with a checksum of
+     the plain-text which can be verified at decryption and used to detect
+     any tampering or damage. Such checksums should be good at detecting
+     burst errors in the input. If any damage is detected, the decryption
+     routine is expected to return an error indicating the failure of an
+     integrity check. Each encryption type is expected to provide and verify
+     an appropriate checksum. The specification of each encryption method
+     sets out its checksum requirements.
+
+     Finally, where a key is to be derived from a user's password, an
+     algorithm for converting the password to a key of the appropriate type
+     is included. It is desirable for the string to key function to be
+     one-way, and for the mapping to be different in different realms. This
+     is important because users who are registered in more than one realm
+     will often use the same password in each, and it is desirable that an
+     attacker compromising the Kerberos server in one realm not obtain or
+     derive the user's key in another.
+
+     For an discussion of the integrity characteristics of the candidate
+     encryption and checksum methods considered for Kerberos, the reader is
+     referred to [SG92].
+
+     6.1. Encryption Specifications
+
+     The following ASN.1 definition describes all encrypted messages. The
+     enc-part field which appears in the unencrypted part of messages in
+     section 5 is a sequence consisting of an encryption type, an optional
+     key version number, and the ciphertext.
+
+     EncryptedData ::=   SEQUENCE {
+                         etype[0]     INTEGER, -- EncryptionType
+                         kvno[1]      INTEGER OPTIONAL,
+                         cipher[2]    OCTET STRING -- ciphertext
+     }
+
+
+
+     etype
+          This field identifies which encryption algorithm was used to
+          encipher the cipher. Detailed specifications for selected
+          encryption types appear later in this section.
+     kvno
+          This field contains the version number of the key under which data
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+          is encrypted. It is only present in messages encrypted under long
+          lasting keys, such as principals' secret keys.
+     cipher
+          This field contains the enciphered text, encoded as an OCTET
+          STRING.
+     The cipher field is generated by applying the specified encryption
+     algorithm to data composed of the message and algorithm-specific
+     inputs. Encryption mechanisms defined for use with Kerberos must take
+     sufficient measures to guarantee the integrity of the plaintext, and we
+     recommend they also take measures to protect against precomputed
+     dictionary attacks. If the encryption algorithm is not itself capable
+     of doing so, the protections can often be enhanced by adding a checksum
+     and a confounder.
+
+     The suggested format for the data to be encrypted includes a
+     confounder, a checksum, the encoded plaintext, and any necessary
+     padding. The msg-seq field contains the part of the protocol message
+     described in section 5 which is to be encrypted. The confounder,
+     checksum, and padding are all untagged and untyped, and their length is
+     exactly sufficient to hold the appropriate item. The type and length is
+     implicit and specified by the particular encryption type being used
+     (etype). The format for the data to be encrypted for some methods is
+     described in the following diagram, but other methods may deviate from
+     this layour - so long as the definition of the method defines the
+     layout actually in use.
+
+           +-----------+----------+-------------+-----+
+           |confounder |   check  |   msg-seq   | pad |
+           +-----------+----------+-------------+-----+
+
+     The format cannot be described in ASN.1, but for those who prefer an
+     ASN.1-like notation:
+
+     CipherText ::=   ENCRYPTED       SEQUENCE {
+          confounder[0]   UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL,
+          check[1]        UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
+          msg-seq[2]      MsgSequence,
+          pad             UNTAGGED OCTET STRING(pad_length) OPTIONAL
+     }
+
+     One generates a random confounder of the appropriate length, placing it
+     in confounder; zeroes out check; calculates the appropriate checksum
+     over confounder, check, and msg-seq, placing the result in check; adds
+     the necessary padding; then encrypts using the specified encryption
+     type and the appropriate key.
+
+     Unless otherwise specified, a definition of an encryption algorithm
+     that specifies a checksum, a length for the confounder field, or an
+     octet boundary for padding uses this ciphertext format[36]. Those
+     fields which are not specified will be omitted.
+
+     In the interest of allowing all implementations using a particular
+     encryption type to communicate with all others using that type, the
+     specification of an encryption type defines any checksum that is needed
+     as part of the encryption process. If an alternative checksum is to be
+     used, a new encryption type must be defined.
+
+     Some cryptosystems require additional information beyond the key and
+     the data to be encrypted. For example, DES, when used in
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     cipher-block-chaining mode, requires an initialization vector. If
+     required, the description for each encryption type must specify the
+     source of such additional information. 6.2. Encryption Keys
+
+     The sequence below shows the encoding of an encryption key:
+
+            EncryptionKey ::=   SEQUENCE {
+                                keytype[0]    INTEGER,
+                                keyvalue[1]   OCTET STRING
+            }
+
+     keytype
+          This field specifies the type of encryption that is to be
+          performed using the key that follows in the keyvalue field. It
+          will always correspond to the etype to be used to generate or
+          decode the EncryptedData. In cases when multiple algorithms use a
+          common kind of key (e.g., if the encryption algorithm uses an
+          alternate checksum algorithm for an integrity check, or a
+          different chaining mechanism), the keytype provides information
+          needed to determine which algorithm is to be used.
+     keyvalue
+          This field contains the key itself, encoded as an octet string.
+     All negative values for the encryption key type are reserved for local
+     use. All non-negative values are reserved for officially assigned type
+     fields and interpreta- tions.
+
+     6.3. Encryption Systems
+
+     6.3.1. The NULL Encryption System (null)
+
+     If no encryption is in use, the encryption system is said to be the
+     NULL encryption system. In the NULL encryption system there is no
+     checksum, confounder or padding. The ciphertext is simply the
+     plaintext. The NULL Key is used by the null encryption system and is
+     zero octets in length, with keytype zero (0).
+
+     6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)
+
+     The des-cbc-crc encryption mode encrypts information under the Data
+     Encryption Standard [DES77] using the cipher block chaining mode
+     [DESM80]. A CRC-32 checksum (described in ISO 3309 [ISO3309]) is
+     applied to the confounder and message sequence (msg-seq) and placed in
+     the cksum field. DES blocks are 8 bytes. As a result, the data to be
+     encrypted (the concatenation of confounder, checksum, and message) must
+     be padded to an 8 byte boundary before encryption. The details of the
+     encryption of this data are identical to those for the des-cbc-md5
+     encryption mode.
+
+     Note that, since the CRC-32 checksum is not collision-proof, an
+     attacker could use a probabilistic chosen-plaintext attack to generate
+     a valid message even if a confounder is used [SG92]. The use of
+     collision-proof checksums is recommended for environments where such
+     attacks represent a significant threat. The use of the CRC-32 as the
+     checksum for ticket or authenticator is no longer mandated as an
+     interoperability requirement for Kerberos Version 5 Specification 1
+     (See section 9.1 for specific details).
+
+     6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     The des-cbc-md4 encryption mode encrypts information under the Data
+     Encryption Standard [DES77] using the cipher block chaining mode
+     [DESM80]. An MD4 checksum (described in [MD492]) is applied to the
+     confounder and message sequence (msg-seq) and placed in the cksum
+     field. DES blocks are 8 bytes. As a result, the data to be encrypted
+     (the concatenation of confounder, checksum, and message) must be padded
+     to an 8 byte boundary before encryption. The details of the encryption
+     of this data are identical to those for the des-cbc-md5 encryption
+     mode.
+
+     6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
+
+     The des-cbc-md5 encryption mode encrypts information under the Data
+     Encryption Standard [DES77] using the cipher block chaining mode
+     [DESM80]. An MD5 checksum (described in [MD5-92].) is applied to the
+     confounder and message sequence (msg-seq) and placed in the cksum
+     field. DES blocks are 8 bytes. As a result, the data to be encrypted
+     (the concatenation of confounder, checksum, and message) must be padded
+     to an 8 byte boundary before encryption.
+
+     Plaintext and DES ciphtertext are encoded as blocks of 8 octets which
+     are concatenated to make the 64-bit inputs for the DES algorithms. The
+     first octet supplies the 8 most significant bits (with the octet's
+     MSbit used as the DES input block's MSbit, etc.), the second octet the
+     next 8 bits, ..., and the eighth octet supplies the 8 least significant
+     bits.
+
+     Encryption under DES using cipher block chaining requires an additional
+     input in the form of an initialization vector. Unless otherwise
+     specified, zero should be used as the initialization vector. Kerberos'
+     use of DES requires an 8 octet confounder.
+
+     The DES specifications identify some 'weak' and 'semi-weak' keys; those
+     keys shall not be used for encrypting messages for use in Kerberos.
+     Additionally, because of the way that keys are derived for the
+     encryption of checksums, keys shall not be used that yield 'weak' or
+     'semi-weak' keys when eXclusive-ORed with the hexadecimal constant
+     F0F0F0F0F0F0F0F0.
+
+     A DES key is 8 octets of data, with keytype one (1). This consists of
+     56 bits of key, and 8 parity bits (one per octet). The key is encoded
+     as a series of 8 octets written in MSB-first order. The bits within the
+     key are also encoded in MSB order. For example, if the encryption key
+     is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where
+     B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the
+     parity bits, the first octet of the key would be B1,B2,...,B7,P1 (with
+     B1 as the MSbit). [See the FIPS 81 introduction for reference.]
+
+     String to key transformation
+
+     To generate a DES key from a text string (password), a "salt" is
+     concatenated to the text string, and then padded with ASCII nulls to an
+     8 byte boundary. This "salt" is normally the realm and each component
+     of the principal's name appended. However, sometimes different salts
+     are used --- for example, when a realm is renamed, or if a user changes
+     her username, or for compatibility with Kerberos V4 (whose
+     string-to-key algorithm uses a null string for the salt). This string
+     is then fan-folded and eXclusive-ORed with itself to form an 8 byte DES
+     key. Before eXclusive-ORing a block, every byte is shifted one bit to
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     the left to leave the lowest bit zero. The key is the "corrected" by
+     correcting the parity on the key, and if the key matches a 'weak' or
+     'semi-weak' key as described in the DES specification, it is
+     eXclusive-ORed with the constant 00000000000000F0. This key is then
+     used to generate a DES CBC checksum on the initial string (with the
+     salt appended). The result of the CBC checksum is the "corrected" as
+     described above to form the result which is return as the key.
+     Pseudocode follows:
+
+          name_to_default_salt(realm, name) {
+               s = realm
+               for(each component in name) {
+                    s = s + component;
+               }
+               return s;
+          }
+
+          key_correction(key) {
+               fixparity(key);
+               if (is_weak_key_key(key))
+                    key = key XOR 0xF0;
+               return(key);
+          }
+
+          string_to_key(string,salt) {
+
+               odd = 1;
+               s = string + salt;
+               tempkey = NULL;
+               pad(s); /* with nulls to 8 byte boundary */
+               for(8byteblock in s) {
+                    if(odd == 0)  {
+                        odd = 1;
+                        reverse(8byteblock)
+                    }
+                    else odd = 0;
+                    left shift every byte in 8byteblock one bit;
+                    tempkey = tempkey XOR 8byteblock;
+               }
+               tempkey = key_correction(tempkey);
+               key = key_correction(DES-CBC-check(s,tempkey));
+               return(key);
+          }
+
+     6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with and
+     without Key Derivation [Original draft by Marc Horowitz, revisions by
+     David Miller]
+
+     This encryption type is based on the Triple DES cryptosystem, the
+     HMAC-SHA1 [Krawczyk96] message authentication algorithm, and key
+     derivation for Kerberos V5 [HorowitzB96]. Key derivation may or may not
+     be used in conjunction with the use of Triple DES keys.
+
+     Algorithm Identifiers
+
+     The des3-cbc-hmac-sha1 encryption type has been assigned the value 7.
+     The des3-cbc-hmac-sha1-kd encryption type, specifying the key
+     derivation variant of the encryption type, has been assigned the value
+     16. The hmac-sha1-des3 checksum type has been assigned the value 13.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     The hmac-sha1-des3-kd checksum type, specifying the key derivation
+     variant of the checksum, has been assigned the value 12.
+
+     Triple DES Key Production
+
+     The EncryptionKey value is 24 octets long. The 7 most significant bits
+     of each octet contain key bits, and the least significant bit is the
+     inverse of the xor of the key bits.
+
+     For the purposes of key derivation, the block size is 64 bits, and the
+     key size is 168 bits. The 168 bits output by key derivation are
+     converted to an EncryptionKey value as follows. First, the 168 bits are
+     divided into three groups of 56 bits, which are expanded individually
+     into 64 bits as follows:
+
+      1  2  3  4  5  6  7  p
+      9 10 11 12 13 14 15  p
+     17 18 19 20 21 22 23  p
+     25 26 27 28 29 30 31  p
+     33 34 35 36 37 38 39  p
+     41 42 43 44 45 46 47  p
+     49 50 51 52 53 54 55  p
+     56 48 40 32 24 16  8  p
+
+     The "p" bits are parity bits computed over the data bits. The output of
+     the three expansions are concatenated to form the EncryptionKey value.
+
+     When the HMAC-SHA1 of a string is computed, the key is used in the
+     EncryptedKey form.
+
+     The string-to-key function is used to tranform UNICODE passwords into
+     DES3 keys. The DES3 string-to-key function relies on the "N-fold"
+     algorithm, which is detailed in [9]. The description of the N-fold
+     algorithm in that document is as follows:
+        o To n-fold a number X, replicate the input value to a length that
+          is the least common multiple of n and the length of X. Before each
+          repetition, the input is rotated to the right by 13 bit positions.
+          The successive n-bit chunks are added together using
+          1's-complement addition (that is, addition with end-around carry)
+          to yield an n-bit result"
+        o The n-fold algorithm, as with DES string-to-key, is applied to the
+          password string concatenated with a salt value. The salt value is
+          derived in the same was as for the DES string-to-key algorithm.
+          For 3-key triple DES then, the operation will involve a 168-fold
+          of the input password string. The remainder of the string-to-key
+          function for DES3 is shown here in pseudocode:
+
+     DES3string-to-key(passwordString, key)
+
+         salt = name_to_default_salt(realm, name)
+         s = passwordString + salt
+         tmpKey1 = 168-fold(s)
+         parityFix(tmpKey1);
+         if not weakKey(tmpKey1)
+             /*
+              * Encrypt temp key in itself with a
+              * zero initialization vector
+              *
+              * Function signature is DES3encrypt(plain, key, iv)
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+              * with cipher as the return value
+              */
+             tmpKey2 = DES3encrypt(tmpKey1, tmpKey1, zeroIvec)
+             /*
+              * Encrypt resultant temp key in itself with third component
+              * of first temp key as initialization vector
+              */
+             key = DES3encrypt(tmpKey2, tmpKey1, tmpKey1[2])
+             parityFix(key)
+             if not weakKey(key)
+                  return SUCCESS
+             else
+                  return FAILURE
+         else
+             return FAILURE
+
+     The weakKey function above is the same weakKey function used with DES
+     keys, but applied to each of the three single DES keys that comprise
+     the triple DES key.
+
+     The lengths of UNICODE encoded character strings include the trailing
+     terminator character (0).
+
+     Encryption Types des3-cbc-hmac-sha1 and des3-cbc-hmac-sha1-kd
+
+     EncryptedData using this type must be generated as described in
+     [Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC mode.
+     The checksum algorithm is HMAC-SHA1. If the key derivation variant of
+     the encryption type is used, encryption key values are modified
+     according to the method under the Key Derivation section below.
+
+     Unless otherwise specified, a zero IV must be used.
+
+     If the length of the input data is not a multiple of the block size,
+     zero octets must be used to pad the plaintext to the next eight-octet
+     boundary. The counfounder must be eight random octets (one block).
+
+     Checksum Types hmac-sha1-des3 and hmac-sha1-des3-kd
+
+     Checksums using this type must be generated as described in
+     [Horowitz96]. The keyed hash algorithm is HMAC-SHA1. If the key
+     derivation variant of the checksum type is used, checksum key values
+     are modified according to the method under the Key Derivation section
+     below.
+
+     Key Derivation
+
+     In the Kerberos protocol, cryptographic keys are used in a number of
+     places. In order to minimize the effect of compromising a key, it is
+     desirable to use a different key for each of these places. Key
+     derivation [Horowitz96] can be used to construct different keys for
+     each operation from the keys transported on the network. For this to be
+     possible, a small change to the specification is necessary.
+
+     This section specifies a profile for the use of key derivation
+     [Horowitz96] with Kerberos. For each place where a key is used, a ``key
+     usage'' must is specified for that purpose. The key, key usage, and
+     encryption/checksum type together describe the transformation from
+     plaintext to ciphertext, or plaintext to checksum.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+     Key Usage Values
+
+     This is a complete list of places keys are used in the kerberos
+     protocol, with key usage values and RFC 1510 section numbers:
+
+      1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the
+         client key (section 5.4.1)
+      2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or
+         application session key), encrypted with the service key
+         (section 5.4.2)
+      3. AS-REP encrypted part (includes tgs session key or application
+         session key), encrypted with the client key (section 5.4.2)
+      4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
+         session key (section 5.4.1)
+      5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
+         authenticator subkey (section 5.4.1)
+      6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
+         with the tgs session key (sections 5.3.2, 5.4.1)
+      7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs
+         authenticator subkey), encrypted with the tgs session key
+         (section 5.3.2)
+      8. TGS-REP encrypted part (includes application session key),
+         encrypted with the tgs session key (section 5.4.2)
+      9. TGS-REP encrypted part (includes application session key),
+         encrypted with the tgs authenticator subkey (section 5.4.2)
+     10. AP-REQ Authenticator cksum, keyed with the application session
+         key (section 5.3.2)
+     11. AP-REQ Authenticator (includes application authenticator
+         subkey), encrypted with the application session key (section
+         5.3.2)
+     12. AP-REP encrypted part (includes application session subkey),
+         encrypted with the application session key (section 5.5.2)
+     13. KRB-PRIV encrypted part, encrypted with a key chosen by the
+         application (section 5.7.1)
+     14. KRB-CRED encrypted part, encrypted with a key chosen by the
+         application (section 5.6.1)
+     15. KRB-SAVE cksum, keyed with a key chosen by the application
+         (section 5.8.1)
+     18. KRB-ERROR checksum (e-cksum in section 5.9.1)
+     19. AD-KDCIssued checksum (ad-checksum in appendix B.1)
+     20. Checksum for Mandatory Ticket Extensions (appendix B.6)
+     21. Checksum in Authorization Data in Ticket Extensions (appendix B.7)
+
+     Key usage values between 1024 and 2047 (inclusive) are reserved for
+     application use. Applications should use even values for encryption and
+     odd values for checksums within this range.
+
+     A few of these key usages need a little clarification. A service which
+     receives an AP-REQ has no way to know if the enclosed Ticket was part
+     of an AS-REP or TGS-REP. Therefore, key usage 2 must always be used for
+     generating a Ticket, whether it is in response to an AS- REQ or
+     TGS-REQ.
+
+     There might exist other documents which define protocols in terms of
+     the RFC1510 encryption types or checksum types. Such documents would
+     not know about key usages. In order that these documents continue to be
+     meaningful until they are updated, key usages 1024 and 1025 must be
+     used to derive keys for encryption and checksums, respectively. New
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     protocols defined in terms of the Kerberos encryption and checksum
+     types should use their own key usages. Key usages may be registered
+     with IANA to avoid conflicts. Key usages must be unsigned 32 bit
+     integers. Zero is not permitted.
+
+     Defining Cryptosystems Using Key Derivation
+
+     Kerberos requires that the ciphertext component of EncryptedData be
+     tamper-resistant as well as confidential. This implies encryption and
+     integrity functions, which must each use their own separate keys. So,
+     for each key usage, two keys must be generated, one for encryption
+     (Ke), and one for integrity (Ki):
+
+           Ke = DK(protocol key, key usage | 0xAA)
+           Ki = DK(protocol key, key usage | 0x55)
+
+     where the protocol key is from the EncryptionKey from the wire
+     protocol, and the key usage is represented as a 32 bit integer in
+     network byte order. The ciphertest must be generated from the plaintext
+     as follows:
+
+        ciphertext = E(Ke, confounder | plaintext | padding) |
+                     H(Ki, confounder | plaintext | padding)
+
+     The confounder and padding are specific to the encryption algorithm E.
+
+     When generating a checksum only, there is no need for a confounder or
+     padding. Again, a new key (Kc) must be used. Checksums must be
+     generated from the plaintext as follows:
+
+           Kc = DK(protocol key, key usage | 0x99)
+           MAC = H(Kc, plaintext)
+
+     Note that each enctype is described by an encryption algorithm E and a
+     keyed hash algorithm H, and each checksum type is described by a keyed
+     hash algorithm H. HMAC, with an appropriate hash, is required for use
+     as H.
+
+     Key Derivation from Passwords
+
+     The well-known constant for password key derivation must be the byte
+     string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values
+     correspond to the ASCII encoding for the string "kerberos".
+
+     6.4. Checksums
+
+     The following is the ASN.1 definition used for a checksum:
+
+              Checksum ::=   SEQUENCE {
+                             cksumtype[0]   INTEGER,
+                             checksum[1]    OCTET STRING
+              }
+
+     cksumtype
+          This field indicates the algorithm used to generate the
+          accompanying checksum.
+     checksum
+          This field contains the checksum itself, encoded as an octet
+          string.
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     Detailed specification of selected checksum types appear later in this
+     section. Negative values for the checksum type are reserved for local
+     use. All non-negative values are reserved for officially assigned type
+     fields and interpretations.
+
+     Checksums used by Kerberos can be classified by two properties: whether
+     they are collision-proof, and whether they are keyed. It is infeasible
+     to find two plaintexts which generate the same checksum value for a
+     collision-proof checksum. A key is required to perturb or initialize
+     the algorithm in a keyed checksum. To prevent message-stream
+     modification by an active attacker, unkeyed checksums should only be
+     used when the checksum and message will be subsequently encrypted (e.g.
+     the checksums defined as part of the encryption algorithms covered
+     earlier in this section).
+
+     Collision-proof checksums can be made tamper-proof if the checksum
+     value is encrypted before inclusion in a message. In such cases, the
+     composition of the checksum and the encryption algorithm must be
+     considered a separate checksum algorithm (e.g. RSA-MD5 encrypted using
+     DES is a new checksum algorithm of type RSA-MD5-DES). For most keyed
+     checksums, as well as for the encrypted forms of unkeyed
+     collision-proof checksums, Kerberos prepends a confounder before the
+     checksum is calculated.
+
+     6.4.1. The CRC-32 Checksum (crc32)
+
+     The CRC-32 checksum calculates a checksum based on a cyclic redundancy
+     check as described in ISO 3309 [ISO3309]. The resulting checksum is
+     four (4) octets in length. The CRC-32 is neither keyed nor
+     collision-proof. The use of this checksum is not recommended. An
+     attacker using a probabilistic chosen-plaintext attack as described in
+     [SG92] might be able to generate an alternative message that satisfies
+     the checksum. The use of collision-proof checksums is recommended for
+     environments where such attacks represent a significant threat.
+
+     6.4.2. The RSA MD4 Checksum (rsa-md4)
+
+     The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm
+     [MD4-92]. The algorithm takes as input an input message of arbitrary
+     length and produces as output a 128-bit (16 octet) checksum. RSA-MD4 is
+     believed to be collision-proof.
+
+     6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des)
+
+     The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by
+     prepending an 8 octet confounder before the text, applying the RSA MD4
+     checksum algorithm, and encrypting the confounder and the checksum
+     using DES in cipher-block-chaining (CBC) mode using a variant of the
+     key, where the variant is computed by eXclusive-ORing the key with the
+     constant F0F0F0F0F0F0F0F0[39]. The initialization vector should be
+     zero. The resulting checksum is 24 octets long (8 octets of which are
+     redundant). This checksum is tamper-proof and believed to be
+     collision-proof.
+
+     The DES specifications identify some weak keys' and 'semi-weak keys';
+     those keys shall not be used for generating RSA-MD4 checksums for use
+     in Kerberos.
+
+     The format for the checksum is described in the follow- ing diagram:
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     |  des-cbc(confounder   +   rsa-md4(confounder+msg),key=var(key),iv=0)  |
+     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+     The format cannot be described in ASN.1, but for those who prefer an
+     ASN.1-like notation:
+
+     rsa-md4-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
+                                confounder[0]   UNTAGGED OCTET STRING(8),
+                                check[1]        UNTAGGED OCTET STRING(16)
+     }
+
+     6.4.4. The RSA MD5 Checksum (rsa-md5)
+
+     The RSA-MD5 checksum calculates a checksum using the RSA MD5 algorithm.
+     [MD5-92]. The algorithm takes as input an input message of arbitrary
+     length and produces as output a 128-bit (16 octet) checksum. RSA-MD5 is
+     believed to be collision-proof.
+
+     6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des)
+
+     The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by
+     prepending an 8 octet confounder before the text, applying the RSA MD5
+     checksum algorithm, and encrypting the confounder and the checksum
+     using DES in cipher-block-chaining (CBC) mode using a variant of the
+     key, where the variant is computed by eXclusive-ORing the key with the
+     hexadecimal constant F0F0F0F0F0F0F0F0. The initialization vector should
+     be zero. The resulting checksum is 24 octets long (8 octets of which
+     are redundant). This checksum is tamper-proof and believed to be
+     collision-proof.
+
+     The DES specifications identify some 'weak keys' and 'semi-weak keys';
+     those keys shall not be used for encrypting RSA-MD5 checksums for use
+     in Kerberos.
+
+     The format for the checksum is described in the following diagram:
+
+     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     |  des-cbc(confounder   +   rsa-md5(confounder+msg),key=var(key),iv=0)  |
+     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+     The format cannot be described in ASN.1, but for those who prefer an
+     ASN.1-like notation:
+
+     rsa-md5-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
+                                confounder[0]   UNTAGGED OCTET STRING(8),
+                                check[1]        UNTAGGED OCTET STRING(16)
+     }
+
+     6.4.6. DES cipher-block chained checksum (des-mac)
+
+     The DES-MAC checksum is computed by prepending an 8 octet confounder to
+     the plaintext, performing a DES CBC-mode encryption on the result using
+     the key and an initialization vector of zero, taking the last block of
+     the ciphertext, prepending the same confounder and encrypting the pair
+     using DES in cipher-block-chaining (CBC) mode using a a variant of the
+     key, where the variant is computed by eXclusive-ORing the key with the
+     hexadecimal constant F0F0F0F0F0F0F0F0. The initialization vector should
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     be zero. The resulting checksum is 128 bits (16 octets) long, 64 bits
+     of which are redundant. This checksum is tamper-proof and
+     collision-proof.
+
+     The format for the checksum is described in the following diagram:
+
+     +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
+     |   des-cbc(confounder  + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) |
+     +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
+
+     The format cannot be described in ASN.1, but for those who prefer an
+     ASN.1-like notation:
+
+     des-mac-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
+                            confounder[0]   UNTAGGED OCTET STRING(8),
+                            check[1]        UNTAGGED OCTET STRING(8)
+     }
+
+     The DES specifications identify some 'weak' and 'semi-weak' keys; those
+     keys shall not be used for generating DES-MAC checksums for use in
+     Kerberos, nor shall a key be used whose variant is 'weak' or
+     'semi-weak'.
+
+     6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative
+     (rsa-md4-des-k)
+
+     The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum
+     by applying the RSA MD4 checksum algorithm and encrypting the results
+     using DES in cipher-block-chaining (CBC) mode using a DES key as both
+     key and initialization vector. The resulting checksum is 16 octets
+     long. This checksum is tamper-proof and believed to be collision-proof.
+     Note that this checksum type is the old method for encoding the
+     RSA-MD4-DES checksum and it is no longer recommended.
+
+     6.4.8. DES cipher-block chained checksum alternative (des-mac-k)
+
+     The DES-MAC-K checksum is computed by performing a DES CBC-mode
+     encryption of the plaintext, and using the last block of the ciphertext
+     as the checksum value. It is keyed with an encryption key and an
+     initialization vector; any uses which do not specify an additional
+     initialization vector will use the key as both key and initialization
+     vector. The resulting checksum is 64 bits (8 octets) long. This
+     checksum is tamper-proof and collision-proof. Note that this checksum
+     type is the old method for encoding the DES-MAC checksum and it is no
+     longer recommended. The DES specifications identify some 'weak keys'
+     and 'semi-weak keys'; those keys shall not be used for generating
+     DES-MAC checksums for use in Kerberos.
+
+     7. Naming Constraints
+
+     7.1. Realm Names
+
+     Although realm names are encoded as GeneralStrings and although a realm
+     can technically select any name it chooses, interoperability across
+     realm boundaries requires agreement on how realm names are to be
+     assigned, and what information they imply.
+
+     To enforce these conventions, each realm must conform to the
+     conventions itself, and it must require that any realms with which
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     inter-realm keys are shared also conform to the conventions and require
+     the same from its neighbors.
+
+     Kerberos realm names are case sensitive. Realm names that differ only
+     in the case of the characters are not equivalent. There are presently
+     four styles of realm names: domain, X500, other, and reserved. Examples
+     of each style follow:
+
+          domain:   ATHENA.MIT.EDU (example)
+            X500:   C=US/O=OSF (example)
+           other:   NAMETYPE:rest/of.name=without-restrictions (example)
+        reserved:   reserved, but will not conflict with above
+
+     Domain names must look like domain names: they consist of components
+     separated by periods (.) and they contain neither colons (:) nor
+     slashes (/). Domain names must be converted to upper case when used as
+     realm names.
+
+     X.500 names contain an equal (=) and cannot contain a colon (:) before
+     the equal. The realm names for X.500 names will be string
+     representations of the names with components separated by slashes.
+     Leading and trailing slashes will not be included.
+
+     Names that fall into the other category must begin with a prefix that
+     contains no equal (=) or period (.) and the prefix must be followed by
+     a colon (:) and the rest of the name. All prefixes must be assigned
+     before they may be used. Presently none are assigned.
+
+     The reserved category includes strings which do not fall into the first
+     three categories. All names in this category are reserved. It is
+     unlikely that names will be assigned to this category unless there is a
+     very strong argument for not using the 'other' category.
+
+     These rules guarantee that there will be no conflicts between the
+     various name styles. The following additional constraints apply to the
+     assignment of realm names in the domain and X.500 categories: the name
+     of a realm for the domain or X.500 formats must either be used by the
+     organization owning (to whom it was assigned) an Internet domain name
+     or X.500 name, or in the case that no such names are registered,
+     authority to use a realm name may be derived from the authority of the
+     parent realm. For example, if there is no domain name for E40.MIT.EDU,
+     then the administrator of the MIT.EDU realm can authorize the creation
+     of a realm with that name.
+
+     This is acceptable because the organization to which the parent is
+     assigned is presumably the organization authorized to assign names to
+     its children in the X.500 and domain name systems as well. If the
+     parent assigns a realm name without also registering it in the domain
+     name or X.500 hierarchy, it is the parent's responsibility to make sure
+     that there will not in the future exists a name identical to the realm
+     name of the child unless it is assigned to the same entity as the realm
+     name.
+
+     7.2. Principal Names
+
+     As was the case for realm names, conventions are needed to ensure that
+     all agree on what information is implied by a principal name. The
+     name-type field that is part of the principal name indicates the kind
+     of information implied by the name. The name-type should be treated as
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     a hint. Ignoring the name type, no two names can be the same (i.e. at
+     least one of the components, or the realm, must be different). The
+     following name types are defined:
+
+ name-type      value   meaning
+
+  NT-UNKNOWN        0  Name type not known
+  NT-PRINCIPAL      1  General principal name (e.g. username, or DCE principal)
+  NT-SRV-INST       2  Service and other unique instance (krbtgt)
+  NT-SRV-HST        3  Service with host name as instance (telnet, rcommands)
+  NT-SRV-XHST       4  Service with slash-separated host name components
+  NT-UID            5  Unique ID
+  NT-X500-PRINCIPAL 6  Encoded X.509 Distingished name [RFC 1779]
+
+     When a name implies no information other than its uniqueness at a
+     particular time the name type PRINCIPAL should be used. The principal
+     name type should be used for users, and it might also be used for a
+     unique server. If the name is a unique machine generated ID that is
+     guaranteed never to be reassigned then the name type of UID should be
+     used (note that it is generally a bad idea to reassign names of any
+     type since stale entries might remain in access control lists).
+
+     If the first component of a name identifies a service and the remaining
+     components identify an instance of the service in a server specified
+     manner, then the name type of SRV-INST should be used. An example of
+     this name type is the Kerberos ticket-granting service whose name has a
+     first component of krbtgt and a second component identifying the realm
+     for which the ticket is valid.
+
+     If instance is a single component following the service name and the
+     instance identifies the host on which the server is running, then the
+     name type SRV-HST should be used. This type is typically used for
+     Internet services such as telnet and the Berkeley R commands. If the
+     separate components of the host name appear as successive components
+     following the name of the service, then the name type SRV-XHST should
+     be used. This type might be used to identify servers on hosts with
+     X.500 names where the slash (/) might otherwise be ambiguous.
+
+     A name type of NT-X500-PRINCIPAL should be used when a name from an
+     X.509 certificiate is translated into a Kerberos name. The encoding of
+     the X.509 name as a Kerberos principal shall conform to the encoding
+     rules specified in RFC 2253.
+
+     A name type of UNKNOWN should be used when the form of the name is not
+     known. When comparing names, a name of type UNKNOWN will match
+     principals authenticated with names of any type. A principal
+     authenticated with a name of type UNKNOWN, however, will only match
+     other names of type UNKNOWN.
+
+     Names of any type with an initial component of 'krbtgt' are reserved
+     for the Kerberos ticket granting service. See section 8.2.3 for the
+     form of such names.
+
+     7.2.1. Name of server principals
+
+     The principal identifier for a server on a host will generally be
+     composed of two parts: (1) the realm of the KDC with which the server
+     is registered, and (2) a two-component name of type NT-SRV-HST if the
+     host name is an Internet domain name or a multi-component name of type
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     NT-SRV-XHST if the name of the host is of a form such as X.500 that
+     allows slash (/) separators. The first component of the two- or
+     multi-component name will identify the service and the latter
+     components will identify the host. Where the name of the host is not
+     case sensitive (for example, with Internet domain names) the name of
+     the host must be lower case. If specified by the application protocol
+     for services such as telnet and the Berkeley R commands which run with
+     system privileges, the first component may be the string 'host' instead
+     of a service specific identifier. When a host has an official name and
+     one or more aliases, the official name of the host must be used when
+     constructing the name of the server principal.
+
+     8. Constants and other defined values
+
+     8.1. Host address types
+
+     All negative values for the host address type are reserved for local
+     use. All non-negative values are reserved for officially assigned type
+     fields and interpretations.
+
+     The values of the types for the following addresses are chosen to match
+     the defined address family constants in the Berkeley Standard
+     Distributions of Unix. They can be found in with symbolic names AF_xxx
+     (where xxx is an abbreviation of the address family name).
+
+     Internet (IPv4) Addresses
+
+     Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
+     MSB order. The type of IPv4 addresses is two (2).
+
+     Internet (IPv6) Addresses [Westerlund]
+
+     IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order.
+     The type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884].
+     The following addresses (see [RFC1884]) MUST not appear in any Kerberos
+     packet:
+        o the Unspecified Address
+        o the Loopback Address
+        o Link-Local addresses
+     IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
+
+     CHAOSnet addresses
+
+     CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB
+     order. The type of CHAOSnet addresses is five (5).
+
+     ISO addresses
+
+     ISO addresses are variable-length. The type of ISO addresses is seven
+     (7).
+
+     Xerox Network Services (XNS) addresses
+
+     XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order.
+     The type of XNS addresses is six (6).
+
+     AppleTalk Datagram Delivery Protocol (DDP) addresses
+
+     AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     network number. The first octet of the address is the node number; the
+     remaining two octets encode the network number in MSB order. The type
+     of AppleTalk DDP addresses is sixteen (16).
+
+     DECnet Phase IV addresses
+
+     DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order.
+     The type of DECnet Phase IV addresses is twelve (12).
+
+     Netbios addresses
+
+     Netbios addresses are 16-octet addresses typically composed of 1 to 15
+     characters, trailing blank (ascii char 20) filled, with a 16th octet of
+     0x0. The type of Netbios addresses is 20 (0x14).
+
+     8.2. KDC messages
+
+     8.2.1. UDP/IP transport
+
+     When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using
+     UDP IP transport, the client shall send a UDP datagram containing only
+     an encoding of the request to port 88 (decimal) at the KDC's IP
+     address; the KDC will respond with a reply datagram containing only an
+     encoding of the reply message (either a KRB_ERROR or a KRB_KDC_REP) to
+     the sending port at the sender's IP address. Kerberos servers
+     supporting IP transport must accept UDP requests on port 88 (decimal).
+     The response to a request made through UDP/IP transport must also use
+     UDP/IP transport.
+
+     8.2.2. TCP/IP transport [Westerlund,Danielsson]
+
+     Kerberos servers (KDC's) should accept TCP requests on port 88
+     (decimal) and clients should support the sending of TCP requests on
+     port 88 (decimal). When the KRB_KDC_REQ message is sent to the KDC over
+     a TCP stream, a new connection will be established for each
+     authentication exchange (request and response). The KRB_KDC_REP or
+     KRB_ERROR message will be returned to the client on the same TCP stream
+     that was established for the request. The response to a request made
+     through TCP/IP transport must also use TCP/IP transport. Implementors
+     should note that some extentions to the Kerberos protocol will not work
+     if any implementation not supporting the TCP transport is involved
+     (client or KDC). Implementors are strongly urged to support the TCP
+     transport on both the client and server and are advised that the
+     current notation of "should" support will likely change in the future
+     to must support. The KDC may close the TCP stream after sending a
+     response, but may leave the stream open if it expects a followup - in
+     which case it may close the stream at any time if resource constratints
+     or other factors make it desirable to do so. Care must be taken in
+     managing TCP/IP connections with the KDC to prevent denial of service
+     attacks based on the number of TCP/IP connections with the KDC that
+     remain open. If multiple exchanges with the KDC are needed for certain
+     forms of preauthentication, multiple TCP connections may be required. A
+     client may close the stream after receiving response, and should close
+     the stream if it does not expect to send followup messages. The client
+     must be prepared to have the stream closed by the KDC at anytime, in
+     which case it must simply connect again when it is ready to send
+     subsequent messages.
+
+     The first four octets of the TCP stream used to transmit the request
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     request will encode in network byte order the length of the request
+     (KRB_KDC_REQ), and the length will be followed by the request itself.
+     The response will similarly be preceeded by a 4 octet encoding in
+     network byte order of the length of the KRB_KDC_REP or the KRB_ERROR
+     message and will be followed by the KRB_KDC_REP or the KRB_ERROR
+     response. If the sign bit is set on the integer represented by the
+     first 4 octets, then the next 4 octets will be read, extending the
+     length of the field by another 4 octets (less the sign bit which is
+     reserved for future expansion).
+
+     8.2.3. OSI transport
+
+     During authentication of an OSI client to an OSI server, the mutual
+     authentication of an OSI server to an OSI client, the transfer of
+     credentials from an OSI client to an OSI server, or during exchange of
+     private or integrity checked messages, Kerberos protocol messages may
+     be treated as opaque objects and the type of the authentication
+     mechanism will be:
+
+     OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),kerberosv5(2)}
+
+     Depending on the situation, the opaque object will be an authentication
+     header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe
+     message (KRB_SAFE), a private message (KRB_PRIV), or a credentials
+     message (KRB_CRED). The opaque data contains an application code as
+     specified in the ASN.1 description for each message. The application
+     code may be used by Kerberos to determine the message type.
+
+     8.2.3. Name of the TGS
+
+     The principal identifier of the ticket-granting service shall be
+     composed of three parts: (1) the realm of the KDC issuing the TGS
+     ticket (2) a two-part name of type NT-SRV-INST, with the first part
+     "krbtgt" and the second part the name of the realm which will accept
+     the ticket-granting ticket. For example, a ticket-granting ticket
+     issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
+     ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU"
+     (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting ticket
+     issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
+     MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm),
+     ("krbtgt", "MIT.EDU") (name).
+
+     8.3. Protocol constants and associated values
+
+     The following tables list constants used in the protocol and defines
+     their meanings. Ranges are specified in the "specification" section
+     that limit the values of constants for which values are defined here.
+     This allows implementations to make assumptions about the maximum
+     values that will be received for these constants. Implementation
+     receiving values outside the range specified in the "specification"
+     section may reject the request, but they must recover cleanly.
+
+  Encryption type       etype value block size  minimum pad size  confounder size
+  NULL                           0     1           0                 0
+  des-cbc-crc                    1     8           4                 8
+  des-cbc-md4                    2     8           0                 8
+  des-cbc-md5                    3     8           0                 8
+  <reserved>                     4
+  des3-cbc-md5                   5     8           0                 8
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+  <reserved>                     6
+  des3-cbc-sha1                  7     8           0                 8
+  dsaWithSHA1-CmsOID             9                                 (pkinit)
+  md5WithRSAEncryption-CmsOID   10                                 (pkinit)
+  sha1WithRSAEncryption-CmsOID  11                                 (pkinit)
+  rc2CBC-EnvOID                 12                                 (pkinit)
+  rsaEncryption-EnvOID          13                 (pkinit from PKCS#1 v1.5)
+  rsaES-OAEP-ENV-OID            14                 (pkinit from PKCS#1 v2.0)
+  des-ede3-cbc-Env-OID          15                                 (pkinit)
+  des3-cbc-sha1-kd              16                                 (Tom Yu)
+  rc4-hmac                      23                                 (swift)
+  rc4-hmac-exp                  24                                 (swift)
+
+  ENCTYPE_PK_CROSS              48                      (reserved for pkcross)
+  <reserved>                    0x8003
+
+  Checksum type              sumtype value       checksum size
+  CRC32                      1                   4
+  rsa-md4                    2                   16
+  rsa-md4-des                3                   24
+  des-mac                    4                   16
+  des-mac-k                  5                   8
+  rsa-md4-des-k              6                   16 (drop rsa ?)
+  rsa-md5                    7                   16 (drop rsa ?)
+  rsa-md5-des                8                   24 (drop rsa ?)
+  rsa-md5-des3               9                   24 (drop rsa ?)
+  hmac-sha1-des3-kd          12                  20
+  hmac-sha1-des3             13                  20
+
+  padata type                     padata-type value
+
+  PA-TGS-REQ                      1
+  PA-ENC-TIMESTAMP                2
+  PA-PW-SALT                      3
+  <reserved>                      4
+  PA-ENC-UNIX-TIME                5                  (depricated)
+  PA-SANDIA-SECUREID              6
+  PA-SESAME                       7
+  PA-OSF-DCE                      8
+  PA-CYBERSAFE-SECUREID           9
+  PA-AFS3-SALT                    10
+  PA-ETYPE-INFO                   11
+  PA-SAM-CHALLENGE                12                  (sam/otp)
+  PA-SAM-RESPONSE                 13                  (sam/otp)
+  PA-PK-AS-REQ                    14                  (pkinit)
+  PA-PK-AS-REP                    15                  (pkinit)
+  PA-USE-SPECIFIED-KVNO           20
+  PA-SAM-REDIRECT                 21                  (sam/otp)
+  PA-GET-FROM-TYPED-DATA          22
+  PA-SAM-ETYPE-INFO               23                  (sam/otp)
+
+data-type                     value    form of typed-data
+
+<reserved>                      1-21
+TD-PADATA                       22
+TD-PKINIT-CMS-CERTIFICATES      101      CertificateSet from CMS
+TD-KRB-PRINCIPAL                102
+TD-KRB-REALM                    103
+TD-TRUSTED-CERTIFIERS           104
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+TD-CERTIFICATE-INDEX            105
+
+authorization data type         ad-type value
+AD-IF-RELEVANT                     1
+AD-INTENDED-FOR-SERVER             2
+AD-INTENDED-FOR-APPLICATION-CLASS  3
+AD-KDC-ISSUED                      4
+AD-OR                              5
+AD-MANDATORY-TICKET-EXTENSIONS     6
+AD-IN-TICKET-EXTENSIONS            7
+reserved values                    8-63
+OSF-DCE                            64
+SESAME                             65
+AD-OSF-DCE-PKI-CERTID              66         (hemsath@us.ibm.com)
+
+Ticket Extension Types
+
+TE-TYPE-NULL                  0      Null ticket extension
+TE-TYPE-EXTERNAL-ADATA        1      Integrity protected authorization data
+<reserved>                    2      TE-TYPE-PKCROSS-KDC  (I have reservations)
+TE-TYPE-PKCROSS-CLIENT        3      PKCROSS cross realm key ticket
+TE-TYPE-CYBERSAFE-EXT         4      Assigned to CyberSafe Corp
+<reserved>                    5      TE-TYPE-DEST-HOST (I have reservations)
+
+alternate authentication type   method-type value
+reserved values                 0-63
+ATT-CHALLENGE-RESPONSE          64
+
+transited encoding type         tr-type value
+DOMAIN-X500-COMPRESS            1
+reserved values                 all others
+
+Label               Value   Meaning or MIT code
+
+pvno                    5   current Kerberos protocol version number
+
+message types
+
+KRB_AS_REQ             10   Request for initial authentication
+KRB_AS_REP             11   Response to KRB_AS_REQ request
+KRB_TGS_REQ            12   Request for authentication based on TGT
+KRB_TGS_REP            13   Response to KRB_TGS_REQ request
+KRB_AP_REQ             14   application request to server
+KRB_AP_REP             15   Response to KRB_AP_REQ_MUTUAL
+KRB_SAFE               20   Safe (checksummed) application message
+KRB_PRIV               21   Private (encrypted) application message
+KRB_CRED               22   Private (encrypted) message to forward credentials
+KRB_ERROR              30   Error response
+
+name types
+
+KRB_NT_UNKNOWN        0  Name type not known
+KRB_NT_PRINCIPAL      1  Just the name of the principal as in DCE, or for users
+KRB_NT_SRV_INST       2  Service and other unique instance (krbtgt)
+KRB_NT_SRV_HST        3  Service with host name as instance (telnet, rcommands)
+KRB_NT_SRV_XHST       4  Service with host as remaining components
+KRB_NT_UID            5  Unique ID
+KRB_NT_X500_PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+error codes
+
+KDC_ERR_NONE                    0   No error
+KDC_ERR_NAME_EXP                1   Client's entry in database has expired
+KDC_ERR_SERVICE_EXP             2   Server's entry in database has expired
+KDC_ERR_BAD_PVNO                3   Requested prot vers number not supported
+KDC_ERR_C_OLD_MAST_KVNO         4   Client's key encrypted in old master key
+KDC_ERR_S_OLD_MAST_KVNO         5   Server's key encrypted in old master key
+KDC_ERR_C_PRINCIPAL_UNKNOWN     6   Client not found in Kerberos database
+KDC_ERR_S_PRINCIPAL_UNKNOWN     7   Server not found in Kerberos database
+KDC_ERR_PRINCIPAL_NOT_UNIQUE    8   Multiple principal entries in database
+KDC_ERR_NULL_KEY                9   The client or server has a null key
+KDC_ERR_CANNOT_POSTDATE        10   Ticket not eligible for postdating
+KDC_ERR_NEVER_VALID            11   Requested start time is later than end time
+KDC_ERR_POLICY                 12   KDC policy rejects request
+KDC_ERR_BADOPTION              13   KDC cannot accommodate requested option
+KDC_ERR_ETYPE_NOSUPP           14   KDC has no support for encryption type
+KDC_ERR_SUMTYPE_NOSUPP         15   KDC has no support for checksum type
+KDC_ERR_PADATA_TYPE_NOSUPP     16   KDC has no support for padata type
+KDC_ERR_TRTYPE_NOSUPP          17   KDC has no support for transited type
+KDC_ERR_CLIENT_REVOKED         18   Clients credentials have been revoked
+KDC_ERR_SERVICE_REVOKED        19   Credentials for server have been revoked
+KDC_ERR_TGT_REVOKED            20   TGT has been revoked
+KDC_ERR_CLIENT_NOTYET          21   Client not yet valid - try again later
+KDC_ERR_SERVICE_NOTYET         22   Server not yet valid - try again later
+KDC_ERR_KEY_EXPIRED            23   Password has expired - change password
+KDC_ERR_PREAUTH_FAILED         24   Pre-authentication information was invalid
+KDC_ERR_PREAUTH_REQUIRED       25   Additional pre-authenticationrequired [40]
+KDC_ERR_SERVER_NOMATCH         26   Requested server and ticket don't match
+KDC_ERR_MUST_USE_USER2USER     27   Server principal valid for user2user only
+KDC_ERR_PATH_NOT_ACCPETED      28   KDC Policy rejects transited path
+KDC_ERR_SVC_UNAVAILABLE        29   A service is not available
+KRB_AP_ERR_BAD_INTEGRITY       31   Integrity check on decrypted field failed
+KRB_AP_ERR_TKT_EXPIRED         32   Ticket expired
+KRB_AP_ERR_TKT_NYV             33   Ticket not yet valid
+KRB_AP_ERR_REPEAT              34   Request is a replay
+KRB_AP_ERR_NOT_US              35   The ticket isn't for us
+KRB_AP_ERR_BADMATCH            36   Ticket and authenticator don't match
+KRB_AP_ERR_SKEW                37   Clock skew too great
+KRB_AP_ERR_BADADDR             38   Incorrect net address
+KRB_AP_ERR_BADVERSION          39   Protocol version mismatch
+KRB_AP_ERR_MSG_TYPE            40   Invalid msg type
+KRB_AP_ERR_MODIFIED            41   Message stream modified
+KRB_AP_ERR_BADORDER            42   Message out of order
+KRB_AP_ERR_BADKEYVER           44   Specified version of key is not available
+KRB_AP_ERR_NOKEY               45   Service key not available
+KRB_AP_ERR_MUT_FAIL            46   Mutual authentication failed
+KRB_AP_ERR_BADDIRECTION        47   Incorrect message direction
+KRB_AP_ERR_METHOD              48   Alternative authentication method required
+KRB_AP_ERR_BADSEQ              49   Incorrect sequence number in message
+KRB_AP_ERR_INAPP_CKSUM         50   Inappropriate type of checksum in message
+KRB_AP_PATH_NOT_ACCEPTED       51   Policy rejects transited path
+KRB_ERR_RESPONSE_TOO_BIG       52   Response too big for UDP, retry with TCP
+KRB_ERR_GENERIC                60   Generic error (description in e-text)
+KRB_ERR_FIELD_TOOLONG          61   Field is too long for this implementation
+KDC_ERROR_CLIENT_NOT_TRUSTED            62 (pkinit)
+KDC_ERROR_KDC_NOT_TRUSTED               63 (pkinit)
+KDC_ERROR_INVALID_SIG                   64 (pkinit)
+KDC_ERR_KEY_TOO_WEAK                    65 (pkinit)
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+KDC_ERR_CERTIFICATE_MISMATCH            66 (pkinit)
+KRB_AP_ERR_NO_TGT                       67 (user-to-user)
+KDC_ERR_WRONG_REALM                     68 (user-to-user)
+KRB_AP_ERR_USER_TO_USER_REQUIRED        69 (user-to-user)
+KDC_ERR_CANT_VERIFY_CERTIFICATE         70 (pkinit)
+KDC_ERR_INVALID_CERTIFICATE             71 (pkinit)
+KDC_ERR_REVOKED_CERTIFICATE             72 (pkinit)
+KDC_ERR_REVOCATION_STATUS_UNKNOWN       73 (pkinit)
+KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74 (pkinit)
+KDC_ERR_CLIENT_NAME_MISMATCH            75 (pkinit)
+KDC_ERR_KDC_NAME_MISMATCH               76 (pkinit)
+
+     9. Interoperability requirements
+
+     Version 5 of the Kerberos protocol supports a myriad of options. Among
+     these are multiple encryption and checksum types, alternative encoding
+     schemes for the transited field, optional mechanisms for
+     pre-authentication, the handling of tickets with no addresses, options
+     for mutual authentication, user to user authentication, support for
+     proxies, forwarding, postdating, and renewing tickets, the format of
+     realm names, and the handling of authorization data.
+
+     In order to ensure the interoperability of realms, it is necessary to
+     define a minimal configuration which must be supported by all
+     implementations. This minimal configuration is subject to change as
+     technology does. For example, if at some later date it is discovered
+     that one of the required encryption or checksum algorithms is not
+     secure, it will be replaced.
+
+     9.1. Specification 2
+
+     This section defines the second specification of these options.
+     Implementations which are configured in this way can be said to support
+     Kerberos Version 5 Specification 2 (5.1). Specification 1 (depricated)
+     may be found in RFC1510.
+
+     Transport
+
+     TCP/IP and UDP/IP transport must be supported by KDCs claiming
+     conformance to specification 2. Kerberos clients claiming conformance
+     to specification 2 must support UDP/IP transport for messages with the
+     KDC and should support TCP/IP transport.
+
+     Encryption and checksum methods
+
+     The following encryption and checksum mechanisms must be supported.
+     Implementations may support other mechanisms as well, but the
+     additional mechanisms may only be used when communicating with
+     principals known to also support them: This list is to be determined.
+
+     Encryption: DES-CBC-MD5, one triple des variant (tbd)
+     Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 (tbd)
+
+     Realm Names
+
+     All implementations must understand hierarchical realms in both the
+     Internet Domain and the X.500 style. When a ticket granting ticket for
+     an unknown realm is requested, the KDC must be able to determine the
+     names of the intermediate realms between the KDCs realm and the
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     requested realm.
+
+     Transited field encoding
+
+     DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported.
+     Alternative encodings may be supported, but they may be used only when
+     that encoding is supported by ALL intermediate realms.
+
+     Pre-authentication methods
+
+     The TGS-REQ method must be supported. The TGS-REQ method is not used on
+     the initial request. The PA-ENC-TIMESTAMP method must be supported by
+     clients but whether it is enabled by default may be determined on a
+     realm by realm basis. If not used in the initial request and the error
+     KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an
+     acceptable method, the client should retry the initial request using
+     the PA-ENC-TIMESTAMP preauthentication method. Servers need not support
+     the PA-ENC-TIMESTAMP method, but if not supported the server should
+     ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a
+     request.
+
+     Mutual authentication
+
+     Mutual authentication (via the KRB_AP_REP message) must be supported.
+
+     Ticket addresses and flags
+
+     All KDC's must pass on tickets that carry no addresses (i.e. if a TGT
+     contains no addresses, the KDC will return derivative tickets), but
+     each realm may set its own policy for issuing such tickets, and each
+     application server will set its own policy with respect to accepting
+     them.
+
+     Proxies and forwarded tickets must be supported. Individual realms and
+     application servers can set their own policy on when such tickets will
+     be accepted.
+
+     All implementations must recognize renewable and postdated tickets, but
+     need not actually implement them. If these options are not supported,
+     the starttime and endtime in the ticket shall specify a ticket's entire
+     useful life. When a postdated ticket is decoded by a server, all
+     implementations shall make the presence of the postdated flag visible
+     to the calling server.
+
+     User-to-user authentication
+
+     Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC
+     option) must be provided by implementations, but individual realms may
+     decide as a matter of policy to reject such requests on a per-principal
+     or realm-wide basis.
+
+     Authorization data
+
+     Implementations must pass all authorization data subfields from
+     ticket-granting tickets to any derivative tickets unless directed to
+     suppress a subfield as part of the definition of that registered
+     subfield type (it is never incorrect to pass on a subfield, and no
+     registered subfield types presently specify suppression at the KDC).
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     Implementations must make the contents of any authorization data
+     subfields available to the server when a ticket is used.
+     Implementations are not required to allow clients to specify the
+     contents of the authorization data fields.
+
+     Constant ranges
+
+     All protocol constants are constrained to 32 bit (signed) values unless
+     further constrained by the protocol definition. This limit is provided
+     to allow implementations to make assumptions about the maximum values
+     that will be received for these constants. Implementation receiving
+     values outside this range may reject the request, but they must recover
+     cleanly.
+
+     9.2. Recommended KDC values
+
+     Following is a list of recommended values for a KDC implementation,
+     based on the list of suggested configuration constants (see section
+     4.4).
+
+     minimum lifetime              5 minutes
+     maximum renewable lifetime    1 week
+     maximum ticket lifetime       1 day
+     empty addresses               only when suitable  restrictions  appear
+                                   in authorization data
+     proxiable, etc.               Allowed.
+
+     10. REFERENCES
+
+     [NT94]    B. Clifford Neuman and Theodore Y. Ts'o, "An  Authenti-
+               cation  Service for Computer Networks," IEEE Communica-
+               tions Magazine, Vol. 32(9), pp. 33-38 (September 1994).
+
+     [MNSS87]  S. P. Miller, B. C. Neuman, J. I. Schiller, and  J.  H.
+               Saltzer,  Section  E.2.1:  Kerberos  Authentication and
+               Authorization System, M.I.T. Project Athena, Cambridge,
+               Massachusetts (December 21, 1987).
+
+     [SNS88]   J. G. Steiner, B. C. Neuman, and J. I. Schiller,  "Ker-
+               beros:  An Authentication Service for Open Network Sys-
+               tems," pp. 191-202 in  Usenix  Conference  Proceedings,
+               Dallas, Texas (February, 1988).
+
+     [NS78]    Roger M.  Needham  and  Michael  D.  Schroeder,  "Using
+               Encryption for Authentication in Large Networks of Com-
+               puters,"  Communications  of  the  ACM,  Vol.   21(12),
+               pp. 993-999 (December, 1978).
+
+     [DS81]    Dorothy E. Denning and  Giovanni  Maria  Sacco,  "Time-
+               stamps  in  Key Distribution Protocols," Communications
+               of the ACM, Vol. 24(8), pp. 533-536 (August 1981).
+
+     [KNT92]   John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o,
+               "The Evolution of the Kerberos Authentication Service,"
+               in an IEEE Computer Society Text soon to  be  published
+               (June 1992).
+
+     [Neu93]   B.  Clifford  Neuman,  "Proxy-Based  Authorization  and
+               Accounting  for Distributed Systems," in Proceedings of
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+               the 13th International Conference on  Distributed  Com-
+               puting Systems, Pittsburgh, PA (May, 1993).
+
+     [DS90]    Don Davis and Ralph Swick,  "Workstation  Services  and
+               Kerberos  Authentication  at Project Athena," Technical
+               Memorandum TM-424,  MIT Laboratory for Computer Science
+               (February 1990).
+
+     [LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E.  Som-
+               merfeld,  and  K. Raeburn, Section E.1: Service Manage-
+               ment System, M.I.T.  Project  Athena,  Cambridge,  Mas-
+               sachusetts (1987).
+
+     [X509-88] CCITT, Recommendation X.509: The Directory  Authentica-
+               tion Framework, December 1988.
+
+     [Pat92].  J. Pato, Using  Pre-Authentication  to  Avoid  Password
+               Guessing  Attacks, Open Software Foundation DCE Request
+               for Comments 26 (December 1992).
+
+     [DES77]   National Bureau of Standards, U.S. Department  of  Com-
+               merce,  "Data Encryption Standard," Federal Information
+               Processing Standards Publication  46,   Washington,  DC
+               (1977).
+
+     [DESM80]  National Bureau of Standards, U.S. Department  of  Com-
+               merce,  "DES  Modes  of Operation," Federal Information
+               Processing Standards Publication 81,   Springfield,  VA
+               (December 1980).
+
+     [SG92]    Stuart G. Stubblebine and Virgil D. Gligor, "On Message
+               Integrity  in  Cryptographic Protocols," in Proceedings
+               of the IEEE  Symposium  on  Research  in  Security  and
+               Privacy, Oakland, California (May 1992).
+
+     [IS3309]  International Organization  for  Standardization,  "ISO
+               Information  Processing  Systems - Data Communication -
+               High-Level Data Link Control Procedure -  Frame  Struc-
+               ture," IS 3309 (October 1984).  3rd Edition.
+
+     [MD4-92]  R. Rivest, "The  MD4  Message  Digest  Algorithm,"  RFC
+               1320,   MIT  Laboratory  for  Computer  Science  (April
+               1992).
+
+     [MD5-92]  R. Rivest, "The  MD5  Message  Digest  Algorithm,"  RFC
+               1321,   MIT  Laboratory  for  Computer  Science  (April
+               1992).
+
+     [KBC96]   H. Krawczyk, M. Bellare, and R. Canetti, "HMAC:  Keyed-
+               Hashing  for  Message  Authentication,"  Working  Draft
+               draft-ietf-ipsec-hmac-md5-01.txt,   (August 1996).
+
+     [Horowitz96] Horowitz, M., "Key Derivation for Authentication,
+               Integrity, and Privacy", draft-horowitz-key-derivation-02.txt,
+               August 1998.
+
+     [HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft-
+               horowitz-kerb-key-derivation-01.txt, September 1998.
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC:
+               Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac-
+               md5-01.txt, August, 1996.
+
+     A. Pseudo-code for protocol processing
+
+     This appendix provides pseudo-code describing how the messages are to
+     be constructed and interpreted by clients and servers.
+
+     A.1. KRB_AS_REQ generation
+
+             request.pvno := protocol version; /* pvno = 5 */
+             request.msg-type := message type; /* type = KRB_AS_REQ */
+
+             if(pa_enc_timestamp_required) then
+                     request.padata.padata-type = PA-ENC-TIMESTAMP;
+                     get system_time;
+                     padata-body.patimestamp,pausec = system_time;
+                     encrypt padata-body into request.padata.padata-value
+                             using client.key; /* derived from password */
+             endif
+
+             body.kdc-options := users's preferences;
+             body.cname := user's name;
+             body.realm := user's realm;
+             body.sname := service's name; /* usually "krbtgt", 
+                                              "localrealm" */
+
+             if (body.kdc-options.POSTDATED is set) then
+                     body.from := requested starting time;
+             else
+                     omit body.from;
+             endif
+             body.till := requested end time;
+             if (body.kdc-options.RENEWABLE is set) then
+                     body.rtime := requested final renewal time;
+             endif
+             body.nonce := random_nonce();
+             body.etype := requested etypes;
+             if (user supplied addresses) then
+                     body.addresses := user's addresses;
+             else
+                     omit body.addresses;
+             endif
+             omit body.enc-authorization-data;
+             request.req-body := body;
+
+             kerberos := lookup(name of local kerberos server (or servers));
+             send(packet,kerberos);
+
+             wait(for response);
+             if (timed_out) then
+                     retry or use alternate server;
+             endif
+
+     A.2. KRB_AS_REQ verification and KRB_AS_REP generation
+
+             decode message into req;
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+             client := lookup(req.cname,req.realm);
+             server := lookup(req.sname,req.realm);
+
+             get system_time;
+             kdc_time := system_time.seconds;
+
+             if (!client) then
+                     /* no client in Database */
+                     error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
+             endif
+             if (!server) then
+                     /* no server in Database */
+                     error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
+             endif
+
+             if(client.pa_enc_timestamp_required and
+                pa_enc_timestamp not present) then
+                     error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
+             endif
+
+             if(pa_enc_timestamp present) then
+                     decrypt req.padata-value into decrypted_enc_timestamp
+                             using client.key;
+                             using auth_hdr.authenticator.subkey;
+                     if (decrypt_error()) then
+                             error_out(KRB_AP_ERR_BAD_INTEGRITY);
+                     if(decrypted_enc_timestamp is not within allowable skew) 
+                         then
+                             error_out(KDC_ERR_PREAUTH_FAILED);
+                     endif
+                     if(decrypted_enc_timestamp and usec is replay)
+                             error_out(KDC_ERR_PREAUTH_FAILED);
+                     endif
+                     add decrypted_enc_timestamp and usec to replay cache;
+             endif
+
+             use_etype := first supported etype in req.etypes;
+
+             if (no support for req.etypes) then
+                     error_out(KDC_ERR_ETYPE_NOSUPP);
+             endif
+
+             new_tkt.vno := ticket version; /* = 5 */
+             new_tkt.sname := req.sname;
+             new_tkt.srealm := req.srealm;
+             reset all flags in new_tkt.flags;
+
+             /* It should be noted that local policy may affect the  */
+             /* processing of any of these flags.  For example, some */
+             /* realms may refuse to issue renewable tickets         */
+
+             if (req.kdc-options.FORWARDABLE is set) then
+                     set new_tkt.flags.FORWARDABLE;
+             endif
+             if (req.kdc-options.PROXIABLE is set) then
+                     set new_tkt.flags.PROXIABLE;
+             endif
+
+             if (req.kdc-options.ALLOW-POSTDATE is set) then
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                     set new_tkt.flags.MAY-POSTDATE;
+             endif
+             if ((req.kdc-options.RENEW is set) or
+                 (req.kdc-options.VALIDATE is set) or
+                 (req.kdc-options.PROXY is set) or
+                 (req.kdc-options.FORWARDED is set) or
+                 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then
+                     error_out(KDC_ERR_BADOPTION);
+             endif
+
+             new_tkt.session := random_session_key();
+             new_tkt.cname := req.cname;
+             new_tkt.crealm := req.crealm;
+             new_tkt.transited := empty_transited_field();
+
+             new_tkt.authtime := kdc_time;
+
+             if (req.kdc-options.POSTDATED is set) then
+                if (against_postdate_policy(req.from)) then
+                     error_out(KDC_ERR_POLICY);
+                endif
+                set new_tkt.flags.POSTDATED;
+                set new_tkt.flags.INVALID;
+                new_tkt.starttime := req.from;
+             else
+                omit new_tkt.starttime; /* treated as authtime when omitted */
+             endif
+             if (req.till = 0) then
+                     till := infinity;
+             else
+                     till := req.till;
+             endif
+
+             new_tkt.endtime := min(till,
+                                   new_tkt.starttime+client.max_life,
+                                   new_tkt.starttime+server.max_life,
+                                   new_tkt.starttime+max_life_for_realm);
+
+             if ((req.kdc-options.RENEWABLE-OK is set) and
+                 (new_tkt.endtime < req.till)) then
+                     /* we set the RENEWABLE option for later processing */
+                     set req.kdc-options.RENEWABLE;
+                     req.rtime := req.till;
+             endif
+
+             if (req.rtime = 0) then
+                     rtime := infinity;
+             else
+                     rtime := req.rtime;
+             endif
+
+             if (req.kdc-options.RENEWABLE is set) then
+                     set new_tkt.flags.RENEWABLE;
+                     new_tkt.renew-till := min(rtime,
+                                     new_tkt.starttime+client.max_rlife,
+                                     new_tkt.starttime+server.max_rlife,
+                                     new_tkt.starttime+max_rlife_for_realm);
+             else
+                     omit new_tkt.renew-till; /* only present if RENEWABLE */
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+             endif
+
+             if (req.addresses) then
+                     new_tkt.caddr := req.addresses;
+             else
+                     omit new_tkt.caddr;
+             endif
+
+             new_tkt.authorization_data := empty_authorization_data();
+
+             encode to-be-encrypted part of ticket into OCTET STRING;
+             new_tkt.enc-part := encrypt OCTET STRING
+                  using etype_for_key(server.key), server.key, server.p_kvno;
+
+             /* Start processing the response */
+
+             resp.pvno := 5;
+             resp.msg-type := KRB_AS_REP;
+             resp.cname := req.cname;
+             resp.crealm := req.realm;
+             resp.ticket := new_tkt;
+
+             resp.key := new_tkt.session;
+             resp.last-req := fetch_last_request_info(client);
+             resp.nonce := req.nonce;
+             resp.key-expiration := client.expiration;
+             resp.flags := new_tkt.flags;
+
+             resp.authtime := new_tkt.authtime;
+             resp.starttime := new_tkt.starttime;
+             resp.endtime := new_tkt.endtime;
+
+             if (new_tkt.flags.RENEWABLE) then
+                     resp.renew-till := new_tkt.renew-till;
+             endif
+
+             resp.realm := new_tkt.realm;
+             resp.sname := new_tkt.sname;
+
+             resp.caddr := new_tkt.caddr;
+
+             encode body of reply into OCTET STRING;
+
+             resp.enc-part := encrypt OCTET STRING
+                              using use_etype, client.key, client.p_kvno;
+             send(resp);
+
+     A.3. KRB_AS_REP verification
+
+             decode response into resp;
+
+             if (resp.msg-type = KRB_ERROR) then
+                  if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then
+                             set pa_enc_timestamp_required;
+                             goto KRB_AS_REQ;
+                     endif
+                     process_error(resp);
+                     return;
+             endif
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+
+             /* On error, discard the response, and zero the session key */
+             /* from the response immediately */
+
+             key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype,
+                                      resp.padata);
+             unencrypted part of resp := decode of decrypt of resp.enc-part
+                                     using resp.enc-part.etype and key;
+             zero(key);
+
+             if (common_as_rep_tgs_rep_checks fail) then
+                     destroy resp.key;
+                     return error;
+             endif
+
+             if near(resp.princ_exp) then
+                     print(warning message);
+             endif
+             save_for_later(ticket,session,client,server,times,flags);
+
+     A.4. KRB_AS_REP and KRB_TGS_REP common checks
+
+             if (decryption_error() or
+                 (req.cname != resp.cname) or
+                 (req.realm != resp.crealm) or
+                 (req.sname != resp.sname) or
+                 (req.realm != resp.realm) or
+                 (req.nonce != resp.nonce) or
+                 (req.addresses != resp.caddr)) then
+                     destroy resp.key;
+                     return KRB_AP_ERR_MODIFIED;
+             endif
+
+      /* make sure no flags are set that shouldn't be, and that all that */
+      /* should be are set                                               */
+         if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then
+                     destroy resp.key;
+                     return KRB_AP_ERR_MODIFIED;
+             endif
+
+             if ((req.from = 0) and
+                 (resp.starttime is not within allowable skew)) then
+                     destroy resp.key;
+                     return KRB_AP_ERR_SKEW;
+             endif
+             if ((req.from != 0) and (req.from != resp.starttime)) then
+                     destroy resp.key;
+                     return KRB_AP_ERR_MODIFIED;
+             endif
+             if ((req.till != 0) and (resp.endtime > req.till)) then
+                     destroy resp.key;
+                     return KRB_AP_ERR_MODIFIED;
+             endif
+
+             if ((req.kdc-options.RENEWABLE is set) and
+                 (req.rtime != 0) and (resp.renew-till > req.rtime)) then
+                     destroy resp.key;
+                     return KRB_AP_ERR_MODIFIED;
+             endif
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+             if ((req.kdc-options.RENEWABLE-OK is set) and
+                 (resp.flags.RENEWABLE) and
+                 (req.till != 0) and
+                 (resp.renew-till > req.till)) then
+                     destroy resp.key;
+                     return KRB_AP_ERR_MODIFIED;
+             endif
+
+     A.5. KRB_TGS_REQ generation
+
+       /* Note that make_application_request might have to recursivly     */
+       /* call this routine to get the appropriate ticket-granting ticket */
+
+             request.pvno := protocol version; /* pvno = 5 */
+             request.msg-type := message type; /* type = KRB_TGS_REQ */
+
+             body.kdc-options := users's preferences;
+             /* If the TGT is not for the realm of the end-server  */
+             /* then the sname will be for a TGT for the end-realm */
+             /* and the realm of the requested ticket (body.realm) */
+             /* will be that of the TGS to which the TGT we are    */
+             /* sending applies                                    */
+             body.sname := service's name;
+             body.realm := service's realm;
+
+             if (body.kdc-options.POSTDATED is set) then
+                     body.from := requested starting time;
+             else
+                     omit body.from;
+             endif
+             body.till := requested end time;
+             if (body.kdc-options.RENEWABLE is set) then
+                     body.rtime := requested final renewal time;
+             endif
+             body.nonce := random_nonce();
+             body.etype := requested etypes;
+             if (user supplied addresses) then
+                     body.addresses := user's addresses;
+             else
+                     omit body.addresses;
+             endif
+
+             body.enc-authorization-data := user-supplied data;
+             if (body.kdc-options.ENC-TKT-IN-SKEY) then
+                     body.additional-tickets_ticket := second TGT;
+             endif
+
+             request.req-body := body;
+             check := generate_checksum (req.body,checksumtype);
+
+             request.padata[0].padata-type := PA-TGS-REQ;
+             request.padata[0].padata-value := create a KRB_AP_REQ using
+                                           the TGT and checksum
+
+             /* add in any other padata as required/supplied */
+
+             kerberos := lookup(name of local kerberose server (or servers));
+             send(packet,kerberos);
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+             wait(for response);
+             if (timed_out) then
+                     retry or use alternate server;
+             endif
+
+     A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation
+
+             /* note that reading the application request requires first
+             determining the server for which a ticket was issued, and
+             choosing the correct key for decryption.  The name of the
+             server appears in the plaintext part of the ticket. */
+
+             if (no KRB_AP_REQ in req.padata) then
+                     error_out(KDC_ERR_PADATA_TYPE_NOSUPP);
+             endif
+             verify KRB_AP_REQ in req.padata;
+
+             /* Note that the realm in which the Kerberos server is
+             operating is determined by the instance from the
+             ticket-granting ticket.  The realm in the ticket-granting
+             ticket is the realm under which the ticket granting
+             ticket was issued.  It is possible for a single Kerberos 
+             server to support more than one realm. */
+
+             auth_hdr := KRB_AP_REQ;
+             tgt := auth_hdr.ticket;
+
+             if (tgt.sname is not a TGT for local realm and is not req.sname) 
+                   then
+                     error_out(KRB_AP_ERR_NOT_US);
+
+             realm := realm_tgt_is_for(tgt);
+
+             decode remainder of request;
+
+             if (auth_hdr.authenticator.cksum is missing) then
+                     error_out(KRB_AP_ERR_INAPP_CKSUM);
+             endif
+
+             if (auth_hdr.authenticator.cksum type is not supported) then
+                     error_out(KDC_ERR_SUMTYPE_NOSUPP);
+             endif
+             if (auth_hdr.authenticator.cksum is not both collision-proof 
+                 and keyed) then
+                     error_out(KRB_AP_ERR_INAPP_CKSUM);
+             endif
+
+             set computed_checksum := checksum(req);
+             if (computed_checksum != auth_hdr.authenticatory.cksum) then
+                     error_out(KRB_AP_ERR_MODIFIED);
+             endif
+
+             server := lookup(req.sname,realm);
+
+             if (!server) then
+                     if (is_foreign_tgt_name(req.sname)) then
+                             server := best_intermediate_tgs(req.sname);
+                     else
+                             /* no server in Database */
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                             error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
+                     endif
+             endif
+
+             session := generate_random_session_key();
+
+             use_etype := first supported etype in req.etypes;
+
+             if (no support for req.etypes) then
+                     error_out(KDC_ERR_ETYPE_NOSUPP);
+             endif
+
+             new_tkt.vno := ticket version; /* = 5 */
+             new_tkt.sname := req.sname;
+             new_tkt.srealm := realm;
+             reset all flags in new_tkt.flags;
+
+             /* It should be noted that local policy may affect the  */
+             /* processing of any of these flags.  For example, some */
+             /* realms may refuse to issue renewable tickets         */
+
+             new_tkt.caddr := tgt.caddr;
+             resp.caddr := NULL; /* We only include this if they change */
+             if (req.kdc-options.FORWARDABLE is set) then
+                     if (tgt.flags.FORWARDABLE is reset) then
+                             error_out(KDC_ERR_BADOPTION);
+                     endif
+                     set new_tkt.flags.FORWARDABLE;
+             endif
+             if (req.kdc-options.FORWARDED is set) then
+                     if (tgt.flags.FORWARDABLE is reset) then
+                             error_out(KDC_ERR_BADOPTION);
+                     endif
+                     set new_tkt.flags.FORWARDED;
+                     new_tkt.caddr := req.addresses;
+                     resp.caddr := req.addresses;
+             endif
+             if (tgt.flags.FORWARDED is set) then
+                     set new_tkt.flags.FORWARDED;
+             endif
+
+             if (req.kdc-options.PROXIABLE is set) then
+                     if (tgt.flags.PROXIABLE is reset)
+                             error_out(KDC_ERR_BADOPTION);
+                     endif
+                     set new_tkt.flags.PROXIABLE;
+             endif
+             if (req.kdc-options.PROXY is set) then
+                     if (tgt.flags.PROXIABLE is reset) then
+                             error_out(KDC_ERR_BADOPTION);
+                     endif
+                     set new_tkt.flags.PROXY;
+                     new_tkt.caddr := req.addresses;
+                     resp.caddr := req.addresses;
+             endif
+
+             if (req.kdc-options.ALLOW-POSTDATE is set) then
+                     if (tgt.flags.MAY-POSTDATE is reset)
+                             error_out(KDC_ERR_BADOPTION);
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                     endif
+                     set new_tkt.flags.MAY-POSTDATE;
+             endif
+             if (req.kdc-options.POSTDATED is set) then
+                     if (tgt.flags.MAY-POSTDATE is reset) then
+                             error_out(KDC_ERR_BADOPTION);
+                     endif
+                     set new_tkt.flags.POSTDATED;
+                     set new_tkt.flags.INVALID;
+                     if (against_postdate_policy(req.from)) then
+                             error_out(KDC_ERR_POLICY);
+                     endif
+                     new_tkt.starttime := req.from;
+             endif
+
+             if (req.kdc-options.VALIDATE is set) then
+                     if (tgt.flags.INVALID is reset) then
+                             error_out(KDC_ERR_POLICY);
+                     endif
+                     if (tgt.starttime > kdc_time) then
+                             error_out(KRB_AP_ERR_NYV);
+                     endif
+                     if (check_hot_list(tgt)) then
+                             error_out(KRB_AP_ERR_REPEAT);
+                     endif
+                     tkt := tgt;
+                     reset new_tkt.flags.INVALID;
+             endif
+
+             if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW,
+                                  and those already processed) is set) then
+                     error_out(KDC_ERR_BADOPTION);
+             endif
+
+             new_tkt.authtime := tgt.authtime;
+
+             if (req.kdc-options.RENEW is set) then
+      /* Note that if the endtime has already passed, the ticket would  */
+      /* have been rejected in the initial authentication stage, so     */
+      /* there is no need to check again here                           */
+                     if (tgt.flags.RENEWABLE is reset) then
+                             error_out(KDC_ERR_BADOPTION);
+                     endif
+                     if (tgt.renew-till < kdc_time) then
+                             error_out(KRB_AP_ERR_TKT_EXPIRED);
+                     endif
+                     tkt := tgt;
+                     new_tkt.starttime := kdc_time;
+                     old_life := tgt.endttime - tgt.starttime;
+                     new_tkt.endtime := min(tgt.renew-till,
+                                            new_tkt.starttime + old_life);
+             else
+                     new_tkt.starttime := kdc_time;
+                     if (req.till = 0) then
+                             till := infinity;
+                     else
+                             till := req.till;
+                     endif
+                     new_tkt.endtime := min(till,
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                                            new_tkt.starttime+client.max_life,
+                                            new_tkt.starttime+server.max_life,
+                                            new_tkt.starttime+max_life_for_realm,
+                                            tgt.endtime);
+
+                     if ((req.kdc-options.RENEWABLE-OK is set) and
+                         (new_tkt.endtime < req.till) and
+                         (tgt.flags.RENEWABLE is set) then
+                             /* we set the RENEWABLE option for later processing */
+                             set req.kdc-options.RENEWABLE;
+                             req.rtime := min(req.till, tgt.renew-till);
+                     endif
+             endif
+
+             if (req.rtime = 0) then
+                     rtime := infinity;
+             else
+                     rtime := req.rtime;
+             endif
+
+             if ((req.kdc-options.RENEWABLE is set) and
+                 (tgt.flags.RENEWABLE is set)) then
+                     set new_tkt.flags.RENEWABLE;
+                     new_tkt.renew-till := min(rtime,
+                                       new_tkt.starttime+client.max_rlife,
+                                       new_tkt.starttime+server.max_rlife,
+                                       new_tkt.starttime+max_rlife_for_realm,
+                                       tgt.renew-till);
+             else
+                     new_tkt.renew-till := OMIT; /* leave the
+                                                   renew-till field out */ 
+             endif
+             if (req.enc-authorization-data is present) then
+                     decrypt req.enc-authorization-data into
+                                  decrypted_authorization_data
+                             using auth_hdr.authenticator.subkey;
+                     if (decrypt_error()) then
+                             error_out(KRB_AP_ERR_BAD_INTEGRITY);
+                     endif
+             endif
+             new_tkt.authorization_data :=
+                     req.auth_hdr.ticket.authorization_data + 
+                                      decrypted_authorization_data;
+
+             new_tkt.key := session;
+             new_tkt.crealm := tgt.crealm;
+             new_tkt.cname := req.auth_hdr.ticket.cname;
+
+             if (realm_tgt_is_for(tgt) := tgt.realm) then
+                     /* tgt issued by local realm */
+                     new_tkt.transited := tgt.transited;
+             else
+                     /* was issued for this realm by some other realm */
+                     if (tgt.transited.tr-type not supported) then
+                             error_out(KDC_ERR_TRTYPE_NOSUPP);
+                     endif
+                     new_tkt.transited :=
+                         compress_transited(tgt.transited + tgt.realm) 
+                     /* Don't check tranited field if TGT for foreign realm,
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                      * or requested not to check */
+                     if (is_not_foreign_tgt_name(new_tkt.server)
+                        && req.kdc-options.DISABLE-TRANSITED-CHECK not
+                             set) then 
+                          /* Check it, so end-server does not have to
+                           * but don't fail, end-server may still accept it */
+                          if (check_transited_field(new_tkt.transited) == OK)
+                                   set new_tkt.flags.TRANSITED-POLICY-CHECKED;
+                             endif
+                     endif
+             endif
+
+             encode encrypted part of new_tkt into OCTET STRING;
+             if (req.kdc-options.ENC-TKT-IN-SKEY is set) then
+                     if (server not specified) then
+                             server = req.second_ticket.client;
+                     endif
+                     if ((req.second_ticket is not a TGT) or
+                         (req.second_ticket.client != server)) then
+                             error_out(KDC_ERR_POLICY);
+                     endif
+
+                     new_tkt.enc-part := encrypt OCTET STRING using
+                             using etype_for_key(second-ticket.key),
+                             second-ticket.key; 
+             else
+                     new_tkt.enc-part := encrypt OCTET STRING
+                             using etype_for_key(server.key),
+                             server.key, server.p_kvno; 
+             endif
+
+             resp.pvno := 5;
+             resp.msg-type := KRB_TGS_REP;
+             resp.crealm := tgt.crealm;
+             resp.cname := tgt.cname;
+             resp.ticket := new_tkt;
+
+             resp.key := session;
+             resp.nonce := req.nonce;
+             resp.last-req := fetch_last_request_info(client);
+             resp.flags := new_tkt.flags;
+
+             resp.authtime := new_tkt.authtime;
+             resp.starttime := new_tkt.starttime;
+             resp.endtime := new_tkt.endtime;
+
+             omit resp.key-expiration;
+
+             resp.sname := new_tkt.sname;
+             resp.realm := new_tkt.realm;
+
+             if (new_tkt.flags.RENEWABLE) then
+                     resp.renew-till := new_tkt.renew-till;
+             endif
+
+             encode body of reply into OCTET STRING;
+
+             if (req.padata.authenticator.subkey)
+                     resp.enc-part := encrypt OCTET STRING using use_etype,
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                             req.padata.authenticator.subkey;
+             else resp.enc-part := encrypt OCTET STRING using
+                                         use_etype, tgt.key; 
+
+             send(resp);
+
+     A.7. KRB_TGS_REP verification
+
+             decode response into resp;
+
+             if (resp.msg-type = KRB_ERROR) then
+                     process_error(resp);
+                     return;
+             endif
+
+             /* On error, discard the response, and zero the session key from
+             the response immediately */
+
+             if (req.padata.authenticator.subkey)
+                     unencrypted part of resp := decode of decrypt of
+                             resp.enc-part 
+                             using resp.enc-part.etype and subkey;
+             else unencrypted part of resp := decode of decrypt of
+                              resp.enc-part 
+                                     using resp.enc-part.etype and
+                                      tgt's session key; 
+             if (common_as_rep_tgs_rep_checks fail) then
+                     destroy resp.key;
+                     return error;
+             endif
+
+             check authorization_data as necessary;
+             save_for_later(ticket,session,client,server,times,flags);
+
+     A.8. Authenticator generation
+
+             body.authenticator-vno := authenticator vno; /* = 5 */
+             body.cname, body.crealm := client name;
+             if (supplying checksum) then
+                     body.cksum := checksum;
+             endif
+             get system_time;
+             body.ctime, body.cusec := system_time;
+             if (selecting sub-session key) then
+                     select sub-session key;
+                     body.subkey := sub-session key;
+             endif
+             if (using sequence numbers) then
+                     select initial sequence number;
+                     body.seq-number := initial sequence;
+             endif
+
+     A.9. KRB_AP_REQ generation
+
+             obtain ticket and session_key from cache;
+
+             packet.pvno := protocol version; /* 5 */
+             packet.msg-type := message type; /* KRB_AP_REQ */
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+             if (desired(MUTUAL_AUTHENTICATION)) then
+                     set packet.ap-options.MUTUAL-REQUIRED;
+             else
+                     reset packet.ap-options.MUTUAL-REQUIRED;
+             endif
+             if (using session key for ticket) then
+                     set packet.ap-options.USE-SESSION-KEY;
+             else
+                     reset packet.ap-options.USE-SESSION-KEY;
+             endif
+             packet.ticket := ticket; /* ticket */
+             generate authenticator;
+             encode authenticator into OCTET STRING;
+             encrypt OCTET STRING into packet.authenticator using session_key;
+
+     A.10. KRB_AP_REQ verification
+
+             receive packet;
+             if (packet.pvno != 5) then
+                     either process using other protocol spec
+                     or error_out(KRB_AP_ERR_BADVERSION);
+             endif
+             if (packet.msg-type != KRB_AP_REQ) then
+                     error_out(KRB_AP_ERR_MSG_TYPE);
+             endif
+             if (packet.ticket.tkt_vno != 5) then
+                     either process using other protocol spec
+                     or error_out(KRB_AP_ERR_BADVERSION);
+             endif
+             if (packet.ap_options.USE-SESSION-KEY is set) then
+                     retrieve session key from ticket-granting ticket for
+                      packet.ticket.{sname,srealm,enc-part.etype};
+             else
+                     retrieve service key for
+                   packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; 
+             endif
+             if (no_key_available) then
+                     if (cannot_find_specified_skvno) then
+                             error_out(KRB_AP_ERR_BADKEYVER);
+                     else
+                             error_out(KRB_AP_ERR_NOKEY);
+                     endif
+             endif
+             decrypt packet.ticket.enc-part into decr_ticket using
+                      retrieved key; 
+             if (decryption_error()) then
+                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
+             endif
+             decrypt packet.authenticator into decr_authenticator
+                     using decr_ticket.key;
+             if (decryption_error()) then
+                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
+             endif
+             if (decr_authenticator.{cname,crealm} !=
+                 decr_ticket.{cname,crealm}) then
+                     error_out(KRB_AP_ERR_BADMATCH);
+             endif
+             if (decr_ticket.caddr is present) then
+                     if (sender_address(packet) is not in
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                                    decr_ticket.caddr) then 
+                             error_out(KRB_AP_ERR_BADADDR);
+                     endif
+             elseif (application requires addresses) then
+                     error_out(KRB_AP_ERR_BADADDR);
+             endif
+             if (not in_clock_skew(decr_authenticator.ctime,
+                                   decr_authenticator.cusec)) then
+                     error_out(KRB_AP_ERR_SKEW);
+             endif
+             if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then
+                     error_out(KRB_AP_ERR_REPEAT);
+             endif
+             save_identifier(decr_authenticator.{ctime,cusec,cname,crealm});
+             get system_time;
+             if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or
+                 (decr_ticket.flags.INVALID is set)) then
+                     /* it hasn't yet become valid */
+                     error_out(KRB_AP_ERR_TKT_NYV);
+             endif
+             if (system_time-decr_ticket.endtime > CLOCK_SKEW) then
+                     error_out(KRB_AP_ERR_TKT_EXPIRED);
+             endif
+             if (decr_ticket.transited) then
+                 /* caller may ignore the TRANSITED-POLICY-CHECKED and do
+                  * check anyway */
+                 if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then
+                      if (check_transited_field(decr_ticket.transited) then
+                           error_out(KDC_AP_PATH_NOT_ACCPETED);
+                      endif
+                 endif
+             endif
+           /* caller must check decr_ticket.flags for any pertinent details */
+           return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED);
+
+     A.11. KRB_AP_REP generation
+
+             packet.pvno := protocol version; /* 5 */
+             packet.msg-type := message type; /* KRB_AP_REP */
+
+             body.ctime := packet.ctime;
+             body.cusec := packet.cusec;
+             if (selecting sub-session key) then
+                     select sub-session key;
+                     body.subkey := sub-session key;
+             endif
+             if (using sequence numbers) then
+                     select initial sequence number;
+                     body.seq-number := initial sequence;
+             endif
+
+             encode body into OCTET STRING;
+
+             select encryption type;
+             encrypt OCTET STRING into packet.enc-part;
+
+     A.12. KRB_AP_REP verification
+
+             receive packet;
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+             if (packet.pvno != 5) then
+                     either process using other protocol spec
+                     or error_out(KRB_AP_ERR_BADVERSION);
+             endif
+             if (packet.msg-type != KRB_AP_REP) then
+                     error_out(KRB_AP_ERR_MSG_TYPE);
+             endif
+             cleartext := decrypt(packet.enc-part) using ticket's session key;
+             if (decryption_error()) then
+                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
+             endif
+             if (cleartext.ctime != authenticator.ctime) then
+                     error_out(KRB_AP_ERR_MUT_FAIL);
+             endif
+             if (cleartext.cusec != authenticator.cusec) then
+                     error_out(KRB_AP_ERR_MUT_FAIL);
+             endif
+             if (cleartext.subkey is present) then
+                     save cleartext.subkey for future use;
+             endif
+             if (cleartext.seq-number is present) then
+                     save cleartext.seq-number for future verifications;
+             endif
+             return(AUTHENTICATION_SUCCEEDED);
+
+     A.13. KRB_SAFE generation
+
+             collect user data in buffer;
+
+             /* assemble packet: */
+             packet.pvno := protocol version; /* 5 */
+             packet.msg-type := message type; /* KRB_SAFE */
+
+             body.user-data := buffer; /* DATA */
+             if (using timestamp) then
+                     get system_time;
+                     body.timestamp, body.usec := system_time;
+             endif
+             if (using sequence numbers) then
+                     body.seq-number := sequence number;
+             endif
+             body.s-address := sender host addresses;
+             if (only one recipient) then
+                     body.r-address := recipient host address;
+             endif
+             checksum.cksumtype := checksum type;
+             compute checksum over body;
+             checksum.checksum := checksum value; /* checksum.checksum */
+             packet.cksum := checksum;
+             packet.safe-body := body;
+
+     A.14. KRB_SAFE verification
+
+             receive packet;
+             if (packet.pvno != 5) then
+                     either process using other protocol spec
+                     or error_out(KRB_AP_ERR_BADVERSION);
+             endif
+             if (packet.msg-type != KRB_SAFE) then
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                     error_out(KRB_AP_ERR_MSG_TYPE);
+             endif
+             if (packet.checksum.cksumtype is not both collision-proof
+                 and keyed) then 
+                     error_out(KRB_AP_ERR_INAPP_CKSUM);
+             endif
+             if (safe_priv_common_checks_ok(packet)) then
+                     set computed_checksum := checksum(packet.body);
+                     if (computed_checksum != packet.checksum) then
+                             error_out(KRB_AP_ERR_MODIFIED);
+                     endif
+                     return (packet, PACKET_IS_GENUINE);
+             else
+                     return common_checks_error;
+             endif
+
+     A.15. KRB_SAFE and KRB_PRIV common checks
+
+             if (packet.s-address != O/S_sender(packet)) then
+                     /* O/S report of sender not who claims to have sent it */
+                     error_out(KRB_AP_ERR_BADADDR);
+             endif
+             if ((packet.r-address is present) and
+                 (packet.r-address != local_host_address)) then
+                     /* was not sent to proper place */
+                     error_out(KRB_AP_ERR_BADADDR);
+             endif
+             if (((packet.timestamp is present) and
+                  (not in_clock_skew(packet.timestamp,packet.usec))) or
+                 (packet.timestamp is not present and timestamp expected)) then
+                     error_out(KRB_AP_ERR_SKEW);
+             endif
+             if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
+                     error_out(KRB_AP_ERR_REPEAT);
+             endif
+
+             if (((packet.seq-number is present) and
+                  ((not in_sequence(packet.seq-number)))) or
+                 (packet.seq-number is not present and sequence expected)) then
+                     error_out(KRB_AP_ERR_BADORDER);
+             endif
+             if (packet.timestamp not present and packet.seq-number
+                   not present) then 
+                     error_out(KRB_AP_ERR_MODIFIED);
+             endif
+
+             save_identifier(packet.{timestamp,usec,s-address},
+                             sender_principal(packet));
+
+             return PACKET_IS_OK;
+
+     A.16. KRB_PRIV generation
+
+             collect user data in buffer;
+
+             /* assemble packet: */
+             packet.pvno := protocol version; /* 5 */
+             packet.msg-type := message type; /* KRB_PRIV */
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+             packet.enc-part.etype := encryption type;
+
+             body.user-data := buffer;
+             if (using timestamp) then
+                     get system_time;
+                     body.timestamp, body.usec := system_time;
+             endif
+             if (using sequence numbers) then
+                     body.seq-number := sequence number;
+             endif
+             body.s-address := sender host addresses;
+             if (only one recipient) then
+                     body.r-address := recipient host address;
+             endif
+
+             encode body into OCTET STRING;
+
+             select encryption type;
+             encrypt OCTET STRING into packet.enc-part.cipher;
+
+     A.17. KRB_PRIV verification
+
+             receive packet;
+             if (packet.pvno != 5) then
+                     either process using other protocol spec
+                     or error_out(KRB_AP_ERR_BADVERSION);
+             endif
+             if (packet.msg-type != KRB_PRIV) then
+                     error_out(KRB_AP_ERR_MSG_TYPE);
+             endif
+
+             cleartext := decrypt(packet.enc-part) using negotiated key;
+             if (decryption_error()) then
+                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
+             endif
+
+             if (safe_priv_common_checks_ok(cleartext)) then
+                     return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED);
+             else
+                     return common_checks_error;
+             endif
+
+     A.18. KRB_CRED generation
+
+             invoke KRB_TGS; /* obtain tickets to be provided to peer */
+
+             /* assemble packet: */
+             packet.pvno := protocol version; /* 5 */
+             packet.msg-type := message type; /* KRB_CRED */
+
+             for (tickets[n] in tickets to be forwarded) do
+                     packet.tickets[n] = tickets[n].ticket;
+             done
+
+             packet.enc-part.etype := encryption type;
+
+             for (ticket[n] in tickets to be forwarded) do
+                     body.ticket-info[n].key = tickets[n].session;
+                     body.ticket-info[n].prealm = tickets[n].crealm;
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+                     body.ticket-info[n].pname = tickets[n].cname;
+                     body.ticket-info[n].flags = tickets[n].flags;
+                     body.ticket-info[n].authtime = tickets[n].authtime;
+                     body.ticket-info[n].starttime = tickets[n].starttime;
+                     body.ticket-info[n].endtime = tickets[n].endtime;
+                     body.ticket-info[n].renew-till = tickets[n].renew-till;
+                     body.ticket-info[n].srealm = tickets[n].srealm;
+                     body.ticket-info[n].sname = tickets[n].sname;
+                     body.ticket-info[n].caddr = tickets[n].caddr;
+             done
+
+             get system_time;
+             body.timestamp, body.usec := system_time;
+
+             if (using nonce) then
+                     body.nonce := nonce;
+             endif
+
+             if (using s-address) then
+                     body.s-address := sender host addresses;
+             endif
+             if (limited recipients) then
+                     body.r-address := recipient host address;
+             endif
+
+             encode body into OCTET STRING;
+
+             select encryption type;
+             encrypt OCTET STRING into packet.enc-part.cipher
+                    using negotiated encryption key;
+
+     A.19. KRB_CRED verification
+
+             receive packet;
+             if (packet.pvno != 5) then
+                     either process using other protocol spec
+                     or error_out(KRB_AP_ERR_BADVERSION);
+             endif
+             if (packet.msg-type != KRB_CRED) then
+                     error_out(KRB_AP_ERR_MSG_TYPE);
+             endif
+
+             cleartext := decrypt(packet.enc-part) using negotiated key;
+             if (decryption_error()) then
+                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
+             endif
+             if ((packet.r-address is present or required) and
+                (packet.s-address != O/S_sender(packet)) then
+                     /* O/S report of sender not who claims to have sent it */
+                     error_out(KRB_AP_ERR_BADADDR);
+             endif
+             if ((packet.r-address is present) and
+                 (packet.r-address != local_host_address)) then
+                     /* was not sent to proper place */
+                     error_out(KRB_AP_ERR_BADADDR);
+             endif
+             if (not in_clock_skew(packet.timestamp,packet.usec)) then
+                     error_out(KRB_AP_ERR_SKEW);
+             endif
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+             if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
+                     error_out(KRB_AP_ERR_REPEAT);
+             endif
+             if (packet.nonce is required or present) and
+                (packet.nonce != expected-nonce) then
+                     error_out(KRB_AP_ERR_MODIFIED);
+             endif
+
+             for (ticket[n] in tickets that were forwarded) do
+                     save_for_later(ticket[n],key[n],principal[n],
+                                    server[n],times[n],flags[n]);
+             return
+
+     A.20. KRB_ERROR generation
+
+             /* assemble packet: */
+             packet.pvno := protocol version; /* 5 */
+             packet.msg-type := message type; /* KRB_ERROR */
+
+             get system_time;
+             packet.stime, packet.susec := system_time;
+             packet.realm, packet.sname := server name;
+
+             if (client time available) then
+                     packet.ctime, packet.cusec := client_time;
+             endif
+             packet.error-code := error code;
+             if (client name available) then
+                     packet.cname, packet.crealm := client name;
+             endif
+             if (error text available) then
+                     packet.e-text := error text;
+             endif
+             if (error data available) then
+                     packet.e-data := error data;
+             endif
+
+     B. Definition of common authorization data elements
+
+     This appendix contains the definitions of common authorization data
+     elements. These common authorization data elements are recursivly
+     defined, meaning the ad-data for these types will itself contain a
+     sequence of authorization data whose interpretation is affected by the
+     encapsulating element. Depending on the meaning of the encapsulating
+     element, the encapsulated elements may be ignored, might be interpreted
+     as issued directly by the KDC, or they might be stored in a separate
+     plaintext part of the ticket. The types of the encapsulating elements
+     are specified as part of the Kerberos specification because the
+     behavior based on these values should be understood across
+     implementations whereas other elements need only be understood by the
+     applications which they affect.
+
+     In the definitions that follow, the value of the ad-type for the
+     element will be specified in the subsection number, and the value of
+     the ad-data will be as shown in the ASN.1 structure that follows the
+     subsection heading.
+
+     B.1. If relevant
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     AD-IF-RELEVANT   AuthorizationData
+
+     AD elements encapsulated within the if-relevant element are intended
+     for interpretation only by application servers that understand the
+     particular ad-type of the embedded element. Application servers that do
+     not understand the type of an element embedded within the if-relevant
+     element may ignore the uninterpretable element. This element promotes
+     interoperability across implementations which may have local extensions
+     for authorization.
+
+     B.2. Intended for server
+
+     AD-INTENDED-FOR-SERVER   SEQUENCE {
+              intended-server[0]     SEQUENCE OF PrincipalName
+              elements[1]            AuthorizationData
+     }
+
+     AD elements encapsulated within the intended-for-server element may be
+     ignored if the application server is not in the list of principal names
+     of intended servers. Further, a KDC issuing a ticket for an application
+     server can remove this element if the application server is not in the
+     list of intended servers.
+
+     Application servers should check for their principal name in the
+     intended-server field of this element. If their principal name is not
+     found, this element should be ignored. If found, then the encapsulated
+     elements should be evaluated in the same manner as if they were present
+     in the top level authorization data field. Applications and application
+     servers that do not implement this element should reject tickets that
+     contain authorization data elements of this type.
+
+     B.3. Intended for application class
+
+     AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE {
+     intended-application-class[0] SEQUENCE OF GeneralString elements[1]
+     AuthorizationData } AD elements encapsulated within the
+     intended-for-application-class element may be ignored if the
+     application server is not in one of the named classes of application
+     servers. Examples of application server classes include "FILESYSTEM",
+     and other kinds of servers.
+
+     This element and the elements it encapulates may be safely ignored by
+     applications, application servers, and KDCs that do not implement this
+     element.
+
+     B.4. KDC Issued
+
+     AD-KDCIssued   SEQUENCE {
+                    ad-checksum[0]    Checksum,
+                     i-realm[1]       Realm OPTIONAL,
+                     i-sname[2]       PrincipalName OPTIONAL,
+                    elements[3]       AuthorizationData.
+     }
+
+     ad-checksum
+          A checksum over the elements field using a cryptographic checksum
+          method that is identical to the checksum used to protect the
+          ticket itself (i.e. using the same hash function and the same
+          encryption algorithm used to encrypt the ticket) and using a key
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+          derived from the same key used to protect the ticket.
+     i-realm, i-sname
+          The name of the issuing principal if different from the KDC
+          itself. This field would be used when the KDC can verify the
+          authenticity of elements signed by the issuing principal and it
+          allows this KDC to notify the application server of the validity
+          of those elements.
+     elements
+          A sequence of authorization data elements issued by the KDC.
+     The KDC-issued ad-data field is intended to provide a means for
+     Kerberos principal credentials to embed within themselves privilege
+     attributes and other mechanisms for positive authorization, amplifying
+     the priveleges of the principal beyond what can be done using a
+     credentials without such an a-data element.
+
+     This can not be provided without this element because the definition of
+     the authorization-data field allows elements to be added at will by the
+     bearer of a TGT at the time that they request service tickets and
+     elements may also be added to a delegated ticket by inclusion in the
+     authenticator.
+
+     For KDC-issued elements this is prevented because the elements are
+     signed by the KDC by including a checksum encrypted using the server's
+     key (the same key used to encrypt the ticket - or a key derived from
+     that key). Elements encapsulated with in the KDC-issued element will be
+     ignored by the application server if this "signature" is not present.
+     Further, elements encapsulated within this element from a ticket
+     granting ticket may be interpreted by the KDC, and used as a basis
+     according to policy for including new signed elements within derivative
+     tickets, but they will not be copied to a derivative ticket directly.
+     If they are copied directly to a derivative ticket by a KDC that is not
+     aware of this element, the signature will not be correct for the
+     application ticket elements, and the field will be ignored by the
+     application server.
+
+     This element and the elements it encapulates may be safely ignored by
+     applications, application servers, and KDCs that do not implement this
+     element.
+
+     B.5. And-Or
+
+     AD-AND-OR           SEQUENCE {
+                             condition-count[0]    INTEGER,
+                             elements[1]           AuthorizationData
+     }
+
+     When restrictive AD elements encapsulated within the and-or element are
+     encountered, only the number specified in condition-count of the
+     encapsulated conditions must be met in order to satisfy this element.
+     This element may be used to implement an "or" operation by setting the
+     condition-count field to 1, and it may specify an "and" operation by
+     setting the condition count to the number of embedded elements.
+     Application servers that do not implement this element must reject
+     tickets that contain authorization data elements of this type.
+
+     B.6. Mandatory ticket extensions
+
+     AD-Mandatory-Ticket-Extensions   Checksum
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     An authorization data element of type mandatory-ticket-extensions
+     specifies a collision-proof checksum using the same hash algorithm used
+     to protect the integrity of the ticket itself. This checksum will be
+     calculated over an individual extension field. If there are more than
+     one extension, multiple Mandatory-Ticket-Extensions authorization data
+     elements may be present, each with a checksum for a different extension
+     field. This restriction indicates that the ticket should not be
+     accepted if a ticket extension is not present in the ticket for which
+     the checksum does not match that checksum specified in the
+     authorization data element. Application servers that do not implement
+     this element must reject tickets that contain authorization data
+     elements of this type.
+
+     B.7. Authorization Data in ticket extensions
+
+     AD-IN-Ticket-Extensions   Checksum
+
+     An authorization data element of type in-ticket-extensions specifies a
+     collision-proof checksum using the same hash algorithm used to protect
+     the integrity of the ticket itself. This checksum is calculated over a
+     separate external AuthorizationData field carried in the ticket
+     extensions. Application servers that do not implement this element must
+     reject tickets that contain authorization data elements of this type.
+     Application servers that do implement this element will search the
+     ticket extensions for authorization data fields, calculate the
+     specified checksum over each authorization data field and look for one
+     matching the checksum in this in-ticket-extensions element. If not
+     found, then the ticket must be rejected. If found, the corresponding
+     authorization data elements will be interpreted in the same manner as
+     if they were contained in the top level authorization data field.
+
+     Note that if multiple external authorization data fields are present in
+     a ticket, each will have a corresponding element of type
+     in-ticket-extensions in the top level authorization data field, and the
+     external entries will be linked to the corresponding element by their
+     checksums.
+
+     C. Definition of common ticket extensions
+
+     This appendix contains the definitions of common ticket extensions.
+     Support for these extensions is optional. However, certain extensions
+     have associated authorization data elements that may require rejection
+     of a ticket containing an extension by application servers that do not
+     implement the particular extension. Other extensions have been defined
+     beyond those described in this specification. Such extensions are
+     described elswhere and for some of those extensions the reserved number
+     may be found in the list of constants.
+
+     It is known that older versions of Kerberos did not support this field,
+     and that some clients will strip this field from a ticket when they
+     parse and then reassemble a ticket as it is passed to the application
+     servers. The presence of the extension will not break such clients, but
+     any functionaly dependent on the extensions will not work when such
+     tickets are handled by old clients. In such situations, some
+     implementation may use alternate methods to transmit the information in
+     the extensions field.
+
+     C.1. Null ticket extension
+
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     TE-NullExtension   OctetString -- The empty Octet String
+
+     The te-data field in the null ticket extension is an octet string of
+     lenght zero. This extension may be included in a ticket granting ticket
+     so that the KDC can determine on presentation of the ticket granting
+     ticket whether the client software will strip the extensions field.
+
+     C.2. External Authorization Data
+
+     TE-ExternalAuthorizationData   AuthorizationData
+
+     The te-data field in the external authorization data ticket extension
+     is field of type AuthorizationData containing one or more authorization
+     data elements. If present, a corresponding authorization data element
+     will be present in the primary authorization data for the ticket and
+     that element will contain a checksum of the external authorization data
+     ticket extension.
+     -----------------------------------------------------------------------
+     [TM] Project Athena, Athena, and Kerberos are trademarks of the
+     Massachusetts Institute of Technology (MIT). No commercial use of these
+     trademarks may be made without prior written permission of MIT.
+
+     [1] Note, however, that many applications use Kerberos' functions only
+     upon the initiation of a stream-based network connection. Unless an
+     application subsequently provides integrity protection for the data
+     stream, the identity verification applies only to the initiation of the
+     connection, and does not guarantee that subsequent messages on the
+     connection originate from the same principal.
+
+     [2] Secret and private are often used interchangeably in the
+     literature. In our usage, it takes two (or more) to share a secret,
+     thus a shared DES key is a secret key. Something is only private when
+     no one but its owner knows it. Thus, in public key cryptosystems, one
+     has a public and a private key.
+
+     [3] Of course, with appropriate permission the client could arrange
+     registration of a separately-named prin- cipal in a remote realm, and
+     engage in normal exchanges with that realm's services. However, for
+     even small numbers of clients this becomes cumbersome, and more
+     automatic methods as described here are necessary.
+
+     [4] Though it is permissible to request or issue tick- ets with no
+     network addresses specified.
+
+     [5] The password-changing request must not be honored unless the
+     requester can provide the old password (the user's current secret key).
+     Otherwise, it would be possible for someone to walk up to an unattended
+     ses- sion and change another user's password.
+
+     [6] To authenticate a user logging on to a local system, the
+     credentials obtained in the AS exchange may first be used in a TGS
+     exchange to obtain credentials for a local server. Those credentials
+     must then be verified by a local server through successful completion
+     of the Client/Server exchange.
+
+     [7] "Random" means that, among other things, it should be impossible to
+     guess the next session key based on knowledge of past session keys.
+     This can only be achieved in a pseudo-random number generator if it is
+     based on cryptographic principles. It is more desirable to use a truly
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     random number generator, such as one based on measurements of random
+     physical phenomena.
+
+     [8] Tickets contain both an encrypted and unencrypted portion, so
+     cleartext here refers to the entire unit, which can be copied from one
+     message and replayed in another without any cryptographic skill.
+
+     [9] Note that this can make applications based on unreliable transports
+     difficult to code correctly. If the transport might deliver duplicated
+     messages, either a new authenticator must be generated for each retry,
+     or the application server must match requests and replies and replay
+     the first reply in response to a detected duplicate.
+
+     [10] This is used for user-to-user authentication as described in [8].
+
+     [11] Note that the rejection here is restricted to authenticators from
+     the same principal to the same server. Other client principals
+     communicating with the same server principal should not be have their
+     authenticators rejected if the time and microsecond fields happen to
+     match some other client's authenticator.
+
+     [12] In the Kerberos version 4 protocol, the timestamp in the reply was
+     the client's timestamp plus one. This is not necessary in version 5
+     because version 5 messages are formatted in such a way that it is not
+     possible to create the reply by judicious message surgery (even in
+     encrypted form) without knowledge of the appropriate encryption keys.
+
+     [13] Note that for encrypting the KRB_AP_REP message, the sub-session
+     key is not used, even if present in the Authenticator.
+
+     [14] Implementations of the protocol may wish to provide routines to
+     choose subkeys based on session keys and random numbers and to generate
+     a negotiated key to be returned in the KRB_AP_REP message.
+
+     [15]This can be accomplished in several ways. It might be known
+     beforehand (since the realm is part of the principal identifier), it
+     might be stored in a nameserver, or it might be obtained from a
+     configura- tion file. If the realm to be used is obtained from a
+     nameserver, there is a danger of being spoofed if the nameservice
+     providing the realm name is not authenti- cated. This might result in
+     the use of a realm which has been compromised, and would result in an
+     attacker's ability to compromise the authentication of the application
+     server to the client.
+
+     [16] If the client selects a sub-session key, care must be taken to
+     ensure the randomness of the selected sub- session key. One approach
+     would be to generate a random number and XOR it with the session key
+     from the ticket-granting ticket.
+
+     [17] This allows easy implementation of user-to-user authentication
+     [8], which uses ticket-granting ticket session keys in lieu of secret
+     server keys in situa- tions where such secret keys could be easily
+     comprom- ised.
+
+     [18] For the purpose of appending, the realm preceding the first listed
+     realm is considered to be the null realm ("").
+
+     [19] For the purpose of interpreting null subfields, the client's realm
+     is considered to precede those in the transited field, and the server's
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     realm is considered to follow them.
+
+     [20] This means that a client and server running on the same host and
+     communicating with one another using the KRB_SAFE messages should not
+     share a common replay cache to detect KRB_SAFE replays.
+
+     [21] The implementation of the Kerberos server need not combine the
+     database and the server on the same machine; it is feasible to store
+     the principal database in, say, a network name service, as long as the
+     entries stored therein are protected from disclosure to and
+     modification by unauthorized parties. However, we recommend against
+     such strategies, as they can make system management and threat analysis
+     quite complex.
+
+     [22] See the discussion of the padata field in section 5.4.2 for
+     details on why this can be useful.
+
+     [23] Warning for implementations that unpack and repack data structures
+     during the generation and verification of embedded checksums: Because
+     any checksums applied to data structures must be checked against the
+     original data the length of bit strings must be preserved within a data
+     structure between the time that a checksum is generated through
+     transmission to the time that the checksum is verified.
+
+     [24] It is NOT recommended that this time value be used to adjust the
+     workstation's clock since the workstation cannot reliably determine
+     that such a KRB_AS_REP actually came from the proper KDC in a timely
+     manner.
+
+     [25] Note, however, that if the time is used as the nonce, one must
+     make sure that the workstation time is monotonically increasing. If the
+     time is ever reset backwards, there is a small, but finite, probability
+     that a nonce will be reused.
+
+     [27] An application code in the encrypted part of a message provides an
+     additional check that the message was decrypted properly.
+
+     [29] An application code in the encrypted part of a message provides an
+     additional check that the message was decrypted properly.
+
+     [31] An application code in the encrypted part of a message provides an
+     additional check that the message was decrypted properly.
+
+     [32] If supported by the encryption method in use, an initialization
+     vector may be passed to the encryption procedure, in order to achieve
+     proper cipher chaining. The initialization vector might come from the
+     last block of the ciphertext from the previous KRB_PRIV message, but it
+     is the application's choice whether or not to use such an
+     initialization vector. If left out, the default initialization vector
+     for the encryption algorithm will be used.
+
+     [33] This prevents an attacker who generates an incorrect AS request
+     from obtaining verifiable plaintext for use in an off-line password
+     guessing attack.
+
+     [35] In the above specification, UNTAGGED OCTET STRING(length) is the
+     notation for an octet string with its tag and length removed. It is not
+     a valid ASN.1 type. The tag bits and length must be removed from the
+     confounder since the purpose of the confounder is so that the message
+
+Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
+
+
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
+
+     starts with random data, but the tag and its length are fixed. For
+     other fields, the length and tag would be redundant if they were
+     included because they are specified by the encryption type. [36] The
+     ordering of the fields in the CipherText is important. Additionally,
+     messages encoded in this format must include a length as part of the
+     msg-seq field. This allows the recipient to verify that the message has
+     not been truncated. Without a length, an attacker could use a chosen
+     plaintext attack to generate a message which could be truncated, while
+     leaving the checksum intact. Note that if the msg-seq is an encoding of
+     an ASN.1 SEQUENCE or OCTET STRING, then the length is part of that
+     encoding.
+
+     [37] In some cases, it may be necessary to use a different "mix-in"
+     string for compatibility reasons; see the discussion of padata in
+     section 5.4.2.
+
+     [38] In some cases, it may be necessary to use a different "mix-in"
+     string for compatibility reasons; see the discussion of padata in
+     section 5.4.2.
+
+     [39] A variant of the key is used to limit the use of a key to a
+     particular function, separating the functions of generating a checksum
+     from other encryption performed using the session key. The constant
+     F0F0F0F0F0F0F0F0 was chosen because it maintains key parity. The
+     properties of DES precluded the use of the complement. The same
+     constant is used for similar purpose in the Message Integrity Check in
+     the Privacy Enhanced Mail standard.
+
+     [40] This error carries additional information in the e- data field.
+     The contents of the e-data field for this message is described in
+     section 5.9.1.
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt
new file mode 100644
index 000000000000..ae79e8a7c4fb
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt
@@ -0,0 +1,7301 @@
+INTERNET-DRAFT                                              Clifford Neuman
+                                                                  John Kohl
+                                                              Theodore Ts'o
+                                                              July 14, 2000
+                                                   Expires January 14, 2001
+
+The Kerberos Network Authentication Service (V5)
+
+
+draft-ietf-cat-kerberos-revisions-06.txt
+
+STATUS OF THIS MEMO
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC 2026. 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.
+
+To learn the current status of any Internet-Draft, please check the
+"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
+ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
+
+The distribution of this memo is unlimited. It is filed as
+draft-ietf-cat-kerberos-revisions-06.txt, and expires January 14, 2001.
+Please send comments to: krb-protocol@MIT.EDU
+
+     This document is getting closer to a last call, but there are several
+     issues to be discussed. Some, but not all of these issues, are
+     highlighted in comments in the draft. We hope to resolve these issues
+     on the mailing list for the Kerberos working group, leading up to and
+     during the Pittsburgh IETF on a section by section basis, since this
+     is a long document, and it has been difficult to consider it as a
+     whole. Once sections are agreed to, it is out intent to issue the more
+     formal WG and IETF last calls.
+
+ABSTRACT
+
+This document provides an overview and specification of Version 5 of the
+Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol
+and its intended use that require more detailed or clearer explanation than
+was provided in RFC1510. This document is intended to provide a detailed
+description of the protocol, suitable for implementation, together with
+descriptions of the appropriate use of protocol messages and fields within
+those messages.
+
+This document is not intended to describe Kerberos to the end user, system
+administrator, or application developer. Higher level papers describing
+Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88],
+are available elsewhere.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+OVERVIEW
+
+This INTERNET-DRAFT describes the concepts and model upon which the
+Kerberos network authentication system is based. It also specifies Version
+5 of the Kerberos protocol.
+
+The motivations, goals, assumptions, and rationale behind most design
+decisions are treated cursorily; they are more fully described in a paper
+available in IEEE communications [NT94] and earlier in the Kerberos portion
+of the Athena Technical Plan [MNSS87]. The protocols have been a proposed
+standard and are being considered for advancement for draft standard
+through the IETF standard process. Comments are encouraged on the
+presentation, but only minor refinements to the protocol as implemented or
+extensions that fit within current protocol framework will be considered at
+this time.
+
+Requests for addition to an electronic mailing list for discussion of
+Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU.
+This mailing list is gatewayed onto the Usenet as the group
+comp.protocols.kerberos. Requests for further information, including
+documents and code availability, may be sent to info-kerberos@MIT.EDU.
+
+BACKGROUND
+
+The Kerberos model is based in part on Needham and Schroeder's trusted
+third-party authentication protocol [NS78] and on modifications suggested
+by Denning and Sacco [DS81]. The original design and implementation of
+Kerberos Versions 1 through 4 was the work of two former Project Athena
+staff members, Steve Miller of Digital Equipment Corporation and Clifford
+Neuman (now at the Information Sciences Institute of the University of
+Southern California), along with Jerome Saltzer, Technical Director of
+Project Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many
+other members of Project Athena have also contributed to the work on
+Kerberos.
+
+Version 5 of the Kerberos protocol (described in this document) has evolved
+from Version 4 based on new requirements and desires for features not
+available in Version 4. The design of Version 5 of the Kerberos protocol
+was led by Clifford Neuman and John Kohl with much input from the
+community. The development of the MIT reference implementation was led at
+MIT by John Kohl and Theodore T'so, with help and contributed code from
+many others. Since RFC1510 was issued, extensions and revisions to the
+protocol have been proposed by many individuals. Some of these proposals
+are reflected in this document. Where such changes involved significant
+effort, the document cites the contribution of the proposer.
+
+Reference implementations of both version 4 and version 5 of Kerberos are
+publicly available and commercial implementations have been developed and
+are widely used. Details on the differences between Kerberos Versions 4 and
+5 can be found in [KNT92].
+
+1. Introduction
+
+Kerberos provides a means of verifying the identities of principals, (e.g.
+a workstation user or a network server) on an open (unprotected) network.
+This is accomplished without relying on assertions by the host operating
+system, without basing trust on host addresses, without requiring physical
+security of all the hosts on the network, and under the assumption that
+packets traveling along the network can be read, modified, and inserted at
+will[1]. Kerberos performs authentication under these conditions as a
+trusted third-party authentication service by using conventional (shared
+secret key [2] cryptography. Kerberos extensions have been proposed and
+implemented that provide for the use of public key cryptography during
+certain phases of the authentication protocol. These extensions provide for
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+authentication of users registered with public key certification
+authorities, and allow the system to provide certain benefits of public key
+cryptography in situations where they are needed.
+
+The basic Kerberos authentication process proceeds as follows: A client
+sends a request to the authentication server (AS) requesting 'credentials'
+for a given server. The AS responds with these credentials, encrypted in
+the client's key. The credentials consist of 1) a 'ticket' for the server
+and 2) a temporary encryption key (often called a "session key"). The
+client transmits the ticket (which contains the client's identity and a
+copy of the session key, all encrypted in the server's key) to the server.
+The session key (now shared by the client and server) is used to
+authenticate the client, and may optionally be used to authenticate the
+server. It may also be used to encrypt further communication between the
+two parties or to exchange a separate sub-session key to be used to encrypt
+further communication.
+
+Implementation of the basic protocol consists of one or more authentication
+servers running on physically secure hosts. The authentication servers
+maintain a database of principals (i.e., users and servers) and their
+secret keys. Code libraries provide encryption and implement the Kerberos
+protocol. In order to add authentication to its transactions, a typical
+network application adds one or two calls to the Kerberos library directly
+or through the Generic Security Services Application Programming Interface,
+GSSAPI, described in separate document. These calls result in the
+transmission of the necessary messages to achieve authentication.
+
+The Kerberos protocol consists of several sub-protocols (or exchanges).
+There are two basic methods by which a client can ask a Kerberos server for
+credentials. In the first approach, the client sends a cleartext request
+for a ticket for the desired server to the AS. The reply is sent encrypted
+in the client's secret key. Usually this request is for a ticket-granting
+ticket (TGT) which can later be used with the ticket-granting server (TGS).
+In the second method, the client sends a request to the TGS. The client
+uses the TGT to authenticate itself to the TGS in the same manner as if it
+were contacting any other application server that requires Kerberos
+authentication. The reply is encrypted in the session key from the TGT.
+Though the protocol specification describes the AS and the TGS as separate
+servers, they are implemented in practice as different protocol entry
+points within a single Kerberos server.
+
+Once obtained, credentials may be used to verify the identity of the
+principals in a transaction, to ensure the integrity of messages exchanged
+between them, or to preserve privacy of the messages. The application is
+free to choose whatever protection may be necessary.
+
+To verify the identities of the principals in a transaction, the client
+transmits the ticket to the application server. Since the ticket is sent
+"in the clear" (parts of it are encrypted, but this encryption doesn't
+thwart replay) and might be intercepted and reused by an attacker,
+additional information is sent to prove that the message originated with
+the principal to whom the ticket was issued. This information (called the
+authenticator) is encrypted in the session key, and includes a timestamp.
+The timestamp proves that the message was recently generated and is not a
+replay. Encrypting the authenticator in the session key proves that it was
+generated by a party possessing the session key. Since no one except the
+requesting principal and the server know the session key (it is never sent
+over the network in the clear) this guarantees the identity of the client.
+
+The integrity of the messages exchanged between principals can also be
+guaranteed using the session key (passed in the ticket and contained in the
+credentials). This approach provides detection of both replay attacks and
+message stream modification attacks. It is accomplished by generating and
+transmitting a collision-proof checksum (elsewhere called a hash or digest
+function) of the client's message, keyed with the session key. Privacy and
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+integrity of the messages exchanged between principals can be secured by
+encrypting the data to be passed using the session key contained in the
+ticket or the subsession key found in the authenticator.
+
+The authentication exchanges mentioned above require read-only access to
+the Kerberos database. Sometimes, however, the entries in the database must
+be modified, such as when adding new principals or changing a principal's
+key. This is done using a protocol between a client and a third Kerberos
+server, the Kerberos Administration Server (KADM). There is also a protocol
+for maintaining multiple copies of the Kerberos database. Neither of these
+protocols are described in this document.
+
+1.1. Cross-Realm Operation
+
+The Kerberos protocol is designed to operate across organizational
+boundaries. A client in one organization can be authenticated to a server
+in another. Each organization wishing to run a Kerberos server establishes
+its own 'realm'. The name of the realm in which a client is registered is
+part of the client's name, and can be used by the end-service to decide
+whether to honor a request.
+
+By establishing 'inter-realm' keys, the administrators of two realms can
+allow a client authenticated in the local realm to prove its identity to
+servers in other realms[3]. The exchange of inter-realm keys (a separate
+key may be used for each direction) registers the ticket-granting service
+of each realm as a principal in the other realm. A client is then able to
+obtain a ticket-granting ticket for the remote realm's ticket-granting
+service from its local realm. When that ticket-granting ticket is used, the
+remote ticket-granting service uses the inter-realm key (which usually
+differs from its own normal TGS key) to decrypt the ticket-granting ticket,
+and is thus certain that it was issued by the client's own TGS. Tickets
+issued by the remote ticket-granting service will indicate to the
+end-service that the client was authenticated from another realm.
+
+A realm is said to communicate with another realm if the two realms share
+an inter-realm key, or if the local realm shares an inter-realm key with an
+intermediate realm that communicates with the remote realm. An
+authentication path is the sequence of intermediate realms that are
+transited in communicating from one realm to another.
+
+Realms are typically organized hierarchically. Each realm shares a key with
+its parent and a different key with each child. If an inter-realm key is
+not directly shared by two realms, the hierarchical organization allows an
+authentication path to be easily constructed. If a hierarchical
+organization is not used, it may be necessary to consult a database in
+order to construct an authentication path between realms.
+
+Although realms are typically hierarchical, intermediate realms may be
+bypassed to achieve cross-realm authentication through alternate
+authentication paths (these might be established to make communication
+between two realms more efficient). It is important for the end-service to
+know which realms were transited when deciding how much faith to place in
+the authentication process. To facilitate this decision, a field in each
+ticket contains the names of the realms that were involved in
+authenticating the client.
+
+The application server is ultimately responsible for accepting or rejecting
+authentication and should check the transited field. The application server
+may choose to rely on the KDC for the application server's realm to check
+the transited field. The application server's KDC will set the
+TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate
+realms may also check the transited field as they issue
+ticket-granting-tickets for other realms, but they are encouraged not to do
+so. A client may request that the KDC's not check the transited field by
+setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not
+required to honor this flag.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     [JBrezak] Should there be a section here on how clients determine what
+     realm a service is in? Something like:
+
+     The client may not immediately know what realm a particular service
+     principal is in. There are 2 basic mechanisms that can be used to
+     determine the realm of a service. The first requires that the client
+     fully specify the service principal including the realm in the
+     Kerberos protocol request. If the Kerberos server for the specified
+     realm does not have a principal that exactly matches the service in
+     the request, the Kerberos server will return an error indicating that
+     the service principal was not found. Alternatively the client can make
+     a request providing just the service principal name and requesting
+     name canonicalization from the Kerberos server. The Kerberos server
+     will attempt to locate a service principal in its database that best
+     matches the request principal or provide a referral to another
+     Kerberos realm that may be contain the requested service principal.
+
+1.2. Authorization
+
+As an authentication service, Kerberos provides a means of verifying the
+identity of principals on a network. Authentication is usually useful
+primarily as a first step in the process of authorization, determining
+whether a client may use a service, which objects the client is allowed to
+access, and the type of access allowed for each. Kerberos does not, by
+itself, provide authorization. Possession of a client ticket for a service
+provides only for authentication of the client to that service, and in the
+absence of a separate authorization procedure, it should not be considered
+by an application as authorizing the use of that service.
+
+Such separate authorization methods may be implemented as application
+specific access control functions and may be based on files such as the
+application server, or on separately issued authorization credentials such
+as those based on proxies [Neu93], or on other authorization services.
+Separately authenticated authorization credentials may be embedded in a
+tickets authorization data when encapsulated by the kdc-issued
+authorization data element.
+
+Applications should not be modified to accept the mere issuance of a
+service ticket by the Kerberos server (even by a modified Kerberos server)
+as granting authority to use the service, since such applications may
+become vulnerable to the bypass of this authorization check in an
+environment if they interoperate with other KDCs or where other options for
+application authentication (e.g. the PKTAPP proposal) are provided.
+
+1.3. Environmental assumptions
+
+Kerberos imposes a few assumptions on the environment in which it can
+properly function:
+
+   * 'Denial of service' attacks are not solved with Kerberos. There are
+     places in these protocols where an intruder can prevent an application
+     from participating in the proper authentication steps. Detection and
+     solution of such attacks (some of which can appear to be nnot-uncommon
+     'normal' failure modes for the system) is usually best left to the
+     human administrators and users.
+   * Principals must keep their secret keys secret. If an intruder somehow
+     steals a principal's key, it will be able to masquerade as that
+     principal or impersonate any server to the legitimate principal.
+   * 'Password guessing' attacks are not solved by Kerberos. If a user
+     chooses a poor password, it is possible for an attacker to
+     successfully mount an offline dictionary attack by repeatedly
+     attempting to decrypt, with successive entries from a dictionary,
+     messages obtained which are encrypted under a key derived from the
+     user's password.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+   * Each host on the network must have a clock which is 'loosely
+     synchronized' to the time of the other hosts; this synchronization is
+     used to reduce the bookkeeping needs of application servers when they
+     do replay detection. The degree of "looseness" can be configured on a
+     per-server basis, but is typically on the order of 5 minutes. If the
+     clocks are synchronized over the network, the clock synchronization
+     protocol must itself be secured from network attackers.
+   * Principal identifiers are not recycled on a short-term basis. A
+     typical mode of access control will use access control lists (ACLs) to
+     grant permissions to particular principals. If a stale ACL entry
+     remains for a deleted principal and the principal identifier is
+     reused, the new principal will inherit rights specified in the stale
+     ACL entry. By not re-using principal identifiers, the danger of
+     inadvertent access is removed.
+
+1.4. Glossary of terms
+
+Below is a list of terms used throughout this document.
+
+Authentication
+     Verifying the claimed identity of a principal.
+Authentication header
+     A record containing a Ticket and an Authenticator to be presented to a
+     server as part of the authentication process.
+Authentication path
+     A sequence of intermediate realms transited in the authentication
+     process when communicating from one realm to another.
+Authenticator
+     A record containing information that can be shown to have been
+     recently generated using the session key known only by the client and
+     server.
+Authorization
+     The process of determining whether a client may use a service, which
+     objects the client is allowed to access, and the type of access
+     allowed for each.
+Capability
+     A token that grants the bearer permission to access an object or
+     service. In Kerberos, this might be a ticket whose use is restricted
+     by the contents of the authorization data field, but which lists no
+     network addresses, together with the session key necessary to use the
+     ticket.
+Ciphertext
+     The output of an encryption function. Encryption transforms plaintext
+     into ciphertext.
+Client
+     A process that makes use of a network service on behalf of a user.
+     Note that in some cases a Server may itself be a client of some other
+     server (e.g. a print server may be a client of a file server).
+Credentials
+     A ticket plus the secret session key necessary to successfully use
+     that ticket in an authentication exchange.
+KDC
+     Key Distribution Center, a network service that supplies tickets and
+     temporary session keys; or an instance of that service or the host on
+     which it runs. The KDC services both initial ticket and
+     ticket-granting ticket requests. The initial ticket portion is
+     sometimes referred to as the Authentication Server (or service). The
+     ticket-granting ticket portion is sometimes referred to as the
+     ticket-granting server (or service).
+Kerberos
+     Aside from the 3-headed dog guarding Hades, the name given to Project
+     Athena's authentication service, the protocol used by that service, or
+     the code used to implement the authentication service.
+Plaintext
+     The input to an encryption function or the output of a decryption
+     function. Decryption transforms ciphertext into plaintext.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+Principal
+     A uniquely named client or server instance that participates in a
+     network communication.
+Principal identifier
+     The name used to uniquely identify each different principal.
+Seal
+     To encipher a record containing several fields in such a way that the
+     fields cannot be individually replaced without either knowledge of the
+     encryption key or leaving evidence of tampering.
+Secret key
+     An encryption key shared by a principal and the KDC, distributed
+     outside the bounds of the system, with a long lifetime. In the case of
+     a human user's principal, the secret key is derived from a password.
+Server
+     A particular Principal which provides a resource to network clients.
+     The server is sometimes refered to as the Application Server.
+Service
+     A resource provided to network clients; often provided by more than
+     one server (for example, remote file service).
+Session key
+     A temporary encryption key used between two principals, with a
+     lifetime limited to the duration of a single login "session".
+Sub-session key
+     A temporary encryption key used between two principals, selected and
+     exchanged by the principals using the session key, and with a lifetime
+     limited to the duration of a single association.
+Ticket
+     A record that helps a client authenticate itself to a server; it
+     contains the client's identity, a session key, a timestamp, and other
+     information, all sealed using the server's secret key. It only serves
+     to authenticate a client when presented along with a fresh
+     Authenticator.
+
+2. Ticket flag uses and requests
+
+Each Kerberos ticket contains a set of flags which are used to indicate
+various attributes of that ticket. Most flags may be requested by a client
+when the ticket is obtained; some are automatically turned on and off by a
+Kerberos server as required. The following sections explain what the
+various flags mean, and gives examples of reasons to use such a flag.
+
+2.1. Initial and pre-authenticated tickets
+
+The INITIAL flag indicates that a ticket was issued using the AS protocol
+and not issued based on a ticket-granting ticket. Application servers that
+want to require the demonstrated knowledge of a client's secret key (e.g. a
+password-changing program) can insist that this flag be set in any tickets
+they accept, and thus be assured that the client's key was recently
+presented to the application client.
+
+The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the
+initial authentication, regardless of whether the current ticket was issued
+directly (in which case INITIAL will also be set) or issued on the basis of
+a ticket-granting ticket (in which case the INITIAL flag is clear, but the
+PRE-AUTHENT and HW-AUTHENT flags are carried forward from the
+ticket-granting ticket).
+
+2.2. Invalid tickets
+
+The INVALID flag indicates that a ticket is invalid. Application servers
+must reject tickets which have this flag set. A postdated ticket will
+usually be issued in this form. Invalid tickets must be validated by the
+KDC before use, by presenting them to the KDC in a TGS request with the
+VALIDATE option specified. The KDC will only validate tickets after their
+starttime has passed. The validation is required so that postdated tickets
+which have been stolen before their starttime can be rendered permanently
+invalid (through a hot-list mechanism) (see section 3.3.3.1).
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+2.3. Renewable tickets
+
+Applications may desire to hold tickets which can be valid for long periods
+of time. However, this can expose their credentials to potential theft for
+equally long periods, and those stolen credentials would be valid until the
+expiration time of the ticket(s). Simply using short-lived tickets and
+obtaining new ones periodically would require the client to have long-term
+access to its secret key, an even greater risk. Renewable tickets can be
+used to mitigate the consequences of theft. Renewable tickets have two
+"expiration times": the first is when the current instance of the ticket
+expires, and the second is the latest permissible value for an individual
+expiration time. An application client must periodically (i.e. before it
+expires) present a renewable ticket to the KDC, with the RENEW option set
+in the KDC request. The KDC will issue a new ticket with a new session key
+and a later expiration time. All other fields of the ticket are left
+unmodified by the renewal process. When the latest permissible expiration
+time arrives, the ticket expires permanently. At each renewal, the KDC may
+consult a hot-list to determine if the ticket had been reported stolen
+since its last renewal; it will refuse to renew such stolen tickets, and
+thus the usable lifetime of stolen tickets is reduced.
+
+The RENEWABLE flag in a ticket is normally only interpreted by the
+ticket-granting service (discussed below in section 3.3). It can usually be
+ignored by application servers. However, some particularly careful
+application servers may wish to disallow renewable tickets.
+
+If a renewable ticket is not renewed by its expiration time, the KDC will
+not renew the ticket. The RENEWABLE flag is reset by default, but a client
+may request it be set by setting the RENEWABLE option in the KRB_AS_REQ
+message. If it is set, then the renew-till field in the ticket contains the
+time after which the ticket may not be renewed.
+
+2.4. Postdated tickets
+
+Applications may occasionally need to obtain tickets for use much later,
+e.g. a batch submission system would need tickets to be valid at the time
+the batch job is serviced. However, it is dangerous to hold valid tickets
+in a batch queue, since they will be on-line longer and more prone to
+theft. Postdated tickets provide a way to obtain these tickets from the KDC
+at job submission time, but to leave them "dormant" until they are
+activated and validated by a further request of the KDC. If a ticket theft
+were reported in the interim, the KDC would refuse to validate the ticket,
+and the thief would be foiled.
+
+The MAY-POSTDATE flag in a ticket is normally only interpreted by the
+ticket-granting service. It can be ignored by application servers. This
+flag must be set in a ticket-granting ticket in order to issue a postdated
+ticket based on the presented ticket. It is reset by default; it may be
+requested by a client by setting the ALLOW-POSTDATE option in the
+KRB_AS_REQ message. This flag does not allow a client to obtain a postdated
+ticket-granting ticket; postdated ticket-granting tickets can only by
+obtained by requesting the postdating in the KRB_AS_REQ message. The life
+(endtime-starttime) of a postdated ticket will be the remaining life of the
+ticket-granting ticket at the time of the request, unless the RENEWABLE
+option is also set, in which case it can be the full life
+(endtime-starttime) of the ticket-granting ticket. The KDC may limit how
+far in the future a ticket may be postdated.
+
+The POSTDATED flag indicates that a ticket has been postdated. The
+application server can check the authtime field in the ticket to see when
+the original authentication occurred. Some services may choose to reject
+postdated tickets, or they may only accept them within a certain period
+after the original authentication. When the KDC issues a POSTDATED ticket,
+it will also be marked as INVALID, so that the application client must
+present the ticket to the KDC to be validated before use.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+2.5. Proxiable and proxy tickets
+
+At times it may be necessary for a principal to allow a service to perform
+an operation on its behalf. The service must be able to take on the
+identity of the client, but only for a particular purpose. A principal can
+allow a service to take on the principal's identity for a particular
+purpose by granting it a proxy.
+
+The process of granting a proxy using the proxy and proxiable flags is used
+to provide credentials for use with specific services. Though conceptually
+also a proxy, user's wishing to delegate their identity for ANY purpose
+must use the ticket forwarding mechanism described in the next section to
+forward a ticket granting ticket.
+
+The PROXIABLE flag in a ticket is normally only interpreted by the
+ticket-granting service. It can be ignored by application servers. When
+set, this flag tells the ticket-granting server that it is OK to issue a
+new ticket (but not a ticket-granting ticket) with a different network
+address based on this ticket. This flag is set if requested by the client
+on initial authentication. By default, the client will request that it be
+set when requesting a ticket granting ticket, and reset when requesting any
+other ticket.
+
+This flag allows a client to pass a proxy to a server to perform a remote
+request on its behalf, e.g. a print service client can give the print
+server a proxy to access the client's files on a particular file server in
+order to satisfy a print request.
+
+In order to complicate the use of stolen credentials, Kerberos tickets are
+usually valid from only those network addresses specifically included in
+the ticket[4]. When granting a proxy, the client must specify the new
+network address from which the proxy is to be used, or indicate that the
+proxy is to be issued for use from any address.
+
+The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket.
+Application servers may check this flag and at their option they may
+require additional authentication from the agent presenting the proxy in
+order to provide an audit trail.
+
+2.6. Forwardable tickets
+
+Authentication forwarding is an instance of a proxy where the service is
+granted complete use of the client's identity. An example where it might be
+used is when a user logs in to a remote system and wants authentication to
+work from that system as if the login were local.
+
+The FORWARDABLE flag in a ticket is normally only interpreted by the
+ticket-granting service. It can be ignored by application servers. The
+FORWARDABLE flag has an interpretation similar to that of the PROXIABLE
+flag, except ticket-granting tickets may also be issued with different
+network addresses. This flag is reset by default, but users may request
+that it be set by setting the FORWARDABLE option in the AS request when
+they request their initial ticket- granting ticket.
+
+This flag allows for authentication forwarding without requiring the user
+to enter a password again. If the flag is not set, then authentication
+forwarding is not permitted, but the same result can still be achieved if
+the user engages in the AS exchange specifying the requested network
+addresses and supplies a password.
+
+The FORWARDED flag is set by the TGS when a client presents a ticket with
+the FORWARDABLE flag set and requests a forwarded ticket by specifying the
+FORWARDED KDC option and supplying a set of addresses for the new ticket.
+It is also set in all tickets issued based on tickets with the FORWARDED
+flag set. Application servers may choose to process FORWARDED tickets
+differently than non-FORWARDED tickets.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+2.7 Name canonicalization [JBrezak]
+
+If a client does not have the full name information for a principal, it can
+request that the Kerberos server attempt to lookup the name in its database
+and return a canonical form of the requested principal or a referral to a
+realm that has the requested principal in its namespace. Name
+canonicalization allows a principal to have alternate names. Name
+canonicalization must not be used to locate principal names supplied from
+wildcards and is not a mechanism to be used to search a Kerberos database.
+
+The CANONICALIZE flag in a ticket request is used to indicate to the
+Kerberos server that the client will accept an alternative name to the
+principal in the request or a referral to another realm. Both the AS and
+TGS must be able to interpret requests with this flag.
+
+By using this flag, the client can avoid extensive configuration needed to
+map specific host names to a particular realm.
+
+2.8. Other KDC options
+
+There are two additional options which may be set in a client's request of
+the KDC. The RENEWABLE-OK option indicates that the client will accept a
+renewable ticket if a ticket with the requested life cannot otherwise be
+provided. If a ticket with the requested life cannot be provided, then the
+KDC may issue a renewable ticket with a renew-till equal to the the
+requested endtime. The value of the renew-till field may still be adjusted
+by site-determined limits or limits imposed by the individual principal or
+server.
+
+The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service.
+It indicates that the ticket to be issued for the end server is to be
+encrypted in the session key from the a additional second ticket-granting
+ticket provided with the request. See section 3.3.3 for specific details.
+
+3. Message Exchanges
+
+The following sections describe the interactions between network clients
+and servers and the messages involved in those exchanges.
+
+3.1. The Authentication Service Exchange
+
+                          Summary
+      Message direction       Message type    Section
+      1. Client to Kerberos   KRB_AS_REQ      5.4.1
+      2. Kerberos to client   KRB_AS_REP or   5.4.2
+                              KRB_ERROR       5.9.1
+
+The Authentication Service (AS) Exchange between the client and the
+Kerberos Authentication Server is initiated by a client when it wishes to
+obtain authentication credentials for a given server but currently holds no
+credentials. In its basic form, the client's secret key is used for
+encryption and decryption. This exchange is typically used at the
+initiation of a login session to obtain credentials for a Ticket-Granting
+Server which will subsequently be used to obtain credentials for other
+servers (see section 3.3) without requiring further use of the client's
+secret key. This exchange is also used to request credentials for services
+which must not be mediated through the Ticket-Granting Service, but rather
+require a principal's secret key, such as the password-changing service[5].
+This exchange does not by itself provide any assurance of the the identity
+of the user[6].
+
+The exchange consists of two messages: KRB_AS_REQ from the client to
+Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
+messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+In the request, the client sends (in cleartext) its own identity and the
+identity of the server for which it is requesting credentials. The
+response, KRB_AS_REP, contains a ticket for the client to present to the
+server, and a session key that will be shared by the client and the server.
+The session key and additional information are encrypted in the client's
+secret key. The KRB_AS_REP message contains information which can be used
+to detect replays, and to associate it with the message to which it
+replies. Various errors can occur; these are indicated by an error response
+(KRB_ERROR) instead of the KRB_AS_REP response. The error message is not
+encrypted. The KRB_ERROR message contains information which can be used to
+associate it with the message to which it replies. The lack of encryption
+in the KRB_ERROR message precludes the ability to detect replays,
+fabrications, or modifications of such messages.
+
+Without preautentication, the authentication server does not know whether
+the client is actually the principal named in the request. It simply sends
+a reply without knowing or caring whether they are the same. This is
+acceptable because nobody but the principal whose identity was given in the
+request will be able to use the reply. Its critical information is
+encrypted in that principal's key. The initial request supports an optional
+field that can be used to pass additional information that might be needed
+for the initial exchange. This field may be used for preauthentication as
+described in section [hl<>].
+
+3.1.1. Generation of KRB_AS_REQ message
+
+The client may specify a number of options in the initial request. Among
+these options are whether pre-authentication is to be performed; whether
+the requested ticket is to be renewable, proxiable, or forwardable; whether
+it should be postdated or allow postdating of derivative tickets; whether
+the client requests name-canonicalization; and whether a renewable ticket
+will be accepted in lieu of a non-renewable ticket if the requested ticket
+expiration date cannot be satisfied by a non-renewable ticket (due to
+configuration constraints; see section 4). See section A.1 for pseudocode.
+
+The client prepares the KRB_AS_REQ message and sends it to the KDC.
+
+3.1.2. Receipt of KRB_AS_REQ message
+
+If all goes well, processing the KRB_AS_REQ message will result in the
+creation of a ticket for the client to present to the server. The format
+for the ticket is described in section 5.3.1. The contents of the ticket
+are determined as follows.
+
+3.1.3. Generation of KRB_AS_REP message
+
+The authentication server looks up the client and server principals named
+in the KRB_AS_REQ in its database, extracting their respective keys.  If
+the requested client principal named in the request is not found in its
+database, then an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is
+returned. If the request had the CANONICALIZE option set, then the AS can
+attempt to lookup the client principal name in an alternate database, if it
+is found an error message with a KDC_ERR_WRONG_REALM error code and the
+cname and crealm in the error message must contain the true client
+principal name and realm.
+
+If required, the server pre-authenticates the request, and if the
+pre-authentication check fails, an error message with the code
+KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the
+requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP
+is returned. Otherwise it generates a 'random' session key[7].
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+If there are multiple encryption keys registered for a client in the
+Kerberos database (or if the key registered supports multiple encryption
+types; e.g. DES3-CBC-SHA1 and DES3-CBC-SHA1-KD), then the etype field from
+the AS request is used by the KDC to select the encryption method to be
+used for encrypting the response to the client. If there is more than one
+supported, strong encryption type in the etype list, the first valid etype
+for which an encryption key is available is used. The encryption method
+used to respond to a TGS request is taken from the keytype of the session
+key found in the ticket granting ticket.
+
+     JBrezak - the behavior of PW-SALT, and ETYPE-INFO should be explained
+     here; also about using keys that have different string-to-key
+     functions like AFSsalt
+
+When the etype field is present in a KDC request, whether an AS or TGS
+request, the KDC will attempt to assign the type of the random session key
+from the list of methods in the etype field. The KDC will select the
+appropriate type using the list of methods provided together with
+information from the Kerberos database indicating acceptable encryption
+methods for the application server. The KDC will not issue tickets with a
+weak session key encryption type.
+
+If the requested start time is absent, indicates a time in the past, or is
+within the window of acceptable clock skew for the KDC and the POSTDATE
+option has not been specified, then the start time of the ticket is set to
+the authentication server's current time. If it indicates a time in the
+future beyond the acceptable clock skew, but the POSTDATED option has not
+been specified then the error KDC_ERR_CANNOT_POSTDATE is returned.
+Otherwise the requested start time is checked against the policy of the
+local realm (the administrator might decide to prohibit certain types or
+ranges of postdated tickets), and if acceptable, the ticket's start time is
+set as requested and the INVALID flag is set in the new ticket. The
+postdated ticket must be validated before use by presenting it to the KDC
+after the start time has been reached.
+
+The expiration time of the ticket will be set to the minimum of the
+following:
+
+   * The expiration time (endtime) requested in the KRB_AS_REQ message.
+   * The ticket's start time plus the maximum allowable lifetime associated
+     with the client principal (the authentication server's database
+     includes a maximum ticket lifetime field in each principal's record;
+     see section 4).
+   * The ticket's start time plus the maximum allowable lifetime associated
+     with the server principal.
+   * The ticket's start time plus the maximum lifetime set by the policy of
+     the local realm.
+
+If the requested expiration time minus the start time (as determined above)
+is less than a site-determined minimum lifetime, an error message with code
+KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the
+ticket exceeds what was determined as above, and if the 'RENEWABLE-OK'
+option was requested, then the 'RENEWABLE' flag is set in the new ticket,
+and the renew-till value is set as if the 'RENEWABLE' option were requested
+(the field and option names are described fully in section 5.4.1).
+
+If the RENEWABLE option has been requested or if the RENEWABLE-OK option
+has been set and a renewable ticket is to be issued, then the renew-till
+field is set to the minimum of:
+
+   * Its requested value.
+   * The start time of the ticket plus the minimum of the two maximum
+     renewable lifetimes associated with the principals' database entries.
+   * The start time of the ticket plus the maximum renewable lifetime set
+     by the policy of the local realm.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+The flags field of the new ticket will have the following options set if
+they have been requested and if the policy of the local realm allows:
+FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new
+ticket is post-dated (the start time is in the future), its INVALID flag
+will also be set.
+
+If all of the above succeed, the server formats a KRB_AS_REP message (see
+section 5.4.2), copying the addresses in the request into the caddr of the
+response, placing any required pre-authentication data into the padata of
+the response, and encrypts the ciphertext part in the client's key using
+the requested encryption method, and sends it to the client. See section
+A.2 for pseudocode.
+
+3.1.4. Generation of KRB_ERROR message
+
+Several errors can occur, and the Authentication Server responds by
+returning an error message, KRB_ERROR, to the client, with the error-code
+and e-text fields set to appropriate values. The error message contents and
+details are described in Section 5.9.1.
+
+3.1.5. Receipt of KRB_AS_REP message
+
+If the reply message type is KRB_AS_REP, then the client verifies that the
+cname and crealm fields in the cleartext portion of the reply match what it
+requested. If any padata fields are present, they may be used to derive the
+proper secret key to decrypt the message. The client decrypts the encrypted
+part of the response using its secret key, verifies that the nonce in the
+encrypted part matches the nonce it supplied in its request (to detect
+replays). It also verifies that the sname and srealm in the response match
+those in the request (or are otherwise expected values), and that the host
+address field is also correct. It then stores the ticket, session key,
+start and expiration times, and other information for later use. The
+key-expiration field from the encrypted part of the response may be checked
+to notify the user of impending key expiration (the client program could
+then suggest remedial action, such as a password change). See section A.3
+for pseudocode.
+
+Proper decryption of the KRB_AS_REP message is not sufficient to verify the
+identity of the user; the user and an attacker could cooperate to generate
+a KRB_AS_REP format message which decrypts properly but is not from the
+proper KDC. If the host wishes to verify the identity of the user, it must
+require the user to present application credentials which can be verified
+using a securely-stored secret key for the host. If those credentials can
+be verified, then the identity of the user can be assured.
+
+3.1.6. Receipt of KRB_ERROR message
+
+If the reply message type is KRB_ERROR, then the client interprets it as an
+error and performs whatever application-specific tasks are necessary to
+recover. If the client set the CANONICALIZE option and a
+KDC_ERR_WRONG_REALM error was returned, the AS request should be retried to
+the realm and client principal name specified in the error message crealm
+and cname field respectively.
+
+3.2. The Client/Server Authentication Exchange
+
+                             Summary
+Message direction                         Message type    Section
+Client to Application server              KRB_AP_REQ      5.5.1
+[optional] Application server to client   KRB_AP_REP or   5.5.2
+                                          KRB_ERROR       5.9.1
+
+The client/server authentication (CS) exchange is used by network
+applications to authenticate the client to the server and vice versa. The
+client must have already acquired credentials for the server using the AS
+or TGS exchange.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+3.2.1. The KRB_AP_REQ message
+
+The KRB_AP_REQ contains authentication information which should be part of
+the first message in an authenticated transaction. It contains a ticket, an
+authenticator, and some additional bookkeeping information (see section
+5.5.1 for the exact format). The ticket by itself is insufficient to
+authenticate a client, since tickets are passed across the network in
+cleartext[DS90], so the authenticator is used to prevent invalid replay of
+tickets by proving to the server that the client knows the session key of
+the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message
+is referred to elsewhere as the 'authentication header.'
+
+3.2.2. Generation of a KRB_AP_REQ message
+
+When a client wishes to initiate authentication to a server, it obtains
+(either through a credentials cache, the AS exchange, or the TGS exchange)
+a ticket and session key for the desired service. The client may re-use any
+tickets it holds until they expire. To use a ticket the client constructs a
+new Authenticator from the the system time, its name, and optionally an
+application specific checksum, an initial sequence number to be used in
+KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in
+negotiations for a session key unique to this particular session.
+Authenticators may not be re-used and will be rejected if replayed to a
+server[LGDSR87]. If a sequence number is to be included, it should be
+randomly chosen so that even after many messages have been exchanged it is
+not likely to collide with other sequence numbers in use.
+
+The client may indicate a requirement of mutual authentication or the use
+of a session-key based ticket by setting the appropriate flag(s) in the
+ap-options field of the message.
+
+The Authenticator is encrypted in the session key and combined with the
+ticket to form the KRB_AP_REQ message which is then sent to the end server
+along with any additional application-specific information. See section A.9
+for pseudocode.
+
+3.2.3. Receipt of KRB_AP_REQ message
+
+Authentication is based on the server's current time of day (clocks must be
+loosely synchronized), the authenticator, and the ticket. Several errors
+are possible. If an error occurs, the server is expected to reply to the
+client with a KRB_ERROR message. This message may be encapsulated in the
+application protocol if its 'raw' form is not acceptable to the protocol.
+The format of error messages is described in section 5.9.1.
+
+The algorithm for verifying authentication information is as follows. If
+the message type is not KRB_AP_REQ, the server returns the
+KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket in
+the KRB_AP_REQ is not one the server can use (e.g., it indicates an old
+key, and the server no longer possesses a copy of the old key), the
+KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION-KEY flag is set
+in the ap-options field, it indicates to the server that the ticket is
+encrypted in the session key from the server's ticket-granting ticket
+rather than its secret key[10]. Since it is possible for the server to be
+registered in multiple realms, with different keys in each, the srealm
+field in the unencrypted portion of the ticket in the KRB_AP_REQ is used to
+specify which secret key the server should use to decrypt that ticket. The
+KRB_AP_ERR_NOKEY error code is returned if the server doesn't have the
+proper key to decipher the ticket.
+
+The ticket is decrypted using the version of the server's key specified by
+the ticket. If the decryption routines detect a modification of the ticket
+(each encryption system must provide safeguards to detect modified
+ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned
+(chances are good that different keys were used to encrypt and decrypt).
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+The authenticator is decrypted using the session key extracted from the
+decrypted ticket. If decryption shows it to have been modified, the
+KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the
+client from the ticket are compared against the same fields in the
+authenticator. If they don't match, the KRB_AP_ERR_BADMATCH error is
+returned (they might not match, for example, if the wrong session key was
+used to encrypt the authenticator). The addresses in the ticket (if any)
+are then searched for an address matching the operating-system reported
+address of the client. If no match is found or the server insists on ticket
+addresses but none are present in the ticket, the KRB_AP_ERR_BADADDR error
+is returned.
+
+If the local (server) time and the client time in the authenticator differ
+by more than the allowable clock skew (e.g., 5 minutes), the
+KRB_AP_ERR_SKEW error is returned. If the server name, along with the
+client name, time and microsecond fields from the Authenticator match any
+recently-seen such tuples, the KRB_AP_ERR_REPEAT error is returned[11]. The
+server must remember any authenticator presented within the allowable clock
+skew, so that a replay attempt is guaranteed to fail. If a server loses
+track of any authenticator presented within the allowable clock skew, it
+must reject all requests until the clock skew interval has passed. This
+assures that any lost or re-played authenticators will fall outside the
+allowable clock skew and can no longer be successfully replayed (If this is
+not done, an attacker could conceivably record the ticket and authenticator
+sent over the network to a server, then disable the client's host, pose as
+the disabled host, and replay the ticket and authenticator to subvert the
+authentication.). If a sequence number is provided in the authenticator,
+the server saves it for later use in processing KRB_SAFE and/or KRB_PRIV
+messages. If a subkey is present, the server either saves it for later use
+or uses it to help generate its own choice for a subkey to be returned in a
+KRB_AP_REP message.
+
+The server computes the age of the ticket: local (server) time minus the
+start time inside the Ticket. If the start time is later than the current
+time by more than the allowable clock skew or if the INVALID flag is set in
+the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the
+current time is later than end time by more than the allowable clock skew,
+the KRB_AP_ERR_TKT_EXPIRED error is returned.
+
+If all these checks succeed without an error, the server is assured that
+the client possesses the credentials of the principal named in the ticket
+and thus, the client has been authenticated to the server. See section A.10
+for pseudocode.
+
+Passing these checks provides only authentication of the named principal;
+it does not imply authorization to use the named service. Applications must
+make a separate authorization decisions based upon the authenticated name
+of the user, the requested operation, local acces control information such
+as that contained in a .k5login or .k5users file, and possibly a separate
+distributed authorization service.
+
+3.2.4. Generation of a KRB_AP_REP message
+
+Typically, a client's request will include both the authentication
+information and its initial request in the same message, and the server
+need not explicitly reply to the KRB_AP_REQ. However, if mutual
+authentication (not only authenticating the client to the server, but also
+the server to the client) is being performed, the KRB_AP_REQ message will
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+have MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message
+is required in response. As with the error message, this message may be
+encapsulated in the application protocol if its "raw" form is not
+acceptable to the application's protocol. The timestamp and microsecond
+field used in the reply must be the client's timestamp and microsecond
+field (as provided in the authenticator)[12]. If a sequence number is to be
+included, it should be randomly chosen as described above for the
+authenticator. A subkey may be included if the server desires to negotiate
+a different subkey. The KRB_AP_REP message is encrypted in the session key
+extracted from the ticket. See section A.11 for pseudocode.
+
+3.2.5. Receipt of KRB_AP_REP message
+
+If a KRB_AP_REP message is returned, the client uses the session key from
+the credentials obtained for the server[13] to decrypt the message, and
+verifies that the timestamp and microsecond fields match those in the
+Authenticator it sent to the server. If they match, then the client is
+assured that the server is genuine. The sequence number and subkey (if
+present) are retained for later use. See section A.12 for pseudocode.
+
+3.2.6. Using the encryption key
+
+After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and
+server share an encryption key which can be used by the application. The
+'true session key' to be used for KRB_PRIV, KRB_SAFE, or other
+application-specific uses may be chosen by the application based on the
+subkeys in the KRB_AP_REP message and the authenticator[14]. In some cases,
+the use of this session key will be implicit in the protocol; in others the
+method of use must be chosen from several alternatives. We leave the
+protocol negotiations of how to use the key (e.g. selecting an encryption
+or checksum type) to the application programmer; the Kerberos protocol does
+not constrain the implementation options, but an example of how this might
+be done follows.
+
+One way that an application may choose to negotiate a key to be used for
+subequent integrity and privacy protection is for the client to propose a
+key in the subkey field of the authenticator. The server can then choose a
+key using the proposed key from the client as input, returning the new
+subkey in the subkey field of the application reply. This key could then be
+used for subsequent communication. To make this example more concrete, if
+the encryption method in use required a 56 bit key, and for whatever
+reason, one of the parties was prevented from using a key with more than 40
+unknown bits, this method would allow the the party which is prevented from
+using more than 40 bits to either propose (if the client) an initial key
+with a known quantity for 16 of those bits, or to mask 16 of the bits (if
+the server) with the known quantity. The application implementor is warned,
+however, that this is only an example, and that an analysis of the
+particular crytosystem to be used, and the reasons for limiting the key
+length, must be made before deciding whether it is acceptable to mask bits
+of the key.
+
+With both the one-way and mutual authentication exchanges, the peers should
+take care not to send sensitive information to each other without proper
+assurances. In particular, applications that require privacy or integrity
+should use the KRB_AP_REP response from the server to client to assure both
+client and server of their peer's identity. If an application protocol
+requires privacy of its messages, it can use the KRB_PRIV message (section
+3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+3.3. The Ticket-Granting Service (TGS) Exchange
+
+                          Summary
+      Message direction       Message type     Section
+      1. Client to Kerberos   KRB_TGS_REQ      5.4.1
+      2. Kerberos to client   KRB_TGS_REP or   5.4.2
+                              KRB_ERROR        5.9.1
+
+The TGS exchange between a client and the Kerberos Ticket-Granting Server
+is initiated by a client when it wishes to obtain authentication
+credentials for a given server (which might be registered in a remote
+realm), when it wishes to renew or validate an existing ticket, or when it
+wishes to obtain a proxy ticket. In the first case, the client must already
+have acquired a ticket for the Ticket-Granting Service using the AS
+exchange (the ticket-granting ticket is usually obtained when a client
+initially authenticates to the system, such as when a user logs in). The
+message format for the TGS exchange is almost identical to that for the AS
+exchange. The primary difference is that encryption and decryption in the
+TGS exchange does not take place under the client's key. Instead, the
+session key from the ticket-granting ticket or renewable ticket, or
+sub-session key from an Authenticator is used. As is the case for all
+application servers, expired tickets are not accepted by the TGS, so once a
+renewable or ticket-granting ticket expires, the client must use a separate
+exchange to obtain valid tickets.
+
+The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the
+client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or
+KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the
+client plus a request for credentials. The authentication information
+consists of the authentication header (KRB_AP_REQ) which includes the
+client's previously obtained ticket-granting, renewable, or invalid ticket.
+In the ticket-granting ticket and proxy cases, the request may include one
+or more of: a list of network addresses, a collection of typed
+authorization data to be sealed in the ticket for authorization use by the
+application server, or additional tickets (the use of which are described
+later). The TGS reply (KRB_TGS_REP) contains the requested credentials,
+encrypted in the session key from the ticket-granting ticket or renewable
+ticket, or if present, in the sub-session key from the Authenticator (part
+of the authentication header). The KRB_ERROR message contains an error code
+and text explaining what went wrong. The KRB_ERROR message is not
+encrypted. The KRB_TGS_REP message contains information which can be used
+to detect replays, and to associate it with the message to which it
+replies. The KRB_ERROR message also contains information which can be used
+to associate it with the message to which it replies, but the lack of
+encryption in the KRB_ERROR message precludes the ability to detect replays
+or fabrications of such messages.
+
+3.3.1. Generation of KRB_TGS_REQ message
+
+Before sending a request to the ticket-granting service, the client must
+determine in which realm the application server is registered[15], if it is
+known. If the client does know the service principal name and realm and it
+does not already possess a ticket-granting ticket for the appropriate
+realm, then one must be obtained. This is first attempted by requesting a
+ticket-granting ticket for the destination realm from a Kerberos server for
+which the client does posess a ticket-granting ticket (using the
+KRB_TGS_REQ message recursively). The Kerberos server may return a TGT for
+the desired realm in which case one can proceed.
+
+If the client does not know the realm of the service or the true service
+principal name, then the CANONICALIZE option must be used in the request.
+This will cause the TGS to locate the service principal based on the target
+service name in the ticket and return the service principal name in the
+response. Alternatively, the Kerberos server may return a TGT for a realm
+which is 'closer' to the desired realm (further along the standard
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+hierarchical path) or the realm that may contain the requested service
+principal name in a request with the CANONCALIZE option set [JBrezak], in
+which case this step must be repeated with a Kerberos server in the realm
+specified in the returned TGT. If neither are returned, then the request
+must be retried with a Kerberos server for a realm higher in the hierarchy.
+This request will itself require a ticket-granting ticket for the higher
+realm which must be obtained by recursively applying these directions.
+
+Once the client obtains a ticket-granting ticket for the appropriate realm,
+it determines which Kerberos servers serve that realm, and contacts one.
+The list might be obtained through a configuration file or network service
+or it may be generated from the name of the realm; as long as the secret
+keys exchanged by realms are kept secret, only denial of service results
+from using a false Kerberos server.
+
+As in the AS exchange, the client may specify a number of options in the
+KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing
+an authentication header as an element of the padata field, and including
+the same fields as used in the KRB_AS_REQ message along with several
+optional fields: the enc-authorization-data field for application server
+use and additional tickets required by some options.
+
+In preparing the authentication header, the client can select a sub-session
+key under which the response from the Kerberos server will be
+encrypted[16]. If the sub-session key is not specified, the session key
+from the ticket-granting ticket will be used. If the enc-authorization-data
+is present, it must be encrypted in the sub-session key, if present, from
+the authenticator portion of the authentication header, or if not present,
+using the session key from the ticket-granting ticket.
+
+Once prepared, the message is sent to a Kerberos server for the destination
+realm. See section A.5 for pseudocode.
+
+3.3.2. Receipt of KRB_TGS_REQ message
+
+The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ
+message, but there are many additional checks to be performed. First, the
+Kerberos server must determine which server the accompanying ticket is for
+and it must select the appropriate key to decrypt it. For a normal
+KRB_TGS_REQ message, it will be for the ticket granting service, and the
+TGS's key will be used. If the TGT was issued by another realm, then the
+appropriate inter-realm key must be used. If the accompanying ticket is not
+a ticket granting ticket for the current realm, but is for an application
+server in the current realm, the RENEW, VALIDATE, or PROXY options are
+specified in the request, and the server for which a ticket is requested is
+the server named in the accompanying ticket, then the KDC will decrypt the
+ticket in the authentication header using the key of the server for which
+it was issued. If no ticket can be found in the padata field, the
+KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
+
+Once the accompanying ticket has been decrypted, the user-supplied checksum
+in the Authenticator must be verified against the contents of the request,
+and the message rejected if the checksums do not match (with an error code
+of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not
+collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the
+checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is
+returned. If the authorization-data are present, they are decrypted using
+the sub-session key from the Authenticator.
+
+If any of the decryptions indicate failed integrity checks, the
+KRB_AP_ERR_BAD_INTEGRITY error is returned. If the CANONICALIZE option is
+set in the KRB_TGS_REQ, then the requested service name may not be the true
+principal name or the service may not be in the TGS realm.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+3.3.3. Generation of KRB_TGS_REP message
+
+The KRB_TGS_REP message shares its format with the KRB_AS_REP
+(KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The detailed
+specification is in section 5.4.2.
+
+The response will include a ticket for the requested server. The Kerberos
+database is queried to retrieve the record for the requested server
+(including the key with which the ticket will be encrypted). If the request
+is for a ticket granting ticket for a remote realm, and if no key is shared
+with the requested realm, then the Kerberos server will select the realm
+"closest" to the requested realm with which it does share a key, and use
+that realm instead. If the CANONICALIZE option is set, the TGS may return a
+ticket containing the server name of the true service principal. If the
+requested server cannot be found in the TGS database, then a TGT for
+another trusted realm may be returned instead of a ticket for the service.
+This TGT is a referral mechanism to cause the client to retry the request
+to the realm of the TGT. These are the only cases where the response for
+the KDC will be for a different server than that requested by the client.
+
+By default, the address field, the client's name and realm, the list of
+transited realms, the time of initial authentication, the expiration time,
+and the authorization data of the newly-issued ticket will be copied from
+the ticket-granting ticket (TGT) or renewable ticket. If the transited
+field needs to be updated, but the transited type is not supported, the
+KDC_ERR_TRTYPE_NOSUPP error is returned.
+
+If the request specifies an endtime, then the endtime of the new ticket is
+set to the minimum of (a) that request, (b) the endtime from the TGT, and
+(c) the starttime of the TGT plus the minimum of the maximum life for the
+application server and the maximum life for the local realm (the maximum
+life for the requesting principal was already applied when the TGT was
+issued). If the new ticket is to be a renewal, then the endtime above is
+replaced by the minimum of (a) the value of the renew_till field of the
+ticket and (b) the starttime for the new ticket plus the life
+(endtime-starttime) of the old ticket.
+
+If the FORWARDED option has been requested, then the resulting ticket will
+contain the addresses specified by the client. This option will only be
+honored if the FORWARDABLE flag is set in the TGT. The PROXY option is
+similar; the resulting ticket will contain the addresses specified by the
+client. It will be honored only if the PROXIABLE flag in the TGT is set.
+The PROXY option will not be honored on requests for additional
+ticket-granting tickets.
+
+If the requested start time is absent, indicates a time in the past, or is
+within the window of acceptable clock skew for the KDC and the POSTDATE
+option has not been specified, then the start time of the ticket is set to
+the authentication server's current time. If it indicates a time in the
+future beyond the acceptable clock skew, but the POSTDATED option has not
+been specified or the MAY-POSTDATE flag is not set in the TGT, then the
+error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the
+ticket-granting ticket has the MAY-POSTDATE flag set, then the resulting
+ticket will be postdated and the requested starttime is checked against the
+policy of the local realm. If acceptable, the ticket's start time is set as
+requested, and the INVALID flag is set. The postdated ticket must be
+validated before use by presenting it to the KDC after the starttime has
+been reached. However, in no case may the starttime, endtime, or renew-till
+time of a newly-issued postdated ticket extend beyond the renew-till time
+of the ticket-granting ticket.
+
+If the ENC-TKT-IN-SKEY option has been specified and an additional ticket
+has been included in the request, the KDC will decrypt the additional
+ticket using the key for the server to which the additional ticket was
+issued and verify that it is a ticket-granting ticket. If the name of the
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+requested server is missing from the request, the name of the client in the
+additional ticket will be used. Otherwise the name of the requested server
+will be compared to the name of the client in the additional ticket and if
+different, the request will be rejected. If the request succeeds, the
+session key from the additional ticket will be used to encrypt the new
+ticket that is issued instead of using the key of the server for which the
+new ticket will be used[17].
+
+If the name of the server in the ticket that is presented to the KDC as
+part of the authentication header is not that of the ticket-granting server
+itself, the server is registered in the realm of the KDC, and the RENEW
+option is requested, then the KDC will verify that the RENEWABLE flag is
+set in the ticket, that the INVALID flag is not set in the ticket, and that
+the renew_till time is still in the future. If the VALIDATE option is
+rqeuested, the KDC will check that the starttime has passed and the INVALID
+flag is set. If the PROXY option is requested, then the KDC will check that
+the PROXIABLE flag is set in the ticket. If the tests succeed, and the
+ticket passes the hotlist check described in the next paragraph, the KDC
+will issue the appropriate new ticket.
+
+3.3.3.1. Checking for revoked tickets
+
+Whenever a request is made to the ticket-granting server, the presented
+ticket(s) is(are) checked against a hot-list of tickets which have been
+canceled. This hot-list might be implemented by storing a range of issue
+timestamps for 'suspect tickets'; if a presented ticket had an authtime in
+that range, it would be rejected. In this way, a stolen ticket-granting
+ticket or renewable ticket cannot be used to gain additional tickets
+(renewals or otherwise) once the theft has been reported. Any normal ticket
+obtained before it was reported stolen will still be valid (because they
+require no interaction with the KDC), but only until their normal
+expiration time.
+
+The ciphertext part of the response in the KRB_TGS_REP message is encrypted
+in the sub-session key from the Authenticator, if present, or the session
+key key from the ticket-granting ticket. It is not encrypted using the
+client's secret key. Furthermore, the client's key's expiration date and
+the key version number fields are left out since these values are stored
+along with the client's database record, and that record is not needed to
+satisfy a request based on a ticket-granting ticket. See section A.6 for
+pseudocode.
+
+3.3.3.2. Encoding the transited field
+
+If the identity of the server in the TGT that is presented to the KDC as
+part of the authentication header is that of the ticket-granting service,
+but the TGT was issued from another realm, the KDC will look up the
+inter-realm key shared with that realm and use that key to decrypt the
+ticket. If the ticket is valid, then the KDC will honor the request,
+subject to the constraints outlined above in the section describing the AS
+exchange. The realm part of the client's identity will be taken from the
+ticket-granting ticket. The name of the realm that issued the
+ticket-granting ticket will be added to the transited field of the ticket
+to be issued. This is accomplished by reading the transited field from the
+ticket-granting ticket (which is treated as an unordered set of realm
+names), adding the new realm to the set, then constructing and writing out
+its encoded (shorthand) form (this may involve a rearrangement of the
+existing encoding).
+
+Note that the ticket-granting service does not add the name of its own
+realm. Instead, its responsibility is to add the name of the previous
+realm. This prevents a malicious Kerberos server from intentionally leaving
+out its own name (it could, however, omit other realms' names).
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+The names of neither the local realm nor the principal's realm are to be
+included in the transited field. They appear elsewhere in the ticket and
+both are known to have taken part in authenticating the principal. Since
+the endpoints are not included, both local and single-hop inter-realm
+authentication result in a transited field that is empty.
+
+Because the name of each realm transited is added to this field, it might
+potentially be very long. To decrease the length of this field, its
+contents are encoded. The initially supported encoding is optimized for the
+normal case of inter-realm communication: a hierarchical arrangement of
+realms using either domain or X.500 style realm names. This encoding
+(called DOMAIN-X500-COMPRESS) is now described.
+
+Realm names in the transited field are separated by a ",". The ",", "\",
+trailing "."s, and leading spaces (" ") are special characters, and if they
+are part of a realm name, they must be quoted in the transited field by
+preced- ing them with a "\".
+
+A realm name ending with a "." is interpreted as being prepended to the
+previous realm. For example, we can encode traversal of EDU, MIT.EDU,
+ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
+
+     "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
+
+Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that
+they would not be included in this field, and we would have:
+
+     "EDU,MIT.,WASHINGTON.EDU"
+
+A realm name beginning with a "/" is interpreted as being appended to the
+previous realm[18]. If it is to stand by itself, then it should be preceded
+by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO,
+/COM/HP, /COM, and /COM/DEC as:
+
+     "/COM,/HP,/APOLLO, /COM/DEC".
+
+Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they
+they would not be included in this field, and we would have:
+
+     "/COM,/HP"
+
+A null subfield preceding or following a "," indicates that all realms
+between the previous realm and the next realm have been traversed[19].
+Thus, "," means that all realms along the path between the client and the
+server have been traversed. ",EDU, /COM," means that that all realms from
+the client's realm up to EDU (in a domain style hierarchy) have been
+traversed, and that everything from /COM down to the server's realm in an
+X.500 style has also been traversed. This could occur if the EDU realm in
+one hierarchy shares an inter-realm key directly with the /COM realm in
+another hierarchy.
+
+3.3.4. Receipt of KRB_TGS_REP message
+
+When the KRB_TGS_REP is received by the client, it is processed in the same
+manner as the KRB_AS_REP processing described above. The primary difference
+is that the ciphertext part of the response must be decrypted using the
+session key from the ticket-granting ticket rather than the client's secret
+key. The server name returned in the reply is the true principal name of
+the service. See section A.7 for pseudocode.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+3.4. The KRB_SAFE Exchange
+
+The KRB_SAFE message may be used by clients requiring the ability to detect
+modifications of messages they exchange. It achieves this by including a
+keyed collision-proof checksum of the user data and some control
+information. The checksum is keyed with an encryption key (usually the last
+key negotiated via subkeys, or the session key if no negotiation has
+occured).
+
+3.4.1. Generation of a KRB_SAFE message
+
+When an application wishes to send a KRB_SAFE message, it collects its data
+and the appropriate control information and computes a checksum over them.
+The checksum algorithm should be a keyed one-way hash function (such as the
+RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES
+MAC), generated using the sub-session key if present, or the session key.
+Different algorithms may be selected by changing the checksum type in the
+message. Unkeyed or non-collision-proof checksums are not suitable for this
+use.
+
+The control information for the KRB_SAFE message includes both a timestamp
+and a sequence number. The designer of an application using the KRB_SAFE
+message must choose at least one of the two mechanisms. This choice should
+be based on the needs of the application protocol.
+
+Sequence numbers are useful when all messages sent will be received by
+one's peer. Connection state is presently required to maintain the session
+key, so maintaining the next sequence number should not present an
+additional problem.
+
+If the application protocol is expected to tolerate lost messages without
+them being resent, the use of the timestamp is the appropriate replay
+detection mechanism. Using timestamps is also the appropriate mechanism for
+multi-cast protocols where all of one's peers share a common sub-session
+key, but some messages will be sent to a subset of one's peers.
+
+After computing the checksum, the client then transmits the information and
+checksum to the recipient in the message format specified in section 5.6.1.
+
+3.4.2. Receipt of KRB_SAFE message
+
+When an application receives a KRB_SAFE message, it verifies it as follows.
+If any error occurs, an error code is reported for use by the application.
+
+The message is first checked by verifying that the protocol version and
+type fields match the current version and KRB_SAFE, respectively. A
+mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error.
+The application verifies that the checksum used is a collision-proof keyed
+checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If
+the sender's address was included in the control information, the recipient
+verifies that the operating system's report of the sender's address matches
+the sender's address in the message, and (if a recipient address is
+specified or the recipient requires an address) that one of the recipient's
+addresses appears as the recipient's address in the message. A failed match
+for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp
+and usec and/or the sequence number fields are checked. If timestamp and
+usec are expected and not present, or they are present but not current, the
+KRB_AP_ERR_SKEW error is generated. If the server name, along with the
+client name, time and microsecond fields from the Authenticator match any
+recently-seen (sent or received[20] ) such tuples, the KRB_AP_ERR_REPEAT
+error is generated. If an incorrect sequence number is included, or a
+sequence number is expected but not present, the KRB_AP_ERR_BADORDER error
+is generated. If neither a time-stamp and usec or a sequence number is
+present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the checksum is
+computed over the data and control information, and if it doesn't match the
+received checksum, a KRB_AP_ERR_MODIFIED error is generated.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+If all the checks succeed, the application is assured that the message was
+generated by its peer and was not modi- fied in transit.
+
+3.5. The KRB_PRIV Exchange
+
+The KRB_PRIV message may be used by clients requiring confidentiality and
+the ability to detect modifications of exchanged messages. It achieves this
+by encrypting the messages and adding control information.
+
+3.5.1. Generation of a KRB_PRIV message
+
+When an application wishes to send a KRB_PRIV message, it collects its data
+and the appropriate control information (specified in section 5.7.1) and
+encrypts them under an encryption key (usually the last key negotiated via
+subkeys, or the session key if no negotiation has occured). As part of the
+control information, the client must choose to use either a timestamp or a
+sequence number (or both); see the discussion in section 3.4.1 for
+guidelines on which to use. After the user data and control information are
+encrypted, the client transmits the ciphertext and some 'envelope'
+information to the recipient.
+
+3.5.2. Receipt of KRB_PRIV message
+
+When an application receives a KRB_PRIV message, it verifies it as follows.
+If any error occurs, an error code is reported for use by the application.
+
+The message is first checked by verifying that the protocol version and
+type fields match the current version and KRB_PRIV, respectively. A
+mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error.
+The application then decrypts the ciphertext and processes the resultant
+plaintext. If decryption shows the data to have been modified, a
+KRB_AP_ERR_BAD_INTEGRITY error is generated. If the sender's address was
+included in the control information, the recipient verifies that the
+operating system's report of the sender's address matches the sender's
+address in the message, and (if a recipient address is specified or the
+recipient requires an address) that one of the recipient's addresses
+appears as the recipient's address in the message. A failed match for
+either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and
+usec and/or the sequence number fields are checked. If timestamp and usec
+are expected and not present, or they are present but not current, the
+KRB_AP_ERR_SKEW error is generated. If the server name, along with the
+client name, time and microsecond fields from the Authenticator match any
+recently-seen such tuples, the KRB_AP_ERR_REPEAT error is generated. If an
+incorrect sequence number is included, or a sequence number is expected but
+not present, the KRB_AP_ERR_BADORDER error is generated. If neither a
+time-stamp and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED
+error is generated.
+
+If all the checks succeed, the application can assume the message was
+generated by its peer, and was securely transmitted (without intruders able
+to see the unencrypted contents).
+
+3.6. The KRB_CRED Exchange
+
+The KRB_CRED message may be used by clients requiring the ability to send
+Kerberos credentials from one host to another. It achieves this by sending
+the tickets together with encrypted data containing the session keys and
+other information associated with the tickets.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+3.6.1. Generation of a KRB_CRED message
+
+When an application wishes to send a KRB_CRED message it first (using the
+KRB_TGS exchange) obtains credentials to be sent to the remote host. It
+then constructs a KRB_CRED message using the ticket or tickets so obtained,
+placing the session key needed to use each ticket in the key field of the
+corresponding KrbCredInfo sequence of the encrypted part of the the
+KRB_CRED message.
+
+Other information associated with each ticket and obtained during the
+KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence
+in the encrypted part of the KRB_CRED message. The current time and, if
+specifically required by the application the nonce, s-address, and
+r-address fields, are placed in the encrypted part of the KRB_CRED message
+which is then encrypted under an encryption key previosuly exchanged in the
+KRB_AP exchange (usually the last key negotiated via subkeys, or the
+session key if no negotiation has occured).
+
+3.6.2. Receipt of KRB_CRED message
+
+When an application receives a KRB_CRED message, it verifies it. If any
+error occurs, an error code is reported for use by the application. The
+message is verified by checking that the protocol version and type fields
+match the current version and KRB_CRED, respectively. A mismatch generates
+a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then
+decrypts the ciphertext and processes the resultant plaintext. If
+decryption shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY
+error is generated.
+
+If present or required, the recipient verifies that the operating system's
+report of the sender's address matches the sender's address in the message,
+and that one of the recipient's addresses appears as the recipient's
+address in the message. A failed match for either case generates a
+KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce
+field if required) are checked next. If the timestamp and usec are not
+present, or they are present but not current, the KRB_AP_ERR_SKEW error is
+generated.
+
+If all the checks succeed, the application stores each of the new tickets
+in its ticket cache together with the session key and other information in
+the corresponding KrbCredInfo sequence from the encrypted part of the
+KRB_CRED message.
+
+4. The Kerberos Database
+
+The Kerberos server must have access to a database containing the principal
+identifiers and secret keys of principals to be authenticated[21].
+
+4.1. Database contents
+
+A database entry should contain at least the following fields:
+
+Field                Value
+
+name                 Principal's identifier
+key                  Principal's secret key
+p_kvno               Principal's key version
+max_life             Maximum lifetime for Tickets
+max_renewable_life   Maximum total lifetime for renewable Tickets
+
+The name field is an encoding of the principal's identifier. The key field
+contains an encryption key. This key is the principal's secret key. (The
+key can be encrypted before storage under a Kerberos "master key" to
+protect it in case the database is compromised but the master key is not.
+In that case, an extra field must be added to indicate the master key
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+version used, see below.) The p_kvno field is the key version number of the
+principal's secret key. The max_life field contains the maximum allowable
+lifetime (endtime - starttime) for any Ticket issued for this principal.
+The max_renewable_life field contains the maximum allowable total lifetime
+for any renewable Ticket issued for this principal. (See section 3.1 for a
+description of how these lifetimes are used in determining the lifetime of
+a given Ticket.)
+
+A server may provide KDC service to several realms, as long as the database
+representation provides a mechanism to distinguish between principal
+records with identifiers which differ only in the realm name.
+
+When an application server's key changes, if the change is routine (i.e.
+not the result of disclosure of the old key), the old key should be
+retained by the server until all tickets that had been issued using that
+key have expired. Because of this, it is possible for several keys to be
+active for a single principal. Ciphertext encrypted in a principal's key is
+always tagged with the version of the key that was used for encryption, to
+help the recipient find the proper key for decryption.
+
+When more than one key is active for a particular principal, the principal
+will have more than one record in the Kerberos database. The keys and key
+version numbers will differ between the records (the rest of the fields may
+or may not be the same). Whenever Kerberos issues a ticket, or responds to
+a request for initial authentication, the most recent key (known by the
+Kerberos server) will be used for encryption. This is the key with the
+highest key version number.
+
+4.2. Additional fields
+
+Project Athena's KDC implementation uses additional fields in its database:
+
+Field        Value
+
+K_kvno       Kerberos' key version
+expiration   Expiration date for entry
+attributes   Bit field of attributes
+mod_date     Timestamp of last modification
+mod_name     Modifying principal's identifier
+
+The K_kvno field indicates the key version of the Kerberos master key under
+which the principal's secret key is encrypted.
+
+After an entry's expiration date has passed, the KDC will return an error
+to any client attempting to gain tickets as or for the principal. (A
+database may want to maintain two expiration dates: one for the principal,
+and one for the principal's current key. This allows password aging to work
+independently of the principal's expiration date. However, due to the
+limited space in the responses, the KDC must combine the key expiration and
+principal expiration date into a single value called 'key_exp', which is
+used as a hint to the user to take administrative action.)
+
+The attributes field is a bitfield used to govern the operations involving
+the principal. This field might be useful in conjunction with user
+registration procedures, for site-specific policy implementations (Project
+Athena currently uses it for their user registration process controlled by
+the system-wide database service, Moira [LGDSR87]), to identify whether a
+principal can play the role of a client or server or both, to note whether
+a server is appropriate trusted to recieve credentials delegated by a
+client, or to identify the 'string to key' conversion algorithm used for a
+principal's key[22]. Other bits are used to indicate that certain ticket
+options should not be allowed in tickets encrypted under a principal's key
+(one bit each): Disallow issuing postdated tickets, disallow issuing
+forwardable tickets, disallow issuing tickets based on TGT authentication,
+disallow issuing renewable tickets, disallow issuing proxiable tickets, and
+disallow issuing tickets for which the principal is the server.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+The mod_date field contains the time of last modification of the entry, and
+the mod_name field contains the name of the principal which last modified
+the entry.
+
+4.3. Frequently Changing Fields
+
+Some KDC implementations may wish to maintain the last time that a request
+was made by a particular principal. Information that might be maintained
+includes the time of the last request, the time of the last request for a
+ticket-granting ticket, the time of the last use of a ticket-granting
+ticket, or other times. This information can then be returned to the user
+in the last-req field (see section 5.2).
+
+Other frequently changing information that can be maintained is the latest
+expiration time for any tickets that have been issued using each key. This
+field would be used to indicate how long old keys must remain valid to
+allow the continued use of outstanding tickets.
+
+4.4. Site Constants
+
+The KDC implementation should have the following configurable constants or
+options, to allow an administrator to make and enforce policy decisions:
+
+   * The minimum supported lifetime (used to determine whether the
+     KDC_ERR_NEVER_VALID error should be returned). This constant should
+     reflect reasonable expectations of round-trip time to the KDC,
+     encryption/decryption time, and processing time by the client and
+     target server, and it should allow for a minimum 'useful' lifetime.
+   * The maximum allowable total (renewable) lifetime of a ticket
+     (renew_till - starttime).
+   * The maximum allowable lifetime of a ticket (endtime - starttime).
+   * Whether to allow the issue of tickets with empty address fields
+     (including the ability to specify that such tickets may only be issued
+     if the request specifies some authorization_data).
+   * Whether proxiable, forwardable, renewable or post-datable tickets are
+     to be issued.
+
+5. Message Specifications
+
+The following sections describe the exact contents and encoding of protocol
+messages and objects. The ASN.1 base definitions are presented in the first
+subsection. The remaining subsections specify the protocol objects (tickets
+and authenticators) and messages. Specification of encryption and checksum
+techniques, and the fields related to them, appear in section 6.
+
+Optional field in ASN.1 sequences
+
+For optional integer value and date fields in ASN.1 sequences where a
+default value has been specified, certain default values will not be
+allowed in the encoding because these values will always be represented
+through defaulting by the absence of the optional field. For example, one
+will not send a microsecond zero value because one must make sure that
+there is only one way to encode this value.
+
+Additional fields in ASN.1 sequences
+
+Implementations receiving Kerberos messages with additional fields present
+in ASN.1 sequences should carry the those fields through, unmodified, when
+the message is forwarded. Implementations should not drop such fields if
+the sequence is reencoded.
+
+5.1. ASN.1 Distinguished Encoding Representation
+
+All uses of ASN.1 in Kerberos shall use the Distinguished Encoding
+Representation of the data elements as described in the X.509
+specification, section 8.7 [X509-88].
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+5.2. ASN.1 Base Definitions
+
+The following ASN.1 base definitions are used in the rest of this section.
+Note that since the underscore character (_) is not permitted in ASN.1
+names, the hyphen (-) is used in its place for the purposes of ASN.1 names.
+
+Realm ::=           GeneralString
+PrincipalName ::=   SEQUENCE {
+                    name-type[0]     INTEGER,
+                    name-string[1]   SEQUENCE OF GeneralString
+}
+
+Kerberos realms are encoded as GeneralStrings. Realms shall not contain a
+character with the code 0 (the ASCII NUL). Most realms will usually consist
+of several components separated by periods (.), in the style of Internet
+Domain Names, or separated by slashes (/) in the style of X.500 names.
+Acceptable forms for realm names are specified in section 7. A
+PrincipalName is a typed sequence of components consisting of the following
+sub-fields:
+
+name-type
+     This field specifies the type of name that follows. Pre-defined values
+     for this field are specified in section 7.2. The name-type should be
+     treated as a hint. Ignoring the name type, no two names can be the
+     same (i.e. at least one of the components, or the realm, must be
+     different). This constraint may be eliminated in the future.
+name-string
+     This field encodes a sequence of components that form a name, each
+     component encoded as a GeneralString. Taken together, a PrincipalName
+     and a Realm form a principal identifier. Most PrincipalNames will have
+     only a few components (typically one or two).
+
+KerberosTime ::=   GeneralizedTime
+                   -- Specifying UTC time zone (Z)
+
+The timestamps used in Kerberos are encoded as GeneralizedTimes. An
+encoding shall specify the UTC time zone (Z) and shall not include any
+fractional portions of the seconds. It further shall not include any
+separators. Example: The only valid format for UTC time 6 minutes, 27
+seconds after 9 pm on 6 November 1985 is 19851106210627Z.
+
+HostAddress ::=     SEQUENCE  {
+                    addr-type[0]             INTEGER,
+                    address[1]               OCTET STRING
+}
+
+HostAddresses ::=   SEQUENCE OF HostAddress
+
+The host adddress encodings consists of two fields:
+
+addr-type
+     This field specifies the type of address that follows. Pre-defined
+     values for this field are specified in section 8.1.
+address
+     This field encodes a single address of type addr-type.
+
+The two forms differ slightly. HostAddress contains exactly one address;
+HostAddresses contains a sequence of possibly many addresses.
+
+AuthorizationData ::=   SEQUENCE OF SEQUENCE {
+                        ad-type[0]               INTEGER,
+                        ad-data[1]               OCTET STRING
+}
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+ad-data
+     This field contains authorization data to be interpreted according to
+     the value of the corresponding ad-type field.
+ad-type
+     This field specifies the format for the ad-data subfield. All negative
+     values are reserved for local use. Non-negative values are reserved
+     for registered use.
+
+Each sequence of type and data is refered to as an authorization element.
+Elements may be application specific, however, there is a common set of
+recursive elements that should be understood by all implementations. These
+elements contain other elements embedded within them, and the
+interpretation of the encapsulating element determines which of the
+embedded elements must be interpreted, and which may be ignored.
+Definitions for these common elements may be found in Appendix B.
+
+TicketExtensions ::= SEQUENCE OF SEQUENCE {
+           te-type[0]       INTEGER,
+           te-data[1]       OCTET STRING
+}
+
+
+
+te-data
+     This field contains opaque data that must be caried with the ticket to
+     support extensions to the Kerberos protocol including but not limited
+     to some forms of inter-realm key exchange and plaintext authorization
+     data. See appendix C for some common uses of this field.
+te-type
+     This field specifies the format for the te-data subfield. All negative
+     values are reserved for local use. Non-negative values are reserved
+     for registered use.
+
+APOptions ::=   BIT STRING
+                  -- reserved(0),
+                  -- use-session-key(1),
+                  -- mutual-required(2)
+
+TicketFlags ::= BIT STRING
+                  -- reserved(0),
+                  -- forwardable(1),
+                  -- forwarded(2),
+                  -- proxiable(3),
+                  -- proxy(4),
+                  -- may-postdate(5),
+                  -- postdated(6),
+                  -- invalid(7),
+                  -- renewable(8),
+                  -- initial(9),
+                  -- pre-authent(10),
+                  -- hw-authent(11),
+                  -- transited-policy-checked(12),
+                  -- ok-as-delegate(13)
+
+KDCOptions ::=   BIT STRING io
+                  -- reserved(0),
+                  -- forwardable(1),
+                  -- forwarded(2),
+                  -- proxiable(3),
+                  -- proxy(4),
+                  -- allow-postdate(5),
+                  -- postdated(6),
+                  -- unused7(7),
+                  -- renewable(8),
+                  -- unused9(9),
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                  -- unused10(10),
+                  -- unused11(11),
+                  -- unused12(12),
+                  -- unused13(13),
+                  -- requestanonymous(14),
+                  -- canonicalize(15),
+                  -- disable-transited-check(26),
+                  -- renewable-ok(27),
+                  -- enc-tkt-in-skey(28),
+                  -- renew(30),
+                  -- validate(31)
+
+ASN.1 Bit strings have a length and a value. When used in Kerberos for the
+APOptions, TicketFlags, and KDCOptions, the length of the bit string on
+generated values should be the smallest number of bits needed to include
+the highest order bit that is set (1), but in no case less than 32 bits.
+The ASN.1 representation of the bit strings uses unnamed bits, with the
+meaning of the individual bits defined by the comments in the specification
+above. Implementations should accept values of bit strings of any length
+and treat the value of flags corresponding to bits beyond the end of the
+bit string as if the bit were reset (0). Comparison of bit strings of
+different length should treat the smaller string as if it were padded with
+zeros beyond the high order bits to the length of the longer string[23].
+
+LastReq ::=   SEQUENCE OF SEQUENCE {
+               lr-type[0]               INTEGER,
+               lr-value[1]              KerberosTime
+}
+
+lr-type
+     This field indicates how the following lr-value field is to be
+     interpreted. Negative values indicate that the information pertains
+     only to the responding server. Non-negative values pertain to all
+     servers for the realm. If the lr-type field is zero (0), then no
+     information is conveyed by the lr-value subfield. If the absolute
+     value of the lr-type field is one (1), then the lr-value subfield is
+     the time of last initial request for a TGT. If it is two (2), then the
+     lr-value subfield is the time of last initial request. If it is three
+     (3), then the lr-value subfield is the time of issue for the newest
+     ticket-granting ticket used. If it is four (4), then the lr-value
+     subfield is the time of the last renewal. If it is five (5), then the
+     lr-value subfield is the time of last request (of any type). If it is
+     (6), then the lr-value subfield is the time when the password will
+     expire.
+lr-value
+     This field contains the time of the last request. the time must be
+     interpreted according to the contents of the accompanying lr-type
+     subfield.
+
+See section 6 for the definitions of Checksum, ChecksumType, EncryptedData,
+EncryptionKey, EncryptionType, and KeyType.
+
+5.3. Tickets and Authenticators
+
+This section describes the format and encryption parameters for tickets and
+authenticators. When a ticket or authenticator is included in a protocol
+message it is treated as an opaque object.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+5.3.1. Tickets
+
+A ticket is a record that helps a client authenticate to a service. A
+Ticket contains the following information:
+
+Ticket ::=        [APPLICATION 1] SEQUENCE {
+                  tkt-vno[0]                   INTEGER,
+                  realm[1]                     Realm,
+                  sname[2]                     PrincipalName,
+                  enc-part[3]                  EncryptedData,
+                  extensions[4]                TicketExtensions OPTIONAL
+}
+
+-- Encrypted part of ticket
+EncTicketPart ::= [APPLICATION 3] SEQUENCE {
+                  flags[0]                     TicketFlags,
+                  key[1]                       EncryptionKey,
+                  crealm[2]                    Realm,
+                  cname[3]                     PrincipalName,
+                  transited[4]                 TransitedEncoding,
+                  authtime[5]                  KerberosTime,
+                  starttime[6]                 KerberosTime OPTIONAL,
+                  endtime[7]                   KerberosTime,
+                  renew-till[8]                KerberosTime OPTIONAL,
+                  caddr[9]                     HostAddresses OPTIONAL,
+                  authorization-data[10]       AuthorizationData OPTIONAL
+}
+-- encoded Transited field
+TransitedEncoding ::=   SEQUENCE {
+                        tr-type[0]             INTEGER, -- must be
+registered
+                        contents[1]            OCTET STRING
+}
+
+The encoding of EncTicketPart is encrypted in the key shared by Kerberos
+and the end server (the server's secret key). See section 6 for the format
+of the ciphertext.
+
+tkt-vno
+     This field specifies the version number for the ticket format. This
+     document describes version number 5.
+realm
+     This field specifies the realm that issued a ticket. It also serves to
+     identify the realm part of the server's principal identifier. Since a
+     Kerberos server can only issue tickets for servers within its realm,
+     the two will always be identical.
+sname
+     This field specifies all components of the name part of the server's
+     identity, including those parts that identify a specific instance of a
+     service.
+enc-part
+     This field holds the encrypted encoding of the EncTicketPart sequence.
+extensions
+     This optional field contains a sequence of extentions that may be used
+     to carry information that must be carried with the ticket to support
+     several extensions, including but not limited to plaintext
+     authorization data, tokens for exchanging inter-realm keys, and other
+     information that must be associated with a ticket for use by the
+     application server. See Appendix C for definitions of some common
+     extensions.
+
+     Note that some older versions of Kerberos did not support this field.
+     Because this is an optional field it will not break older clients, but
+     older clients might strip this field from the ticket before sending it
+     to the application server. This limits the usefulness of this ticket
+     field to environments where the ticket will not be parsed and
+     reconstructed by these older Kerberos clients.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     If it is known that the client will strip this field from the ticket,
+     as an interim measure the KDC may append this field to the end of the
+     enc-part of the ticket and append a traler indicating the lenght of
+     the appended extensions field. (this paragraph is open for discussion,
+     including the form of the traler).
+flags
+     This field indicates which of various options were used or requested
+     when the ticket was issued. It is a bit-field, where the selected
+     options are indicated by the bit being set (1), and the unselected
+     options and reserved fields being reset (0). Bit 0 is the most
+     significant bit. The encoding of the bits is specified in section 5.2.
+     The flags are described in more detail above in section 2. The
+     meanings of the flags are:
+
+          Bit(s)      Name         Description
+
+          0           RESERVED
+                                   Reserved for future  expansion  of  this
+                                   field.
+
+          1           FORWARDABLE
+                                   The FORWARDABLE flag  is  normally  only
+                                   interpreted  by  the  TGS,  and  can  be
+                                   ignored by end servers.  When set,  this
+                                   flag  tells  the  ticket-granting server
+                                   that it is OK to  issue  a  new  ticket-
+                                   granting ticket with a different network
+                                   address based on the presented ticket.
+
+          2           FORWARDED
+                                   When set, this flag indicates  that  the
+                                   ticket  has either been forwarded or was
+                                   issued based on authentication involving
+                                   a forwarded ticket-granting ticket.
+
+          3           PROXIABLE
+                                   The  PROXIABLE  flag  is  normally  only
+                                   interpreted  by  the  TGS,  and  can  be
+                                   ignored by end servers.   The  PROXIABLE
+                                   flag  has an interpretation identical to
+                                   that of  the  FORWARDABLE  flag,  except
+                                   that   the   PROXIABLE  flag  tells  the
+                                   ticket-granting server  that  only  non-
+                                   ticket-granting  tickets  may  be issued
+                                   with different network addresses.
+
+          4           PROXY
+                                   When set, this  flag  indicates  that  a
+                                   ticket is a proxy.
+
+          5           MAY-POSTDATE
+                                   The MAY-POSTDATE flag is  normally  only
+                                   interpreted  by  the  TGS,  and  can  be
+                                   ignored by end servers.  This flag tells
+                                   the  ticket-granting server that a post-
+                                   dated ticket may be issued based on this
+                                   ticket-granting ticket.
+
+          6           POSTDATED
+                                   This flag indicates that this ticket has
+                                   been  postdated.   The  end-service  can
+                                   check the authtime field to see when the
+                                   original authentication occurred.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+          7           INVALID
+                                   This flag indicates  that  a  ticket  is
+                                   invalid, and it must be validated by the
+                                   KDC  before  use.   Application  servers
+                                   must reject tickets which have this flag
+                                   set.
+
+          8           RENEWABLE
+                                   The  RENEWABLE  flag  is  normally  only
+                                   interpreted  by the TGS, and can usually
+                                   be ignored by end servers (some particu-
+                                   larly careful servers may wish to disal-
+                                   low  renewable  tickets).   A  renewable
+                                   ticket  can be used to obtain a replace-
+                                   ment ticket  that  expires  at  a  later
+                                   date.
+
+          9           INITIAL
+                                   This flag indicates that this ticket was
+                                   issued  using  the  AS protocol, and not
+                                   issued  based   on   a   ticket-granting
+                                   ticket.
+
+          10          PRE-AUTHENT
+                                   This flag indicates that during  initial
+                                   authentication, the client was authenti-
+                                   cated by the KDC  before  a  ticket  was
+                                   issued.    The   strength  of  the  pre-
+                                   authentication method is not  indicated,
+                                   but is acceptable to the KDC.
+
+          11          HW-AUTHENT
+                                   This flag indicates  that  the  protocol
+                                   employed   for   initial  authentication
+                                   required the use of hardware expected to
+                                   be possessed solely by the named client.
+                                   The hardware  authentication  method  is
+                                   selected  by the KDC and the strength of
+                                   the method is not indicated.
+
+          12           TRANSITED   This flag indicates that the KDC for the
+                  POLICY-CHECKED   realm has checked the transited field
+                                   against a realm defined policy for
+                                   trusted certifiers.  If this flag is
+                                   reset (0), then the application server
+                                   must check the transited field itself,
+                                   and if unable to do so it must reject
+                                   the authentication.  If the flag is set
+                                   (1) then the application server may skip
+                                   its own validation of the transited
+                                   field, relying on the validation
+                                   performed by the KDC.  At its option the
+                                   application server may still apply its
+                                   own validation based on a separate
+                                   policy for acceptance.
+
+          13      OK-AS-DELEGATE   This flag indicates that the server (not
+                                   the client) specified in the ticket has
+                                   been determined by policy of the realm
+                                   to be a suitable recipient of
+                                   delegation.  A client can use the
+                                   presence of this flag to help it make a
+                                   decision whether to delegate credentials
+                                   (either grant a proxy or a forwarded
+                                   ticket granting ticket) to this server.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                                   The client is free to ignore the value
+                                   of this flag.  When setting this flag,
+                                   an administrator should consider the
+                                   Security and placement of the server on
+                                   which the service will run, as well as
+                                   whether the service requires the use of
+                                   delegated credentials.
+
+          14          ANONYMOUS
+                                   This flag indicates that  the  principal
+                                   named in the ticket is a generic princi-
+                                   pal for the realm and does not  identify
+                                   the  individual  using  the ticket.  The
+                                   purpose  of  the  ticket  is   only   to
+                                   securely  distribute  a session key, and
+                                   not to identify  the  user.   Subsequent
+                                   requests  using the same ticket and ses-
+                                   sion may be  considered  as  originating
+                                   from  the  same  user, but requests with
+                                   the same username but a different ticket
+                                   are  likely  to originate from different
+                                   users.
+
+          15-31       RESERVED
+                                   Reserved for future use.
+
+key
+     This field exists in the ticket and the KDC response and is used to
+     pass the session key from Kerberos to the application server and the
+     client. The field's encoding is described in section 6.2.
+crealm
+     This field contains the name of the realm in which the client is
+     registered and in which initial authentication took place.
+cname
+     This field contains the name part of the client's principal
+     identifier.
+transited
+     This field lists the names of the Kerberos realms that took part in
+     authenticating the user to whom this ticket was issued. It does not
+     specify the order in which the realms were transited. See section
+     3.3.3.2 for details on how this field encodes the traversed realms.
+     When the names of CA's are to be embedded inthe transited field (as
+     specified for some extentions to the protocol), the X.500 names of the
+     CA's should be mapped into items in the transited field using the
+     mapping defined by RFC2253.
+authtime
+     This field indicates the time of initial authentication for the named
+     principal. It is the time of issue for the original ticket on which
+     this ticket is based. It is included in the ticket to provide
+     additional information to the end service, and to provide the
+     necessary information for implementation of a `hot list' service at
+     the KDC. An end service that is particularly paranoid could refuse to
+     accept tickets for which the initial authentication occurred "too far"
+     in the past. This field is also returned as part of the response from
+     the KDC. When returned as part of the response to initial
+     authentication (KRB_AS_REP), this is the current time on the Kerberos
+     server[24].
+starttime
+     This field in the ticket specifies the time after which the ticket is
+     valid. Together with endtime, this field specifies the life of the
+     ticket. If it is absent from the ticket, its value should be treated
+     as that of the authtime field.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+endtime
+     This field contains the time after which the ticket will not be
+     honored (its expiration time). Note that individual services may place
+     their own limits on the life of a ticket and may reject tickets which
+     have not yet expired. As such, this is really an upper bound on the
+     expiration time for the ticket.
+renew-till
+     This field is only present in tickets that have the RENEWABLE flag set
+     in the flags field. It indicates the maximum endtime that may be
+     included in a renewal. It can be thought of as the absolute expiration
+     time for the ticket, including all renewals.
+caddr
+     This field in a ticket contains zero (if omitted) or more (if present)
+     host addresses. These are the addresses from which the ticket can be
+     used. If there are no addresses, the ticket can be used from any
+     location. The decision by the KDC to issue or by the end server to
+     accept zero-address tickets is a policy decision and is left to the
+     Kerberos and end-service administrators; they may refuse to issue or
+     accept such tickets. The suggested and default policy, however, is
+     that such tickets will only be issued or accepted when additional
+     information that can be used to restrict the use of the ticket is
+     included in the authorization_data field. Such a ticket is a
+     capability.
+
+     Network addresses are included in the ticket to make it harder for an
+     attacker to use stolen credentials. Because the session key is not
+     sent over the network in cleartext, credentials can't be stolen simply
+     by listening to the network; an attacker has to gain access to the
+     session key (perhaps through operating system security breaches or a
+     careless user's unattended session) to make use of stolen tickets.
+
+     It is important to note that the network address from which a
+     connection is received cannot be reliably determined. Even if it could
+     be, an attacker who has compromised the client's workstation could use
+     the credentials from there. Including the network addresses only makes
+     it more difficult, not impossible, for an attacker to walk off with
+     stolen credentials and then use them from a "safe" location.
+authorization-data
+     The authorization-data field is used to pass authorization data from
+     the principal on whose behalf a ticket was issued to the application
+     service. If no authorization data is included, this field will be left
+     out. Experience has shown that the name of this field is confusing,
+     and that a better name for this field would be restrictions.
+     Unfortunately, it is not possible to change the name of this field at
+     this time.
+
+     This field contains restrictions on any authority obtained on the
+     basis of authentication using the ticket. It is possible for any
+     principal in posession of credentials to add entries to the
+     authorization data field since these entries further restrict what can
+     be done with the ticket. Such additions can be made by specifying the
+     additional entries when a new ticket is obtained during the TGS
+     exchange, or they may be added during chained delegation using the
+     authorization data field of the authenticator.
+
+     Because entries may be added to this field by the holder of
+     credentials, except when an entry is separately authenticated by
+     encapulation in the kdc-issued element, it is not allowable for the
+     presence of an entry in the authorization data field of a ticket to
+     amplify the priveleges one would obtain from using a ticket.
+
+     The data in this field may be specific to the end service; the field
+     will contain the names of service specific objects, and the rights to
+     those objects. The format for this field is described in section 5.2.
+     Although Kerberos is not concerned with the format of the contents of
+     the sub-fields, it does carry type information (ad-type).
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     By using the authorization_data field, a principal is able to issue a
+     proxy that is valid for a specific purpose. For example, a client
+     wishing to print a file can obtain a file server proxy to be passed to
+     the print server. By specifying the name of the file in the
+     authorization_data field, the file server knows that the print server
+     can only use the client's rights when accessing the particular file to
+     be printed.
+
+     A separate service providing authorization or certifying group
+     membership may be built using the authorization-data field. In this
+     case, the entity granting authorization (not the authorized entity),
+     may obtain a ticket in its own name (e.g. the ticket is issued in the
+     name of a privelege server), and this entity adds restrictions on its
+     own authority and delegates the restricted authority through a proxy
+     to the client. The client would then present this authorization
+     credential to the application server separately from the
+     authentication exchange. Alternatively, such authorization credentials
+     may be embedded in the ticket authenticating the authorized entity,
+     when the authorization is separately authenticated using the
+     kdc-issued authorization data element (see B.4).
+
+     Similarly, if one specifies the authorization-data field of a proxy
+     and leaves the host addresses blank, the resulting ticket and session
+     key can be treated as a capability. See [Neu93] for some suggested
+     uses of this field.
+
+     The authorization-data field is optional and does not have to be
+     included in a ticket.
+
+5.3.2. Authenticators
+
+An authenticator is a record sent with a ticket to a server to certify the
+client's knowledge of the encryption key in the ticket, to help the server
+detect replays, and to help choose a "true session key" to use with the
+particular session. The encoding is encrypted in the ticket's session key
+shared by the client and the server:
+
+-- Unencrypted authenticator
+Authenticator ::= [APPLICATION 2] SEQUENCE  {
+                  authenticator-vno[0]          INTEGER,
+                  crealm[1]                     Realm,
+                  cname[2]                      PrincipalName,
+                  cksum[3]                      Checksum OPTIONAL,
+                  cusec[4]                      INTEGER,
+                  ctime[5]                      KerberosTime,
+                  subkey[6]                     EncryptionKey OPTIONAL,
+                  seq-number[7]                 INTEGER OPTIONAL,
+                  authorization-data[8]         AuthorizationData OPTIONAL
+}
+
+
+authenticator-vno
+     This field specifies the version number for the format of the
+     authenticator. This document specifies version 5.
+crealm and cname
+     These fields are the same as those described for the ticket in section
+     5.3.1.
+cksum
+     This field contains a checksum of the the applica- tion data that
+     accompanies the KRB_AP_REQ.
+cusec
+     This field contains the microsecond part of the client's timestamp.
+     Its value (before encryption) ranges from 0 to 999999. It often
+     appears along with ctime. The two fields are used together to specify
+     a reasonably accurate timestamp.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+ctime
+     This field contains the current time on the client's host.
+subkey
+     This field contains the client's choice for an encryption key which is
+     to be used to protect this specific application session. Unless an
+     application specifies otherwise, if this field is left out the session
+     key from the ticket will be used.
+seq-number
+     This optional field includes the initial sequence number to be used by
+     the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to
+     detect replays (It may also be used by application specific messages).
+     When included in the authenticator this field specifies the initial
+     sequence number for messages from the client to the server. When
+     included in the AP-REP message, the initial sequence number is that
+     for messages from the server to the client. When used in KRB_PRIV or
+     KRB_SAFE messages, it is incremented by one after each message is
+     sent. Sequence numbers fall in the range of 0 through 2^32 - 1 and
+     wrap to zero following the value 2^32 - 1.
+
+     For sequence numbers to adequately support the detection of replays
+     they should be non-repeating, even across connection boundaries. The
+     initial sequence number should be random and uniformly distributed
+     across the full space of possible sequence numbers, so that it cannot
+     be guessed by an attacker and so that it and the successive sequence
+     numbers do not repeat other sequences.
+authorization-data
+     This field is the same as described for the ticket in section 5.3.1.
+     It is optional and will only appear when additional restrictions are
+     to be placed on the use of a ticket, beyond those carried in the
+     ticket itself.
+
+5.4. Specifications for the AS and TGS exchanges
+
+This section specifies the format of the messages used in the exchange
+between the client and the Kerberos server. The format of possible error
+messages appears in section 5.9.1.
+
+5.4.1. KRB_KDC_REQ definition
+
+The KRB_KDC_REQ message has no type of its own. Instead, its type is one of
+KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an
+initial ticket or an additional ticket. In either case, the message is sent
+from the client to the Authentication Server to request credentials for a
+service.
+
+The message fields are:
+
+AS-REQ ::=         [APPLICATION 10] KDC-REQ
+TGS-REQ ::=        [APPLICATION 12] KDC-REQ
+
+KDC-REQ ::=        SEQUENCE {
+                   pvno[1]            INTEGER,
+                   msg-type[2]        INTEGER,
+                   padata[3]          SEQUENCE OF PA-DATA OPTIONAL,
+                   req-body[4]        KDC-REQ-BODY
+}
+
+PA-DATA ::=        SEQUENCE {
+                   padata-type[1]     INTEGER,
+                   padata-value[2]    OCTET STRING,
+                                      -- might be encoded AP-REQ
+}
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+KDC-REQ-BODY ::=   SEQUENCE {
+                    kdc-options[0]         KDCOptions,
+                    cname[1]               PrincipalName OPTIONAL,
+                                           -- Used only in AS-REQ
+                    realm[2]               Realm, -- Server's realm
+                                           -- Also client's in AS-REQ
+                    sname[3]               PrincipalName OPTIONAL,
+                    from[4]                KerberosTime OPTIONAL,
+                    till[5]                KerberosTime OPTIONAL,
+                    rtime[6]               KerberosTime OPTIONAL,
+                    nonce[7]               INTEGER,
+                    etype[8]               SEQUENCE OF INTEGER,
+                                           -- EncryptionType,
+                                           -- in preference order
+                    addresses[9]           HostAddresses OPTIONAL,
+                enc-authorization-data[10] EncryptedData OPTIONAL,
+                                           -- Encrypted AuthorizationData
+                                           -- encoding
+                    additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
+}
+
+The fields in this message are:
+
+pvno
+     This field is included in each message, and specifies the protocol
+     version number. This document specifies protocol version 5.
+msg-type
+     This field indicates the type of a protocol message. It will almost
+     always be the same as the application identifier associated with a
+     message. It is included to make the identifier more readily accessible
+     to the application. For the KDC-REQ message, this type will be
+     KRB_AS_REQ or KRB_TGS_REQ.
+padata
+     The padata (pre-authentication data) field contains a sequence of
+     authentication information which may be needed before credentials can
+     be issued or decrypted. In the case of requests for additional tickets
+     (KRB_TGS_REQ), this field will include an element with padata-type of
+     PA-TGS-REQ and data of an authentication header (ticket-granting
+     ticket and authenticator). The checksum in the authenticator (which
+     must be collision-proof) is to be computed over the KDC-REQ-BODY
+     encoding. In most requests for initial authentication (KRB_AS_REQ) and
+     most replies (KDC-REP), the padata field will be left out.
+
+     This field may also contain information needed by certain extensions
+     to the Kerberos protocol. For example, it might be used to initially
+     verify the identity of a client before any response is returned. When
+     this field is used to authenticate or pre-authenticate a request, it
+     should contain a keyed checksum over the KDC-REQ-BODY to bind the
+     pre-authentication data to rest of the request. The KDC, as a matter
+     of policy, may decide whether to honor a KDC-REQ which includes any
+     pre-authentication data that does not contain the checksum field.
+     PA-ENC-TIMESTAMP defines a pre-authentication data type that is used
+     for authenticating a client by way of an encrypted timestamp. This is
+     accomplished with a padata field with padata-type equal to
+     PA-ENC-TIMESTAMP and padata-value defined as follows (query: the
+     checksum is new in this definition. If the optional field will break
+     things we can keep the old PA-ENC-TS-ENC, and define a new alternate
+     form that includes the checksum). :
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+          padata-type     ::= PA-ENC-TIMESTAMP
+          padata-value    ::= EncryptedData -- PA-ENC-TS-ENC
+
+          PA-ENC-TS-ENC   ::= SEQUENCE {
+                          patimestamp[0]     KerberosTime, -- client's time
+                          pausec[1]          INTEGER OPTIONAL,
+                          pachecksum[2]      checksum OPTIONAL
+                                             -- keyed checksum of
+KDC-REQ-BODY
+          }
+
+     with patimestamp containing the client's time and pausec containing
+     the microseconds which may be omitted if a client will not generate
+     more than one request per second. The ciphertext (padata-value)
+     consists of the PA-ENC-TS-ENC sequence, encrypted using the client's
+     secret key.
+
+     [use-specified-kvno item is here for discussion and may be removed] It
+     may also be used by the client to specify the version of a key that is
+     being used for accompanying preauthentication, and/or which should be
+     used to encrypt the reply from the KDC.
+
+     PA-USE-SPECIFIED-KVNO  ::=  Integer
+
+     The KDC should only accept and abide by the value of the
+     use-specified-kvno preauthentication data field when the specified key
+     is still valid and until use of a new key is confirmed. This situation
+     is likely to occur primarily during the period during which an updated
+     key is propagating to other KDC's in a realm.
+
+     The padata field can also contain information needed to help the KDC
+     or the client select the key needed for generating or decrypting the
+     response. This form of the padata is useful for supporting the use of
+     certain token cards with Kerberos. The details of such extensions are
+     specified in separate documents. See [Pat92] for additional uses of
+     this field.
+padata-type
+     The padata-type element of the padata field indicates the way that the
+     padata-value element is to be interpreted. Negative values of
+     padata-type are reserved for unregistered use; non-negative values are
+     used for a registered interpretation of the element type.
+req-body
+     This field is a placeholder delimiting the extent of the remaining
+     fields. If a checksum is to be calculated over the request, it is
+     calculated over an encoding of the KDC-REQ-BODY sequence which is
+     enclosed within the req-body field.
+kdc-options
+     This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the
+     KDC and indicates the flags that the client wants set on the tickets
+     as well as other information that is to modify the behavior of the
+     KDC. Where appropriate, the name of an option may be the same as the
+     flag that is set by that option. Although in most case, the bit in the
+     options field will be the same as that in the flags field, this is not
+     guaranteed, so it is not acceptable to simply copy the options field
+     to the flags field. There are various checks that must be made before
+     honoring an option anyway.
+
+     The kdc_options field is a bit-field, where the selected options are
+     indicated by the bit being set (1), and the unselected options and
+     reserved fields being reset (0). The encoding of the bits is specified
+     in section 5.2. The options are described in more detail above in
+     section 2. The meanings of the options are:
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+        Bit(s)    Name                Description
+         0        RESERVED
+                                      Reserved for future  expansion  of
+this
+                                      field.
+
+         1        FORWARDABLE
+                                      The FORWARDABLE  option  indicates
+that
+                                      the  ticket  to be issued is to have
+its
+                                      forwardable flag set.  It  may  only
+be
+                                      set on the initial request, or in a
+sub-
+                                      sequent request if  the
+ticket-granting
+                                      ticket on which it is based is also
+for-
+                                      wardable.
+
+         2        FORWARDED
+                                      The FORWARDED option is  only
+specified
+                                      in  a  request  to  the
+ticket-granting
+                                      server and will only be honored  if
+the
+                                      ticket-granting  ticket  in  the
+request
+                                      has  its  FORWARDABLE  bit  set.
+This
+                                      option  indicates that this is a
+request
+                                      for forwarding.  The address(es) of
+the
+                                      host  from which the resulting ticket
+is
+                                      to  be  valid  are   included   in
+the
+                                      addresses field of the request.
+
+         3        PROXIABLE
+                                      The PROXIABLE option indicates that
+the
+                                      ticket to be issued is to have its
+prox-
+                                      iable flag set.  It may only be  set
+on
+                                      the  initial request, or in a
+subsequent
+                                      request if the ticket-granting ticket
+on
+                                      which it is based is also proxiable.
+
+         4        PROXY
+                                      The PROXY option indicates that this
+is
+                                      a request for a proxy.  This option
+will
+                                      only be honored if  the
+ticket-granting
+                                      ticket  in the request has its
+PROXIABLE
+                                      bit set.  The address(es)  of  the
+host
+                                      from which the resulting ticket is to
+be
+                                       valid  are  included  in  the
+addresses
+                                      field of the request.
+
+         5        ALLOW-POSTDATE
+                                      The ALLOW-POSTDATE option indicates
+that
+                                      the  ticket  to be issued is to have
+its
+                                      MAY-POSTDATE flag set.  It may  only
+be
+                                      set on the initial request, or in a
+sub-
+                                      sequent request if  the
+ticket-granting
+                                      ticket on which it is based also has
+its
+                                      MAY-POSTDATE flag set.
+
+         6        POSTDATED
+                                      The POSTDATED option indicates that
+this
+                                      is  a  request  for  a postdated
+ticket.
+                                      This option will only be honored if
+the
+                                      ticket-granting  ticket  on  which it
+is
+                                      based has  its  MAY-POSTDATE  flag
+set.
+                                      The  resulting ticket will also have
+its
+                                      INVALID flag set, and that flag  may
+be
+                                      reset by a subsequent request to the
+KDC
+                                      after the starttime in  the  ticket
+has
+                                      been reached.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+         7        UNUSED
+                                      This option is presently unused.
+
+         8        RENEWABLE
+                                      The RENEWABLE option indicates that
+the
+                                      ticket  to  be  issued  is  to  have
+its
+                                      RENEWABLE flag set.  It may only be
+set
+                                      on  the  initial  request,  or  when
+the
+                                      ticket-granting  ticket  on  which
+the
+                                      request  is based is also renewable.
+If
+                                      this option is requested, then the
+rtime
+                                      field   in   the  request  contains
+the
+                                      desired absolute expiration time for
+the
+                                      ticket.
+
+         9       RESERVED
+                                      Reserved for PK-Cross
+
+         10-13     UNUSED
+                                      These options are presently unused.
+
+         14       REQUEST-ANONYMOUS
+                                      The REQUEST-ANONYMOUS  option
+indicates
+                                      that  the  ticket to be issued is not
+to
+                                      identify  the  user  to  which  it
+was
+                                      issued.  Instead, the principal
+identif-
+                                      ier is to be generic,  as  specified
+by
+                                      the  policy  of  the realm (e.g.
+usually
+                                      anonymous@realm).  The  purpose  of
+the
+                                      ticket  is only to securely distribute
+a
+                                      session key, and  not  to  identify
+the
+                                      user.   The ANONYMOUS flag on the
+ticket
+                                      to be returned should be  set.   If
+the
+                                      local  realms  policy  does  not
+permit
+                                      anonymous credentials, the request is
+to
+                                      be rejected.
+
+         15      CANONICALIZE
+                                      The CANONICALIZE option indicates that
+                                      the client will accept the return of a
+                                      true server name instead of the name
+                                      specified in the request. In addition
+                                      the client will be able to process
+                                      any TGT referrals that will direct
+                                      the client to another realm to locate
+                                      the requested server. If a KDC does
+                                      not support name- canonicalization,
+                                      the option is ignored and the
+                                      appropriate
+                                      KDC_ERR_C_PRINCIPAL_UNKNOWN or
+                                      KDC_ERR_S_PRINCIPAL_UNKNOWN error is
+                                      returned. [JBrezak]
+
+         16-25    RESERVED
+                                      Reserved for future use.
+
+         26       DISABLE-TRANSITED-CHECK
+                                      By default the KDC will check the
+                                      transited field of a ticket-granting-
+                                      ticket against the policy of the local
+                                      realm before it will issue derivative
+                                      tickets based on the ticket granting
+                                      ticket.  If this flag is set in the
+                                      request, checking of the transited
+field
+                                      is disabled.  Tickets issued without
+the
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                                      performance of this check will be
+noted
+                                      by the reset (0) value of the
+                                      TRANSITED-POLICY-CHECKED flag,
+                                      indicating to the application server
+                                      that the tranisted field must be
+checked
+                                      locally.  KDC's are encouraged but not
+                                      required to honor the
+                                      DISABLE-TRANSITED-CHECK option.
+
+         27       RENEWABLE-OK
+                                      The RENEWABLE-OK option indicates that
+a
+                                      renewable ticket will be acceptable if
+a
+                                      ticket with the  requested  life
+cannot
+                                      otherwise be provided.  If a ticket
+with
+                                      the requested life cannot  be
+provided,
+                                      then  a  renewable  ticket may be
+issued
+                                      with  a  renew-till  equal  to  the
+the
+                                      requested  endtime.   The  value  of
+the
+                                      renew-till field may still be limited
+by
+                                      local  limits, or limits selected by
+the
+                                      individual principal or server.
+
+         28       ENC-TKT-IN-SKEY
+                                      This option is used only by the
+ticket-
+                                      granting  service.   The
+ENC-TKT-IN-SKEY
+                                      option indicates that the ticket for
+the
+                                      end  server  is  to  be encrypted in
+the
+                                      session key from the additional
+ticket-
+                                      granting ticket provided.
+
+         29       RESERVED
+                                      Reserved for future use.
+
+         30       RENEW
+                                      This option is used only by the
+ticket-
+                                      granting   service.   The  RENEW
+option
+                                      indicates that the  present  request
+is
+                                      for  a  renewal.  The ticket provided
+is
+                                      encrypted in  the  secret  key  for
+the
+                                      server  on  which  it  is  valid.
+This
+                                      option  will  only  be  honored  if
+the
+                                      ticket  to  be renewed has its
+RENEWABLE
+                                      flag set and if the time in  its
+renew-
+                                      till  field  has not passed.  The
+ticket
+                                      to be renewed is passed  in  the
+padata
+                                      field  as  part  of  the
+authentication
+                                      header.
+
+         31       VALIDATE
+                                      This option is used only by the
+ticket-
+                                      granting  service.   The VALIDATE
+option
+                                      indicates that the request is  to
+vali-
+                                      date  a  postdated ticket.  It will
+only
+                                      be honored if the  ticket  presented
+is
+                                      postdated,  presently  has  its
+INVALID
+                                      flag set, and would be otherwise
+usable
+                                      at  this time.  A ticket cannot be
+vali-
+                                      dated before its starttime.  The
+ticket
+                                      presented for validation is encrypted
+in
+                                      the key of the server for  which  it
+is
+                                      valid  and is passed in the padata
+field
+                                      as part of the authentication header.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+cname and sname
+     These fields are the same as those described for the ticket in section
+     5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is
+     specified. If absent, the name of the server is taken from the name of
+     the client in the ticket passed as additional-tickets.
+enc-authorization-data
+     The enc-authorization-data, if present (and it can only be present in
+     the TGS_REQ form), is an encoding of the desired authorization-data
+     encrypted under the sub-session key if present in the Authenticator,
+     or alternatively from the session key in the ticket-granting ticket,
+     both from the padata field in the KRB_AP_REQ.
+realm
+     This field specifies the realm part of the server's principal
+     identifier. In the AS exchange, this is also the realm part of the
+     client's principal identifier. If the CANONICALIZE option is set, the
+     realm is used as a hint to the KDC for its database lookup.
+from
+     This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
+     requests when the requested ticket is to be postdated. It specifies
+     the desired start time for the requested ticket. If this field is
+     omitted then the KDC should use the current time instead.
+till
+     This field contains the expiration date requested by the client in a
+     ticket request. It is optional and if omitted the requested ticket is
+     to have the maximum endtime permitted according to KDC policy for the
+     parties to the authentication exchange as limited by expiration date
+     of the ticket granting ticket or other preauthentication credentials.
+rtime
+     This field is the requested renew-till time sent from a client to the
+     KDC in a ticket request. It is optional.
+nonce
+     This field is part of the KDC request and response. It it intended to
+     hold a random number generated by the client. If the same number is
+     included in the encrypted response from the KDC, it provides evidence
+     that the response is fresh and has not been replayed by an attacker.
+     Nonces must never be re-used. Ideally, it should be generated
+     randomly, but if the correct time is known, it may suffice[25].
+etype
+     This field specifies the desired encryption algorithm to be used in
+     the response.
+addresses
+     This field is included in the initial request for tickets, and
+     optionally included in requests for additional tickets from the
+     ticket-granting server. It specifies the addresses from which the
+     requested ticket is to be valid. Normally it includes the addresses
+     for the client's host. If a proxy is requested, this field will
+     contain other addresses. The contents of this field are usually copied
+     by the KDC into the caddr field of the resulting ticket.
+additional-tickets
+     Additional tickets may be optionally included in a request to the
+     ticket-granting server. If the ENC-TKT-IN-SKEY option has been
+     specified, then the session key from the additional ticket will be
+     used in place of the server's key to encrypt the new ticket. When he
+     ENC-TKT-IN-SKEY option is used for user-to-user authentication, this
+     addional ticket may be a TGT issued by the local realm or an
+     inter-realm TGT issued for the current KDC's realm by a remote KDC. If
+     more than one option which requires additional tickets has been
+     specified, then the additional tickets are used in the order specified
+     by the ordering of the options bits (see kdc-options, above).
+
+The application code will be either ten (10) or twelve (12) depending on
+whether the request is for an initial ticket (AS-REQ) or for an additional
+ticket (TGS-REQ).
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+The optional fields (addresses, authorization-data and additional-tickets)
+are only included if necessary to perform the operation specified in the
+kdc-options field.
+
+It should be noted that in KRB_TGS_REQ, the protocol version number appears
+twice and two different message types appear: the KRB_TGS_REQ message
+contains these fields as does the authentication header (KRB_AP_REQ) that
+is passed in the padata field.
+
+5.4.2. KRB_KDC_REP definition
+
+The KRB_KDC_REP message format is used for the reply from the KDC for
+either an initial (AS) request or a subsequent (TGS) request. There is no
+message type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP
+or KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply
+depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in
+the client's secret key, and the client's key version number is included in
+the key version number for the encrypted data. For KRB_TGS_REP, the
+ciphertext is encrypted in the sub-session key from the Authenticator, or
+if absent, the session key from the ticket-granting ticket used in the
+request. In that case, no version number will be present in the
+EncryptedData sequence.
+
+The KRB_KDC_REP message contains the following fields:
+
+AS-REP ::=    [APPLICATION 11] KDC-REP
+TGS-REP ::=   [APPLICATION 13] KDC-REP
+
+KDC-REP ::=   SEQUENCE {
+              pvno[0]                    INTEGER,
+              msg-type[1]                INTEGER,
+              padata[2]                  SEQUENCE OF PA-DATA OPTIONAL,
+              crealm[3]                  Realm,
+              cname[4]                   PrincipalName,
+              ticket[5]                  Ticket,
+              enc-part[6]                EncryptedData
+}
+
+EncASRepPart ::=    [APPLICATION 25[27]] EncKDCRepPart
+EncTGSRepPart ::=   [APPLICATION 26] EncKDCRepPart
+
+EncKDCRepPart ::=   SEQUENCE {
+                    key[0]               EncryptionKey,
+                    last-req[1]          LastReq,
+                    nonce[2]             INTEGER,
+                    key-expiration[3]    KerberosTime OPTIONAL,
+                    flags[4]             TicketFlags,
+                    authtime[5]          KerberosTime,
+                    starttime[6]         KerberosTime OPTIONAL,
+                    endtime[7]           KerberosTime,
+                    renew-till[8]        KerberosTime OPTIONAL,
+                    srealm[9]            Realm,
+                    sname[10]            PrincipalName,
+                    caddr[11]            HostAddresses OPTIONAL
+}
+
+pvno and msg-type
+     These fields are described above in section 5.4.1. msg-type is either
+     KRB_AS_REP or KRB_TGS_REP.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+padata
+     This field is described in detail in section 5.4.1. One possible use
+     for this field is to encode an alternate "mix-in" string to be used
+     with a string-to-key algorithm (such as is described in section
+     6.3.2). This ability is useful to ease transitions if a realm name
+     needs to change (e.g. when a company is acquired); in such a case all
+     existing password-derived entries in the KDC database would be flagged
+     as needing a special mix-in string until the next password change.
+crealm, cname, srealm and sname
+     These fields are the same as those described for the ticket in section
+     5.3.1.
+ticket
+     The newly-issued ticket, from section 5.3.1.
+enc-part
+     This field is a place holder for the ciphertext and related
+     information that forms the encrypted part of a message. The
+     description of the encrypted part of the message follows each
+     appearance of this field. The encrypted part is encoded as described
+     in section 6.1.
+key
+     This field is the same as described for the ticket in section 5.3.1.
+last-req
+     This field is returned by the KDC and specifies the time(s) of the
+     last request by a principal. Depending on what information is
+     available, this might be the last time that a request for a
+     ticket-granting ticket was made, or the last time that a request based
+     on a ticket-granting ticket was successful. It also might cover all
+     servers for a realm, or just the particular server. Some
+     implementations may display this information to the user to aid in
+     discovering unauthorized use of one's identity. It is similar in
+     spirit to the last login time displayed when logging into timesharing
+     systems.
+nonce
+     This field is described above in section 5.4.1.
+key-expiration
+     The key-expiration field is part of the response from the KDC and
+     specifies the time that the client's secret key is due to expire. The
+     expiration might be the result of password aging or an account
+     expiration. This field will usually be left out of the TGS reply since
+     the response to the TGS request is encrypted in a session key and no
+     client information need be retrieved from the KDC database. It is up
+     to the application client (usually the login program) to take
+     appropriate action (such as notifying the user) if the expiration time
+     is imminent.
+flags, authtime, starttime, endtime, renew-till and caddr
+     These fields are duplicates of those found in the encrypted portion of
+     the attached ticket (see section 5.3.1), provided so the client may
+     verify they match the intended request and to assist in proper ticket
+     caching. If the message is of type KRB_TGS_REP, the caddr field will
+     only be filled in if the request was for a proxy or forwarded ticket,
+     or if the user is substituting a subset of the addresses from the
+     ticket granting ticket. If the client-requested addresses are not
+     present or not used, then the addresses contained in the ticket will
+     be the same as those included in the ticket-granting ticket.
+
+5.5. Client/Server (CS) message specifications
+
+This section specifies the format of the messages used for the
+authentication of the client to the application server.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+5.5.1. KRB_AP_REQ definition
+
+The KRB_AP_REQ message contains the Kerberos protocol version number, the
+message type KRB_AP_REQ, an options field to indicate any options in use,
+and the ticket and authenticator themselves. The KRB_AP_REQ message is
+often referred to as the 'authentication header'.
+
+AP-REQ ::=      [APPLICATION 14] SEQUENCE {
+                pvno[0]                       INTEGER,
+                msg-type[1]                   INTEGER,
+                ap-options[2]                 APOptions,
+                ticket[3]                     Ticket,
+                authenticator[4]              EncryptedData
+}
+
+APOptions ::=   BIT STRING {
+                reserved(0),
+                use-session-key(1),
+                mutual-required(2)
+}
+
+
+
+pvno and msg-type
+     These fields are described above in section 5.4.1. msg-type is
+     KRB_AP_REQ.
+ap-options
+     This field appears in the application request (KRB_AP_REQ) and affects
+     the way the request is processed. It is a bit-field, where the
+     selected options are indicated by the bit being set (1), and the
+     unselected options and reserved fields being reset (0). The encoding
+     of the bits is specified in section 5.2. The meanings of the options
+     are:
+
+	  Bit(s)   Name              Description
+
+	  0        RESERVED
+				     Reserved for future  expansion  of  this
+				     field.
+
+	  1        USE-SESSION-KEY
+				     The  USE-SESSION-KEY  option   indicates
+				     that the ticket the client is presenting
+				     to a server is encrypted in the  session
+				     key  from  the  server's ticket-granting
+				     ticket.  When this option is not  speci-
+				     fied,  the  ticket  is  encrypted in the
+				     server's secret key.
+
+	  2        MUTUAL-REQUIRED
+				     The  MUTUAL-REQUIRED  option  tells  the
+				     server  that  the client requires mutual
+				     authentication, and that it must respond
+				     with a KRB_AP_REP message.
+
+	  3-31     RESERVED
+				     Reserved for future use.
+
+ticket
+     This field is a ticket authenticating the client to the server.
+authenticator
+     This contains the authenticator, which includes the client's choice of
+     a subkey. Its encoding is described in section 5.3.2.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+5.5.2. KRB_AP_REP definition
+
+The KRB_AP_REP message contains the Kerberos protocol version number, the
+message type, and an encrypted time- stamp. The message is sent in in
+response to an application request (KRB_AP_REQ) where the mutual
+authentication option has been selected in the ap-options field.
+
+AP-REP ::=         [APPLICATION 15] SEQUENCE {
+                   pvno[0]                           INTEGER,
+                   msg-type[1]                       INTEGER,
+                   enc-part[2]                       EncryptedData
+}
+
+EncAPRepPart ::=   [APPLICATION 27[29]] SEQUENCE {
+                   ctime[0]                          KerberosTime,
+                   cusec[1]                          INTEGER,
+                   subkey[2]                         EncryptionKey OPTIONAL,
+                   seq-number[3]                     INTEGER OPTIONAL
+}
+
+The encoded EncAPRepPart is encrypted in the shared session key of the
+ticket. The optional subkey field can be used in an application-arranged
+negotiation to choose a per association session key.
+
+pvno and msg-type
+     These fields are described above in section 5.4.1. msg-type is
+     KRB_AP_REP.
+enc-part
+     This field is described above in section 5.4.2.
+ctime
+     This field contains the current time on the client's host.
+cusec
+     This field contains the microsecond part of the client's timestamp.
+subkey
+     This field contains an encryption key which is to be used to protect
+     this specific application session. See section 3.2.6 for specifics on
+     how this field is used to negotiate a key. Unless an application
+     specifies otherwise, if this field is left out, the sub-session key
+     from the authenticator, or if also left out, the session key from the
+     ticket will be used.
+
+5.5.3. Error message reply
+
+If an error occurs while processing the application request, the KRB_ERROR
+message will be sent in response. See section 5.9.1 for the format of the
+error message. The cname and crealm fields may be left out if the server
+cannot determine their appropriate values from the corresponding KRB_AP_REQ
+message. If the authenticator was decipherable, the ctime and cusec fields
+will contain the values from it.
+
+5.6. KRB_SAFE message specification
+
+This section specifies the format of a message that can be used by either
+side (client or server) of an application to send a tamper-proof message to
+its peer. It presumes that a session key has previously been exchanged (for
+example, by using the KRB_AP_REQ/KRB_AP_REP messages).
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+5.6.1. KRB_SAFE definition
+
+The KRB_SAFE message contains user data along with a collision-proof
+checksum keyed with the last encryption key negotiated via subkeys, or the
+session key if no negotiation has occured. The message fields are:
+
+KRB-SAFE ::=        [APPLICATION 20] SEQUENCE {
+                    pvno[0]                       INTEGER,
+                    msg-type[1]                   INTEGER,
+                    safe-body[2]                  KRB-SAFE-BODY,
+                    cksum[3]                      Checksum
+}
+
+KRB-SAFE-BODY ::=   SEQUENCE {
+                    user-data[0]                  OCTET STRING,
+                    timestamp[1]                  KerberosTime OPTIONAL,
+                    usec[2]                       INTEGER OPTIONAL,
+                    seq-number[3]                 INTEGER OPTIONAL,
+                    s-address[4]                  HostAddress OPTIONAL,
+                    r-address[5]                  HostAddress OPTIONAL
+}
+
+pvno and msg-type
+     These fields are described above in section 5.4.1. msg-type is
+     KRB_SAFE.
+safe-body
+     This field is a placeholder for the body of the KRB-SAFE message.
+cksum
+     This field contains the checksum of the application data. Checksum
+     details are described in section 6.4. The checksum is computed over
+     the encoding of the KRB-SAFE sequence. First, the cksum is zeroed and
+     the checksum is computed over the encoding of the KRB-SAFE sequence,
+     then the checksum is set to the result of that computation, and
+     finally the KRB-SAFE sequence is encoded again.
+user-data
+     This field is part of the KRB_SAFE and KRB_PRIV messages and contain
+     the application specific data that is being passed from the sender to
+     the recipient.
+timestamp
+     This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents
+     are the current time as known by the sender of the message. By
+     checking the timestamp, the recipient of the message is able to make
+     sure that it was recently generated, and is not a replay.
+usec
+     This field is part of the KRB_SAFE and KRB_PRIV headers. It contains
+     the microsecond part of the timestamp.
+seq-number
+     This field is described above in section 5.3.2.
+s-address
+     This field specifies the address in use by the sender of the message.
+     It may be omitted if not required by the application protocol. The
+     application designer considering omission of this field is warned,
+     that the inclusion of this address prevents some kinds of replay
+     attacks (e.g., reflection attacks) and that it is only acceptable to
+     omit this address if there is sufficient information in the integrity
+     protected part of the application message for the recipient to
+     unambiguously determine if it was the intended recipient.
+r-address
+     This field specifies the address in use by the recipient of the
+     message. It may be omitted for some uses (such as broadcast
+     protocols), but the recipient may arbitrarily reject such messages.
+     This field along with s-address can be used to help detect messages
+     which have been incorrectly or maliciously delivered to the wrong
+     recipient.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+5.7. KRB_PRIV message specification
+
+This section specifies the format of a message that can be used by either
+side (client or server) of an application to securely and privately send a
+message to its peer. It presumes that a session key has previously been
+exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages).
+
+5.7.1. KRB_PRIV definition
+
+The KRB_PRIV message contains user data encrypted in the Session Key. The
+message fields are:
+
+KRB-PRIV ::=         [APPLICATION 21] SEQUENCE {
+                     pvno[0]                           INTEGER,
+                     msg-type[1]                       INTEGER,
+                     enc-part[3]                       EncryptedData
+}
+
+EncKrbPrivPart ::=   [APPLICATION 28[31]] SEQUENCE {
+                     user-data[0]        OCTET STRING,
+                     timestamp[1]        KerberosTime OPTIONAL,
+                     usec[2]             INTEGER OPTIONAL,
+                     seq-number[3]       INTEGER OPTIONAL,
+                     s-address[4]        HostAddress OPTIONAL, -- sender's
+addr
+                     r-address[5]        HostAddress OPTIONAL -- recip's
+addr
+}
+
+pvno and msg-type
+     These fields are described above in section 5.4.1. msg-type is
+     KRB_PRIV.
+enc-part
+     This field holds an encoding of the EncKrbPrivPart sequence encrypted
+     under the session key[32]. This encrypted encoding is used for the
+     enc-part field of the KRB-PRIV message. See section 6 for the format
+     of the ciphertext.
+user-data, timestamp, usec, s-address and r-address
+     These fields are described above in section 5.6.1.
+seq-number
+     This field is described above in section 5.3.2.
+
+5.8. KRB_CRED message specification
+
+This section specifies the format of a message that can be used to send
+Kerberos credentials from one principal to another. It is presented here to
+encourage a common mechanism to be used by applications when forwarding
+tickets or providing proxies to subordinate servers. It presumes that a
+session key has already been exchanged perhaps by using the
+KRB_AP_REQ/KRB_AP_REP messages.
+
+5.8.1. KRB_CRED definition
+
+The KRB_CRED message contains a sequence of tickets to be sent and
+information needed to use the tickets, including the session key from each.
+The information needed to use the tickets is encrypted under an encryption
+key previously exchanged or transferred alongside the KRB_CRED message. The
+message fields are:
+
+KRB-CRED         ::= [APPLICATION 22]   SEQUENCE {
+                 pvno[0]                INTEGER,
+                 msg-type[1]            INTEGER, -- KRB_CRED
+                 tickets[2]             SEQUENCE OF Ticket,
+                 enc-part[3]            EncryptedData
+}
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+EncKrbCredPart   ::= [APPLICATION 29]   SEQUENCE {
+                 ticket-info[0]         SEQUENCE OF KrbCredInfo,
+                 nonce[1]               INTEGER OPTIONAL,
+                 timestamp[2]           KerberosTime OPTIONAL,
+                 usec[3]                INTEGER OPTIONAL,
+                 s-address[4]           HostAddress OPTIONAL,
+                 r-address[5]           HostAddress OPTIONAL
+}
+
+KrbCredInfo      ::=                    SEQUENCE {
+                 key[0]                 EncryptionKey,
+                 prealm[1]              Realm OPTIONAL,
+                 pname[2]               PrincipalName OPTIONAL,
+                 flags[3]               TicketFlags OPTIONAL,
+                 authtime[4]            KerberosTime OPTIONAL,
+                 starttime[5]           KerberosTime OPTIONAL,
+                 endtime[6]             KerberosTime OPTIONAL
+                 renew-till[7]          KerberosTime OPTIONAL,
+                 srealm[8]              Realm OPTIONAL,
+                 sname[9]               PrincipalName OPTIONAL,
+                 caddr[10]              HostAddresses OPTIONAL
+}
+
+pvno and msg-type
+     These fields are described above in section 5.4.1. msg-type is
+     KRB_CRED.
+tickets
+     These are the tickets obtained from the KDC specifically for use by
+     the intended recipient. Successive tickets are paired with the
+     corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED
+     message.
+enc-part
+     This field holds an encoding of the EncKrbCredPart sequence encrypted
+     under the session key shared between the sender and the intended
+     recipient. This encrypted encoding is used for the enc-part field of
+     the KRB-CRED message. See section 6 for the format of the ciphertext.
+nonce
+     If practical, an application may require the inclusion of a nonce
+     generated by the recipient of the message. If the same value is
+     included as the nonce in the message, it provides evidence that the
+     message is fresh and has not been replayed by an attacker. A nonce
+     must never be re-used; it should be generated randomly by the
+     recipient of the message and provided to the sender of the message in
+     an application specific manner.
+timestamp and usec
+     These fields specify the time that the KRB-CRED message was generated.
+     The time is used to provide assurance that the message is fresh.
+s-address and r-address
+     These fields are described above in section 5.6.1. They are used
+     optionally to provide additional assurance of the integrity of the
+     KRB-CRED message.
+key
+     This field exists in the corresponding ticket passed by the KRB-CRED
+     message and is used to pass the session key from the sender to the
+     intended recipient. The field's encoding is described in section 6.2.
+
+The following fields are optional. If present, they can be associated with
+the credentials in the remote ticket file. If left out, then it is assumed
+that the recipient of the credentials already knows their value.
+
+prealm and pname
+     The name and realm of the delegated principal identity.
+flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr
+     These fields contain the values of the correspond- ing fields from the
+     ticket found in the ticket field. Descriptions of the fields are
+     identical to the descriptions in the KDC-REP message.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+5.9. Error message specification
+
+This section specifies the format for the KRB_ERROR message. The fields
+included in the message are intended to return as much information as
+possible about an error. It is not expected that all the information
+required by the fields will be available for all types of errors. If the
+appropriate information is not available when the message is composed, the
+corresponding field will be left out of the message.
+
+Note that since the KRB_ERROR message is only optionally integrity
+protected, it is quite possible for an intruder to synthesize or modify
+such a message. In particular, this means that unless appropriate integrity
+protection mechanisms have been applied to the KRB_ERROR message, the
+client should not use any fields in this message for security-critical
+purposes, such as setting a system clock or generating a fresh
+authenticator. The message can be useful, however, for advising a user on
+the reason for some failure.
+
+5.9.1. KRB_ERROR definition
+
+The KRB_ERROR message consists of the following fields:
+
+KRB-ERROR ::=   [APPLICATION 30] SEQUENCE {
+                pvno[0]                       INTEGER,
+                msg-type[1]                   INTEGER,
+                ctime[2]                      KerberosTime OPTIONAL,
+                cusec[3]                      INTEGER OPTIONAL,
+                stime[4]                      KerberosTime,
+                susec[5]                      INTEGER,
+                error-code[6]                 INTEGER,
+                crealm[7]                     Realm OPTIONAL,
+                cname[8]                      PrincipalName OPTIONAL,
+                realm[9]                      Realm, -- Correct realm
+                sname[10]                     PrincipalName, -- Correct name
+                e-text[11]                    GeneralString OPTIONAL,
+                e-data[12]                    OCTET STRING OPTIONAL,
+                e-cksum[13]                   Checksum OPTIONAL,
+}
+
+
+
+pvno and msg-type
+     These fields are described above in section 5.4.1. msg-type is
+     KRB_ERROR.
+ctime
+     This field is described above in section 5.4.1.
+cusec
+     This field is described above in section 5.5.2.
+stime
+     This field contains the current time on the server. It is of type
+     KerberosTime.
+susec
+     This field contains the microsecond part of the server's timestamp.
+     Its value ranges from 0 to 999999. It appears along with stime. The
+     two fields are used in conjunction to specify a reasonably accurate
+     timestamp.
+error-code
+     This field contains the error code returned by Kerberos or the server
+     when a request fails. To interpret the value of this field see the
+     list of error codes in section 8. Implementations are encouraged to
+     provide for national language support in the display of error
+     messages.
+crealm, cname, srealm and sname
+     These fields are described above in section 5.3.1.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+e-text
+     This field contains additional text to help explain the error code
+     associated with the failed request (for example, it might include a
+     principal name which was unknown).
+e-data
+     This field contains additional data about the error for use by the
+     application to help it recover from or handle the error. If present,
+     this field will contain the encoding of a sequence of TypedData
+     (TYPED-DATA below), unless the errorcode is KDC_ERR_PREAUTH_REQUIRED,
+     in which case it will contain the encoding of a sequence of of padata
+     fields (METHOD-DATA below), each corresponding to an acceptable
+     pre-authentication method and optionally containing data for the
+     method:
+
+     TYPED-DATA   ::=   SEQUENCE of TypeData
+     METHOD-DATA  ::=   SEQUENCE of PA-DATA
+
+     TypedData ::=   SEQUENCE {
+                         data-type[0]   INTEGER,
+                         data-value[1]  OCTET STRING OPTIONAL
+     }
+
+     Note that e-data-types have been reserved for all PA data types
+     defined prior to July 1999. For the KDC_ERR_PREAUTH_REQUIRED message,
+     when using new PA data types defined in July 1999 or later, the
+     METHOD-DATA sequence must itself be encapsulated in an TypedData
+     element of type TD-PADATA. All new implementations interpreting the
+     METHOD-DATA field for the KDC_ERR_PREAUTH_REQUIRED message must accept
+     a type of TD-PADATA, extract the typed data field and interpret the
+     use any elements encapsulated in the TD-PADATA elements as if they
+     were present in the METHOD-DATA sequence.
+e-cksum
+     This field contains an optional checksum for the KRB-ERROR message.
+     The checksum is calculated over the Kerberos ASN.1 encoding of the
+     KRB-ERROR message with the checksum absent. The checksum is then added
+     to the KRB-ERROR structure and the message is re-encoded. The Checksum
+     should be calculated using the session key from the ticket granting
+     ticket or service ticket, where available. If the error is in response
+     to a TGS or AP request, the checksum should be calculated uing the the
+     session key from the client's ticket. If the error is in response to
+     an AS request, then the checksum should be calulated using the
+     client's secret key ONLY if there has been suitable preauthentication
+     to prove knowledge of the secret key by the client[33]. If a checksum
+     can not be computed because the key to be used is not available, no
+     checksum will be included.
+
+     6. Encryption and Checksum Specifications
+
+     The Kerberos protocols described in this document are designed to use
+     stream encryption ciphers, which can be simulated using commonly
+     available block encryption ciphers, such as the Data Encryption
+     Standard [DES77], and triple DES variants, in conjunction with block
+     chaining and checksum methods [DESM80]. Encryption is used to prove
+     the identities of the network entities participating in message
+     exchanges. The Key Distribution Center for each realm is trusted by
+     all principals registered in that realm to store a secret key in
+     confidence. Proof of knowledge of this secret key is used to verify
+     the authenticity of a principal.
+
+     The KDC uses the principal's secret key (in the AS exchange) or a
+     shared session key (in the TGS exchange) to encrypt responses to
+     ticket requests; the ability to obtain the secret key or session key
+     implies the knowledge of the appropriate keys and the identity of the
+     KDC. The ability of a principal to decrypt the KDC response and
+     present a Ticket and a properly formed Authenticator (generated with
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     the session key from the KDC response) to a service verifies the
+     identity of the principal; likewise the ability of the service to
+     extract the session key from the Ticket and prove its knowledge
+     thereof in a response verifies the identity of the service.
+
+     The Kerberos protocols generally assume that the encryption used is
+     secure from cryptanalysis; however, in some cases, the order of fields
+     in the encrypted portions of messages are arranged to minimize the
+     effects of poorly chosen keys. It is still important to choose good
+     keys. If keys are derived from user-typed passwords, those passwords
+     need to be well chosen to make brute force attacks more difficult.
+     Poorly chosen keys still make easy targets for intruders.
+
+     The following sections specify the encryption and checksum mechanisms
+     currently defined for Kerberos. The encodings, chaining, and padding
+     requirements for each are described. For encryption methods, it is
+     often desirable to place random information (often referred to as a
+     confounder) at the start of the message. The requirements for a
+     confounder are specified with each encryption mechanism.
+
+     Some encryption systems use a block-chaining method to improve the the
+     security characteristics of the ciphertext. However, these chaining
+     methods often don't provide an integrity check upon decryption. Such
+     systems (such as DES in CBC mode) must be augmented with a checksum of
+     the plain-text which can be verified at decryption and used to detect
+     any tampering or damage. Such checksums should be good at detecting
+     burst errors in the input. If any damage is detected, the decryption
+     routine is expected to return an error indicating the failure of an
+     integrity check. Each encryption type is expected to provide and
+     verify an appropriate checksum. The specification of each encryption
+     method sets out its checksum requirements.
+
+     Finally, where a key is to be derived from a user's password, an
+     algorithm for converting the password to a key of the appropriate type
+     is included. It is desirable for the string to key function to be
+     one-way, and for the mapping to be different in different realms. This
+     is important because users who are registered in more than one realm
+     will often use the same password in each, and it is desirable that an
+     attacker compromising the Kerberos server in one realm not obtain or
+     derive the user's key in another.
+
+     For an discussion of the integrity characteristics of the candidate
+     encryption and checksum methods considered for Kerberos, the reader is
+     referred to [SG92].
+
+     6.1. Encryption Specifications
+
+     The following ASN.1 definition describes all encrypted messages. The
+     enc-part field which appears in the unencrypted part of messages in
+     section 5 is a sequence consisting of an encryption type, an optional
+     key version number, and the ciphertext.
+
+     EncryptedData ::=   SEQUENCE {
+                         etype[0]     INTEGER, -- EncryptionType
+                         kvno[1]      INTEGER OPTIONAL,
+                         cipher[2]    OCTET STRING -- ciphertext
+     }
+
+
+
+     etype
+          This field identifies which encryption algorithm was used to
+          encipher the cipher. Detailed specifications for selected
+          encryption types appear later in this section.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     kvno
+          This field contains the version number of the key under which
+          data is encrypted. It is only present in messages encrypted under
+          long lasting keys, such as principals' secret keys.
+     cipher
+          This field contains the enciphered text, encoded as an OCTET
+          STRING.
+     The cipher field is generated by applying the specified encryption
+     algorithm to data composed of the message and algorithm-specific
+     inputs. Encryption mechanisms defined for use with Kerberos must take
+     sufficient measures to guarantee the integrity of the plaintext, and
+     we recommend they also take measures to protect against precomputed
+     dictionary attacks. If the encryption algorithm is not itself capable
+     of doing so, the protections can often be enhanced by adding a
+     checksum and a confounder.
+
+     The suggested format for the data to be encrypted includes a
+     confounder, a checksum, the encoded plaintext, and any necessary
+     padding. The msg-seq field contains the part of the protocol message
+     described in section 5 which is to be encrypted. The confounder,
+     checksum, and padding are all untagged and untyped, and their length
+     is exactly sufficient to hold the appropriate item. The type and
+     length is implicit and specified by the particular encryption type
+     being used (etype). The format for the data to be encrypted for some
+     methods is described in the following diagram, but other methods may
+     deviate from this layour - so long as the definition of the method
+     defines the layout actually in use.
+
+           +-----------+----------+-------------+-----+
+           |confounder |   check  |   msg-seq   | pad |
+           +-----------+----------+-------------+-----+
+
+     The format cannot be described in ASN.1, but for those who prefer an
+     ASN.1-like notation:
+
+     CipherText ::=   ENCRYPTED       SEQUENCE {
+             confounder[0]   UNTAGGED[35] OCTET STRING(conf_length)
+OPTIONAL,
+             check[1]        UNTAGGED OCTET STRING(checksum_length)
+OPTIONAL,
+             msg-seq[2]      MsgSequence,
+             pad             UNTAGGED OCTET STRING(pad_length) OPTIONAL
+     }
+
+     One generates a random confounder of the appropriate length, placing
+     it in confounder; zeroes out check; calculates the appropriate
+     checksum over confounder, check, and msg-seq, placing the result in
+     check; adds the necessary padding; then encrypts using the specified
+     encryption type and the appropriate key.
+
+     Unless otherwise specified, a definition of an encryption algorithm
+     that specifies a checksum, a length for the confounder field, or an
+     octet boundary for padding uses this ciphertext format[36]. Those
+     fields which are not specified will be omitted.
+
+     In the interest of allowing all implementations using a particular
+     encryption type to communicate with all others using that type, the
+     specification of an encryption type defines any checksum that is
+     needed as part of the encryption process. If an alternative checksum
+     is to be used, a new encryption type must be defined.
+
+     Some cryptosystems require additional information beyond the key and
+     the data to be encrypted. For example, DES, when used in
+     cipher-block-chaining mode, requires an initialization vector. If
+     required, the description for each encryption type must specify the
+     source of such additional information. 6.2. Encryption Keys
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     The sequence below shows the encoding of an encryption key:
+
+            EncryptionKey ::=   SEQUENCE {
+                                keytype[0]    INTEGER,
+                                keyvalue[1]   OCTET STRING
+            }
+
+     keytype
+          This field specifies the type of encryption that is to be
+          performed using the key that follows in the keyvalue field. It
+          will always correspond to the etype to be used to generate or
+          decode the EncryptedData. In cases when multiple algorithms use a
+          common kind of key (e.g., if the encryption algorithm uses an
+          alternate checksum algorithm for an integrity check, or a
+          different chaining mechanism), the keytype provides information
+          needed to determine which algorithm is to be used.
+     keyvalue
+          This field contains the key itself, encoded as an octet string.
+     All negative values for the encryption key type are reserved for local
+     use. All non-negative values are reserved for officially assigned type
+     fields and interpreta- tions.
+
+     6.3. Encryption Systems
+
+     6.3.1. The NULL Encryption System (null)
+
+     If no encryption is in use, the encryption system is said to be the
+     NULL encryption system. In the NULL encryption system there is no
+     checksum, confounder or padding. The ciphertext is simply the
+     plaintext. The NULL Key is used by the null encryption system and is
+     zero octets in length, with keytype zero (0).
+
+     6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)
+
+     The des-cbc-crc encryption mode encrypts information under the Data
+     Encryption Standard [DES77] using the cipher block chaining mode
+     [DESM80]. A CRC-32 checksum (described in ISO 3309 [ISO3309]) is
+     applied to the confounder and message sequence (msg-seq) and placed in
+     the cksum field. DES blocks are 8 bytes. As a result, the data to be
+     encrypted (the concatenation of confounder, checksum, and message)
+     must be padded to an 8 byte boundary before encryption. The details of
+     the encryption of this data are identical to those for the des-cbc-md5
+     encryption mode.
+
+     Note that, since the CRC-32 checksum is not collision-proof, an
+     attacker could use a probabilistic chosen-plaintext attack to generate
+     a valid message even if a confounder is used [SG92]. The use of
+     collision-proof checksums is recommended for environments where such
+     attacks represent a significant threat. The use of the CRC-32 as the
+     checksum for ticket or authenticator is no longer mandated as an
+     interoperability requirement for Kerberos Version 5 Specification 1
+     (See section 9.1 for specific details).
+
+     6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
+
+     The des-cbc-md4 encryption mode encrypts information under the Data
+     Encryption Standard [DES77] using the cipher block chaining mode
+     [DESM80]. An MD4 checksum (described in [MD492]) is applied to the
+     confounder and message sequence (msg-seq) and placed in the cksum
+     field. DES blocks are 8 bytes. As a result, the data to be encrypted
+     (the concatenation of confounder, checksum, and message) must be
+     padded to an 8 byte boundary before encryption. The details of the
+     encryption of this data are identical to those for the des-cbc-md5
+     encryption mode.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
+
+     The des-cbc-md5 encryption mode encrypts information under the Data
+     Encryption Standard [DES77] using the cipher block chaining mode
+     [DESM80]. An MD5 checksum (described in [MD5-92].) is applied to the
+     confounder and message sequence (msg-seq) and placed in the cksum
+     field. DES blocks are 8 bytes. As a result, the data to be encrypted
+     (the concatenation of confounder, checksum, and message) must be
+     padded to an 8 byte boundary before encryption.
+
+     Plaintext and DES ciphtertext are encoded as blocks of 8 octets which
+     are concatenated to make the 64-bit inputs for the DES algorithms. The
+     first octet supplies the 8 most significant bits (with the octet's
+     MSbit used as the DES input block's MSbit, etc.), the second octet the
+     next 8 bits, ..., and the eighth octet supplies the 8 least
+     significant bits.
+
+     Encryption under DES using cipher block chaining requires an
+     additional input in the form of an initialization vector. Unless
+     otherwise specified, zero should be used as the initialization vector.
+     Kerberos' use of DES requires an 8 octet confounder.
+
+     The DES specifications identify some 'weak' and 'semi-weak' keys;
+     those keys shall not be used for encrypting messages for use in
+     Kerberos. Additionally, because of the way that keys are derived for
+     the encryption of checksums, keys shall not be used that yield 'weak'
+     or 'semi-weak' keys when eXclusive-ORed with the hexadecimal constant
+     F0F0F0F0F0F0F0F0.
+
+     A DES key is 8 octets of data, with keytype one (1). This consists of
+     56 bits of key, and 8 parity bits (one per octet). The key is encoded
+     as a series of 8 octets written in MSB-first order. The bits within
+     the key are also encoded in MSB order. For example, if the encryption
+     key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8)
+     where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8
+     are the parity bits, the first octet of the key would be
+     B1,B2,...,B7,P1 (with B1 as the MSbit). [See the FIPS 81 introduction
+     for reference.]
+
+     String to key transformation
+
+     To generate a DES key from a text string (password), a "salt" is
+     concatenated to the text string, and then padded with ASCII nulls to
+     an 8 byte boundary. This "salt" is normally the realm and each
+     component of the principal's name appended. However, sometimes
+     different salts are used --- for example, when a realm is renamed, or
+     if a user changes her username, or for compatibility with Kerberos V4
+     (whose string-to-key algorithm uses a null string for the salt). This
+     string is then fan-folded and eXclusive-ORed with itself to form an 8
+     byte DES key. Before eXclusive-ORing a block, every byte is shifted
+     one bit to the left to leave the lowest bit zero. The key is the
+     "corrected" by correcting the parity on the key, and if the key
+     matches a 'weak' or 'semi-weak' key as described in the DES
+     specification, it is eXclusive-ORed with the constant
+     00000000000000F0. This key is then used to generate a DES CBC checksum
+     on the initial string (with the salt appended). The result of the CBC
+     checksum is the "corrected" as described above to form the result
+     which is return as the key. Pseudocode follows:
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+          name_to_default_salt(realm, name) {
+               s = realm
+               for(each component in name) {
+                    s = s + component;
+               }
+               return s;
+          }
+
+          key_correction(key) {
+               fixparity(key);
+               if (is_weak_key_key(key))
+                    key = key XOR 0xF0;
+               return(key);
+          }
+
+          string_to_key(string,salt) {
+
+               odd = 1;
+               s = string + salt;
+               tempkey = NULL;
+               pad(s); /* with nulls to 8 byte boundary */
+               for(8byteblock in s) {
+                    if(odd == 0)  {
+                        odd = 1;
+                        reverse(8byteblock)
+                    }
+                    else odd = 0;
+                    left shift every byte in 8byteblock one bit;
+                    tempkey = tempkey XOR 8byteblock;
+               }
+               tempkey = key_correction(tempkey);
+               key = key_correction(DES-CBC-check(s,tempkey));
+               return(key);
+          }
+
+     6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with and
+     without Key Derivation [Original draft by Marc Horowitz, revisions by
+     David Miller]
+
+          There are still a few pieces of this specification to be included
+          by falue, rather than by reference. This will be done before the
+          Pittsburgh IETF.
+     This encryption type is based on the Triple DES cryptosystem, the
+     HMAC-SHA1 [Krawczyk96] message authentication algorithm, and key
+     derivation for Kerberos V5 [HorowitzB96]. Key derivation may or may
+     not be used in conjunction with the use of Triple DES keys.
+
+     Algorithm Identifiers
+
+     The des3-cbc-hmac-sha1 encryption type has been assigned the value 7.
+     The des3-cbc-hmac-sha1-kd encryption type, specifying the key
+     derivation variant of the encryption type, has been assigned the value
+     16. The hmac-sha1-des3 checksum type has been assigned the value 13.
+     The hmac-sha1-des3-kd checksum type, specifying the key derivation
+     variant of the checksum, has been assigned the value 12.
+
+     Triple DES Key Production
+
+     The EncryptionKey value is 24 octets long. The 7 most significant bits
+     of each octet contain key bits, and the least significant bit is the
+     inverse of the xor of the key bits.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     For the purposes of key derivation, the block size is 64 bits, and the
+     key size is 168 bits. The 168 bits output by key derivation are
+     converted to an EncryptionKey value as follows. First, the 168 bits
+     are divided into three groups of 56 bits, which are expanded
+     individually into 64 bits as follows:
+
+      1  2  3  4  5  6  7  p
+      9 10 11 12 13 14 15  p
+     17 18 19 20 21 22 23  p
+     25 26 27 28 29 30 31  p
+     33 34 35 36 37 38 39  p
+     41 42 43 44 45 46 47  p
+     49 50 51 52 53 54 55  p
+     56 48 40 32 24 16  8  p
+
+     The "p" bits are parity bits computed over the data bits. The output
+     of the three expansions are concatenated to form the EncryptionKey
+     value.
+
+     When the HMAC-SHA1 of a string is computed, the key is used in the
+     EncryptedKey form.
+
+     The string-to-key function is used to tranform UNICODE passwords into
+     DES3 keys. The DES3 string-to-key function relies on the "N-fold"
+     algorithm, which is detailed in [9]. The description of the N-fold
+     algorithm in that document is as follows:
+        o To n-fold a number X, replicate the input value to a length that
+          is the least common multiple of n and the length of X. Before
+          each repetition, the input is rotated to the right by 13 bit
+          positions. The successive n-bit chunks are added together using
+          1's-complement addition (that is, addition with end-around carry)
+          to yield an n-bit result"
+        o The n-fold algorithm, as with DES string-to-key, is applied to
+          the password string concatenated with a salt value. The salt
+          value is derived in the same was as for the DES string-to-key
+          algorithm. For 3-key triple DES then, the operation will involve
+          a 168-fold of the input password string. The remainder of the
+          string-to-key function for DES3 is shown here in pseudocode:
+
+     DES3string-to-key(passwordString, key)
+
+         salt = name_to_default_salt(realm, name)
+         s = passwordString + salt
+         tmpKey1 = 168-fold(s)
+         parityFix(tmpKey1);
+         if not weakKey(tmpKey1)
+             /*
+              * Encrypt temp key in itself with a
+              * zero initialization vector
+              *
+              * Function signature is DES3encrypt(plain, key, iv)
+              * with cipher as the return value
+              */
+             tmpKey2 = DES3encrypt(tmpKey1, tmpKey1, zeroIvec)
+             /*
+              * Encrypt resultant temp key in itself with third component
+              * of first temp key as initialization vector
+              */
+             key = DES3encrypt(tmpKey2, tmpKey1, tmpKey1[2])
+             parityFix(key)
+             if not weakKey(key)
+                  return SUCCESS
+             else
+                  return FAILURE
+         else
+             return FAILURE
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     The weakKey function above is the same weakKey function used with DES
+     keys, but applied to each of the three single DES keys that comprise
+     the triple DES key.
+
+     The lengths of UNICODE encoded character strings include the trailing
+     terminator character (0).
+
+     Encryption Types des3-cbc-hmac-sha1 and des3-cbc-hmac-sha1-kd
+
+     EncryptedData using this type must be generated as described in
+     [Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC
+     mode. The checksum algorithm is HMAC-SHA1. If the key derivation
+     variant of the encryption type is used, encryption key values are
+     modified according to the method under the Key Derivation section
+     below.
+
+     Unless otherwise specified, a zero IV must be used.
+
+     If the length of the input data is not a multiple of the block size,
+     zero octets must be used to pad the plaintext to the next eight-octet
+     boundary. The counfounder must be eight random octets (one block).
+
+     Checksum Types hmac-sha1-des3 and hmac-sha1-des3-kd
+
+     Checksums using this type must be generated as described in
+     [Horowitz96]. The keyed hash algorithm is HMAC-SHA1. If the key
+     derivation variant of the checksum type is used, checksum key values
+     are modified according to the method under the Key Derivation section
+     below.
+
+     Key Derivation
+
+     In the Kerberos protocol, cryptographic keys are used in a number of
+     places. In order to minimize the effect of compromising a key, it is
+     desirable to use a different key for each of these places. Key
+     derivation [Horowitz96] can be used to construct different keys for
+     each operation from the keys transported on the network. For this to
+     be possible, a small change to the specification is necessary.
+
+     This section specifies a profile for the use of key derivation
+     [Horowitz96] with Kerberos. For each place where a key is used, a
+     ``key usage'' must is specified for that purpose. The key, key usage,
+     and encryption/checksum type together describe the transformation from
+     plaintext to ciphertext, or plaintext to checksum.
+
+     Key Usage Values
+
+     This is a complete list of places keys are used in the kerberos
+     protocol, with key usage values and RFC 1510 section numbers:
+
+      1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the
+         client key (section 5.4.1)
+      2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or
+         application session key), encrypted with the service key
+         (section 5.4.2)
+      3. AS-REP encrypted part (includes tgs session key or application
+         session key), encrypted with the client key (section 5.4.2)
+      4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
+         session key (section 5.4.1)
+      5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
+         authenticator subkey (section 5.4.1)
+      6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
+         with the tgs session key (sections 5.3.2, 5.4.1)
+      7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs
+         authenticator subkey), encrypted with the tgs session key
+         (section 5.3.2)
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+      8. TGS-REP encrypted part (includes application session key),
+         encrypted with the tgs session key (section 5.4.2)
+      9. TGS-REP encrypted part (includes application session key),
+         encrypted with the tgs authenticator subkey (section 5.4.2)
+     10. AP-REQ Authenticator cksum, keyed with the application session
+         key (section 5.3.2)
+     11. AP-REQ Authenticator (includes application authenticator
+         subkey), encrypted with the application session key (section
+         5.3.2)
+     12. AP-REP encrypted part (includes application session subkey),
+         encrypted with the application session key (section 5.5.2)
+     13. KRB-PRIV encrypted part, encrypted with a key chosen by the
+         application (section 5.7.1)
+     14. KRB-CRED encrypted part, encrypted with a key chosen by the
+         application (section 5.6.1)
+     15. KRB-SAVE cksum, keyed with a key chosen by the application
+         (section 5.8.1)
+     18. KRB-ERROR checksum (e-cksum in section 5.9.1)
+     19. AD-KDCIssued checksum (ad-checksum in appendix B.1)
+     20. Checksum for Mandatory Ticket Extensions (appendix B.6)
+     21. Checksum in Authorization Data in Ticket Extensions (appendix B.7)
+
+     Key usage values between 1024 and 2047 (inclusive) are reserved for
+     application use. Applications should use even values for encryption
+     and odd values for checksums within this range.
+
+     A few of these key usages need a little clarification. A service which
+     receives an AP-REQ has no way to know if the enclosed Ticket was part
+     of an AS-REP or TGS-REP. Therefore, key usage 2 must always be used
+     for generating a Ticket, whether it is in response to an AS- REQ or
+     TGS-REQ.
+
+     There might exist other documents which define protocols in terms of
+     the RFC1510 encryption types or checksum types. Such documents would
+     not know about key usages. In order that these documents continue to
+     be meaningful until they are updated, key usages 1024 and 1025 must be
+     used to derive keys for encryption and checksums, respectively. New
+     protocols defined in terms of the Kerberos encryption and checksum
+     types should use their own key usages. Key usages may be registered
+     with IANA to avoid conflicts. Key usages must be unsigned 32 bit
+     integers. Zero is not permitted.
+
+     Defining Cryptosystems Using Key Derivation
+
+     Kerberos requires that the ciphertext component of EncryptedData be
+     tamper-resistant as well as confidential. This implies encryption and
+     integrity functions, which must each use their own separate keys. So,
+     for each key usage, two keys must be generated, one for encryption
+     (Ke), and one for integrity (Ki):
+
+           Ke = DK(protocol key, key usage | 0xAA)
+           Ki = DK(protocol key, key usage | 0x55)
+
+     where the protocol key is from the EncryptionKey from the wire
+     protocol, and the key usage is represented as a 32 bit integer in
+     network byte order. The ciphertest must be generated from the
+     plaintext as follows:
+
+        ciphertext = E(Ke, confounder | plaintext | padding) |
+                     H(Ki, confounder | plaintext | padding)
+
+     The confounder and padding are specific to the encryption algorithm E.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     When generating a checksum only, there is no need for a confounder or
+     padding. Again, a new key (Kc) must be used. Checksums must be
+     generated from the plaintext as follows:
+
+           Kc = DK(protocol key, key usage | 0x99)
+           MAC = H(Kc, plaintext)
+
+     Note that each enctype is described by an encryption algorithm E and a
+     keyed hash algorithm H, and each checksum type is described by a keyed
+     hash algorithm H. HMAC, with an appropriate hash, is required for use
+     as H.
+
+     Key Derivation from Passwords
+
+     The well-known constant for password key derivation must be the byte
+     string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values
+     correspond to the ASCII encoding for the string "kerberos".
+
+     6.4. Checksums
+
+     The following is the ASN.1 definition used for a checksum:
+
+              Checksum ::=   SEQUENCE {
+                             cksumtype[0]   INTEGER,
+                             checksum[1]    OCTET STRING
+              }
+
+     cksumtype
+          This field indicates the algorithm used to generate the
+          accompanying checksum.
+     checksum
+          This field contains the checksum itself, encoded as an octet
+          string.
+     Detailed specification of selected checksum types appear later in this
+     section. Negative values for the checksum type are reserved for local
+     use. All non-negative values are reserved for officially assigned type
+     fields and interpretations.
+
+     Checksums used by Kerberos can be classified by two properties:
+     whether they are collision-proof, and whether they are keyed. It is
+     infeasible to find two plaintexts which generate the same checksum
+     value for a collision-proof checksum. A key is required to perturb or
+     initialize the algorithm in a keyed checksum. To prevent
+     message-stream modification by an active attacker, unkeyed checksums
+     should only be used when the checksum and message will be subsequently
+     encrypted (e.g. the checksums defined as part of the encryption
+     algorithms covered earlier in this section).
+
+     Collision-proof checksums can be made tamper-proof if the checksum
+     value is encrypted before inclusion in a message. In such cases, the
+     composition of the checksum and the encryption algorithm must be
+     considered a separate checksum algorithm (e.g. RSA-MD5 encrypted using
+     DES is a new checksum algorithm of type RSA-MD5-DES). For most keyed
+     checksums, as well as for the encrypted forms of unkeyed
+     collision-proof checksums, Kerberos prepends a confounder before the
+     checksum is calculated.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     6.4.1. The CRC-32 Checksum (crc32)
+
+     The CRC-32 checksum calculates a checksum based on a cyclic redundancy
+     check as described in ISO 3309 [ISO3309]. The resulting checksum is
+     four (4) octets in length. The CRC-32 is neither keyed nor
+     collision-proof. The use of this checksum is not recommended. An
+     attacker using a probabilistic chosen-plaintext attack as described in
+     [SG92] might be able to generate an alternative message that satisfies
+     the checksum. The use of collision-proof checksums is recommended for
+     environments where such attacks represent a significant threat.
+
+     6.4.2. The RSA MD4 Checksum (rsa-md4)
+
+     The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm
+     [MD4-92]. The algorithm takes as input an input message of arbitrary
+     length and produces as output a 128-bit (16 octet) checksum. RSA-MD4
+     is believed to be collision-proof.
+
+     6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des)
+
+     The RSA-MD4-DES checksum calculates a keyed collision-proof checksum
+     by prepending an 8 octet confounder before the text, applying the RSA
+     MD4 checksum algorithm, and encrypting the confounder and the checksum
+     using DES in cipher-block-chaining (CBC) mode using a variant of the
+     key, where the variant is computed by eXclusive-ORing the key with the
+     constant F0F0F0F0F0F0F0F0[39]. The initialization vector should be
+     zero. The resulting checksum is 24 octets long (8 octets of which are
+     redundant). This checksum is tamper-proof and believed to be
+     collision-proof.
+
+     The DES specifications identify some weak keys' and 'semi-weak keys';
+     those keys shall not be used for generating RSA-MD4 checksums for use
+     in Kerberos.
+
+     The format for the checksum is described in the follow- ing diagram:
+
+
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     |  des-cbc(confounder   +   rsa-md4(confounder+msg),key=var(key),iv=0)
+|
+
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+     The format cannot be described in ASN.1, but for those who prefer an
+     ASN.1-like notation:
+
+     rsa-md4-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
+                                confounder[0]   UNTAGGED OCTET STRING(8),
+                                check[1]        UNTAGGED OCTET STRING(16)
+     }
+
+     6.4.4. The RSA MD5 Checksum (rsa-md5)
+
+     The RSA-MD5 checksum calculates a checksum using the RSA MD5
+     algorithm. [MD5-92]. The algorithm takes as input an input message of
+     arbitrary length and produces as output a 128-bit (16 octet) checksum.
+     RSA-MD5 is believed to be collision-proof.
+
+     6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des)
+
+     The RSA-MD5-DES checksum calculates a keyed collision-proof checksum
+     by prepending an 8 octet confounder before the text, applying the RSA
+     MD5 checksum algorithm, and encrypting the confounder and the checksum
+     using DES in cipher-block-chaining (CBC) mode using a variant of the
+     key, where the variant is computed by eXclusive-ORing the key with the
+     hexadecimal constant F0F0F0F0F0F0F0F0. The initialization vector
+     should be zero. The resulting checksum is 24 octets long (8 octets of
+     which are redundant). This checksum is tamper-proof and believed to be
+     collision-proof.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     The DES specifications identify some 'weak keys' and 'semi-weak keys';
+     those keys shall not be used for encrypting RSA-MD5 checksums for use
+     in Kerberos.
+
+     The format for the checksum is described in the following diagram:
+
+
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     |  des-cbc(confounder   +   rsa-md5(confounder+msg),key=var(key),iv=0)
+|
+
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+     The format cannot be described in ASN.1, but for those who prefer an
+     ASN.1-like notation:
+
+     rsa-md5-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
+                                confounder[0]   UNTAGGED OCTET STRING(8),
+                                check[1]        UNTAGGED OCTET STRING(16)
+     }
+
+     6.4.6. DES cipher-block chained checksum (des-mac)
+
+     The DES-MAC checksum is computed by prepending an 8 octet confounder
+     to the plaintext, performing a DES CBC-mode encryption on the result
+     using the key and an initialization vector of zero, taking the last
+     block of the ciphertext, prepending the same confounder and encrypting
+     the pair using DES in cipher-block-chaining (CBC) mode using a a
+     variant of the key, where the variant is computed by eXclusive-ORing
+     the key with the hexadecimal constant F0F0F0F0F0F0F0F0. The
+     initialization vector should be zero. The resulting checksum is 128
+     bits (16 octets) long, 64 bits of which are redundant. This checksum
+     is tamper-proof and collision-proof.
+
+     The format for the checksum is described in the following diagram:
+
+
++--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
+     |   des-cbc(confounder  + des-mac(conf+msg,iv=0,key),key=var(key),iv=0)
+|
+
++--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
+
+     The format cannot be described in ASN.1, but for those who prefer an
+     ASN.1-like notation:
+
+     des-mac-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
+                            confounder[0]   UNTAGGED OCTET STRING(8),
+                            check[1]        UNTAGGED OCTET STRING(8)
+     }
+
+     The DES specifications identify some 'weak' and 'semi-weak' keys;
+     those keys shall not be used for generating DES-MAC checksums for use
+     in Kerberos, nor shall a key be used whose variant is 'weak' or
+     'semi-weak'.
+
+     6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative
+     (rsa-md4-des-k)
+
+     The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum
+     by applying the RSA MD4 checksum algorithm and encrypting the results
+     using DES in cipher-block-chaining (CBC) mode using a DES key as both
+     key and initialization vector. The resulting checksum is 16 octets
+     long. This checksum is tamper-proof and believed to be
+     collision-proof. Note that this checksum type is the old method for
+     encoding the RSA-MD4-DES checksum and it is no longer recommended.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     6.4.8. DES cipher-block chained checksum alternative (des-mac-k)
+
+     The DES-MAC-K checksum is computed by performing a DES CBC-mode
+     encryption of the plaintext, and using the last block of the
+     ciphertext as the checksum value. It is keyed with an encryption key
+     and an initialization vector; any uses which do not specify an
+     additional initialization vector will use the key as both key and
+     initialization vector. The resulting checksum is 64 bits (8 octets)
+     long. This checksum is tamper-proof and collision-proof. Note that
+     this checksum type is the old method for encoding the DES-MAC checksum
+     and it is no longer recommended. The DES specifications identify some
+     'weak keys' and 'semi-weak keys'; those keys shall not be used for
+     generating DES-MAC checksums for use in Kerberos.
+
+     7. Naming Constraints
+
+     7.1. Realm Names
+
+     Although realm names are encoded as GeneralStrings and although a
+     realm can technically select any name it chooses, interoperability
+     across realm boundaries requires agreement on how realm names are to
+     be assigned, and what information they imply.
+
+     To enforce these conventions, each realm must conform to the
+     conventions itself, and it must require that any realms with which
+     inter-realm keys are shared also conform to the conventions and
+     require the same from its neighbors.
+
+     Kerberos realm names are case sensitive. Realm names that differ only
+     in the case of the characters are not equivalent. There are presently
+     four styles of realm names: domain, X500, other, and reserved.
+     Examples of each style follow:
+
+          domain:   ATHENA.MIT.EDU (example)
+            X500:   C=US/O=OSF (example)
+           other:   NAMETYPE:rest/of.name=without-restrictions (example)
+        reserved:   reserved, but will not conflict with above
+
+     Domain names must look like domain names: they consist of components
+     separated by periods (.) and they contain neither colons (:) nor
+     slashes (/). Though domain names themselves are case insensitive, in
+     order for realms to match, the case must match as well. When
+     establishing a new realm name based on an internet domain name it is
+     recommended by convention that the characters be converted to upper
+     case.
+
+     X.500 names contain an equal (=) and cannot contain a colon (:) before
+     the equal. The realm names for X.500 names will be string
+     representations of the names with components separated by slashes.
+     Leading and trailing slashes will not be included.
+
+     Names that fall into the other category must begin with a prefix that
+     contains no equal (=) or period (.) and the prefix must be followed by
+     a colon (:) and the rest of the name. All prefixes must be assigned
+     before they may be used. Presently none are assigned.
+
+     The reserved category includes strings which do not fall into the
+     first three categories. All names in this category are reserved. It is
+     unlikely that names will be assigned to this category unless there is
+     a very strong argument for not using the 'other' category.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     These rules guarantee that there will be no conflicts between the
+     various name styles. The following additional constraints apply to the
+     assignment of realm names in the domain and X.500 categories: the name
+     of a realm for the domain or X.500 formats must either be used by the
+     organization owning (to whom it was assigned) an Internet domain name
+     or X.500 name, or in the case that no such names are registered,
+     authority to use a realm name may be derived from the authority of the
+     parent realm. For example, if there is no domain name for E40.MIT.EDU,
+     then the administrator of the MIT.EDU realm can authorize the creation
+     of a realm with that name.
+
+     This is acceptable because the organization to which the parent is
+     assigned is presumably the organization authorized to assign names to
+     its children in the X.500 and domain name systems as well. If the
+     parent assigns a realm name without also registering it in the domain
+     name or X.500 hierarchy, it is the parent's responsibility to make
+     sure that there will not in the future exists a name identical to the
+     realm name of the child unless it is assigned to the same entity as
+     the realm name.
+
+     7.2. Principal Names
+
+     As was the case for realm names, conventions are needed to ensure that
+     all agree on what information is implied by a principal name. The
+     name-type field that is part of the principal name indicates the kind
+     of information implied by the name. The name-type should be treated as
+     a hint. Ignoring the name type, no two names can be the same (i.e. at
+     least one of the components, or the realm, must be different). The
+     following name types are defined:
+
+     name-type      value   meaning
+
+    NT-UNKNOWN        0   Name type not known
+    NT-PRINCIPAL      1   General principal name (e.g. username, DCE
+principal)
+    NT-SRV-INST       2   Service and other unique instance (krbtgt)
+    NT-SRV-HST        3   Service with host name as instance (telnet, rcmds)
+    NT-SRV-XHST       4   Service with slash-separated host name components
+    NT-UID            5   Unique ID
+    NT-X500-PRINCIPAL 6   Encoded X.509 Distingished name [RFC 1779]
+    NT-SMTP-NAME      7   Name in form of SMTP email name (e.g.
+user@foo.com)
+
+     When a name implies no information other than its uniqueness at a
+     particular time the name type PRINCIPAL should be used. The principal
+     name type should be used for users, and it might also be used for a
+     unique server. If the name is a unique machine generated ID that is
+     guaranteed never to be reassigned then the name type of UID should be
+     used (note that it is generally a bad idea to reassign names of any
+     type since stale entries might remain in access control lists).
+
+     If the first component of a name identifies a service and the
+     remaining components identify an instance of the service in a server
+     specified manner, then the name type of SRV-INST should be used. An
+     example of this name type is the Kerberos ticket-granting service
+     whose name has a first component of krbtgt and a second component
+     identifying the realm for which the ticket is valid.
+
+     If instance is a single component following the service name and the
+     instance identifies the host on which the server is running, then the
+     name type SRV-HST should be used. This type is typically used for
+     Internet services such as telnet and the Berkeley R commands. If the
+     separate components of the host name appear as successive components
+     following the name of the service, then the name type SRV-XHST should
+     be used. This type might be used to identify servers on hosts with
+     X.500 names where the slash (/) might otherwise be ambiguous.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     A name type of NT-X500-PRINCIPAL should be used when a name from an
+     X.509 certificiate is translated into a Kerberos name. The encoding of
+     the X.509 name as a Kerberos principal shall conform to the encoding
+     rules specified in RFC 2253.
+
+     A name type of SMTP allows a name to be of a form that resembles a
+     SMTP email name. This name type can be used in conjunction with
+     name-canonicalization to allow a free-form of username to be specified
+     as a client name and allow the KDC to determine the Kerberos principal
+     name for the requested name. [JBrezak]
+
+     A name type of UNKNOWN should be used when the form of the name is not
+     known. When comparing names, a name of type UNKNOWN will match
+     principals authenticated with names of any type. A principal
+     authenticated with a name of type UNKNOWN, however, will only match
+     other names of type UNKNOWN.
+
+     Names of any type with an initial component of 'krbtgt' are reserved
+     for the Kerberos ticket granting service. See section 8.2.3 for the
+     form of such names.
+
+     7.2.1. Name of server principals
+
+     The principal identifier for a server on a host will generally be
+     composed of two parts: (1) the realm of the KDC with which the server
+     is registered, and (2) a two-component name of type NT-SRV-HST if the
+     host name is an Internet domain name or a multi-component name of type
+     NT-SRV-XHST if the name of the host is of a form such as X.500 that
+     allows slash (/) separators. The first component of the two- or
+     multi-component name will identify the service and the latter
+     components will identify the host. Where the name of the host is not
+     case sensitive (for example, with Internet domain names) the name of
+     the host must be lower case. If specified by the application protocol
+     for services such as telnet and the Berkeley R commands which run with
+     system privileges, the first component may be the string 'host'
+     instead of a service specific identifier. When a host has an official
+     name and one or more aliases, the official name of the host must be
+     used when constructing the name of the server principal.
+
+     8. Constants and other defined values
+
+     8.1. Host address types
+
+     All negative values for the host address type are reserved for local
+     use. All non-negative values are reserved for officially assigned type
+     fields and interpretations.
+
+     The values of the types for the following addresses are chosen to
+     match the defined address family constants in the Berkeley Standard
+     Distributions of Unix. They can be found in with symbolic names AF_xxx
+     (where xxx is an abbreviation of the address family name).
+
+     Internet (IPv4) Addresses
+
+     Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
+     MSB order. The type of IPv4 addresses is two (2).
+
+     Internet (IPv6) Addresses [Westerlund]
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB
+     order. The type of IPv6 addresses is twenty-four (24). [RFC1883]
+     [RFC1884]. The following addresses (see [RFC1884]) MUST not appear in
+     any Kerberos packet:
+        o the Unspecified Address
+        o the Loopback Address
+        o Link-Local addresses
+     IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
+
+     CHAOSnet addresses
+
+     CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB
+     order. The type of CHAOSnet addresses is five (5).
+
+     ISO addresses
+
+     ISO addresses are variable-length. The type of ISO addresses is seven
+     (7).
+
+     Xerox Network Services (XNS) addresses
+
+     XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order.
+     The type of XNS addresses is six (6).
+
+     AppleTalk Datagram Delivery Protocol (DDP) addresses
+
+     AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit
+     network number. The first octet of the address is the node number; the
+     remaining two octets encode the network number in MSB order. The type
+     of AppleTalk DDP addresses is sixteen (16).
+
+     DECnet Phase IV addresses
+
+     DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order.
+     The type of DECnet Phase IV addresses is twelve (12).
+
+     Netbios addresses
+
+     Netbios addresses are 16-octet addresses typically composed of 1 to 15
+     characters, trailing blank (ascii char 20) filled, with a 16th octet
+     of 0x0. The type of Netbios addresses is 20 (0x14).
+
+     8.2. KDC messages
+
+     8.2.1. UDP/IP transport
+
+     When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request
+     using UDP IP transport, the client shall send a UDP datagram
+     containing only an encoding of the request to port 88 (decimal) at the
+     KDC's IP address; the KDC will respond with a reply datagram
+     containing only an encoding of the reply message (either a KRB_ERROR
+     or a KRB_KDC_REP) to the sending port at the sender's IP address.
+     Kerberos servers supporting IP transport must accept UDP requests on
+     port 88 (decimal). The response to a request made through UDP/IP
+     transport must also use UDP/IP transport.
+
+     8.2.2. TCP/IP transport [Westerlund,Danielsson]
+
+     Kerberos servers (KDC's) should accept TCP requests on port 88
+     (decimal) and clients should support the sending of TCP requests on
+     port 88 (decimal). When the KRB_KDC_REQ message is sent to the KDC
+     over a TCP stream, a new connection will be established for each
+     authentication exchange (request and response). The KRB_KDC_REP or
+     KRB_ERROR message will be returned to the client on the same TCP
+     stream that was established for the request. The response to a request
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     made through TCP/IP transport must also use TCP/IP transport.
+     Implementors should note that some extentions to the Kerberos protocol
+     will not work if any implementation not supporting the TCP transport
+     is involved (client or KDC). Implementors are strongly urged to
+     support the TCP transport on both the client and server and are
+     advised that the current notation of "should" support will likely
+     change in the future to must support. The KDC may close the TCP stream
+     after sending a response, but may leave the stream open if it expects
+     a followup - in which case it may close the stream at any time if
+     resource constratints or other factors make it desirable to do so.
+     Care must be taken in managing TCP/IP connections with the KDC to
+     prevent denial of service attacks based on the number of TCP/IP
+     connections with the KDC that remain open. If multiple exchanges with
+     the KDC are needed for certain forms of preauthentication, multiple
+     TCP connections may be required. A client may close the stream after
+     receiving response, and should close the stream if it does not expect
+     to send followup messages. The client must be prepared to have the
+     stream closed by the KDC at anytime, in which case it must simply
+     connect again when it is ready to send subsequent messages.
+
+     The first four octets of the TCP stream used to transmit the request
+     request will encode in network byte order the length of the request
+     (KRB_KDC_REQ), and the length will be followed by the request itself.
+     The response will similarly be preceeded by a 4 octet encoding in
+     network byte order of the length of the KRB_KDC_REP or the KRB_ERROR
+     message and will be followed by the KRB_KDC_REP or the KRB_ERROR
+     response. If the sign bit is set on the integer represented by the
+     first 4 octets, then the next 4 octets will be read, extending the
+     length of the field by another 4 octets (less the sign bit which is
+     reserved for future expansion).
+
+     8.2.3. OSI transport
+
+     During authentication of an OSI client to an OSI server, the mutual
+     authentication of an OSI server to an OSI client, the transfer of
+     credentials from an OSI client to an OSI server, or during exchange of
+     private or integrity checked messages, Kerberos protocol messages may
+     be treated as opaque objects and the type of the authentication
+     mechanism will be:
+
+     OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1),
+security(5),kerberosv5(2)}
+
+     Depending on the situation, the opaque object will be an
+     authentication header (KRB_AP_REQ), an authentication reply
+     (KRB_AP_REP), a safe message (KRB_SAFE), a private message (KRB_PRIV),
+     or a credentials message (KRB_CRED). The opaque data contains an
+     application code as specified in the ASN.1 description for each
+     message. The application code may be used by Kerberos to determine the
+     message type.
+
+     8.2.3. Name of the TGS
+
+     The principal identifier of the ticket-granting service shall be
+     composed of three parts: (1) the realm of the KDC issuing the TGS
+     ticket (2) a two-part name of type NT-SRV-INST, with the first part
+     "krbtgt" and the second part the name of the realm which will accept
+     the ticket-granting ticket. For example, a ticket-granting ticket
+     issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
+     ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU"
+     (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting ticket
+     issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
+     MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm),
+     ("krbtgt", "MIT.EDU") (name).
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     8.3. Protocol constants and associated values
+
+     The following tables list constants used in the protocol and defines
+     their meanings. Ranges are specified in the "specification" section
+     that limit the values of constants for which values are defined here.
+     This allows implementations to make assumptions about the maximum
+     values that will be received for these constants. Implementation
+     receiving values outside the range specified in the "specification"
+     section may reject the request, but they must recover cleanly.
+
+     Encryption type       etype value block size  minimum pad  confounder
+size
+     NULL                           0     1           0            0
+     des-cbc-crc                    1     8           4            8
+     des-cbc-md4                    2     8           0            8
+     des-cbc-md5                    3     8           0            8
+     reserved                       4
+     des3-cbc-md5                   5     8           0                 8
+     reserved                       6
+     des3-cbc-sha1                  7     8           0                 8
+     dsaWithSHA1-CmsOID             9
+(pkinit)
+     md5WithRSAEncryption-CmsOID   10
+(pkinit)
+     sha1WithRSAEncryption-CmsOID  11
+(pkinit)
+     rc2CBC-EnvOID                 12
+(pkinit)
+     rsaEncryption-EnvOID          13                (pkinit from PKCS#1
+v1.5)
+     rsaES-OAEP-ENV-OID            14                (pkinit from PKCS#1
+v2.0)
+     des-ede3-cbc-Env-OID          15
+(pkinit)
+     des3-cbc-sha1-kd              16                                 (Tom
+Yu)
+     rc4-hmac                      23
+(swift)
+     rc4-hmac-exp                  24
+(swift)
+
+     reserved                      0x8003
+
+     Checksum type              sumtype value       checksum size
+     CRC32                      1                   4
+     rsa-md4                    2                   16
+     rsa-md4-des                3                   24
+     des-mac                    4                   16
+     des-mac-k                  5                   8
+     rsa-md4-des-k              6                   16 (drop rsa ?)
+     rsa-md5                    7                   16 (drop rsa ?)
+     rsa-md5-des                8                   24 (drop rsa ?)
+     rsa-md5-des3               9                   24 (drop rsa ?)
+     hmac-sha1-des3-kd          12                  20
+     hmac-sha1-des3             13                  20
+     sha1 (unkeyed)             14                  20
+
+     padata type                     padata-type value
+
+     PA-TGS-REQ                      1
+     PA-ENC-TIMESTAMP                2
+     PA-PW-SALT                      3
+     reserved                        4
+     PA-ENC-UNIX-TIME                5                  (depricated)
+     PA-SANDIA-SECUREID              6
+     PA-SESAME                       7
+     PA-OSF-DCE                      8
+     PA-CYBERSAFE-SECUREID           9
+     PA-AFS3-SALT                    10
+     PA-ETYPE-INFO                   11
+     PA-SAM-CHALLENGE                12                  (sam/otp)
+     PA-SAM-RESPONSE                 13                  (sam/otp)
+     PA-PK-AS-REQ                    14                  (pkinit)
+     PA-PK-AS-REP                    15                  (pkinit)
+     PA-USE-SPECIFIED-KVNO           20
+     PA-SAM-REDIRECT                 21                  (sam/otp)
+     PA-GET-FROM-TYPED-DATA          22
+     PA-SAM-ETYPE-INFO               23                  (sam/otp)
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     data-type                     value    form of typed-data
+
+     reserved                        1-21
+     TD-PADATA                       22
+     TD-PKINIT-CMS-CERTIFICATES      101      CertificateSet from CMS
+     TD-KRB-PRINCIPAL                102
+     TD-KRB-REALM                    103
+     TD-TRUSTED-CERTIFIERS           104
+     TD-CERTIFICATE-INDEX            105
+     TD-APP-DEFINED-ERROR            106
+
+     authorization data type         ad-type value
+     AD-IF-RELEVANT                     1
+     AD-INTENDED-FOR-SERVER             2
+     AD-INTENDED-FOR-APPLICATION-CLASS  3
+     AD-KDC-ISSUED                      4
+     AD-OR                              5
+     AD-MANDATORY-TICKET-EXTENSIONS     6
+     AD-IN-TICKET-EXTENSIONS            7
+     reserved values                    8-63
+     OSF-DCE                            64
+     SESAME                             65
+     AD-OSF-DCE-PKI-CERTID              66    (hemsath@us.ibm.com)
+     AD-WIN200-PAC                     128
+(jbrezak@exchange.microsoft.com)
+
+     Ticket Extension Types
+
+     TE-TYPE-NULL                  0     Null ticket extension
+     TE-TYPE-EXTERNAL-ADATA        1     Integrity protected authorization
+data
+     reserved                      2     TE-TYPE-PKCROSS-KDC
+     TE-TYPE-PKCROSS-CLIENT        3     PKCROSS cross realm key ticket
+     TE-TYPE-CYBERSAFE-EXT         4     Assigned to CyberSafe Corp
+     reserved                      5     TE-TYPE-DEST-HOST
+
+     alternate authentication type   method-type value
+     reserved values                 0-63
+     ATT-CHALLENGE-RESPONSE          64
+
+     transited encoding type         tr-type value
+     DOMAIN-X500-COMPRESS            1
+     reserved values                 all others
+
+     Label               Value   Meaning or MIT code
+
+     pvno                    5   current Kerberos protocol version number
+
+     message types
+
+     KRB_AS_REQ             10   Request for initial authentication
+     KRB_AS_REP             11   Response to KRB_AS_REQ request
+     KRB_TGS_REQ            12   Request for authentication based on TGT
+     KRB_TGS_REP            13   Response to KRB_TGS_REQ request
+     KRB_AP_REQ             14   application request to server
+     KRB_AP_REP             15   Response to KRB_AP_REQ_MUTUAL
+     KRB_SAFE               20   Safe (checksummed) application message
+     KRB_PRIV               21   Private (encrypted) application message
+     KRB_CRED               22   Private (encrypted) message to forward
+credentials
+     KRB_ERROR              30   Error response
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     name types
+
+     KRB_NT_UNKNOWN        0  Name type not known
+     KRB_NT_PRINCIPAL      1  Just the name of the principal as in DCE, or
+for users
+     KRB_NT_SRV_INST       2  Service and other unique instance (krbtgt)
+     KRB_NT_SRV_HST        3  Service with host name as instance (telnet,
+rcommands)
+     KRB_NT_SRV_XHST       4  Service with host as remaining components
+     KRB_NT_UID            5  Unique ID
+     KRB_NT_X500_PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
+
+     error codes
+
+     KDC_ERR_NONE                    0   No error
+     KDC_ERR_NAME_EXP                1   Client's entry in database has
+expired
+     KDC_ERR_SERVICE_EXP             2   Server's entry in database has
+expired
+     KDC_ERR_BAD_PVNO                3   Requested protocol version number
+not supported
+     KDC_ERR_C_OLD_MAST_KVNO         4   Client's key encrypted in old
+master key
+     KDC_ERR_S_OLD_MAST_KVNO         5   Server's key encrypted in old
+master key
+     KDC_ERR_C_PRINCIPAL_UNKNOWN     6   Client not found in Kerberos
+database
+     KDC_ERR_S_PRINCIPAL_UNKNOWN     7   Server not found in Kerberos
+database
+     KDC_ERR_PRINCIPAL_NOT_UNIQUE    8   Multiple principal entries in
+database
+     KDC_ERR_NULL_KEY                9   The client or server has a null key
+     KDC_ERR_CANNOT_POSTDATE        10   Ticket not eligible for postdating
+     KDC_ERR_NEVER_VALID            11   Requested start time is later than
+end time
+     KDC_ERR_POLICY                 12   KDC policy rejects request
+     KDC_ERR_BADOPTION              13   KDC cannot accommodate requested
+option
+     KDC_ERR_ETYPE_NOSUPP           14   KDC has no support for encryption
+type
+     KDC_ERR_SUMTYPE_NOSUPP         15   KDC has no support for checksum
+type
+     KDC_ERR_PADATA_TYPE_NOSUPP     16   KDC has no support for padata type
+     KDC_ERR_TRTYPE_NOSUPP          17   KDC has no support for transited
+type
+     KDC_ERR_CLIENT_REVOKED         18   Clients credentials have been
+revoked
+     KDC_ERR_SERVICE_REVOKED        19   Credentials for server have been
+revoked
+     KDC_ERR_TGT_REVOKED            20   TGT has been revoked
+     KDC_ERR_CLIENT_NOTYET          21   Client not yet valid - try again
+later
+     KDC_ERR_SERVICE_NOTYET         22   Server not yet valid - try again
+later
+     KDC_ERR_KEY_EXPIRED            23   Password has expired - change
+password to reset
+     KDC_ERR_PREAUTH_FAILED         24   Pre-authentication information was
+invalid
+     KDC_ERR_PREAUTH_REQUIRED       25   Additional
+pre-authenticationrequired [40]
+     KDC_ERR_SERVER_NOMATCH         26   Requested server and ticket don't
+match
+     KDC_ERR_MUST_USE_USER2USER     27   Server principal valid for
+user2user only
+     KDC_ERR_PATH_NOT_ACCPETED      28   KDC Policy rejects transited path
+     KDC_ERR_SVC_UNAVAILABLE        29   A service is not available
+     KRB_AP_ERR_BAD_INTEGRITY       31   Integrity check on decrypted field
+failed
+     KRB_AP_ERR_TKT_EXPIRED         32   Ticket expired
+     KRB_AP_ERR_TKT_NYV             33   Ticket not yet valid
+     KRB_AP_ERR_REPEAT              34   Request is a replay
+     KRB_AP_ERR_NOT_US              35   The ticket isn't for us
+     KRB_AP_ERR_BADMATCH            36   Ticket and authenticator don't
+match
+     KRB_AP_ERR_SKEW                37   Clock skew too great
+     KRB_AP_ERR_BADADDR             38   Incorrect net address
+     KRB_AP_ERR_BADVERSION          39   Protocol version mismatch
+     KRB_AP_ERR_MSG_TYPE            40   Invalid msg type
+     KRB_AP_ERR_MODIFIED            41   Message stream modified
+     KRB_AP_ERR_BADORDER            42   Message out of order
+     KRB_AP_ERR_BADKEYVER           44   Specified version of key is not
+available
+     KRB_AP_ERR_NOKEY               45   Service key not available
+     KRB_AP_ERR_MUT_FAIL            46   Mutual authentication failed
+     KRB_AP_ERR_BADDIRECTION        47   Incorrect message direction
+     KRB_AP_ERR_METHOD              48   Alternative authentication method
+required
+     KRB_AP_ERR_BADSEQ              49   Incorrect sequence number in
+message
+     KRB_AP_ERR_INAPP_CKSUM         50   Inappropriate type of checksum in
+message
+     KRB_AP_PATH_NOT_ACCEPTED       51   Policy rejects transited path
+     KRB_ERR_RESPONSE_TOO_BIG       52   Response too big for UDP, retry
+with TCP
+     KRB_ERR_GENERIC                60   Generic error (description in
+e-text)
+     KRB_ERR_FIELD_TOOLONG          61   Field is too long for this
+implementation
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     KDC_ERROR_CLIENT_NOT_TRUSTED            62 (pkinit)
+     KDC_ERROR_KDC_NOT_TRUSTED               63 (pkinit)
+     KDC_ERROR_INVALID_SIG                   64 (pkinit)
+     KDC_ERR_KEY_TOO_WEAK                    65 (pkinit)
+     KDC_ERR_CERTIFICATE_MISMATCH            66 (pkinit)
+     KRB_AP_ERR_NO_TGT                       67 (user-to-user)
+     KDC_ERR_WRONG_REALM                     68 (user-to-user)
+     KRB_AP_ERR_USER_TO_USER_REQUIRED        69 (user-to-user)
+     KDC_ERR_CANT_VERIFY_CERTIFICATE         70 (pkinit)
+     KDC_ERR_INVALID_CERTIFICATE             71 (pkinit)
+     KDC_ERR_REVOKED_CERTIFICATE             72 (pkinit)
+     KDC_ERR_REVOCATION_STATUS_UNKNOWN       73 (pkinit)
+     KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74 (pkinit)
+     KDC_ERR_CLIENT_NAME_MISMATCH            75 (pkinit)
+     KDC_ERR_KDC_NAME_MISMATCH               76 (pkinit)
+
+     9. Interoperability requirements
+
+     Version 5 of the Kerberos protocol supports a myriad of options. Among
+     these are multiple encryption and checksum types, alternative encoding
+     schemes for the transited field, optional mechanisms for
+     pre-authentication, the handling of tickets with no addresses, options
+     for mutual authentication, user to user authentication, support for
+     proxies, forwarding, postdating, and renewing tickets, the format of
+     realm names, and the handling of authorization data.
+
+     In order to ensure the interoperability of realms, it is necessary to
+     define a minimal configuration which must be supported by all
+     implementations. This minimal configuration is subject to change as
+     technology does. For example, if at some later date it is discovered
+     that one of the required encryption or checksum algorithms is not
+     secure, it will be replaced.
+
+     9.1. Specification 2
+
+     This section defines the second specification of these options.
+     Implementations which are configured in this way can be said to
+     support Kerberos Version 5 Specification 2 (5.1). Specification 1
+     (depricated) may be found in RFC1510.
+
+     Transport
+
+     TCP/IP and UDP/IP transport must be supported by KDCs claiming
+     conformance to specification 2. Kerberos clients claiming conformance
+     to specification 2 must support UDP/IP transport for messages with the
+     KDC and should support TCP/IP transport.
+
+     Encryption and checksum methods
+
+     The following encryption and checksum mechanisms must be supported.
+     Implementations may support other mechanisms as well, but the
+     additional mechanisms may only be used when communicating with
+     principals known to also support them: This list is to be determined.
+
+     Encryption: DES-CBC-MD5, one triple des variant (tbd)
+     Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 (tbd)
+
+     Realm Names
+
+     All implementations must understand hierarchical realms in both the
+     Internet Domain and the X.500 style. When a ticket granting ticket for
+     an unknown realm is requested, the KDC must be able to determine the
+     names of the intermediate realms between the KDCs realm and the
+     requested realm.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     Transited field encoding
+
+     DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported.
+     Alternative encodings may be supported, but they may be used only when
+     that encoding is supported by ALL intermediate realms.
+
+     Pre-authentication methods
+
+     The TGS-REQ method must be supported. The TGS-REQ method is not used
+     on the initial request. The PA-ENC-TIMESTAMP method must be supported
+     by clients but whether it is enabled by default may be determined on a
+     realm by realm basis. If not used in the initial request and the error
+     KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an
+     acceptable method, the client should retry the initial request using
+     the PA-ENC-TIMESTAMP preauthentication method. Servers need not
+     support the PA-ENC-TIMESTAMP method, but if not supported the server
+     should ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a
+     request.
+
+     Mutual authentication
+
+     Mutual authentication (via the KRB_AP_REP message) must be supported.
+
+     Ticket addresses and flags
+
+     All KDC's must pass on tickets that carry no addresses (i.e. if a TGT
+     contains no addresses, the KDC will return derivative tickets), but
+     each realm may set its own policy for issuing such tickets, and each
+     application server will set its own policy with respect to accepting
+     them.
+
+     Proxies and forwarded tickets must be supported. Individual realms and
+     application servers can set their own policy on when such tickets will
+     be accepted.
+
+     All implementations must recognize renewable and postdated tickets,
+     but need not actually implement them. If these options are not
+     supported, the starttime and endtime in the ticket shall specify a
+     ticket's entire useful life. When a postdated ticket is decoded by a
+     server, all implementations shall make the presence of the postdated
+     flag visible to the calling server.
+
+     User-to-user authentication
+
+     Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC
+     option) must be provided by implementations, but individual realms may
+     decide as a matter of policy to reject such requests on a
+     per-principal or realm-wide basis.
+
+     Authorization data
+
+     Implementations must pass all authorization data subfields from
+     ticket-granting tickets to any derivative tickets unless directed to
+     suppress a subfield as part of the definition of that registered
+     subfield type (it is never incorrect to pass on a subfield, and no
+     registered subfield types presently specify suppression at the KDC).
+
+     Implementations must make the contents of any authorization data
+     subfields available to the server when a ticket is used.
+     Implementations are not required to allow clients to specify the
+     contents of the authorization data fields.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     Constant ranges
+
+     All protocol constants are constrained to 32 bit (signed) values
+     unless further constrained by the protocol definition. This limit is
+     provided to allow implementations to make assumptions about the
+     maximum values that will be received for these constants.
+     Implementation receiving values outside this range may reject the
+     request, but they must recover cleanly.
+
+     9.2. Recommended KDC values
+
+     Following is a list of recommended values for a KDC implementation,
+     based on the list of suggested configuration constants (see section
+     4.4).
+
+     minimum lifetime              5 minutes
+     maximum renewable lifetime    1 week
+     maximum ticket lifetime       1 day
+     empty addresses               only when suitable  restrictions  appear
+                                   in authorization data
+     proxiable, etc.               Allowed.
+
+     10. REFERENCES
+
+     [NT94]    B. Clifford Neuman and Theodore Y. Ts'o, "An  Authenti-
+               cation  Service for Computer Networks," IEEE Communica-
+               tions Magazine, Vol. 32(9), pp. 33-38 (September 1994).
+
+     [MNSS87]  S. P. Miller, B. C. Neuman, J. I. Schiller, and  J.  H.
+               Saltzer,  Section  E.2.1:  Kerberos  Authentication and
+               Authorization System, M.I.T. Project Athena, Cambridge,
+               Massachusetts (December 21, 1987).
+
+     [SNS88]   J. G. Steiner, B. C. Neuman, and J. I. Schiller,  "Ker-
+               beros:  An Authentication Service for Open Network Sys-
+               tems," pp. 191-202 in  Usenix  Conference  Proceedings,
+               Dallas, Texas (February, 1988).
+
+     [NS78]    Roger M.  Needham  and  Michael  D.  Schroeder,  "Using
+               Encryption for Authentication in Large Networks of Com-
+               puters,"  Communications  of  the  ACM,  Vol.   21(12),
+               pp. 993-999 (December, 1978).
+
+     [DS81]    Dorothy E. Denning and  Giovanni  Maria  Sacco,  "Time-
+               stamps  in  Key Distribution Protocols," Communications
+               of the ACM, Vol. 24(8), pp. 533-536 (August 1981).
+
+     [KNT92]   John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o,
+               "The Evolution of the Kerberos Authentication Service,"
+               in an IEEE Computer Society Text soon to  be  published
+               (June 1992).
+
+     [Neu93]   B.  Clifford  Neuman,  "Proxy-Based  Authorization  and
+               Accounting  for Distributed Systems," in Proceedings of
+               the 13th International Conference on  Distributed  Com-
+               puting Systems, Pittsburgh, PA (May, 1993).
+
+     [DS90]    Don Davis and Ralph Swick,  "Workstation  Services  and
+               Kerberos  Authentication  at Project Athena," Technical
+               Memorandum TM-424,  MIT Laboratory for Computer Science
+               (February 1990).
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     [LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E.  Som-
+               merfeld,  and  K. Raeburn, Section E.1: Service Manage-
+               ment System, M.I.T.  Project  Athena,  Cambridge,  Mas-
+               sachusetts (1987).
+
+     [X509-88] CCITT, Recommendation X.509: The Directory  Authentica-
+               tion Framework, December 1988.
+
+     [Pat92].  J. Pato, Using  Pre-Authentication  to  Avoid  Password
+               Guessing  Attacks, Open Software Foundation DCE Request
+               for Comments 26 (December 1992).
+
+     [DES77]   National Bureau of Standards, U.S. Department  of  Com-
+               merce,  "Data Encryption Standard," Federal Information
+               Processing Standards Publication  46,   Washington,  DC
+               (1977).
+
+     [DESM80]  National Bureau of Standards, U.S. Department  of  Com-
+               merce,  "DES  Modes  of Operation," Federal Information
+               Processing Standards Publication 81,   Springfield,  VA
+               (December 1980).
+
+     [SG92]    Stuart G. Stubblebine and Virgil D. Gligor, "On Message
+               Integrity  in  Cryptographic Protocols," in Proceedings
+               of the IEEE  Symposium  on  Research  in  Security  and
+               Privacy, Oakland, California (May 1992).
+
+     [IS3309]  International Organization  for  Standardization,  "ISO
+               Information  Processing  Systems - Data Communication -
+               High-Level Data Link Control Procedure -  Frame  Struc-
+               ture," IS 3309 (October 1984).  3rd Edition.
+
+     [MD4-92]  R. Rivest, "The  MD4  Message  Digest  Algorithm,"  RFC
+               1320,   MIT  Laboratory  for  Computer  Science  (April
+               1992).
+
+     [MD5-92]  R. Rivest, "The  MD5  Message  Digest  Algorithm,"  RFC
+               1321,   MIT  Laboratory  for  Computer  Science  (April
+               1992).
+
+     [KBC96]   H. Krawczyk, M. Bellare, and R. Canetti, "HMAC:  Keyed-
+               Hashing  for  Message  Authentication,"  Working  Draft
+               draft-ietf-ipsec-hmac-md5-01.txt,   (August 1996).
+
+     [Horowitz96] Horowitz, M., "Key Derivation for Authentication,
+               Integrity, and Privacy",
+draft-horowitz-key-derivation-02.txt,
+               August 1998.
+
+     [HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft-
+               horowitz-kerb-key-derivation-01.txt, September 1998.
+
+     [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC:
+               Keyed-Hashing for Message Authentication",
+draft-ietf-ipsec-hmac-
+               md5-01.txt, August, 1996.
+
+     A. Pseudo-code for protocol processing
+
+     This appendix provides pseudo-code describing how the messages are to
+     be constructed and interpreted by clients and servers.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     A.1. KRB_AS_REQ generation
+
+             request.pvno := protocol version; /* pvno = 5 */
+             request.msg-type := message type; /* type = KRB_AS_REQ */
+
+             if(pa_enc_timestamp_required) then
+                     request.padata.padata-type = PA-ENC-TIMESTAMP;
+                     get system_time;
+                     padata-body.patimestamp,pausec = system_time;
+                     encrypt padata-body into request.padata.padata-value
+                             using client.key; /* derived from password */
+             endif
+
+             body.kdc-options := users's preferences;
+             body.cname := user's name;
+             body.realm := user's realm;
+             body.sname := service's name; /* usually "krbtgt",
+"localrealm" */
+             if (body.kdc-options.POSTDATED is set) then
+                     body.from := requested starting time;
+             else
+                     omit body.from;
+             endif
+             body.till := requested end time;
+             if (body.kdc-options.RENEWABLE is set) then
+                     body.rtime := requested final renewal time;
+             endif
+             body.nonce := random_nonce();
+             body.etype := requested etypes;
+             if (user supplied addresses) then
+                     body.addresses := user's addresses;
+             else
+                     omit body.addresses;
+             endif
+             omit body.enc-authorization-data;
+             request.req-body := body;
+
+             kerberos := lookup(name of local kerberos server (or servers));
+             send(packet,kerberos);
+
+             wait(for response);
+             if (timed_out) then
+                     retry or use alternate server;
+             endif
+
+     A.2. KRB_AS_REQ verification and KRB_AS_REP generation
+
+             decode message into req;
+
+             client := lookup(req.cname,req.realm);
+             server := lookup(req.sname,req.realm);
+
+             get system_time;
+             kdc_time := system_time.seconds;
+
+             if (!client) then
+                     /* no client in Database */
+                     error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
+             endif
+             if (!server) then
+                     /* no server in Database */
+                     error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
+             endif
+
+             if(client.pa_enc_timestamp_required and
+                pa_enc_timestamp not present) then
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                     error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
+             endif
+
+             if(pa_enc_timestamp present) then
+                     decrypt req.padata-value into decrypted_enc_timestamp
+                             using client.key;
+                             using auth_hdr.authenticator.subkey;
+                     if (decrypt_error()) then
+                             error_out(KRB_AP_ERR_BAD_INTEGRITY);
+                     if(decrypted_enc_timestamp is not within allowable
+skew) then
+                             error_out(KDC_ERR_PREAUTH_FAILED);
+                     endif
+                     if(decrypted_enc_timestamp and usec is replay)
+                             error_out(KDC_ERR_PREAUTH_FAILED);
+                     endif
+                     add decrypted_enc_timestamp and usec to replay cache;
+             endif
+
+             use_etype := first supported etype in req.etypes;
+
+             if (no support for req.etypes) then
+                     error_out(KDC_ERR_ETYPE_NOSUPP);
+             endif
+
+             new_tkt.vno := ticket version; /* = 5 */
+             new_tkt.sname := req.sname;
+             new_tkt.srealm := req.srealm;
+             reset all flags in new_tkt.flags;
+
+             /* It should be noted that local policy may affect the  */
+             /* processing of any of these flags.  For example, some */
+             /* realms may refuse to issue renewable tickets         */
+
+             if (req.kdc-options.FORWARDABLE is set) then
+                     set new_tkt.flags.FORWARDABLE;
+             endif
+             if (req.kdc-options.PROXIABLE is set) then
+                     set new_tkt.flags.PROXIABLE;
+             endif
+
+             if (req.kdc-options.ALLOW-POSTDATE is set) then
+                     set new_tkt.flags.MAY-POSTDATE;
+             endif
+             if ((req.kdc-options.RENEW is set) or
+                 (req.kdc-options.VALIDATE is set) or
+                 (req.kdc-options.PROXY is set) or
+                 (req.kdc-options.FORWARDED is set) or
+                 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then
+                     error_out(KDC_ERR_BADOPTION);
+             endif
+
+             new_tkt.session := random_session_key();
+             new_tkt.cname := req.cname;
+             new_tkt.crealm := req.crealm;
+             new_tkt.transited := empty_transited_field();
+
+             new_tkt.authtime := kdc_time;
+
+             if (req.kdc-options.POSTDATED is set) then
+                if (against_postdate_policy(req.from)) then
+                     error_out(KDC_ERR_POLICY);
+                endif
+                set new_tkt.flags.POSTDATED;
+                set new_tkt.flags.INVALID;
+                new_tkt.starttime := req.from;
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+             else
+                omit new_tkt.starttime; /* treated as authtime when omitted
+*/
+             endif
+             if (req.till = 0) then
+                     till := infinity;
+             else
+                     till := req.till;
+             endif
+
+             new_tkt.endtime := min(till,
+                                   new_tkt.starttime+client.max_life,
+                                   new_tkt.starttime+server.max_life,
+                                   new_tkt.starttime+max_life_for_realm);
+
+             if ((req.kdc-options.RENEWABLE-OK is set) and
+                 (new_tkt.endtime < req.till)) then
+                     /* we set the RENEWABLE option for later processing */
+                     set req.kdc-options.RENEWABLE;
+                     req.rtime := req.till;
+             endif
+
+             if (req.rtime = 0) then
+                     rtime := infinity;
+             else
+                     rtime := req.rtime;
+             endif
+
+             if (req.kdc-options.RENEWABLE is set) then
+                     set new_tkt.flags.RENEWABLE;
+                     new_tkt.renew-till := min(rtime,
+
+new_tkt.starttime+client.max_rlife,
+
+new_tkt.starttime+server.max_rlife,
+
+new_tkt.starttime+max_rlife_for_realm);
+             else
+                     omit new_tkt.renew-till; /* only present if RENEWABLE
+*/
+             endif
+
+             if (req.addresses) then
+                     new_tkt.caddr := req.addresses;
+             else
+                     omit new_tkt.caddr;
+             endif
+
+             new_tkt.authorization_data := empty_authorization_data();
+
+             encode to-be-encrypted part of ticket into OCTET STRING;
+             new_tkt.enc-part := encrypt OCTET STRING
+                     using etype_for_key(server.key), server.key,
+server.p_kvno;
+
+             /* Start processing the response */
+
+             resp.pvno := 5;
+             resp.msg-type := KRB_AS_REP;
+             resp.cname := req.cname;
+             resp.crealm := req.realm;
+             resp.ticket := new_tkt;
+
+             resp.key := new_tkt.session;
+             resp.last-req := fetch_last_request_info(client);
+             resp.nonce := req.nonce;
+             resp.key-expiration := client.expiration;
+             resp.flags := new_tkt.flags;
+
+             resp.authtime := new_tkt.authtime;
+             resp.starttime := new_tkt.starttime;
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+             resp.endtime := new_tkt.endtime;
+
+             if (new_tkt.flags.RENEWABLE) then
+                     resp.renew-till := new_tkt.renew-till;
+             endif
+
+             resp.realm := new_tkt.realm;
+             resp.sname := new_tkt.sname;
+
+             resp.caddr := new_tkt.caddr;
+
+             encode body of reply into OCTET STRING;
+
+             resp.enc-part := encrypt OCTET STRING
+                              using use_etype, client.key, client.p_kvno;
+             send(resp);
+
+     A.3. KRB_AS_REP verification
+
+             decode response into resp;
+
+             if (resp.msg-type = KRB_ERROR) then
+                     if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP))
+then
+                             set pa_enc_timestamp_required;
+                             goto KRB_AS_REQ;
+                     endif
+                     process_error(resp);
+                     return;
+             endif
+
+             /* On error, discard the response, and zero the session key */
+             /* from the response immediately */
+
+             key = get_decryption_key(resp.enc-part.kvno,
+resp.enc-part.etype,
+                                      resp.padata);
+             unencrypted part of resp := decode of decrypt of resp.enc-part
+                                     using resp.enc-part.etype and key;
+             zero(key);
+
+             if (common_as_rep_tgs_rep_checks fail) then
+                     destroy resp.key;
+                     return error;
+             endif
+
+             if near(resp.princ_exp) then
+                     print(warning message);
+             endif
+             save_for_later(ticket,session,client,server,times,flags);
+
+     A.4. KRB_AS_REP and KRB_TGS_REP common checks
+
+             if (decryption_error() or
+                 (req.cname != resp.cname) or
+                 (req.realm != resp.crealm) or
+                 (req.sname != resp.sname) or
+                 (req.realm != resp.realm) or
+                 (req.nonce != resp.nonce) or
+                 (req.addresses != resp.caddr)) then
+                     destroy resp.key;
+                     return KRB_AP_ERR_MODIFIED;
+             endif
+
+             /* make sure no flags are set that shouldn't be, and that all
+that */
+             /* should be are set
+*/
+             if (!check_flags_for_compatability(req.kdc-options,resp.flags))
+then
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                     destroy resp.key;
+                     return KRB_AP_ERR_MODIFIED;
+             endif
+
+             if ((req.from = 0) and
+                 (resp.starttime is not within allowable skew)) then
+                     destroy resp.key;
+                     return KRB_AP_ERR_SKEW;
+             endif
+             if ((req.from != 0) and (req.from != resp.starttime)) then
+                     destroy resp.key;
+                     return KRB_AP_ERR_MODIFIED;
+             endif
+             if ((req.till != 0) and (resp.endtime > req.till)) then
+                     destroy resp.key;
+                     return KRB_AP_ERR_MODIFIED;
+             endif
+
+             if ((req.kdc-options.RENEWABLE is set) and
+                 (req.rtime != 0) and (resp.renew-till > req.rtime)) then
+                     destroy resp.key;
+                     return KRB_AP_ERR_MODIFIED;
+             endif
+             if ((req.kdc-options.RENEWABLE-OK is set) and
+                 (resp.flags.RENEWABLE) and
+                 (req.till != 0) and
+                 (resp.renew-till > req.till)) then
+                     destroy resp.key;
+                     return KRB_AP_ERR_MODIFIED;
+             endif
+
+     A.5. KRB_TGS_REQ generation
+
+             /* Note that make_application_request might have to recursivly
+*/
+             /* call this routine to get the appropriate ticket-granting
+ticket */
+
+             request.pvno := protocol version; /* pvno = 5 */
+             request.msg-type := message type; /* type = KRB_TGS_REQ */
+
+             body.kdc-options := users's preferences;
+             /* If the TGT is not for the realm of the end-server  */
+             /* then the sname will be for a TGT for the end-realm */
+             /* and the realm of the requested ticket (body.realm) */
+             /* will be that of the TGS to which the TGT we are    */
+             /* sending applies                                    */
+             body.sname := service's name;
+             body.realm := service's realm;
+
+             if (body.kdc-options.POSTDATED is set) then
+                     body.from := requested starting time;
+             else
+                     omit body.from;
+             endif
+             body.till := requested end time;
+             if (body.kdc-options.RENEWABLE is set) then
+                     body.rtime := requested final renewal time;
+             endif
+             body.nonce := random_nonce();
+             body.etype := requested etypes;
+             if (user supplied addresses) then
+                     body.addresses := user's addresses;
+             else
+                     omit body.addresses;
+             endif
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+             body.enc-authorization-data := user-supplied data;
+             if (body.kdc-options.ENC-TKT-IN-SKEY) then
+                     body.additional-tickets_ticket := second TGT;
+             endif
+
+             request.req-body := body;
+             check := generate_checksum (req.body,checksumtype);
+
+             request.padata[0].padata-type := PA-TGS-REQ;
+             request.padata[0].padata-value := create a KRB_AP_REQ using
+                                           the TGT and checksum
+
+             /* add in any other padata as required/supplied */
+
+             kerberos := lookup(name of local kerberose server (or
+servers));
+             send(packet,kerberos);
+
+             wait(for response);
+             if (timed_out) then
+                     retry or use alternate server;
+             endif
+
+     A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation
+
+             /* note that reading the application request requires first
+             determining the server for which a ticket was issued, and
+choosing the
+             correct key for decryption.  The name of the server appears in
+the
+             plaintext part of the ticket. */
+
+             if (no KRB_AP_REQ in req.padata) then
+                     error_out(KDC_ERR_PADATA_TYPE_NOSUPP);
+             endif
+             verify KRB_AP_REQ in req.padata;
+
+             /* Note that the realm in which the Kerberos server is
+operating is
+             determined by the instance from the ticket-granting ticket.
+The realm
+             in the ticket-granting ticket is the realm under which the
+ticket
+             granting ticket was issued.  It is possible for a single
+Kerberos
+             server to support more than one realm. */
+
+             auth_hdr := KRB_AP_REQ;
+             tgt := auth_hdr.ticket;
+
+             if (tgt.sname is not a TGT for local realm and is not
+req.sname) then
+                     error_out(KRB_AP_ERR_NOT_US);
+
+             realm := realm_tgt_is_for(tgt);
+
+             decode remainder of request;
+
+             if (auth_hdr.authenticator.cksum is missing) then
+                     error_out(KRB_AP_ERR_INAPP_CKSUM);
+             endif
+
+             if (auth_hdr.authenticator.cksum type is not supported) then
+                     error_out(KDC_ERR_SUMTYPE_NOSUPP);
+             endif
+             if (auth_hdr.authenticator.cksum is not both collision-proof
+and keyed) then
+                     error_out(KRB_AP_ERR_INAPP_CKSUM);
+             endif
+
+             set computed_checksum := checksum(req);
+             if (computed_checksum != auth_hdr.authenticatory.cksum) then
+                     error_out(KRB_AP_ERR_MODIFIED);
+             endif
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+
+             server := lookup(req.sname,realm);
+
+             if (!server) then
+                     if (is_foreign_tgt_name(req.sname)) then
+                             server := best_intermediate_tgs(req.sname);
+                     else
+                             /* no server in Database */
+                             error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
+                     endif
+             endif
+
+             session := generate_random_session_key();
+
+             use_etype := first supported etype in req.etypes;
+
+             if (no support for req.etypes) then
+                     error_out(KDC_ERR_ETYPE_NOSUPP);
+             endif
+
+             new_tkt.vno := ticket version; /* = 5 */
+             new_tkt.sname := req.sname;
+             new_tkt.srealm := realm;
+             reset all flags in new_tkt.flags;
+
+             /* It should be noted that local policy may affect the  */
+             /* processing of any of these flags.  For example, some */
+             /* realms may refuse to issue renewable tickets         */
+
+             new_tkt.caddr := tgt.caddr;
+             resp.caddr := NULL; /* We only include this if they change */
+             if (req.kdc-options.FORWARDABLE is set) then
+                     if (tgt.flags.FORWARDABLE is reset) then
+                             error_out(KDC_ERR_BADOPTION);
+                     endif
+                     set new_tkt.flags.FORWARDABLE;
+             endif
+             if (req.kdc-options.FORWARDED is set) then
+                     if (tgt.flags.FORWARDABLE is reset) then
+                             error_out(KDC_ERR_BADOPTION);
+                     endif
+                     set new_tkt.flags.FORWARDED;
+                     new_tkt.caddr := req.addresses;
+                     resp.caddr := req.addresses;
+             endif
+             if (tgt.flags.FORWARDED is set) then
+                     set new_tkt.flags.FORWARDED;
+             endif
+
+             if (req.kdc-options.PROXIABLE is set) then
+                     if (tgt.flags.PROXIABLE is reset)
+                             error_out(KDC_ERR_BADOPTION);
+                     endif
+                     set new_tkt.flags.PROXIABLE;
+             endif
+             if (req.kdc-options.PROXY is set) then
+                     if (tgt.flags.PROXIABLE is reset) then
+                             error_out(KDC_ERR_BADOPTION);
+                     endif
+                     set new_tkt.flags.PROXY;
+                     new_tkt.caddr := req.addresses;
+                     resp.caddr := req.addresses;
+             endif
+
+             if (req.kdc-options.ALLOW-POSTDATE is set) then
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                     if (tgt.flags.MAY-POSTDATE is reset)
+                             error_out(KDC_ERR_BADOPTION);
+                     endif
+                     set new_tkt.flags.MAY-POSTDATE;
+             endif
+             if (req.kdc-options.POSTDATED is set) then
+                     if (tgt.flags.MAY-POSTDATE is reset) then
+                             error_out(KDC_ERR_BADOPTION);
+                     endif
+                     set new_tkt.flags.POSTDATED;
+                     set new_tkt.flags.INVALID;
+                     if (against_postdate_policy(req.from)) then
+                             error_out(KDC_ERR_POLICY);
+                     endif
+                     new_tkt.starttime := req.from;
+             endif
+
+             if (req.kdc-options.VALIDATE is set) then
+                     if (tgt.flags.INVALID is reset) then
+                             error_out(KDC_ERR_POLICY);
+                     endif
+                     if (tgt.starttime > kdc_time) then
+                             error_out(KRB_AP_ERR_NYV);
+                     endif
+                     if (check_hot_list(tgt)) then
+                             error_out(KRB_AP_ERR_REPEAT);
+                     endif
+                     tkt := tgt;
+                     reset new_tkt.flags.INVALID;
+             endif
+
+             if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW,
+                                  and those already processed) is set) then
+                     error_out(KDC_ERR_BADOPTION);
+             endif
+
+             new_tkt.authtime := tgt.authtime;
+
+             if (req.kdc-options.RENEW is set) then
+               /* Note that if the endtime has already passed, the ticket
+would  */
+               /* have been rejected in the initial authentication stage, so
+*/
+               /* there is no need to check again here
+*/
+                     if (tgt.flags.RENEWABLE is reset) then
+                             error_out(KDC_ERR_BADOPTION);
+                     endif
+                     if (tgt.renew-till < kdc_time) then
+                             error_out(KRB_AP_ERR_TKT_EXPIRED);
+                     endif
+                     tkt := tgt;
+                     new_tkt.starttime := kdc_time;
+                     old_life := tgt.endttime - tgt.starttime;
+                     new_tkt.endtime := min(tgt.renew-till,
+                                            new_tkt.starttime + old_life);
+             else
+                     new_tkt.starttime := kdc_time;
+                     if (req.till = 0) then
+                             till := infinity;
+                     else
+                             till := req.till;
+                     endif
+                     new_tkt.endtime := min(till,
+
+new_tkt.starttime+client.max_life,
+
+new_tkt.starttime+server.max_life,
+
+new_tkt.starttime+max_life_for_realm,
+                                            tgt.endtime);
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+
+                     if ((req.kdc-options.RENEWABLE-OK is set) and
+                         (new_tkt.endtime < req.till) and
+                         (tgt.flags.RENEWABLE is set) then
+                             /* we set the RENEWABLE option for later
+processing */
+                             set req.kdc-options.RENEWABLE;
+                             req.rtime := min(req.till, tgt.renew-till);
+                     endif
+             endif
+
+             if (req.rtime = 0) then
+                     rtime := infinity;
+             else
+                     rtime := req.rtime;
+             endif
+
+             if ((req.kdc-options.RENEWABLE is set) and
+                 (tgt.flags.RENEWABLE is set)) then
+                     set new_tkt.flags.RENEWABLE;
+                     new_tkt.renew-till := min(rtime,
+
+new_tkt.starttime+client.max_rlife,
+
+new_tkt.starttime+server.max_rlife,
+
+new_tkt.starttime+max_rlife_for_realm,
+                                               tgt.renew-till);
+             else
+                     new_tkt.renew-till := OMIT; /* leave the renew-till
+field out */
+             endif
+             if (req.enc-authorization-data is present) then
+                     decrypt req.enc-authorization-data into
+decrypted_authorization_data
+                             using auth_hdr.authenticator.subkey;
+                     if (decrypt_error()) then
+                             error_out(KRB_AP_ERR_BAD_INTEGRITY);
+                     endif
+             endif
+             new_tkt.authorization_data :=
+req.auth_hdr.ticket.authorization_data +
+                                      decrypted_authorization_data;
+
+             new_tkt.key := session;
+             new_tkt.crealm := tgt.crealm;
+             new_tkt.cname := req.auth_hdr.ticket.cname;
+
+             if (realm_tgt_is_for(tgt) := tgt.realm) then
+                     /* tgt issued by local realm */
+                     new_tkt.transited := tgt.transited;
+             else
+                     /* was issued for this realm by some other realm */
+                     if (tgt.transited.tr-type not supported) then
+                             error_out(KDC_ERR_TRTYPE_NOSUPP);
+                     endif
+                     new_tkt.transited := compress_transited(tgt.transited +
+tgt.realm)
+                     /* Don't check tranited field if TGT for foreign realm,
+                      * or requested not to check */
+                     if (is_not_foreign_tgt_name(new_tkt.server)
+                        && req.kdc-options.DISABLE-TRANSITED-CHECK not set)
+then
+                             /* Check it, so end-server does not have to
+                              * but don't fail, end-server may still accept
+it */
+                             if (check_transited_field(new_tkt.transited) ==
+OK)
+                                   set
+new_tkt.flags.TRANSITED-POLICY-CHECKED;
+                             endif
+                     endif
+             endif
+
+             encode encrypted part of new_tkt into OCTET STRING;
+             if (req.kdc-options.ENC-TKT-IN-SKEY is set) then
+                     if (server not specified) then
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                             server = req.second_ticket.client;
+                     endif
+                     if ((req.second_ticket is not a TGT) or
+                         (req.second_ticket.client != server)) then
+                             error_out(KDC_ERR_POLICY);
+                     endif
+
+                     new_tkt.enc-part := encrypt OCTET STRING using
+                             using etype_for_key(second-ticket.key),
+second-ticket.key;
+             else
+                     new_tkt.enc-part := encrypt OCTET STRING
+                             using etype_for_key(server.key), server.key,
+server.p_kvno;
+             endif
+
+             resp.pvno := 5;
+             resp.msg-type := KRB_TGS_REP;
+             resp.crealm := tgt.crealm;
+             resp.cname := tgt.cname;
+             resp.ticket := new_tkt;
+
+             resp.key := session;
+             resp.nonce := req.nonce;
+             resp.last-req := fetch_last_request_info(client);
+             resp.flags := new_tkt.flags;
+
+             resp.authtime := new_tkt.authtime;
+             resp.starttime := new_tkt.starttime;
+             resp.endtime := new_tkt.endtime;
+
+             omit resp.key-expiration;
+
+             resp.sname := new_tkt.sname;
+             resp.realm := new_tkt.realm;
+
+             if (new_tkt.flags.RENEWABLE) then
+                     resp.renew-till := new_tkt.renew-till;
+             endif
+
+             encode body of reply into OCTET STRING;
+
+             if (req.padata.authenticator.subkey)
+                     resp.enc-part := encrypt OCTET STRING using use_etype,
+                             req.padata.authenticator.subkey;
+             else resp.enc-part := encrypt OCTET STRING using use_etype,
+tgt.key;
+
+             send(resp);
+
+     A.7. KRB_TGS_REP verification
+
+             decode response into resp;
+
+             if (resp.msg-type = KRB_ERROR) then
+                     process_error(resp);
+                     return;
+             endif
+
+             /* On error, discard the response, and zero the session key
+from
+             the response immediately */
+
+             if (req.padata.authenticator.subkey)
+                     unencrypted part of resp := decode of decrypt of
+resp.enc-part
+                             using resp.enc-part.etype and subkey;
+             else unencrypted part of resp := decode of decrypt of
+resp.enc-part
+                                     using resp.enc-part.etype and tgt's
+session key;
+             if (common_as_rep_tgs_rep_checks fail) then
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                     destroy resp.key;
+                     return error;
+             endif
+
+             check authorization_data as necessary;
+             save_for_later(ticket,session,client,server,times,flags);
+
+     A.8. Authenticator generation
+
+             body.authenticator-vno := authenticator vno; /* = 5 */
+             body.cname, body.crealm := client name;
+             if (supplying checksum) then
+                     body.cksum := checksum;
+             endif
+             get system_time;
+             body.ctime, body.cusec := system_time;
+             if (selecting sub-session key) then
+                     select sub-session key;
+                     body.subkey := sub-session key;
+             endif
+             if (using sequence numbers) then
+                     select initial sequence number;
+                     body.seq-number := initial sequence;
+             endif
+
+     A.9. KRB_AP_REQ generation
+
+             obtain ticket and session_key from cache;
+
+             packet.pvno := protocol version; /* 5 */
+             packet.msg-type := message type; /* KRB_AP_REQ */
+
+             if (desired(MUTUAL_AUTHENTICATION)) then
+                     set packet.ap-options.MUTUAL-REQUIRED;
+             else
+                     reset packet.ap-options.MUTUAL-REQUIRED;
+             endif
+             if (using session key for ticket) then
+                     set packet.ap-options.USE-SESSION-KEY;
+             else
+                     reset packet.ap-options.USE-SESSION-KEY;
+             endif
+             packet.ticket := ticket; /* ticket */
+             generate authenticator;
+             encode authenticator into OCTET STRING;
+             encrypt OCTET STRING into packet.authenticator using
+session_key;
+
+     A.10. KRB_AP_REQ verification
+
+             receive packet;
+             if (packet.pvno != 5) then
+                     either process using other protocol spec
+                     or error_out(KRB_AP_ERR_BADVERSION);
+             endif
+             if (packet.msg-type != KRB_AP_REQ) then
+                     error_out(KRB_AP_ERR_MSG_TYPE);
+             endif
+             if (packet.ticket.tkt_vno != 5) then
+                     either process using other protocol spec
+                     or error_out(KRB_AP_ERR_BADVERSION);
+             endif
+             if (packet.ap_options.USE-SESSION-KEY is set) then
+                     retrieve session key from ticket-granting ticket for
+                      packet.ticket.{sname,srealm,enc-part.etype};
+             else
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                     retrieve service key for
+
+packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno};
+             endif
+             if (no_key_available) then
+                     if (cannot_find_specified_skvno) then
+                             error_out(KRB_AP_ERR_BADKEYVER);
+                     else
+                             error_out(KRB_AP_ERR_NOKEY);
+                     endif
+             endif
+             decrypt packet.ticket.enc-part into decr_ticket using retrieved
+key;
+             if (decryption_error()) then
+                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
+             endif
+             decrypt packet.authenticator into decr_authenticator
+                     using decr_ticket.key;
+             if (decryption_error()) then
+                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
+             endif
+             if (decr_authenticator.{cname,crealm} !=
+                 decr_ticket.{cname,crealm}) then
+                     error_out(KRB_AP_ERR_BADMATCH);
+             endif
+             if (decr_ticket.caddr is present) then
+                     if (sender_address(packet) is not in decr_ticket.caddr)
+then
+                             error_out(KRB_AP_ERR_BADADDR);
+                     endif
+             elseif (application requires addresses) then
+                     error_out(KRB_AP_ERR_BADADDR);
+             endif
+             if (not in_clock_skew(decr_authenticator.ctime,
+                                   decr_authenticator.cusec)) then
+                     error_out(KRB_AP_ERR_SKEW);
+             endif
+             if (repeated(decr_authenticator.{ctime,cusec,cname,crealm}))
+then
+                     error_out(KRB_AP_ERR_REPEAT);
+             endif
+             save_identifier(decr_authenticator.{ctime,cusec,cname,crealm});
+             get system_time;
+             if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or
+                 (decr_ticket.flags.INVALID is set)) then
+                     /* it hasn't yet become valid */
+                     error_out(KRB_AP_ERR_TKT_NYV);
+             endif
+             if (system_time-decr_ticket.endtime > CLOCK_SKEW) then
+                     error_out(KRB_AP_ERR_TKT_EXPIRED);
+             endif
+             if (decr_ticket.transited) then
+                 /* caller may ignore the TRANSITED-POLICY-CHECKED and do
+                  * check anyway */
+                 if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set)
+then
+                      if (check_transited_field(decr_ticket.transited) then
+                           error_out(KDC_AP_PATH_NOT_ACCPETED);
+                      endif
+                 endif
+             endif
+             /* caller must check decr_ticket.flags for any pertinent
+details */
+             return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED);
+
+     A.11. KRB_AP_REP generation
+
+             packet.pvno := protocol version; /* 5 */
+             packet.msg-type := message type; /* KRB_AP_REP */
+
+             body.ctime := packet.ctime;
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+             body.cusec := packet.cusec;
+             if (selecting sub-session key) then
+                     select sub-session key;
+                     body.subkey := sub-session key;
+             endif
+             if (using sequence numbers) then
+                     select initial sequence number;
+                     body.seq-number := initial sequence;
+             endif
+
+             encode body into OCTET STRING;
+
+             select encryption type;
+             encrypt OCTET STRING into packet.enc-part;
+
+     A.12. KRB_AP_REP verification
+
+             receive packet;
+             if (packet.pvno != 5) then
+                     either process using other protocol spec
+                     or error_out(KRB_AP_ERR_BADVERSION);
+             endif
+             if (packet.msg-type != KRB_AP_REP) then
+                     error_out(KRB_AP_ERR_MSG_TYPE);
+             endif
+             cleartext := decrypt(packet.enc-part) using ticket's session
+key;
+             if (decryption_error()) then
+                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
+             endif
+             if (cleartext.ctime != authenticator.ctime) then
+                     error_out(KRB_AP_ERR_MUT_FAIL);
+             endif
+             if (cleartext.cusec != authenticator.cusec) then
+                     error_out(KRB_AP_ERR_MUT_FAIL);
+             endif
+             if (cleartext.subkey is present) then
+                     save cleartext.subkey for future use;
+             endif
+             if (cleartext.seq-number is present) then
+                     save cleartext.seq-number for future verifications;
+             endif
+             return(AUTHENTICATION_SUCCEEDED);
+
+     A.13. KRB_SAFE generation
+
+             collect user data in buffer;
+
+             /* assemble packet: */
+             packet.pvno := protocol version; /* 5 */
+             packet.msg-type := message type; /* KRB_SAFE */
+
+             body.user-data := buffer; /* DATA */
+             if (using timestamp) then
+                     get system_time;
+                     body.timestamp, body.usec := system_time;
+             endif
+             if (using sequence numbers) then
+                     body.seq-number := sequence number;
+             endif
+             body.s-address := sender host addresses;
+             if (only one recipient) then
+                     body.r-address := recipient host address;
+             endif
+             checksum.cksumtype := checksum type;
+             compute checksum over body;
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+             checksum.checksum := checksum value; /* checksum.checksum */
+             packet.cksum := checksum;
+             packet.safe-body := body;
+
+     A.14. KRB_SAFE verification
+
+             receive packet;
+             if (packet.pvno != 5) then
+                     either process using other protocol spec
+                     or error_out(KRB_AP_ERR_BADVERSION);
+             endif
+             if (packet.msg-type != KRB_SAFE) then
+                     error_out(KRB_AP_ERR_MSG_TYPE);
+             endif
+             if (packet.checksum.cksumtype is not both collision-proof and
+keyed) then
+                     error_out(KRB_AP_ERR_INAPP_CKSUM);
+             endif
+             if (safe_priv_common_checks_ok(packet)) then
+                     set computed_checksum := checksum(packet.body);
+                     if (computed_checksum != packet.checksum) then
+                             error_out(KRB_AP_ERR_MODIFIED);
+                     endif
+                     return (packet, PACKET_IS_GENUINE);
+             else
+                     return common_checks_error;
+             endif
+
+     A.15. KRB_SAFE and KRB_PRIV common checks
+
+             if (packet.s-address != O/S_sender(packet)) then
+                     /* O/S report of sender not who claims to have sent it
+*/
+                     error_out(KRB_AP_ERR_BADADDR);
+             endif
+             if ((packet.r-address is present) and
+                 (packet.r-address != local_host_address)) then
+                     /* was not sent to proper place */
+                     error_out(KRB_AP_ERR_BADADDR);
+             endif
+             if (((packet.timestamp is present) and
+                  (not in_clock_skew(packet.timestamp,packet.usec))) or
+                 (packet.timestamp is not present and timestamp expected))
+then
+                     error_out(KRB_AP_ERR_SKEW);
+             endif
+             if (repeated(packet.timestamp,packet.usec,packet.s-address))
+then
+                     error_out(KRB_AP_ERR_REPEAT);
+             endif
+
+             if (((packet.seq-number is present) and
+                  ((not in_sequence(packet.seq-number)))) or
+                 (packet.seq-number is not present and sequence expected))
+then
+                     error_out(KRB_AP_ERR_BADORDER);
+             endif
+             if (packet.timestamp not present and packet.seq-number not
+present) then
+                     error_out(KRB_AP_ERR_MODIFIED);
+             endif
+
+             save_identifier(packet.{timestamp,usec,s-address},
+                             sender_principal(packet));
+
+             return PACKET_IS_OK;
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     A.16. KRB_PRIV generation
+
+             collect user data in buffer;
+
+             /* assemble packet: */
+             packet.pvno := protocol version; /* 5 */
+             packet.msg-type := message type; /* KRB_PRIV */
+
+             packet.enc-part.etype := encryption type;
+
+             body.user-data := buffer;
+             if (using timestamp) then
+                     get system_time;
+                     body.timestamp, body.usec := system_time;
+             endif
+             if (using sequence numbers) then
+                     body.seq-number := sequence number;
+             endif
+             body.s-address := sender host addresses;
+             if (only one recipient) then
+                     body.r-address := recipient host address;
+             endif
+
+             encode body into OCTET STRING;
+
+             select encryption type;
+             encrypt OCTET STRING into packet.enc-part.cipher;
+
+     A.17. KRB_PRIV verification
+
+             receive packet;
+             if (packet.pvno != 5) then
+                     either process using other protocol spec
+                     or error_out(KRB_AP_ERR_BADVERSION);
+             endif
+             if (packet.msg-type != KRB_PRIV) then
+                     error_out(KRB_AP_ERR_MSG_TYPE);
+             endif
+
+             cleartext := decrypt(packet.enc-part) using negotiated key;
+             if (decryption_error()) then
+                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
+             endif
+
+             if (safe_priv_common_checks_ok(cleartext)) then
+                     return(cleartext.DATA,
+PACKET_IS_GENUINE_AND_UNMODIFIED);
+             else
+                     return common_checks_error;
+             endif
+
+     A.18. KRB_CRED generation
+
+             invoke KRB_TGS; /* obtain tickets to be provided to peer */
+
+             /* assemble packet: */
+             packet.pvno := protocol version; /* 5 */
+             packet.msg-type := message type; /* KRB_CRED */
+
+             for (tickets[n] in tickets to be forwarded) do
+                     packet.tickets[n] = tickets[n].ticket;
+             done
+
+             packet.enc-part.etype := encryption type;
+
+             for (ticket[n] in tickets to be forwarded) do
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                     body.ticket-info[n].key = tickets[n].session;
+                     body.ticket-info[n].prealm = tickets[n].crealm;
+                     body.ticket-info[n].pname = tickets[n].cname;
+                     body.ticket-info[n].flags = tickets[n].flags;
+                     body.ticket-info[n].authtime = tickets[n].authtime;
+                     body.ticket-info[n].starttime = tickets[n].starttime;
+                     body.ticket-info[n].endtime = tickets[n].endtime;
+                     body.ticket-info[n].renew-till = tickets[n].renew-till;
+                     body.ticket-info[n].srealm = tickets[n].srealm;
+                     body.ticket-info[n].sname = tickets[n].sname;
+                     body.ticket-info[n].caddr = tickets[n].caddr;
+             done
+
+             get system_time;
+             body.timestamp, body.usec := system_time;
+
+             if (using nonce) then
+                     body.nonce := nonce;
+             endif
+
+             if (using s-address) then
+                     body.s-address := sender host addresses;
+             endif
+             if (limited recipients) then
+                     body.r-address := recipient host address;
+             endif
+
+             encode body into OCTET STRING;
+
+             select encryption type;
+             encrypt OCTET STRING into packet.enc-part.cipher
+                    using negotiated encryption key;
+
+     A.19. KRB_CRED verification
+
+             receive packet;
+             if (packet.pvno != 5) then
+                     either process using other protocol spec
+                     or error_out(KRB_AP_ERR_BADVERSION);
+             endif
+             if (packet.msg-type != KRB_CRED) then
+                     error_out(KRB_AP_ERR_MSG_TYPE);
+             endif
+
+             cleartext := decrypt(packet.enc-part) using negotiated key;
+             if (decryption_error()) then
+                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
+             endif
+             if ((packet.r-address is present or required) and
+                (packet.s-address != O/S_sender(packet)) then
+                     /* O/S report of sender not who claims to have sent it
+*/
+                     error_out(KRB_AP_ERR_BADADDR);
+             endif
+             if ((packet.r-address is present) and
+                 (packet.r-address != local_host_address)) then
+                     /* was not sent to proper place */
+                     error_out(KRB_AP_ERR_BADADDR);
+             endif
+             if (not in_clock_skew(packet.timestamp,packet.usec)) then
+                     error_out(KRB_AP_ERR_SKEW);
+             endif
+             if (repeated(packet.timestamp,packet.usec,packet.s-address))
+then
+                     error_out(KRB_AP_ERR_REPEAT);
+             endif
+             if (packet.nonce is required or present) and
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+                (packet.nonce != expected-nonce) then
+                     error_out(KRB_AP_ERR_MODIFIED);
+             endif
+
+             for (ticket[n] in tickets that were forwarded) do
+                     save_for_later(ticket[n],key[n],principal[n],
+                                    server[n],times[n],flags[n]);
+             return
+
+     A.20. KRB_ERROR generation
+
+             /* assemble packet: */
+             packet.pvno := protocol version; /* 5 */
+             packet.msg-type := message type; /* KRB_ERROR */
+
+             get system_time;
+             packet.stime, packet.susec := system_time;
+             packet.realm, packet.sname := server name;
+
+             if (client time available) then
+                     packet.ctime, packet.cusec := client_time;
+             endif
+             packet.error-code := error code;
+             if (client name available) then
+                     packet.cname, packet.crealm := client name;
+             endif
+             if (error text available) then
+                     packet.e-text := error text;
+             endif
+             if (error data available) then
+                     packet.e-data := error data;
+             endif
+
+     B. Definition of common authorization data elements
+
+     This appendix contains the definitions of common authorization data
+     elements. These common authorization data elements are recursivly
+     defined, meaning the ad-data for these types will itself contain a
+     sequence of authorization data whose interpretation is affected by the
+     encapsulating element. Depending on the meaning of the encapsulating
+     element, the encapsulated elements may be ignored, might be
+     interpreted as issued directly by the KDC, or they might be stored in
+     a separate plaintext part of the ticket. The types of the
+     encapsulating elements are specified as part of the Kerberos
+     specification because the behavior based on these values should be
+     understood across implementations whereas other elements need only be
+     understood by the applications which they affect.
+
+     In the definitions that follow, the value of the ad-type for the
+     element will be specified in the subsection number, and the value of
+     the ad-data will be as shown in the ASN.1 structure that follows the
+     subsection heading.
+
+     B.1. If relevant
+
+     AD-IF-RELEVANT   AuthorizationData
+
+     AD elements encapsulated within the if-relevant element are intended
+     for interpretation only by application servers that understand the
+     particular ad-type of the embedded element. Application servers that
+     do not understand the type of an element embedded within the
+     if-relevant element may ignore the uninterpretable element. This
+     element promotes interoperability across implementations which may
+     have local extensions for authorization.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     B.2. Intended for server
+
+     AD-INTENDED-FOR-SERVER   SEQUENCE {
+              intended-server[0]     SEQUENCE OF PrincipalName
+              elements[1]            AuthorizationData
+     }
+
+     AD elements encapsulated within the intended-for-server element may be
+     ignored if the application server is not in the list of principal
+     names of intended servers. Further, a KDC issuing a ticket for an
+     application server can remove this element if the application server
+     is not in the list of intended servers.
+
+     Application servers should check for their principal name in the
+     intended-server field of this element. If their principal name is not
+     found, this element should be ignored. If found, then the encapsulated
+     elements should be evaluated in the same manner as if they were
+     present in the top level authorization data field. Applications and
+     application servers that do not implement this element should reject
+     tickets that contain authorization data elements of this type.
+
+     B.3. Intended for application class
+
+     AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE {
+     intended-application-class[0] SEQUENCE OF GeneralString elements[1]
+     AuthorizationData } AD elements encapsulated within the
+     intended-for-application-class element may be ignored if the
+     application server is not in one of the named classes of application
+     servers. Examples of application server classes include "FILESYSTEM",
+     and other kinds of servers.
+
+     This element and the elements it encapulates may be safely ignored by
+     applications, application servers, and KDCs that do not implement this
+     element.
+
+     B.4. KDC Issued
+
+     AD-KDCIssued   SEQUENCE {
+                    ad-checksum[0]    Checksum,
+                     i-realm[1]       Realm OPTIONAL,
+                     i-sname[2]       PrincipalName OPTIONAL,
+                    elements[3]       AuthorizationData.
+     }
+
+     ad-checksum
+          A checksum over the elements field using a cryptographic checksum
+          method that is identical to the checksum used to protect the
+          ticket itself (i.e. using the same hash function and the same
+          encryption algorithm used to encrypt the ticket) and using a key
+          derived from the same key used to protect the ticket.
+     i-realm, i-sname
+          The name of the issuing principal if different from the KDC
+          itself. This field would be used when the KDC can verify the
+          authenticity of elements signed by the issuing principal and it
+          allows this KDC to notify the application server of the validity
+          of those elements.
+     elements
+          A sequence of authorization data elements issued by the KDC.
+     The KDC-issued ad-data field is intended to provide a means for
+     Kerberos principal credentials to embed within themselves privilege
+     attributes and other mechanisms for positive authorization, amplifying
+     the priveleges of the principal beyond what can be done using a
+     credentials without such an a-data element.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     This can not be provided without this element because the definition
+     of the authorization-data field allows elements to be added at will by
+     the bearer of a TGT at the time that they request service tickets and
+     elements may also be added to a delegated ticket by inclusion in the
+     authenticator.
+
+     For KDC-issued elements this is prevented because the elements are
+     signed by the KDC by including a checksum encrypted using the server's
+     key (the same key used to encrypt the ticket - or a key derived from
+     that key). Elements encapsulated with in the KDC-issued element will
+     be ignored by the application server if this "signature" is not
+     present. Further, elements encapsulated within this element from a
+     ticket granting ticket may be interpreted by the KDC, and used as a
+     basis according to policy for including new signed elements within
+     derivative tickets, but they will not be copied to a derivative ticket
+     directly. If they are copied directly to a derivative ticket by a KDC
+     that is not aware of this element, the signature will not be correct
+     for the application ticket elements, and the field will be ignored by
+     the application server.
+
+     This element and the elements it encapulates may be safely ignored by
+     applications, application servers, and KDCs that do not implement this
+     element.
+
+     B.5. And-Or
+
+     AD-AND-OR           SEQUENCE {
+                             condition-count[0]    INTEGER,
+                             elements[1]           AuthorizationData
+     }
+
+     When restrictive AD elements encapsulated within the and-or element
+     are encountered, only the number specified in condition-count of the
+     encapsulated conditions must be met in order to satisfy this element.
+     This element may be used to implement an "or" operation by setting the
+     condition-count field to 1, and it may specify an "and" operation by
+     setting the condition count to the number of embedded elements.
+     Application servers that do not implement this element must reject
+     tickets that contain authorization data elements of this type.
+
+     B.6. Mandatory ticket extensions
+
+     AD-Mandatory-Ticket-Extensions           SEQUENCE {
+                             te-type[0]       INTEGER,
+                             te-checksum[0]    Checksum
+     }
+
+     An authorization data element of type mandatory-ticket-extensions
+     specifies the type and a collision-proof checksum using the same hash
+     algorithm used to protect the integrity of the ticket itself. This
+     checksum will be calculated over an individual extension field of the
+     type indicated. If there are more than one extension, multiple
+     Mandatory-Ticket-Extensions authorization data elements may be
+     present, each with a checksum for a different extension field. This
+     restriction indicates that the ticket should not be accepted if a
+     ticket extension is not present in the ticket for which the type and
+     checksum do not match that checksum specified in the authorization
+     data element. Note that although the type is redundant for the
+     purposes of the comparison, it makes the comparison easier when
+     multiple extensions are present. Application servers that do not
+     implement this element must reject tickets that contain authorization
+     data elements of this type.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     B.7. Authorization Data in ticket extensions
+
+     AD-IN-Ticket-Extensions   Checksum
+
+     An authorization data element of type in-ticket-extensions specifies a
+     collision-proof checksum using the same hash algorithm used to protect
+     the integrity of the ticket itself. This checksum is calculated over a
+     separate external AuthorizationData field carried in the ticket
+     extensions. Application servers that do not implement this element
+     must reject tickets that contain authorization data elements of this
+     type. Application servers that do implement this element will search
+     the ticket extensions for authorization data fields, calculate the
+     specified checksum over each authorization data field and look for one
+     matching the checksum in this in-ticket-extensions element. If not
+     found, then the ticket must be rejected. If found, the corresponding
+     authorization data elements will be interpreted in the same manner as
+     if they were contained in the top level authorization data field.
+
+     Note that if multiple external authorization data fields are present
+     in a ticket, each will have a corresponding element of type
+     in-ticket-extensions in the top level authorization data field, and
+     the external entries will be linked to the corresponding element by
+     their checksums.
+
+     C. Definition of common ticket extensions
+
+     This appendix contains the definitions of common ticket extensions.
+     Support for these extensions is optional. However, certain extensions
+     have associated authorization data elements that may require rejection
+     of a ticket containing an extension by application servers that do not
+     implement the particular extension. Other extensions have been defined
+     beyond those described in this specification. Such extensions are
+     described elswhere and for some of those extensions the reserved
+     number may be found in the list of constants.
+
+     It is known that older versions of Kerberos did not support this
+     field, and that some clients will strip this field from a ticket when
+     they parse and then reassemble a ticket as it is passed to the
+     application servers. The presence of the extension will not break such
+     clients, but any functionaly dependent on the extensions will not work
+     when such tickets are handled by old clients. In such situations, some
+     implementation may use alternate methods to transmit the information
+     in the extensions field.
+
+     C.1. Null ticket extension
+
+     TE-NullExtension   OctetString -- The empty Octet String
+
+     The te-data field in the null ticket extension is an octet string of
+     lenght zero. This extension may be included in a ticket granting
+     ticket so that the KDC can determine on presentation of the ticket
+     granting ticket whether the client software will strip the extensions
+     field.
+
+     C.2. External Authorization Data
+
+     TE-ExternalAuthorizationData   AuthorizationData
+
+     The te-data field in the external authorization data ticket extension
+     is field of type AuthorizationData containing one or more
+     authorization data elements. If present, a corresponding authorization
+     data element will be present in the primary authorization data for the
+     ticket and that element will contain a checksum of the external
+     authorization data ticket extension.
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     ----------------------------------------------------------------------
+     [TM] Project Athena, Athena, and Kerberos are trademarks of the
+     Massachusetts Institute of Technology (MIT). No commercial use of
+     these trademarks may be made without prior written permission of MIT.
+
+     [1] Note, however, that many applications use Kerberos' functions only
+     upon the initiation of a stream-based network connection. Unless an
+     application subsequently provides integrity protection for the data
+     stream, the identity verification applies only to the initiation of
+     the connection, and does not guarantee that subsequent messages on the
+     connection originate from the same principal.
+
+     [2] Secret and private are often used interchangeably in the
+     literature. In our usage, it takes two (or more) to share a secret,
+     thus a shared DES key is a secret key. Something is only private when
+     no one but its owner knows it. Thus, in public key cryptosystems, one
+     has a public and a private key.
+
+     [3] Of course, with appropriate permission the client could arrange
+     registration of a separately-named prin- cipal in a remote realm, and
+     engage in normal exchanges with that realm's services. However, for
+     even small numbers of clients this becomes cumbersome, and more
+     automatic methods as described here are necessary.
+
+     [4] Though it is permissible to request or issue tick- ets with no
+     network addresses specified.
+
+     [5] The password-changing request must not be honored unless the
+     requester can provide the old password (the user's current secret
+     key). Otherwise, it would be possible for someone to walk up to an
+     unattended ses- sion and change another user's password.
+
+     [6] To authenticate a user logging on to a local system, the
+     credentials obtained in the AS exchange may first be used in a TGS
+     exchange to obtain credentials for a local server. Those credentials
+     must then be verified by a local server through successful completion
+     of the Client/Server exchange.
+
+     [7] "Random" means that, among other things, it should be impossible
+     to guess the next session key based on knowledge of past session keys.
+     This can only be achieved in a pseudo-random number generator if it is
+     based on cryptographic principles. It is more desirable to use a truly
+     random number generator, such as one based on measurements of random
+     physical phenomena.
+
+     [8] Tickets contain both an encrypted and unencrypted portion, so
+     cleartext here refers to the entire unit, which can be copied from one
+     message and replayed in another without any cryptographic skill.
+
+     [9] Note that this can make applications based on unreliable
+     transports difficult to code correctly. If the transport might deliver
+     duplicated messages, either a new authenticator must be generated for
+     each retry, or the application server must match requests and replies
+     and replay the first reply in response to a detected duplicate.
+
+     [10] This is used for user-to-user authentication as described in [8].
+
+     [11] Note that the rejection here is restricted to authenticators from
+     the same principal to the same server. Other client principals
+     communicating with the same server principal should not be have their
+     authenticators rejected if the time and microsecond fields happen to
+     match some other client's authenticator.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     [12] In the Kerberos version 4 protocol, the timestamp in the reply
+     was the client's timestamp plus one. This is not necessary in version
+     5 because version 5 messages are formatted in such a way that it is
+     not possible to create the reply by judicious message surgery (even in
+     encrypted form) without knowledge of the appropriate encryption keys.
+
+     [13] Note that for encrypting the KRB_AP_REP message, the sub-session
+     key is not used, even if present in the Authenticator.
+
+     [14] Implementations of the protocol may wish to provide routines to
+     choose subkeys based on session keys and random numbers and to
+     generate a negotiated key to be returned in the KRB_AP_REP message.
+
+     [15]This can be accomplished in several ways. It might be known
+     beforehand (since the realm is part of the principal identifier), it
+     might be stored in a nameserver, or it might be obtained from a
+     configura- tion file. If the realm to be used is obtained from a
+     nameserver, there is a danger of being spoofed if the nameservice
+     providing the realm name is not authenti- cated. This might result in
+     the use of a realm which has been compromised, and would result in an
+     attacker's ability to compromise the authentication of the application
+     server to the client.
+
+     [16] If the client selects a sub-session key, care must be taken to
+     ensure the randomness of the selected sub- session key. One approach
+     would be to generate a random number and XOR it with the session key
+     from the ticket-granting ticket.
+
+     [17] This allows easy implementation of user-to-user authentication
+     [8], which uses ticket-granting ticket session keys in lieu of secret
+     server keys in situa- tions where such secret keys could be easily
+     comprom- ised.
+
+     [18] For the purpose of appending, the realm preceding the first
+     listed realm is considered to be the null realm ("").
+
+     [19] For the purpose of interpreting null subfields, the client's
+     realm is considered to precede those in the transited field, and the
+     server's realm is considered to follow them.
+
+     [20] This means that a client and server running on the same host and
+     communicating with one another using the KRB_SAFE messages should not
+     share a common replay cache to detect KRB_SAFE replays.
+
+     [21] The implementation of the Kerberos server need not combine the
+     database and the server on the same machine; it is feasible to store
+     the principal database in, say, a network name service, as long as the
+     entries stored therein are protected from disclosure to and
+     modification by unauthorized parties. However, we recommend against
+     such strategies, as they can make system management and threat
+     analysis quite complex.
+
+     [22] See the discussion of the padata field in section 5.4.2 for
+     details on why this can be useful.
+
+     [23] Warning for implementations that unpack and repack data
+     structures during the generation and verification of embedded
+     checksums: Because any checksums applied to data structures must be
+     checked against the original data the length of bit strings must be
+     preserved within a data structure between the time that a checksum is
+     generated through transmission to the time that the checksum is
+     verified.
+
+
+Neuman, Ts'o, Kohl                                   Expires: 14 January
+2001
+
+^L
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
+2000
+
+     [24] It is NOT recommended that this time value be used to adjust the
+     workstation's clock since the workstation cannot reliably determine
+     that such a KRB_AS_REP actually came from the proper KDC in a timely
+     manner.
+
+     [25] Note, however, that if the time is used as the nonce, one must
+     make sure that the workstation time is monotonically increasing. If
+     the time is ever reset backwards, there is a small, but finite,
+     probability that a nonce will be reused.
+
+     [27] An application code in the encrypted part of a message provides
+     an additional check that the message was decrypted properly.
+
+     [29] An application code in the encrypted part of a message provides
+     an additional check that the message was decrypted properly.
+
+     [31] An application code in the encrypted part of a message provides
+     an additional check that the message was decrypted properly.
+
+     [32] If supported by the encryption method in use, an initialization
+     vector may be passed to the encryption procedure, in order to achieve
+     proper cipher chaining. The initialization vector might come from the
+     last block of the ciphertext from the previous KRB_PRIV message, but
+     it is the application's choice whether or not to use such an
+     initialization vector. If left out, the default initialization vector
+     for the encryption algorithm will be used.
+
+     [33] This prevents an attacker who generates an incorrect AS request
+     from obtaining verifiable plaintext for use in an off-line password
+     guessing attack.
+
+     [35] In the above specification, UNTAGGED OCTET STRING(length) is the
+     notation for an octet string with its tag and length removed. It is
+     not a valid ASN.1 type. The tag bits and length must be removed from
+     the confounder since the purpose of the confounder is so that the
+     message starts with random data, but the tag and its length are fixed.
+     For other fields, the length and tag would be redundant if they were
+     included because they are specified by the encryption type. [36] The
+     ordering of the fields in the CipherText is important. Additionally,
+     messages encoded in this format must include a length as part of the
+     msg-seq field. This allows the recipient to verify that the message
+     has not been truncated. Without a length, an attacker could use a
+     chosen plaintext attack to generate a message which could be
+     truncated, while leaving the checksum intact. Note that if the msg-seq
+     is an encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length
+     is part of that encoding.
+
+     [37] In some cases, it may be necessary to use a different "mix-in"
+     string for compatibility reasons; see the discussion of padata in
+     section 5.4.2.
+
+     [38] In some cases, it may be necessary to use a different "mix-in"
+     string for compatibility reasons; see the discussion of padata in
+     section 5.4.2.
+
+     [39] A variant of the key is used to limit the use of a key to a
+     particular function, separating the functions of generating a checksum
+     from other encryption performed using the session key. The constant
+     F0F0F0F0F0F0F0F0 was chosen because it maintains key parity. The
+     properties of DES precluded the use of the complement. The same
+     constant is used for similar purpose in the Message Integrity Check in
+     the Privacy Enhanced Mail standard.
+
+     [40] This error carries additional information in the e- data field.
+     The contents of the e-data field for this message is described in
+     section 5.9.1.
+
+
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt
new file mode 100644
index 000000000000..6f7dae0dea70
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt
@@ -0,0 +1,325 @@
+
+INTERNET-DRAFT                                        Mike Swift 
+draft-ietf-cat-kerberos-set-passwd-02.txt             Microsoft
+March 2000                                            Jonathan Trostle
+                                                      Cisco Systems
+                                                      John Brezak
+                                                      Microsoft
+                                                      Bill Gossman
+                                                      Cybersafe
+
+              Kerberos Set/Change Password: Version 2
+
+
+0. 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.
+
+   Comments and suggestions on this document are encouraged.  Comments 
+   on this document should be sent to the CAT working group discussion 
+   list:
+                       ietf-cat-wg@stanford.edu
+
+1. Abstract
+
+   The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), 
+   does not allow for an administrator to set a password for a new user. 
+   This functionality is useful in some environments, and this proposal 
+   extends [4] to allow password setting. The changes are: adding new 
+   fields to the request message to indicate the principal which is 
+   having its password set, not requiring the initial flag in the service 
+   ticket, using a new protocol version number, and adding three new 
+   result codes. We also extend the set/change protocol to allow a 
+   client to send a sequence of keys to the KDC instead of a cleartext 
+   password. If in the cleartext password case, the cleartext password 
+   fails to satisfy password policy, the server should use the result    
+   code KRB5_KPASSWD_POLICY_REJECT.
+
+2. Conventions used in this document 
+    
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC-2119 [2]. 
+   
+3. The Protocol
+
+   The service must accept requests on UDP port 464 and TCP port 464 as 
+   well. The protocol consists of a single request message followed by 
+   a single reply message.  For UDP transport, each message must be fully 
+   contained in a single UDP packet.
+
+   For TCP transport, there is a 4 octet header in network byte order
+   precedes the message and specifies the length of the message. This
+   requirement is consistent with the TCP transport header in 1510bis.
+
+Request Message
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         message length        |    protocol version number    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          AP_REQ length        |         AP-REQ data           /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                        KRB-PRIV message                       /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   All 16 bit fields are in network byte order. 
+
+   message length field: contains the number of bytes in the message 
+   including this field.
+
+   protocol version number: contains the hex constant 0x0002 (network
+   byte order).
+
+   AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, 
+   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
+   message.
+
+   AP-REQ data: (see [3]) The AP-REQ message must be for the service 
+   principal kadmin/changepw@REALM, where REALM is the REALM of the user 
+   who wishes to change/set his password.  The ticket in the AP-REQ must 
+   must include a subkey in the Authenticator. To enable setting of 
+   passwords/keys, it is not required that the initial flag be set in the 
+   Kerberos service ticket. The initial flag is required for change requests,
+   but not for set password requests. We have the following definitions:
+
+                    old passwd   initial flag  target principal can be
+                    in request?  required?     distinct from 
+                                               authenticating principal?
+                                              
+   change password:  yes         yes           no
+
+   set password:     no          no            yes
+
+   set key:          no          policy        yes
+                                 determined
+
+   KRB-PRIV message (see [3]) This KRB-PRIV message must be generated 
+   using the subkey from the authenticator in the AP-REQ data. 
+
+   The user-data component of the message consists of the following ASN.1 
+   structure encoded as an OCTET STRING:
+
+   ChangePasswdData :: =  SEQUENCE {
+                       newpasswdorkeys[0]   NewPasswdOrKeys,
+                       targname[1]          PrincipalName OPTIONAL,
+                         -- only present in set password: the principal
+                         -- which will have its password set
+                       targrealm[2]         Realm OPTIONAL, 
+                         -- only present in set password: the realm for 
+                         -- the principal which will have its password set
+
+                       }
+
+   NewPasswdOrKeys :: = CHOICE {
+                       passwords[0]  PasswordSequence,       
+                       keyseq[1]     KeySequences
+   }
+                         
+   KeySequences :: = SEQUENCE OF KeySequence
+
+   KeySequence :: = SEQUENCE {
+                       key[0]        EncryptionKey,
+                       salt[1]       OCTET STRING OPTIONAL,
+                       salt-type[2]  INTEGER OPTIONAL
+   }
+
+   PasswordSequence :: = SEQUENCE {
+                       newpasswd[0]  OCTET STRING,
+                       oldpasswd[1]  OCTET STRING OPTIONAL
+                         -- oldpasswd always present for change password
+                         -- but not present for set password 
+   }
+
+   The server must verify the AP-REQ message, check whether the client 
+   principal in the ticket is authorized to set or change the password 
+   (either for that principal, or for the principal in the targname 
+   field if present), and decrypt the new password/keys. The server 
+   also checks whether the initial flag is required for this request, 
+   replying with status 0x0007 if it is not set and should be. An 
+   authorization failure is cause to respond with status 0x0005. For 
+   forward compatibility, the server should be prepared to ignore fields 
+   after targrealm in the structure that it does not understand. 
+
+   The newpasswdorkeys field contains either the new cleartext password 
+   (with the old cleartext password for a change password operation), 
+   or a sequence of encryption keys with their respective salts. 
+
+   In the cleartext password case, if the old password is sent in the
+   request, the request is defined to be a change password request. If
+   the old password is not present in the request, the request is a set
+   password request. The server should apply policy checks to the old 
+   and new password after verifying that the old password is valid. 
+   The server can check validity by obtaining a key from the old 
+   password with a keytype that is present in the KDC database for the 
+   user and comparing the keys for equality. The server then generates 
+   the appropriate keytypes from the password and stores them in the KDC 
+
+   database. If all goes well, status 0x0000 is returned to the client 
+   in the reply message (see below). For a change password operation,
+   the initial flag in the service ticket MUST be set. 
+
+   In the key sequence case, the sequence of keys is sent to the set
+   password service. For a principal that can act as a server, its 
+   preferred keytype should be sent as the first key in the sequence, 
+   but the KDC is not required to honor this preference. Application 
+   servers should use the key sequence option for changing/setting their 
+   keys. The set password service should check that all keys are in the
+   proper format, returning the KRB5_KPASSWD_MALFORMED error otherwise. 
+
+Reply Message
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         message length        |    protocol version number    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          AP_REP length        |         AP-REP data           /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                          KRB-PRIV message                     /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   All 16 bit fields are in network byte order. 
+
+   message length field: contains the number of bytes in the message 
+   including this field.
+
+   protocol version number: contains the hex constant 0x0002 (network
+   byte order). (The reply message has the same format as in [4]).
+
+   AP-REP length: length of AP-REP data, in bytes. If the length is zero, 
+   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
+   message.
+
+   AP-REP data: the AP-REP is the response to the AP-REQ in the request 
+   packet.
+   
+   KRB-PRIV from [4]: This KRB-PRIV message must be generated using the 
+   subkey in the authenticator in the AP-REQ data.
+
+   The server will respond with a KRB-PRIV message unless it cannot
+   validate the client AP-REQ or KRB-PRIV message, in which case it will
+   respond with a KRB-ERROR message. NOTE: Unlike change password version
+   1, the KRB-ERROR message will be sent back without any encapsulation. 
+
+   The user-data component of the KRB-PRIV message, or e-data component 
+   of the KRB-ERROR message, must consist of the following data.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          result code          |        result string          /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             edata                             /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      result code (16 bits) (result codes 0-4 are from [4]):
+         The result code must have one of the following values (network
+         byte order):
+         KRB5_KPASSWD_SUCCESS      0 request succeeds (This value is not 
+                                     allowed in a KRB-ERROR message)
+         KRB5_KPASSWD_MALFORMED    1 request fails due to being malformed
+         KRB5_KPASSWD_HARDERROR    2 request fails due to "hard" error in
+                                     processing the request (for example, 
+                                     there is a resource or other problem 
+                                     causing the request to fail)
+         KRB5_KPASSWD_AUTHERROR    3 request fails due to an error in 
+                                     authentication processing
+         KRB5_KPASSWD_SOFTERROR    4 request fails due to a soft error 
+                                     in processing the request 
+         KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
+         KRB5_KPASSWD_BAD_VERSION  6 protocol version unsupported
+         KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required
+         KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy;
+         the result string should include a text message to be presented
+         to the user.
+         KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist
+         (only in response to a set password request).
+         KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence
+         containing at least one etype that is not supported by the KDC.
+         The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO 
+         type that specifies the etypes that the KDC supports:
+         
+         KERB-ETYPE-INFO-ENTRY :: = SEQUENCE {
+                encryption-type[0]  INTEGER,
+                salt[1]             OCTET STRING OPTIONAL -- not sent
+         }
+
+         PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY
+
+         The client should retry the request using only etypes (keytypes)
+         that are contained within the PKERB-ETYPE-INFO structure in the
+         previous response. 
+         0xFFFF if the request fails for some other reason.
+         The client must interpret any non-zero result code as a failure.
+      result string - from [4]:
+         This field is a UTF-8 encoded string which should be displayed
+         to the user by the client. Specific reasons for a password 
+         set/change policy failure is one use for this string. 
+      edata: used to convey additional information as defined by the 
+         result code. 
+
+4. References
+
+   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+       9, RFC 2026, October 1996. 
+    
+   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+       Levels", BCP 14, RFC 2119, March 1997 
+ 
+   [3] J. Kohl, C. Neuman. The Kerberos Network Authentication
+       Service (V5), Request for Comments 1510.
+
+   [4] M. Horowitz. Kerberos Change Password Protocol,
+       ftp://ds.internic.net/internet-drafts/
+       draft-ietf-cat-kerb-chg-password-02.txt
+
+5. Expiration Date
+
+   This draft expires in September 2000.
+
+6. Authors' Addresses
+
+   Jonathan Trostle
+   Cisco Systems
+   170 W. Tasman Dr.
+   San Jose, CA 95134
+   Email: jtrostle@cisco.com
+
+   Mike Swift 
+   1 Microsoft Way
+   Redmond, WA 98052
+   Email: mikesw@microsoft.com
+
+   John Brezak
+   1 Microsoft Way
+   Redmond, WA 98052
+   Email: jbrezak@microsoft.com
+
+   Bill Gossman
+   Cybersafe Corporation
+   1605 NW Sammamish Rd.
+   Issaquah, WA 98027-5378
+   Email: bill.gossman@cybersafe.com
+
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt
new file mode 100644
index 000000000000..0319f8bf347c
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt
@@ -0,0 +1,345 @@
+
+INTERNET-DRAFT                                        Mike Swift 
+draft-ietf-cat-kerberos-set-passwd-03.txt             Microsoft
+April 2000                                            Jonathan Trostle
+                                                      Cisco Systems
+                                                      John Brezak
+                                                      Microsoft
+                                                      Bill Gossman
+                                                      Cybersafe
+
+              Kerberos Set/Change Password: Version 2
+
+
+0. 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.
+
+   Comments and suggestions on this document are encouraged.  Comments 
+   on this document should be sent to the CAT working group discussion 
+   list:
+                       ietf-cat-wg@stanford.edu
+
+1. Abstract
+
+   The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), 
+   does not allow for an administrator to set a password for a new user. 
+   This functionality is useful in some environments, and this proposal 
+   extends [4] to allow password setting. The changes are: adding new 
+   fields to the request message to indicate the principal which is 
+   having its password set, not requiring the initial flag in the service 
+   ticket, using a new protocol version number, and adding three new 
+   result codes. We also extend the set/change protocol to allow a 
+   client to send a sequence of keys to the KDC instead of a cleartext 
+   password. If in the cleartext password case, the cleartext password 
+   fails to satisfy password policy, the server should use the result    
+   code KRB5_KPASSWD_POLICY_REJECT.
+
+2. Conventions used in this document 
+    
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC-2119 [2]. 
+   
+3. The Protocol
+
+   The service must accept requests on UDP port 464 and TCP port 464 as 
+   well. The protocol consists of a single request message followed by 
+   a single reply message.  For UDP transport, each message must be fully 
+   contained in a single UDP packet.
+
+   For TCP transport, there is a 4 octet header in network byte order
+   precedes the message and specifies the length of the message. This
+   requirement is consistent with the TCP transport header in 1510bis.
+
+Request Message
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         message length        |    protocol version number    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          AP_REQ length        |         AP-REQ data           /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                        KRB-PRIV message                       /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   All 16 bit fields are in network byte order. 
+
+   message length field: contains the number of bytes in the message 
+   including this field.
+
+   protocol version number: contains the hex constant 0x0002 (network
+   byte order).
+
+   AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, 
+   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
+   message.
+
+   AP-REQ data: (see [3]) For a change password/key request, the AP-REQ 
+   message service ticket sname, srealm principal identifier is 
+   kadmin/changepw@REALM where REALM is the realm of the change password 
+   service. The same applies to a set password/key request except the 
+   principal identifier is kadmin/setpw@REALM. The ticket in the AP-REQ 
+   must include a subkey in the Authenticator. To enable setting of 
+   passwords/keys, it is not required that the initial flag be set in the 
+   Kerberos service ticket. The initial flag is required for change requests,
+   but not for set requests. We have the following definitions:
+
+                    old passwd   initial flag  target principal can be
+                    in request?  required?     distinct from 
+                                               authenticating principal?
+                                              
+   change password:  yes         yes           no
+
+   set password:     no          policy (*)    yes
+
+   set key:          no          policy (*)    yes
+                                 
+   change key:       no          yes           no
+
+   policy (*): implementations SHOULD allow administrators to set the
+   initial flag required for set requests policy to either yes or no.
+   Clients MUST be able to retry set requests that fail due to error 7
+   (initial flag required) with an initial ticket. Clients SHOULD NOT
+   cache service tickets targetted at kadmin/changepw.
+
+   KRB-PRIV message (see [3]) This KRB-PRIV message must be generated 
+   using the subkey from the authenticator in the AP-REQ data. 
+
+   The user-data component of the message consists of the following ASN.1 
+   structure encoded as an OCTET STRING:
+
+   ChangePasswdData :: =  SEQUENCE {
+                       newpasswdorkeys[0]   NewPasswdOrKeys,
+                       targname[1]          PrincipalName OPTIONAL,
+                         -- only present in set password/key: the principal
+                         -- which will have its password or keys set. Not
+                         -- present in a set request if the client principal
+                         -- from the ticket is the principal having its 
+                         -- passwords or keys set.
+                       targrealm[2]         Realm OPTIONAL, 
+                         -- only present in set password/key: the realm for 
+                         -- the principal which will have its password or
+                         -- keys set. Not present in a set request if the 
+                         -- client principal from the ticket is the principal 
+                         -- having its passwords or keys set.
+                       }
+
+   NewPasswdOrKeys :: = CHOICE {
+                       passwords[0]  PasswordSequence,  -- change/set passwd   
+                       keyseq[1]     KeySequences       -- change/set key
+   }
+                         
+   KeySequences :: = SEQUENCE OF KeySequence
+
+   KeySequence :: = SEQUENCE {
+                       key[0]        EncryptionKey,
+                       salt[1]       OCTET STRING OPTIONAL,
+                       salt-type[2]  INTEGER OPTIONAL
+   }
+
+   PasswordSequence :: = SEQUENCE {
+                       newpasswd[0]  OCTET STRING,
+                       oldpasswd[1]  OCTET STRING OPTIONAL
+                         -- oldpasswd always present for change password
+                         -- but not present for set password, set key, or
+                         -- change key
+   }
+
+   The server must verify the AP-REQ message, check whether the client 
+   principal in the ticket is authorized to set or change the password 
+   (either for that principal, or for the principal in the targname 
+   field if present), and decrypt the new password/keys. The server 
+   also checks whether the initial flag is required for this request, 
+   replying with status 0x0007 if it is not set and should be. An 
+   authorization failure is cause to respond with status 0x0005. For 
+   forward compatibility, the server should be prepared to ignore fields 
+   after targrealm in the structure that it does not understand. 
+
+   The newpasswdorkeys field contains either the new cleartext password 
+   (with the old cleartext password for a change password operation), 
+   or a sequence of encryption keys with their respective salts. 
+
+   In the cleartext password case, if the old password is sent in the
+   request, the request MUST be a change password request. If the old 
+   password is not present in the request, the request MUST be a set
+   password request. The server should apply policy checks to the old 
+   and new password after verifying that the old password is valid. 
+   The server can check validity by obtaining a key from the old 
+   password with a keytype that is present in the KDC database for the 
+   user and comparing the keys for equality. The server then generates 
+   the appropriate keytypes from the password and stores them in the KDC 
+   database. If all goes well, status 0x0000 is returned to the client 
+   in the reply message (see below). For a change password operation,
+   the initial flag in the service ticket MUST be set. 
+
+   In the key sequence case, the sequence of keys is sent to the change
+   or set password service (kadmin/changepw or kadmin/setpw respectively). 
+   For a principal that can act as a server, its preferred keytype should 
+   be sent as the first key in the sequence, but the KDC is not required 
+   to honor this preference. Application servers should use the key 
+   sequence option for changing/setting their keys. The change/set password 
+   services should check that all keys are in the proper format, returning 
+   the KRB5_KPASSWD_MALFORMED error otherwise. 
+
+Reply Message
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         message length        |    protocol version number    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          AP_REP length        |         AP-REP data           /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                          KRB-PRIV message                     /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   All 16 bit fields are in network byte order. 
+
+   message length field: contains the number of bytes in the message 
+   including this field.
+
+   protocol version number: contains the hex constant 0x0002 (network
+   byte order). (The reply message has the same format as in [4]).
+
+   AP-REP length: length of AP-REP data, in bytes. If the length is zero, 
+   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
+   message.
+
+   AP-REP data: the AP-REP is the response to the AP-REQ in the request 
+   packet.
+   
+   KRB-PRIV from [4]: This KRB-PRIV message must be generated using the 
+   subkey in the authenticator in the AP-REQ data.
+
+   The server will respond with a KRB-PRIV message unless it cannot
+   validate the client AP-REQ or KRB-PRIV message, in which case it will
+   respond with a KRB-ERROR message. NOTE: Unlike change password version
+   1, the KRB-ERROR message will be sent back without any encapsulation. 
+
+   The user-data component of the KRB-PRIV message, or e-data component 
+   of the KRB-ERROR message, must consist of the following data.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          result code          |        result string          /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             edata                             /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      result code (16 bits) (result codes 0-4 are from [4]):
+         The result code must have one of the following values (network
+         byte order):
+         KRB5_KPASSWD_SUCCESS      0 request succeeds (This value is not 
+                                     allowed in a KRB-ERROR message)
+         KRB5_KPASSWD_MALFORMED    1 request fails due to being malformed
+         KRB5_KPASSWD_HARDERROR    2 request fails due to "hard" error in
+                                     processing the request (for example, 
+                                     there is a resource or other problem 
+                                     causing the request to fail)
+         KRB5_KPASSWD_AUTHERROR    3 request fails due to an error in 
+                                     authentication processing
+         KRB5_KPASSWD_SOFTERROR    4 request fails due to a soft error 
+                                     in processing the request 
+         KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
+         KRB5_KPASSWD_BAD_VERSION  6 protocol version unsupported
+         KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required
+         KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy;
+         the result string should include a text message to be presented
+         to the user.
+         KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist
+         (only in response to a set password request).
+         KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence
+         containing at least one etype that is not supported by the KDC.
+         The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO 
+         type that specifies the etypes that the KDC supports:
+         
+         KERB-ETYPE-INFO-ENTRY :: = SEQUENCE {
+                encryption-type[0]  INTEGER,
+                salt[1]             OCTET STRING OPTIONAL -- not sent
+         }
+
+         PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY
+
+         The client should retry the request using only etypes (keytypes)
+         that are contained within the PKERB-ETYPE-INFO structure in the
+         previous response. 
+         0xFFFF if the request fails for some other reason.
+         The client must interpret any non-zero result code as a failure.
+      result string - from [4]:
+         This field is a UTF-8 encoded string which should be displayed
+         to the user by the client. Specific reasons for a password 
+
+         set/change policy failure is one use for this string. 
+      edata: used to convey additional information as defined by the 
+         result code. 
+
+4. Acknowledgements
+  
+   The authors thank Tony Andrea for his input to the document.
+
+5. References
+
+   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+       9, RFC 2026, October 1996. 
+    
+   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+       Levels", BCP 14, RFC 2119, March 1997 
+ 
+   [3] J. Kohl, C. Neuman. The Kerberos Network Authentication
+       Service (V5), Request for Comments 1510.
+
+   [4] M. Horowitz. Kerberos Change Password Protocol,
+       ftp://ds.internic.net/internet-drafts/
+       draft-ietf-cat-kerb-chg-password-02.txt
+
+6. Expiration Date
+
+   This draft expires in October 2000.
+
+7. Authors' Addresses
+
+   Jonathan Trostle
+   Cisco Systems
+   170 W. Tasman Dr.
+   San Jose, CA 95134
+   Email: jtrostle@cisco.com
+
+   Mike Swift 
+   1 Microsoft Way
+   Redmond, WA 98052
+   Email: mikesw@microsoft.com
+
+   John Brezak
+   1 Microsoft Way
+   Redmond, WA 98052
+   Email: jbrezak@microsoft.com
+
+   Bill Gossman
+   Cybersafe Corporation
+   1605 NW Sammamish Rd.
+   Issaquah, WA 98027-5378
+   Email: bill.gossman@cybersafe.com
+
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt
new file mode 100644
index 000000000000..bd31750a15af
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                             Ken Hornstein
+<draft-ietf-cat-krb-dns-locate-02.txt>                               NRL
+March 10, 2000                                            Jeffrey Altman
+Expires: September 10, 2000                          Columbia University
+
+
+
+          Distributing Kerberos KDC and Realm Information with DNS
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all 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/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   Distribution of this memo is unlimited.  It is filed as <draft-ietf-
+   cat-krb-dns-locate-02.txt>, and expires on September 10, 2000.  Please
+   send comments to the authors.
+
+Abstract
+
+   Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto-
+   col [RFC????] describe any mechanism for clients to learn critical
+   configuration information necessary for proper operation of the pro-
+   tocol.  Such information includes the location of Kerberos key dis-
+   tribution centers or a mapping between DNS domains and Kerberos
+   realms.
+
+   Current Kerberos implementations generally store such configuration
+   information in a file on each client machine.  Experience has shown
+   this method of storing configuration information presents problems
+   with out-of-date information and scaling problems, especially when
+
+
+
+Hornstein, Altman                                               [Page 1]
+
+RFC DRAFT                                                 March 10, 2000
+
+
+   using cross-realm authentication.
+
+   This memo describes a method for using the Domain Name System
+   [RFC1035] for storing such configuration information.  Specifically,
+   methods for storing KDC location and hostname/domain name to realm
+   mapping information are discussed.
+
+DNS vs. Kerberos - Case Sensitivity of Realm Names
+
+   In Kerberos, realm names are case sensitive.  While it is strongly
+   encouraged that all realm names be all upper case this recommendation
+   has not been adopted by all sites.  Some sites use all lower case
+   names and other use mixed case.  DNS on the other hand is case insen-
+   sitive for queries but is case preserving for responses to TXT
+   queries.  Since "MYREALM", "myrealm", and "MyRealm" are all different
+   it is necessary that the DNS entries be distinguishable.
+
+   Since the recommend realm names are all upper case, we will not
+   require any quoting to be applied to upper case names.  If the realm
+   name contains lower case characters each character is to be quoted by
+   a '=' character.  So "MyRealm" would be represented as "M=yR=e=a=l=m"
+   and "myrealm" as "=m=y=r=e=a=l=m".  If the realm name contains the
+   '=' character it will be represented as "==".
+
+
+Overview - KDC location information
+
+   KDC location information is to be stored using the DNS SRV RR [RFC
+   2052].  The format of this RR is as follows:
+
+   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
+
+   The Service name for Kerberos is always "_kerberos".
+
+   The Proto can be either "_udp" or "_tcp".  If these records are to be
+   used, a "_udp" record MUST be included.  If the Kerberos implementa-
+   tion supports TCP transport, a "_tcp" record SHOULD be included.
+
+   The Realm is the Kerberos realm that this record corresponds to.
+
+   TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
+   meaning as defined in RFC 2052.
+
+Example - KDC location information
+
+   These are DNS records for a Kerberos realm ASDF.COM.  It has two Ker-
+   beros servers, kdc1.asdf.com and kdc2.asdf.com.  Queries should be
+   directed to kdc1.asdf.com first as per the specified priority.
+
+
+
+Hornstein, Altman                                               [Page 2]
+
+RFC DRAFT                                                 March 10, 2000
+
+
+   Weights are not used in these records.
+
+   _kerberos._udp.ASDF.COM.        IN      SRV     0 0 88 kdc1.asdf.com.
+   _kerberos._udp.ASDF.COM.        IN      SRV     1 0 88 kdc2.asdf.com.
+
+Overview - Kerberos password changing server location information
+
+   Kerberos password changing server [KERB-CHG] location is to be stored
+   using the DNS SRV RR [RFC 2052].  The format of this RR is as fol-
+   lows:
+
+   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
+
+   The Service name for the password server is always "_kpasswd".
+
+   The Proto MUST be "_udp".
+
+   The Realm is the Kerberos realm that this record corresponds to.
+
+   TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
+   meaning as defined in RFC 2052.
+
+Overview - Kerberos admin server location information
+
+   Kerberos admin location information is to be stored using the DNS SRV
+   RR [RFC 2052].  The format of this RR is as follows:
+
+   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
+
+   The Service name for the admin server is always "_kerberos-adm".
+
+   The Proto can be either "_udp" or "_tcp".  If these records are to be
+   used, a "_tcp" record MUST be included.  If the Kerberos admin imple-
+   mentation supports UDP transport, a "_udp" record SHOULD be included.
+
+   The Realm is the Kerberos realm that this record corresponds to.
+
+   TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
+   meaning as defined in RFC 2052.
+
+   Note that there is no formal definition of a Kerberos admin protocol,
+   so the use of this record is optional and implementation-dependent.
+
+Example - Kerberos administrative server location information
+
+   These are DNS records for a Kerberos realm ASDF.COM.  It has one
+   administrative server, kdc1.asdf.com.
+
+
+
+
+Hornstein, Altman                                               [Page 3]
+
+RFC DRAFT                                                 March 10, 2000
+
+
+   _kerberos-adm._tcp.ASDF.COM.    IN      SRV     0 0 88 kdc1.asdf.com.
+
+Overview - Hostname/domain name to Kerberos realm mapping
+
+   Information on the mapping of DNS hostnames and domain names to Ker-
+   beros realms is stored using DNS TXT records [RFC 1035].  These
+   records have the following format.
+
+   Service.Name TTL Class TXT Realm
+
+   The Service field is always "_kerberos", and prefixes all entries of
+   this type.
+
+   The Name is a DNS hostname or domain name.  This is explained in
+   greater detail below.
+
+   TTL, Class, and TXT have the standard DNS meaning as defined in RFC
+   1035.
+
+   The Realm is the data for the TXT RR, and consists simply of the Ker-
+   beros realm that corresponds to the Name specified.
+
+   When a Kerberos client wishes to utilize a host-specific service, it
+   will perform a DNS TXT query, using the hostname in the Name field of
+   the DNS query.  If the record is not found, the first label of the
+   name is stripped and the query is retried.
+
+   Compliant implementations MUST query the full hostname and the most
+   specific domain name (the hostname with the first label removed).
+   Compliant implementations SHOULD try stripping all subsequent labels
+   until a match is found or the Name field is empty.
+
+Example - Hostname/domain name to Kerberos realm mapping
+
+   For the previously mentioned ASDF.COM realm and domain, some sample
+   records might be as follows:
+
+   _kerberos.asdf.com.             IN      TXT     "ASDF.COM"
+   _kerberos.mrkserver.asdf.com.   IN      TXT     "MARKETING.ASDF.COM"
+   _kerberos.salesserver.asdf.com. IN      TXT     "SALES.ASDF.COM"
+
+   Let us suppose that in this case, a Kerberos client wishes to use a
+   Kerberized service on the host foo.asdf.com.  It would first query:
+
+   _kerberos.foo.asdf.com. IN TXT
+
+   Finding no match, it would then query:
+
+
+
+
+Hornstein, Altman                                               [Page 4]
+
+RFC DRAFT                                                 March 10, 2000
+
+
+   _kerberos.asdf.com. IN TXT
+
+   And find an answer of ASDF.COM.  This would be the realm that
+   foo.asdf.com resides in.
+
+   If another Kerberos client wishes to use a Kerberized service on the
+   host salesserver.asdf.com, it would query:
+
+   _kerberos.salesserver.asdf.com IN TXT
+
+   And find an answer of SALES.ASDF.COM.
+
+Security considerations
+
+   As DNS is deployed today, it is an unsecure service.  Thus the infor-
+   mation returned by it cannot be trusted.
+
+   Current practice for REALM to KDC mapping is to use hostnames to
+   indicate KDC hosts (stored in some implementation-dependent location,
+   but generally a local config file).  These hostnames are vulnerable
+   to the standard set of DNS attacks (denial of service, spoofed
+   entries, etc).  The design of the Kerberos protocol limits attacks of
+   this sort to denial of service.  However, the use of SRV records does
+   not change this attack in any way.  They have the same vulnerabili-
+   ties that already exist in the common practice of using hostnames for
+   KDC locations.
+
+   Current practice for HOSTNAME to REALM mapping is to provide a local
+   configuration of mappings of hostname or domain name to realm which
+   are then mapped to KDCs.  But this again is vulnerable to spoofing
+   via CNAME records that point to hosts in other domains.  This has the
+   same effect as when a TXT record is spoofed.  In a realm with no
+   cross-realm trusts this is a DoS attack.  However, when cross-realm
+   trusts are used it is possible to redirect a client to use a comprom-
+   ised realm.
+
+   This is not an exploit of the Kerberos protocol but of the Kerberos
+   trust model.  The same can be done to any application that must
+   resolve the hostname in order to determine which domain a non-FQDN
+   belongs to.
+
+   Implementations SHOULD provide a way of specifying this information
+   locally without the use of DNS.  However, to make this feature
+   worthwhile a lack of any configuration information on a client should
+   be interpretted as permission to use DNS.
+
+
+
+
+
+
+Hornstein, Altman                                               [Page 5]
+
+RFC DRAFT                                                 March 10, 2000
+
+
+Expiration
+
+   This Internet-Draft expires on September 10, 2000.
+
+References
+
+
+   [RFC1510]
+        The Kerberos Network Authentication System; Kohl, Newman; Sep-
+        tember 1993.
+
+   [RFC1035]
+        Domain Names - Implementation and Specification; Mockapetris;
+        November 1987
+
+   [RFC2782]
+        A DNS RR for specifying the location of services (DNS SRV); Gul-
+        brandsen, Vixie; Feburary 2000
+
+   [KERB-CHG]
+        Kerberos Change Password Protocol; Horowitz;
+        ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-
+        password-02.txt
+
+Authors' Addresses
+
+   Ken Hornstein
+   US Naval Research Laboratory
+   Bldg A-49, Room 2
+   4555 Overlook Avenue
+   Washington DC  20375 USA
+
+   Phone: +1 (202) 404-4765
+   EMail: kenh@cmf.nrl.navy.mil
+
+   Jeffrey Altman
+   The Kermit Project
+   Columbia University
+   612 West 115th Street #716
+   New York NY 10025-7799 USA
+
+   Phone: +1 (212) 854-1344
+   EMail: jaltman@columbia.edu
+
+
+
+
+
+
+
+
+Hornstein, Altman                                               [Page 6]
+
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt
new file mode 100644
index 000000000000..11e5dc9f9548
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt
@@ -0,0 +1,1333 @@
+
+INTERNET-DRAFT                                                    Tom Yu
+Common Authentication Technology WG                                  MIT
+draft-ietf-cat-krb5gss-mech2-03.txt                        04 March 2000
+
+           The Kerberos Version 5 GSSAPI Mechanism, Version 2
+
+Status of This Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all 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/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   Comments on this document should be sent to
+   "ietf-cat-wg@lists.stanford.edu", the IETF Common Authentication
+   Technology WG discussion list.
+
+Abstract
+
+   This document defines protocols, procedures, and conventions to be
+   employed by peers implementing the Generic Security Service
+   Application Program Interface (as specified in RFC 2743) when using
+   Kerberos Version 5 technology (as specified in RFC 1510).  This
+   obsoletes RFC 1964.
+
+Acknowledgements
+
+   Much of the material in this specification is based on work done for
+   Cygnus Solutions by Marc Horowitz.
+
+Table of Contents
+
+   Status of This Memo ............................................    1
+   Abstract .......................................................    1
+   Acknowledgements ...............................................    1
+   Table of Contents ..............................................    1
+   1.  Introduction ...............................................    3
+   2.  Token Formats ..............................................    3
+      2.1.  Packet Notation .......................................    3
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 1]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+      2.2.  Mechanism OID .........................................    4
+      2.3.  Context Establishment .................................    4
+         2.3.1.  Option Format ....................................    4
+            2.3.1.1.  Delegated Credentials Option ................    5
+            2.3.1.2.  Null Option .................................    5
+         2.3.2.  Initial Token ....................................    6
+            2.3.2.1.  Data to be Checksummed in APREQ .............    8
+         2.3.3.  Response Token ...................................   10
+      2.4.  Per-message Tokens ....................................   12
+         2.4.1.  Sequence Number Usage ............................   12
+         2.4.2.  MIC Token ........................................   12
+            2.4.2.1.  Data to be Checksummed in MIC Token .........   13
+         2.4.3.  Wrap Token .......................................   14
+            2.4.3.1.  Wrap Token With Integrity Only ..............   14
+            2.4.3.2.  Wrap Token With Integrity and Encryption
+                      .............................................   15
+               2.4.3.2.1.  Data to be Encrypted in Wrap Token .....   16
+   3.  ASN.1 Encoding of Octet Strings ............................   17
+   4.  Name Types .................................................   18
+      4.1.  Mandatory Name Forms ..................................   18
+         4.1.1.  Kerberos Principal Name Form .....................   18
+         4.1.2.  Exported Name Object Form for Kerberos5
+                 Mechanism ........................................   19
+   5.  Credentials ................................................   20
+   6.  Parameter Definitions ......................................   20
+      6.1.  Minor Status Codes ....................................   20
+         6.1.1.  Non-Kerberos-specific codes ......................   21
+         6.1.2.  Kerberos-specific-codes ..........................   21
+   7.  Kerberos Protocol Dependencies .............................   22
+   8.  Security Considerations ....................................   22
+   9.  References .................................................   22
+   10.  Author's Address ..........................................   23
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 2]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+1.  Introduction
+
+   The original Kerberos 5 GSSAPI mechanism[RFC1964] has a number of
+   shortcomings.  This document attempts to remedy them by defining a
+   completely new Kerberos 5 GSSAPI mechanism.
+
+   The context establishment token format requires that the
+   authenticator of AP-REQ messages contain a cleartext data structure
+   in its checksum field, which is a needless and potentially confusing
+   overloading of that field.  This is implemented by a special checksum
+   algorithm whose purpose is to copy the input data directly into the
+   checksum field of the authenticator.
+
+   The number assignments for checksum algorithms and for encryption
+   types are inconsistent between the Kerberos protocol and the original
+   GSSAPI mechanism.  If new encryption or checksum algorithms are added
+   to the Kerberos protocol at some point, the GSSAPI mechanism will
+   need to be separately updated to use these new algorithms.
+
+   The original mechanism specifies a crude method of key derivation (by
+   using the XOR of the context key with a fixed constant), which is
+   incompatible with newer cryptosystems which specify key derivation
+   procedures themselves.  The original mechanism also assumes that both
+   checksums and cryptosystem blocksizes are eight bytes.
+
+   Defining all GSSAPI tokens for the new Kerberos 5 mechanism in terms
+   of the Kerberos protocol specification ensures that new encryption
+   types and checksum types may be automatically used as they are
+   defined for the Kerberos protocol.
+
+2.  Token Formats
+
+   All tokens, not just the initial token, are framed as the
+   InitialContextToken described in RFC 2743 section 3.1.  The
+   innerContextToken element of the token will not itself be encoded in
+   ASN.1, with the exception of caller-provided application data.
+
+   One rationale for avoiding the use of ASN.1 in the inner token is
+   that some implementors may wish to implement this mechanism in a
+   kernel or other similarly constrained application where handling of
+   full ASN.1 encoding may be cumbersome.  Also, due to the poor
+   availability of the relevant standards documents, ASN.1 encoders and
+   decoders are difficult to implement completely correctly, so keeping
+   ASN.1 usage to a minimum decreases the probability of bugs in the
+   implementation of the mechanism.  In particular, bit strings need to
+   be transferred at certain points in this mechanism.  There are many
+   conflicting common misunderstandings of how to encode and decode
+   ASN.1 bit strings, which have led difficulties in the implementaion
+   of the Kerberos protocol.
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 3]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+2.1.  Packet Notation
+
+   The order of transmission of this protocol is described at the octet
+   level.  Packet diagrams depict bits in the order of transmission,
+   assuming that individual octets are transmitted with the most
+   significant bit (MSB) first.  The diagrams read from left to right
+   and from top to bottom, as in printed English.  In each octet, bit
+   number 7 is the MSB and bit number 0 is the LSB.
+
+   Numbers prefixed by the characters "0x" are in hexadecimal notation,
+   as in the C programming language.  Even though packet diagrams are
+   drawn 16 bits wide, no padding should be used to align the ends of
+   variable-length fields to a 32-bit or 16-bit boundary.
+
+   All integer fields are in network byte order.  All other fields have
+   the size shown in the diagrams, with the exception of variable length
+   fields.
+
+2.2.  Mechanism OID
+
+   The Object Identifier (OID) of the new krb5 v2 mechanism is:
+
+   {iso(1) member-body(2) us(840) mit(113554) infosys(1) gssapi(2)
+   krb5v2(3)}
+
+
+2.3.  Context Establishment
+
+2.3.1.  Option Format
+
+   Context establishment tokens, i.e., the initial ones that the
+   GSS_Init_sec_context() and the GSS_Accept_sec_context() calls emit
+   while a security context is being set up, may contain options that
+   influence the subsequent behavior of the context.  This document
+   describes only a small set of options, but additional types may be
+   added by documents intended to supplement this one.  The generic
+   format is as follows:
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                          option type                          |
+     +-------------------------------+-------------------------------+
+  2  |                                                               |
+     +--                  option length (32 bits)                  --+
+  4  |                                                               |
+     +-------------------------------+-------------------------------+
+  6  |                               .                               |
+     /                 option data (variable length)                 /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 4]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   option type (16 bits)
+        The type identifier of the following option.
+
+   option length (32 bits)
+        The length in bytes of the following option.
+
+   option data (variable length)
+        The actual option data.
+
+   Any number of options may appear in an initator or acceptor token.
+   The final option in a token must be the null option, in order to mark
+   the end of the list.  Option type 0xffff is reserved.
+
+   The initiator and acceptor shall ignore any options that they do not
+   understand.
+
+2.3.1.1.  Delegated Credentials Option
+
+   Only the initiator may use this option.  The format of the delegated
+   credentials option is as follows:
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                     option type = 0x00001                     |
+     +-------------------------------+-------------------------------+
+  2  |                                                               |
+     +--                      KRB-CRED length                      --+
+  4  |                                                               |
+     +-------------------------------+-------------------------------+
+  6  |                               .                               |
+     /                        KRB-CRED message                       /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   option type (16 bits)
+        The option type for this option shall be 0x0001.
+
+   KRB-CRED length (32 bits)
+        The length in bytes of the following KRB-CRED message.
+
+   KRB-CRED message (variable length)
+        The option data for this option shall be the KRB-CRED message
+        that contains the credentials being delegated (forwarded) to the
+        context acceptor.  Only the initiator may use this option.
+
+2.3.1.2.  Null Option
+
+   The Null option terminates the option list, and must be used by both
+   the initiator and the acceptor.  Its format is as follows:
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 5]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                        option type = 0                        |
+     +-------------------------------+-------------------------------+
+  2  |                                                               |
+     +--                         length = 0                        --+
+  4  |                                                               |
+     +-------------------------------+-------------------------------+
+
+
+   option type (16 bits)
+        The option type of this option must be zero.
+
+   option length (32 bits)
+        The length of this option must be zero.
+
+2.3.2.  Initial Token
+
+   This is the initial token sent by the context initiator, generated by
+   GSS_Init_sec_context().
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                   initial token id = 0x0101                   |
+     +-------------------------------+-------------------------------+
+  2  |                                                               |
+     +--         reserved flag bits          +-----------------------+
+  4  |                                       | I | C | S | R | M | D |
+     +-------------------------------+-------------------------------+
+  6  |                      checksum type count                      |
+     +-------------------------------+-------------------------------+
+  8  |                               .                               |
+     /                       checksum type list                      /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  n  |                               .                               |
+     /                            options                            /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  m  |                                                               |
+     +--                       AP-REQ length                       --+
+ m+2 |                                                               |
+     +-------------------------------+-------------------------------+
+ m+4 |                               .                               |
+     /                          AP-REQ data                          /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   initial token ID (16 bits)
+        Contains the integer 0x0101, which identifies this as the
+        initial token in the context setup.
+
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 6]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   reserved flag bits (26 bits)
+        These bits are reserved for future expansion.  They must be set
+        to zero by the initiator and be ignored by the acceptor.
+
+   I flag (1 bit)
+        0x00000020 -- GSS_C_INTEG_FLAG
+
+   C flag (1 bit)
+        0x00000010 -- GSS_C_CONF_FLAG
+
+   S flag (1 bit)
+        0x00000008 -- GSS_C_SEQUENCE_FLAG
+
+   R flag (1 bit)
+        0x00000004 -- GSS_C_REPLAY_FLAG
+
+   M flag (1 bit)
+        0x00000002 -- GSS_C_MUTUAL_FLAG
+
+   D flag (1 bit)
+        0x00000001 -- GSS_C_DELEG_FLAG; This flag must be set if the
+        "delegated credentials" option is included.
+
+   checksum type count (16 bits)
+        The number of checksum types supported by the initiator.
+
+   checksum type list (variable length)
+        A list of Kerberos checksum types, as defined in RFC 1510
+        section 6.4. These checksum types must be collision-proof and
+        keyed with the context key; no checksum types that are
+        incompatible with the encryption key shall be used.  Each
+        checksum type number shall be 32 bits wide.  This list should
+        contain all the checksum types supported by the initiator.  If
+        mutual authentication is not used, then this list shall contain
+        only one checksum type.
+
+   options (variable length)
+        The context initiation options, described in section 2.3.1.
+
+   AP-REQ length (32 bits)
+        The length of the following KRB_AP_REQ message.
+
+   AP-REQ data (variable length)
+        The AP-REQ message as described in RFC 1510.  The checksum in
+        the authenticator will be computed over the items listed in the
+        next section.
+
+   The optional sequence number field shall be used in the AP-REQ.  The
+   initiator should generate a subkey in the authenticator, and the
+   acceptor should generate a subkey in the AP-REP.  The key used for
+   the per-message tokens will be the AP-REP subkey, or if that is not
+   present, the authenticator subkey, or if that is not present, the
+   session key.  When subkeys are generated, it is strongly recommended
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 7]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   that they be of the same type as the associated session key.
+
+   XXX The above is not secure.  There should be an algorithmic process
+   to arrive at a subsession key which both sides of the authentication
+   exchange can perform based on the ticket sessions key and data known
+   to both parties, and this should probably be part of the revised
+   Kerberos protocol rather than bound to the GSSAPI mechanism.
+
+2.3.2.1.  Data to be Checksummed in AP-REQ
+
+   The checksum in the AP-REQ message is calculated over the following
+   items.  Like in the actual tokens, no padding should be added to
+   force integer fields to align on 32 bit boundaries.  This particular
+   set of data should not be sent as a part of any token; it merely
+   specifies what is to be checksummed in the AP-REQ.  The items in this
+   encoding that precede the initial token ID correspond to the channel
+   bindings passed to GSS_Init_sec_context().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 8]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                                                               |
+     +--                   initiator address type                  --+
+  2  |                                                               |
+     +-------------------------------+-------------------------------+
+  4  |                    initiator address length                   |
+     +-------------------------------+-------------------------------+
+  6  |                               .                               |
+     /                       initiator address                       /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  n  |                                                               |
+     +--                   acceptor address type                   --+
+     |                                                               |
+     +-------------------------------+-------------------------------+
+ n+4 |                    acceptor address length                    |
+     +-------------------------------+-------------------------------+
+ n+6 |                               .                               |
+     /                        acceptor address                       /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  m  |                               .                               |
+     /                        application data                       /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  k  |                   initial token id = 0x0101                   |
+     +-------------------------------+-------------------------------+
+ k+2 |                                                               |
+     +--                           flags                           --+
+ k+4 |                                                               |
+     +-------------------------------+-------------------------------+
+ k+6 |                      checksum type count                      |
+     +-------------------------------+-------------------------------+
+ k+8 |                               .                               |
+     /                       checksum type list                      /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  j  |                               .                               |
+     /                            options                            /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   initiator address type (32 bits)
+        The initiator address type, as defined in the Kerberos protocol
+        specification.  If no initiator address is provided, this must
+        be zero.
+
+   initiator address length (16 bits)
+        The length in bytes of the following initiator address.  If
+        there is no inititator address provided, this must be zero.
+
+
+Yu                  Document Expiration: 04 Sep 2000            [Page 9]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   initiator address (variable length)
+        The actual initiator address, in network byte order.
+
+   acceptor address type (32 bits)
+        The acceptor address type, as defined in the Kerberos protocol
+        specification.  If no acceptor address is provided, this must be
+        zero.
+
+   acceptor address length (16 bits)
+        The length in bytes of the following acceptor address.  This
+        must be zero is there is no acceptor address provided.
+
+   initiator address (variable length)
+        The actual acceptor address, in network byte order.
+
+   applicatation data (variable length)
+        The application data, if provided, encoded as a ASN.1 octet
+        string using DER.  If no application data are passed as input
+        channel bindings, this shall be a zero-length ASN.1 octet
+        string.
+
+   initial token ID (16 bits)
+        The initial token ID from the initial token.
+
+   flags (32 bits)
+        The context establishment flags from the initial token.
+
+   checksum type count (16 bits)
+        The number of checksum types supported by the initiator.
+
+   checksum type list (variable length)
+        The same list of checksum types contained in the initial token.
+
+   options (variable length)
+        The options list from the initial token.
+
+2.3.3.  Response Token
+
+   This is the reponse token sent by the context acceptor, if mutual
+   authentication is enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 10]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                   response token id = 0x0202                  |
+     +-------------------------------+-------------------------------+
+  2  |                                                               |
+     +--                  reserved flag bits                 +-------+
+  4  |                                                       | D | E |
+     +-------------------------------+-------------------------------+
+  6  |                                                               |
+     +--                       checksum type                       --+
+  8  |                                                               |
+     +-------------------------------+-------------------------------+
+ 10  |                               .                               |
+     /                            options                            /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  n  |                                                               |
+     +--                 AP-REP or KRB-ERROR length                --+
+ n+2 |                                                               |
+     +-------------------------------+-------------------------------+
+ n+4 |                               .                               |
+     /                    AP-REP or KRB-ERROR data                   /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  m  |                               .                               |
+     /                            MIC data                           /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   response token id (16 bits)
+        Contains the integer 0x0202, which identifies this as the
+        response token in the context setup.
+
+   reserved flag bits (30 bits)
+        These bits are reserved for future expansion.  They must be set
+        to zero by the acceptor and be ignored by the initiator.
+
+   D flag -- delegated creds accepted (1 bit)
+        0x00000002 -- If this flag is set, the acceptor processed the
+        delegated credentials, and GSS_C_DELEG_FLAG should be returned
+        to the caller.
+
+   E flag -- error (1 bit)
+        0x00000001 -- If this flag is set, a KRB-ERROR message shall be
+        present, rather than an AP-REP message.  If this flag is not
+        set, an AP-REP message shall be present.
+
+   checksum type count (16 bits)
+        The number of checksum types supported by both the initiator and
+        the acceptor.
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 11]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   checksum type (32 bits)
+        A Kerberos checksum type, as defined in RFC 1510 section 6.4.
+        This checksum type must be among the types listed by the
+        initiator, and will be used in for subsequent checksums
+        generated during this security context.
+
+   options (variable length)
+        The option list, as described earlier.  At this time, no options
+        are defined for the acceptor, but an implementation might make
+        use of these options to acknowledge an option from the initial
+        token.  After all the options are specified, a null option must
+        be used to terminate the list.
+
+   AP-REP or KRB-ERROR length (32 bits)
+        Depending on the value of the error flag, length in bytes of the
+        AP-REP or KRB-ERROR message.
+
+   AP-REP or KRB-ERROR data (variable length)
+        Depending on the value of the error flag, the AP-REP or
+        KRB-ERROR message as described in RFC 1510.  If this field
+        contains an AP-REP message, the sequence number field in the
+        AP-REP shall be filled.  If this is a KRB-ERROR message, no
+        further fields will be in this message.
+
+   MIC data (variable length)
+        A MIC token, as described in section 2.4.2, computed over the
+        concatentation of the response token ID, flags, checksum length
+        and type fields, and all option fields.  This field and the
+        preceding length field must not be present if the error flag is
+        set.
+
+2.4.  Per-message Tokens
+
+2.4.1.  Sequence Number Usage
+
+   Sequence numbers for per-message tokens are 31 bit unsigned integers,
+   which are incremented by 1 after each token.  An overflow condition
+   should result in a wraparound of the sequence number to zero.  The
+   initiator and acceptor each keep their own sequence numbers per
+   connection.
+
+   The intial sequence number for tokens sent from the initiator to the
+   acceptor shall be the least significant 31 bits of sequence number in
+   the AP-REQ message.  The initial sequence number for tokens sent from
+   the acceptor to the initiator shall be the least significant 31 bits
+   of the sequence number in the AP-REP message if mutual authentication
+   is used; if mutual authentication is not used, the initial sequence
+   number from acceptor to initiator shall be the least significant 31
+   bits of the sequence number in the AP-REQ message.
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 12]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+2.4.2.  MIC Token
+
+   Use of the GSS_GetMIC() call yields a token, separate from the user
+   data being protected, which can be used to verify the integrity of
+   that data when it is received.  The MIC token has the following
+   format:
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                     MIC token id = 0x0303                     |
+     +-------------------------------+-------------------------------+
+  2  | D |                                                           |
+     +---+                     sequence number                     --+
+  4  |                                                               |
+     +-------------------------------+-------------------------------+
+  6  |                        checksum length                        |
+     +-------------------------------+-------------------------------+
+  8  |                               .                               |
+     /                         checksum data                         /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   MIC token id (16 bits)
+        Contains the integer 0x0303, which identifies this as a MIC
+        token.
+
+   D -- direction bit (1 bit)
+        This bit shall be zero if the message is sent from the context
+        initiator.  If the message is sent from the context acceptor,
+        this bit shall be one.
+
+   sequence number (31 bits)
+        The sequence number.
+
+   checksum length (16 bits)
+        The number of bytes in the following checksum data field.
+
+   checksum data (variable length)
+        The checksum itself, as defined in RFC 1510 section 6.4.  The
+        checksum is calculated over the encoding described in the
+        following section.  The key usage GSS_TOK_MIC -- 22 [XXX need to
+        register this] shall be used in cryptosystems that support key
+        derivation.
+
+   The mechanism implementation shall only use the checksum type
+   returned by the acceptor in the case of mutual authentication.  If
+   mutual authentication is not requested, then only the checksum type
+   in the initiator token shall be used.
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 13]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+2.4.2.1.  Data to be Checksummed in MIC Token
+
+   The checksum in the MIC token shall be calculated over the following
+   elements.  This set of data is not actually included in the token as
+   is; the description only appears for the purpose of specifying the
+   method of calculating the checksum.
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                     MIC token id = 0x0303                     |
+     +-------------------------------+-------------------------------+
+  2  | D |                                                           |
+     +---+                     sequence number                     --+
+  4  |                                                               |
+     +-------------------------------+-------------------------------+
+  6  |                               .                               |
+     /                        application data                       /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   MIC token ID (16 bits)
+        The MIC token ID from the MIC message.
+
+   D -- direction bit (1 bit)
+        This bit shall be zero if the message is sent from the context
+        initiator.  If the message is sent from the context acceptor,
+        this bit shall be one.
+
+   sequence number (31 bits)
+        The sequence number.
+
+   application data (variable length)
+        The application-supplied data, encoded as an ASN.1 octet string
+        using DER.
+
+2.4.3.  Wrap Token
+
+   Use of the GSS_Wrap() call yields a token which encapsulates the
+   input user data (optionally encrypted) along with associated
+   integrity check quantities.
+
+2.4.3.1.  Wrap Token With Integrity Only
+
+
+
+
+
+
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 14]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  |                integrity wrap token id = 0x0404               |
+     +-------------------------------+-------------------------------+
+  2  | D |                                                           |
+     +---+                     sequence number                     --+
+  4  |                                                               |
+     +-------------------------------+-------------------------------+
+  6  |                               .                               |
+     /                        application data                       /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+  n  |                        checksum length                        |
+     +-------------------------------+-------------------------------+
+ n+2 |                               .                               |
+     /                         checksum data                         /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   integrity wrap token id (16 bits)
+        Contains the integer 0x0404, which identifies this as a Wrap
+        token with integrity only.
+
+   D -- direction bit (1 bit)
+        This bit shall be zero if the message is sent from the context
+        initiator.  If the message is sent from the context acceptor,
+        this bit shall be one.
+
+   sequence number (31 bits)
+        The sequence number.
+
+   application data (variable length)
+        The application-supplied data, encoded as an ASN.1 octet string
+        using DER.
+
+   checksum length (16 bits)
+        The number of bytes in the following checksum data field.
+
+   checksum data (variable length)
+        The checksum itself, as defined in RFC 1510 section 6.4,
+        computed over the concatenation of the token ID, sequence
+        number, direction field, application data length, and
+        application data, as in the MIC token checksum in the previous
+        section.  The key usage GSS_TOK_WRAP_INTEG -- 23 [XXX need to
+        register this] shall be used in cryptosystems that support key
+        derivation.
+
+   The mechanism implementation should only use checksum types which it
+   knows to be valid for both peers, as described for MIC tokens.
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 15]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+2.4.3.2.  Wrap Token With Integrity and Encryption
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+     |                encrypted wrap token id = 0x0505               |
+     +-------------------------------+-------------------------------+
+  2  |                               .                               |
+     /                         encrypted data                        /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   encrypted wrap token id (16 bits)
+        Contains the integer 0x0505, which identifies this as a Wrap
+        token with integrity and encryption.
+
+   encrypted data (variable length)
+        The encrypted data itself, as defined in RFC 1510 section 6.3,
+        encoded as an ASN.1 octet string using DER.  Note that this is
+        not the ASN.1 type EncryptedData as defined in RFC 1510
+        section 6.1, but rather the ciphertext without encryption type
+        or kvno information.  The encryption is performed using the
+        key/enctype exchanged during context setup.  The confounder and
+        checksum are as specified in the Kerberos protocol
+        specification.  The key usage GSS_TOK_WRAP_PRIV -- 24 [XXX need
+        to register this] shall be used in cryptosystems that support
+        key derivation.  The actual data to be encrypted are specified
+        below.
+
+2.4.3.2.1.  Data to be Encrypted in Wrap Token
+
+  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+byte +-------------------------------+-------------------------------+
+  0  | D |                                                           |
+     +---+                     sequence number                     --+
+  2  |                                                               |
+     +-------------------------------+-------------------------------+
+  4  |                               .                               |
+     /                        application data                       /
+     |                               .                               |
+     +-------------------------------+-------------------------------+
+
+
+   D -- direction bit (1 bit)
+        This bit shall be zero if the message is sent from the context
+        initiator.  If the message is sent from the context acceptor,
+        this bit shall be one.
+
+   sequence number (31 bits)
+        The sequence number.
+
+   application data (variable length)
+        The application-supplied data, encoded as an ASN.1 octet string
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 16]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+        using DER.
+
+3.  ASN.1 Encoding of Octet Strings
+
+   In order to encode arbitirarly-sized application data, ASN.1 octet
+   string encoding is in this protocol.  The Distinguished Encoding
+   Rules (DER) shall always be used in such cases.  For reference
+   purposes, the DER encoding of an ASN.1 octet string, adapted from
+   ITU-T X.690, follows:
+
+   +--------+-------//-------+-------//-------+
+   |00000100| length octets  |contents octets |
+   +--------+-------//-------+-------//-------+
+    |
+    +-- identifier octet = 0x04 = [UNIVERSAL 4]
+
+
+   In this section only, the bits in each octet shall be numbered as in
+   the ASN.1 specification, from 8 to 1, with bit 8 being the MSB of the
+   octet, and with bit 1 being the LSB of the octet.
+
+   identifier octet (8 bits)
+        Contains the constant 0x04, the tag for primitive encoding of an
+        octet string with the default (UNIVERSAL 4) tag.
+
+   length octets (variable length)
+        Contains the length of the contents octets, in definite form
+        (since this encoding uses DER).
+
+   contents octets (variable length)
+        The contents of the octet string.
+
+   The length octets shall consist of either a short form (one byte
+   only), which is to be used only if the number of octets in the
+   contents octets is less than or equal to 127, or a long form, which
+   is to be used in all other cases.  The short form shall consist of a
+   single octet with bit 8 (the MSB) equal to zero, and the remaining
+   bits encoding the number of contents octets (which may be zero) as an
+   unsigned binary integer.
+
+   The long form shall consist of an initial octet and one or more
+   subsequent octets.  The first octet shall have bit 8 (the MSB) set to
+   one, and the remaining bits shall encode the number of subsequent
+   octets in the length encoding as an unsigned binary integer.  The
+   length must be encoded in the minimum number of octets.  An initial
+   octet of 0xFF is reserved by the ASN.1 specification.  Bits 8 to 1 of
+   the first subsequent octet, followed by bits 8 to 1 of each
+   subsequent octet in order, shall be the encoding of an unsigned
+   binary integer, with bit 8 of the first octet being the most
+   significant bit.  Thus, the length encoding within is in network byte
+   order.
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 17]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   An initial length octet of 0x80 shall not be used, as that is
+   reserved by the ASN.1 specification for indefinite lengths in
+   conjunction with constructed contents encodings, which are not to be
+   used with DER.
+
+4.  Name Types
+
+   This section discusses the name types which may be passed as input to
+   the Kerberos 5 GSSAPI mechanism's GSS_Import_name() call, and their
+   associated identifier values.  It defines interface elements in
+   support of portability, and assumes use of C language bindings per
+   RFC 2744.  In addition to specifying OID values for name type
+   identifiers, symbolic names are included and recommended to GSSAPI
+   implementors in the interests of convenience to callers.  It is
+   understood that not all implementations of the Kerberos 5 GSSAPI
+   mechanism need support all name types in this list, and that
+   additional name forms will likely be added to this list over time.
+   Further, the definitions of some or all name types may later migrate
+   to other, mechanism-independent, specifications.  The occurrence of a
+   name type in this specification is specifically not intended to
+   suggest that the type may be supported only by an implementation of
+   the Kerberos 5 mechanism.  In particular, the occurrence of the
+   string "_KRB5_" in the symbolic name strings constitutes a means to
+   unambiguously register the name strings, avoiding collision with
+   other documents; it is not meant to limit the name types' usage or
+   applicability.
+
+   For purposes of clarification to GSSAPI implementors, this section's
+   discussion of some name forms describes means through which those
+   forms can be supported with existing Kerberos technology.  These
+   discussions are not intended to preclude alternative implementation
+   strategies for support of the name forms within Kerberos mechanisms
+   or mechanisms based on other technologies.  To enhance application
+   portability, implementors of mechanisms are encouraged to support
+   name forms as defined in this section, even if their mechanisms are
+   independent of Kerberos 5.
+
+4.1.  Mandatory Name Forms
+
+   This section discusses name forms which are to be supported by all
+   conformant implementations of the Kerberos 5 GSSAPI mechanism.
+
+4.1.1.  Kerberos Principal Name Form
+
+   This name form shall be represented by the Object Identifier {iso(1)
+   member-body(2) us(840) mit(113554) infosys(1) gssapi(2) krb5(2)
+   krb5_name(1)}.  The recommended symbolic name for this type is
+   "GSS_KRB5_NT_PRINCIPAL_NAME".
+
+   This name type corresponds to the single-string representation of a
+   Kerberos name.  (Within the MIT Kerberos 5 implementation, such names
+   are parseable with the krb5_parse_name() function.)  The elements
+   included within this name representation are as follows, proceeding
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 18]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   from the beginning of the string:
+
+        (1) One or more principal name components; if more than one
+        principal name component is included, the components are
+        separated by '/'.  Arbitrary octets may be included within
+        principal name components, with the following constraints and
+        special considerations:
+
+           (1a) Any occurrence of the characters '@' or '/' within a
+           name component must be immediately preceded by the '\'
+           quoting character, to prevent interpretation as a component
+           or realm separator.
+
+           (1b) The ASCII newline, tab, backspace, and null characters
+           may occur directly within the component or may be
+           represented, respectively, by '\n', '\t', '\b', or '\0'.
+
+           (1c) If the '\' quoting character occurs outside the contexts
+           described in (1a) and (1b) above, the following character is
+           interpreted literally.  As a special case, this allows the
+           doubled representation '\\' to represent a single occurrence
+           of the quoting character.
+
+           (1d) An occurrence of the '\' quoting character as the last
+           character of a component is illegal.
+
+        (2) Optionally, a '@' character, signifying that a realm name
+        immediately follows. If no realm name element is included, the
+        local realm name is assumed.  The '/' , ':', and null characters
+        may not occur within a realm name; the '@', newline, tab, and
+        backspace characters may be included using the quoting
+        conventions described in (1a), (1b), and (1c) above.
+
+4.1.2.  Exported Name Object Form for Kerberos 5 Mechanism
+
+   When generated by the Kerberos 5 mechanism, the Mechanism OID within
+   the exportable name shall be that of the original Kerberos 5
+   mechanism[RFC1964].  The Mechanism OID for the original Kerberos 5
+   mechanism is:
+
+   {iso(1) member-body(2) us(840) mit(113554) infosys(1) gssapi(2)
+   krb5(2)}
+
+   The name component within the exportable name shall be a contiguous
+   string with structure as defined for the Kerberos Principal Name
+   Form.
+
+   In order to achieve a distinguished encoding for comparison purposes,
+   the following additional constraints are imposed on the export
+   operation:
+
+        (1) all occurrences of the characters '@', '/', and '\' within
+        principal components or realm names shall be quoted with an
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 19]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+        immediately-preceding '\'.
+
+        (2) all occurrences of the null, backspace, tab, or newline
+        characters within principal components or realm names will be
+        represented, respectively, with '\0', '\b', '\t', or '\n'.
+
+        (3) the '\' quoting character shall not be emitted within an
+        exported name except to accomodate cases (1) and (2).
+
+5.  Credentials
+
+   The Kerberos 5 protocol uses different credentials (in the GSSAPI
+   sense) for initiating and accepting security contexts.  Normal
+   clients receive a ticket-granting ticket (TGT) and an associated
+   session key at "login" time; the pair of a TGT and its corresponding
+   session key forms a credential which is suitable for initiating
+   security contexts.  A ticket-granting ticket, its session key, and
+   any other (ticket, key) pairs obtained through use of the
+   ticket-granting-ticket, are typically stored in a Kerberos 5
+   credentials cache, sometimes known as a ticket file.
+
+   The encryption key used by the Kerberos server to seal tickets for a
+   particular application service forms the credentials suitable for
+   accepting security contexts.  These service keys are typically stored
+   in a Kerberos 5 key table (keytab), or srvtab file (the Kerberos 4
+   terminology).  In addition to their use as accepting credentials,
+   these service keys may also be used to obtain initiating credentials
+   for their service principal.
+
+   The Kerberos 5 mechanism's credential handle may contain references
+   to either or both types of credentials.  It is a local matter how the
+   Kerberos 5 mechanism implementation finds the appropriate Kerberos 5
+   credentials cache or key table.
+
+   However, when the Kerberos 5 mechanism attempts to obtain initiating
+   credentials for a service principal which are not available in a
+   credentials cache, and the key for that service principal is
+   available in a Kerberos 5 key table, the mechanism should use the
+   service key to obtain initiating credentials for that service.  This
+   should be accomplished by requesting a ticket-granting-ticket from
+   the Kerberos Key Distribution Center (KDC), and decrypting the KDC's
+   reply using the service key.
+
+6.  Parameter Definitions
+
+   This section defines parameter values used by the Kerberos V5 GSSAPI
+   mechanism.  It defines interface elements in support of portability,
+   and assumes use of C language bindings per RFC 2744.
+
+6.1.  Minor Status Codes
+
+   This section recommends common symbolic names for minor_status values
+   to be returned by the Kerberos 5 GSSAPI mechanism.  Use of these
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 20]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   definitions will enable independent implementors to enhance
+   application portability across different implementations of the
+   mechanism defined in this specification.  (In all cases,
+   implementations of GSS_Display_status() will enable callers to
+   convert minor_status indicators to text representations.)  Each
+   implementation should make available, through include files or other
+   means, a facility to translate these symbolic names into the concrete
+   values which a particular GSSAPI implementation uses to represent the
+   minor_status values specified in this section.
+
+   It is recognized that this list may grow over time, and that the need
+   for additional minor_status codes specific to particular
+   implementations may arise.  It is recommended, however, that
+   implementations should return a minor_status value as defined on a
+   mechanism-wide basis within this section when that code is accurately
+   representative of reportable status rather than using a separate,
+   implementation-defined code.
+
+6.1.1.  Non-Kerberos-specific codes
+
+   These symbols should likely be incorporated into the generic GSSAPI
+   C-bindings document, since they really are more general.
+
+GSS_KRB5_S_G_BAD_SERVICE_NAME
+        /* "No @ in SERVICE-NAME name string" */
+GSS_KRB5_S_G_BAD_STRING_UID
+        /* "STRING-UID-NAME contains nondigits" */
+GSS_KRB5_S_G_NOUSER
+        /* "UID does not resolve to username" */
+GSS_KRB5_S_G_VALIDATE_FAILED
+        /* "Validation error" */
+GSS_KRB5_S_G_BUFFER_ALLOC
+        /* "Couldn't allocate gss_buffer_t data" */
+GSS_KRB5_S_G_BAD_MSG_CTX
+        /* "Message context invalid" */
+GSS_KRB5_S_G_WRONG_SIZE
+        /* "Buffer is the wrong size" */
+GSS_KRB5_S_G_BAD_USAGE
+        /* "Credential usage type is unknown" */
+GSS_KRB5_S_G_UNKNOWN_QOP
+        /* "Unknown quality of protection specified" */
+
+
+6.1.2.  Kerberos-specific-codes
+
+
+
+
+
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 21]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+GSS_KRB5_S_KG_CCACHE_NOMATCH
+        /* "Principal in credential cache does not match desired name" */
+GSS_KRB5_S_KG_KEYTAB_NOMATCH
+        /* "No principal in keytab matches desired name" */
+GSS_KRB5_S_KG_TGT_MISSING
+        /* "Credential cache has no TGT" */
+GSS_KRB5_S_KG_NO_SUBKEY
+        /* "Authenticator has no subkey" */
+GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
+        /* "Context is already fully established" */
+GSS_KRB5_S_KG_BAD_SIGN_TYPE
+        /* "Unknown signature type in token" */
+GSS_KRB5_S_KG_BAD_LENGTH
+        /* "Invalid field length in token" */
+GSS_KRB5_S_KG_CTX_INCOMPLETE
+        /* "Attempt to use incomplete security context" */
+
+
+7.  Kerberos Protocol Dependencies
+
+   This protocol makes several assumptions about the Kerberos protocol,
+   which may require changes to the successor of RFC 1510.
+
+   Sequence numbers, checksum types, and address types are assumed to be
+   no wider than 32 bits.  The Kerberos protocol specification might
+   need to be modified to accomodate this.  This obviously requires some
+   further discussion.
+
+   Key usages need to be registered within the Kerberos protocol for use
+   with GSSAPI per-message tokens.  The current specification of the
+   Kerberos protocol does not include descriptions of key derivations or
+   key usages, but planned revisions to the protocol will include them.
+
+   This protocol also makes the assumption that any cryptosystem used
+   with the session key will include integrity protection, i.e., it
+   assumes that no "raw" cryptosystems will be used.
+
+8.  Security Considerations
+
+   The GSSAPI is a security protocol; therefore, security considerations
+   are discussed throughout this document.  The original Kerberos 5
+   GSSAPI mechanism's constraints on possible cryptosystems and checksum
+   types do not permit it to be readily extended to accomodate more
+   secure cryptographic technologies with larger checksums or encryption
+   block sizes.  Sites are strongly encouraged to adopt the mechanism
+   specified in this document in the light of recent publicity about the
+   deficiencies of DES.
+
+9.  References
+
+   [X.680] ISO/IEC, "Information technology -- Abstract Syntax Notation
+   One (ASN.1): Specification of basic notation", ITU-T X.680 (1997) |
+   ISO/IEC 8824-1:1998
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 22]
+
+Internet-Draft             krb5-gss-mech2-03                  March 2000
+
+   [X.690] ISO/IEC, "Information technology -- ASN.1 encoding rules:
+   Specification of Basic Encoding Rules (BER), Canonical Encoding Rules
+   (CER) and Distinguished Encoding Rules (DER)", ITU-T X.690 (1997) |
+   ISO/IEC 8825-1:1998.
+
+   [RFC1510] Kohl, J., Neumann, C., "The Kerberos Network Authentication
+   Service (V5)", RFC 1510.
+
+   [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+   RFC 1964.
+
+   [RFC2743] Linn, J., "Generic Security Service Application Program
+   Interface, Version 2, Update 1", RFC 2743.
+
+   [RFC2744] Wray, J., "Generic Security Service API Version 2:
+   C-bindings", RFC 2744.
+
+10.  Author's Address
+
+   Tom Yu
+   Massachusetts Institute of Technology
+   Room E40-345
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+   USA
+
+   email: tlyu@mit.edu
+   phone: +1 617 253 1753
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                  Document Expiration: 04 Sep 2000           [Page 23]
+
diff --git a/crypto/heimdal/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt b/crypto/heimdal/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt
new file mode 100644
index 000000000000..24325fdbda74
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt
@@ -0,0 +1,281 @@
+CAT Working Group                                           K. Raeburn
+Internet-draft                                                     MIT
+Category:                                                July 14, 2000
+Updates: RFC 1964
+Document: draft-raeburn-cat-gssapi-krb5-3des-00.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 [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/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
+   encryption types defined by Kerberos, appears to be a better
+   approach.  Efforts to produce such a specification are under way.
+
+   In the interest of providing increased security in the interim,
+   however, MIT is proposing adding support for triple-DES to the
+   existing mechanism, as described here.
+
+2. Conventions Used in this Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
+   this document are to be interpreted as described in RFC 2119.
+
+3. 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 (ought to be described) in [KrbRev].
+
+   [XXX: The current [KrbRev] description refers to expired 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 5.3
+   below for the use of checksum lengths of other than eight bytes.
+
+4. 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
+
+5. Adjustments to Previous Definitions
+
+5.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.
+
+   [Implementation note: MIT's code does not implement QoP, and
+   returns an error for any non-zero QoP value.]
+
+5.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.)
+
+5.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.
+
+6. 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 MUST 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
+   is not likely to 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.
+
+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 5.
+
+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.
+
+   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+   3", RFC 2026, October, 1996.
+
+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." 
diff --git a/crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt b/crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt
new file mode 100644
index 000000000000..64ca1ac498be
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Kerberos Working Group                                        K. Raeburn
+Category: Informational                                              MIT
+Document: draft-raeburn-krb-gssapi-krb5-3des-01.txt    November 24, 2000
+
+
+         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 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 probably a better approach.  Various people have
+   expressed interest in designing one, but the work has not yet been
+   completed.
+
+   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.  So,
+   in the interest of providing increased security in the near term, MIT
+   is adding support for triple-DES to the existing mechanism
+   implementation we ship, as an interim measure.
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 1]
+
+INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
+
+
+2. New Algorithm Identifiers
+
+   One new sealing algorithm is defined, for use in Wrap tokens.
+
+
+   +--------------------------------------------------------------------+
+   |          name                                octet values          |
+   +--------------------------------------------------------------------+
+   |         DES3-KD                                 02 00              |
+   +--------------------------------------------------------------------+
+
+   This algorithm uses triple-DES with key derivation, with a usage
+   value KG_USAGE_SEAL.  (Unlike the EncryptedData definition in
+   [KrbRev], no integrity protection is needed, so this is "raw" triple-
+   DES, with no checksum attached to the encrypted data.)  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.
+
+
+   +--------------------------------------------------------------------+
+   |             name                               octet values        |
+   +--------------------------------------------------------------------+
+   |       HMAC SHA1 DES3-KD                           04 00            |
+   +--------------------------------------------------------------------+
+
+   This algorithm generates an HMAC using SHA-1 and a derived DES3 key
+   with usage KG_USAGE_SIGN, as described in [KrbRev].
+
+   [N.B.: The current [KrbRev] description refers to expired 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 2]
+
+INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
+
+
+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:
+
+
+   +--------------------------------------------------------------------+
+   |             name                                    value          |
+   +--------------------------------------------------------------------+
+   |         KG_USAGE_SEAL                                22            |
+   |         KG_USAGE_SIGN                                23            |
+   |         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 forcing the use of plain DES when the application doesn't
+   use mechanism-specific QOP values, we redefine the explicit DES QOP
+   value as a 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:
+
+   +--------------------------------------------------------------------+
+   |             name                  value      meaning               |
+   +--------------------------------------------------------------------+
+   | GSS_KRB5_INTEG_C_QOP_HMAC_SHA1    0x0004     SHA-1 HMAC, using     |
+   |                                              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 attempt to specify a generic mechanism for deriving a key
+   of one type given a key of another type, and evaluate the security
+   implications of using a short key to generate a longer key to satisfy
+   the requested quality of protection, our implementation will simply
+
+
+
+Raeburn                                                         [Page 3]
+
+INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
+
+
+   return an error if the nonzero QOP value specified does not
+   correspond to the session key type.
+
+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 token:
+
+   Byte #             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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 4]
+
+INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
+
+
+   Wrap token:
+
+   Byte #           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 (e.g., the
+   service key) 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 (most
+   notably the "host" service key), 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
+
+
+
+Raeburn                                                         [Page 5]
+
+INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
+
+
+   principal, which keeps the protection of non-GSSAPI services weaker
+   than necessary.
+
+   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.
+
+   For MIT's 1.2 release, we chose 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
+   weaker protection of non-GSSAPI Kerberos services running earlier
+   versions of the software.
+
+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 5.
+
+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-06.txt, July 4, 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.
+
+
+
+
+Raeburn                                                         [Page 6]
+
+INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
+
+
+   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."
+
+10. Document Change History
+
+>From -00 to -01:
+
+   Converted master to GNU troff and tbl, rewriting tables in the
+   process.
+
+   Specify informational category only.  Modify some text to emphasize
+   that this document intends to describe MIT's extensions.
+
+   Point out that while EncryptedData for 3des-kd includes a checksum,
+   DES3-KD GSS encryption does not.
+
+   Shorten backwards-compatibility descriptions a little.
+
+   Submit to Kerberos working group rather than CAT.
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 7]
+
diff --git a/crypto/heimdal/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt b/crypto/heimdal/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt
new file mode 100644
index 000000000000..321c5ba09986
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt
@@ -0,0 +1,929 @@
+
+
+DHC Working Group                                          S. Medvinsky
+Internet Draft                                                 Motorola
+Document: <draft-smedvinsky-dhc-kerbauth-01.txt>
+Category: Standards Track                                    P.Lalwaney
+Expires: January 2001                                             Nokia
+
+                                                              July 2000
+
+
+        Kerberos V Authentication Mode for Uninitialized Clients
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all 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/ietf/1id-abstracts.txt
+
+   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-
+   smedvinsky-dhc-kerbauth-01.txt>, and expires January 2001. Please
+   send comments to the authors.
+
+
+
+1. Abstract
+
+   The Dynamic Host Configuration Protocol (DHCP) [1] includes an
+   option that allows authentication of all DHCP messages, as specified
+   in [2].  This document specifies a DHCP authentication mode based on
+   Kerberos V tickets. This provides mutual authentication between a
+   DHCP client and server, as well as authentication of all DHCP
+   messages.
+
+   This document specifies Kerberos message exchanges between an
+   uninitialized client and the KDC (Key Distribution Center) using an
+   IAKERB proxy [7] so that the Kerberos key management phase is
+   decoupled from, and precedes the address allocation and network
+   configuration phase that uses the DHCP authentication option.  In
+   order to make use of the IAKERB proxy, this document specifies a
+   transport mechanism that works with an uninitialized client (i.e. a
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+   client without an assigned IP address). In addition, the document
+   specifies the format of the Kerberos authenticator to be used with
+   the DHCP authentication option.
+
+2. Conventions used in this document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
+   this document are to be interpreted as described in RFC-2119.
+
+3. Introduction
+
+   3.1 Terminology
+
+   o "DHCP client"
+
+   A DHCP client is an Internet host using DHCP to obtain configuration
+   parameters such as a network address.
+
+   o "DHCP server"
+
+   A DHCP server is an Internet host that returns configuration
+   parameters to DHCP clients.
+
+   O "Ticket"
+
+   A Kerberos term for a record that helps a client authenticate itself
+   to a server; it contains the client's identity, a session key, a
+   timestamp, and other information, all sealed using the server's
+   secret key. It only serves to authenticate a client when presented
+   along with a fresh Authenticator.
+
+   o "Key Distribution Center"
+
+   Key Distribution Center, a network service that supplies tickets and
+   temporary session keys; or an instance of that service or the host
+   on which it runs. The KDC services both initial ticket and Ticket-
+   Granting Ticket (TGT) requests. The initial ticket portion is
+   sometimes referred to as the Authentication Server (or service. The
+   Ticket-Granting Ticket portion is sometimes referred to as the
+   Ticket-Granting Server (or service).
+
+   o "Realm"
+
+   A Kerberos administrative domain that represents a group of
+   principals registered at a KDC.  A single KDC may be responsible for
+   one or more realms.  A fully qualified principal name includes a
+   realm name along with a principal name unique within that realm.
+
+3.2 Protocol Overview
+
+
+
+S. Medvinsky, P. Lalwaney                                          -2-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+   DHCP as defined in [1] defines the protocol exchanges for a client
+   to obtain its IP address and network configuration information from
+   a DHCP Server. Kerberos V5 as described in [6] defines the protocol
+   and message exchanges to mutually authenticate two parties. It is
+   our goal to provide authentication support for DHCP using Kerberos.
+   This implies that the Kerberos key management exchange has to take
+   place before a client gets its IP address from the DHCP Server.
+   Kerberos assumes that the client has a network address and can
+   contact the Key Distribution Center to obtain its credentials for
+   authenticated communication with an application server.
+
+   In this specification we utilize the key exchange using an IAKERB
+   proxy described in [7]. This does not require any changes to either
+   the IAKERB or the Kerberos V5 specification.  This document also
+   specifies a particular transport that allows an uninitialized client
+   to contact an IAKERB proxy.
+
+   The Kerberos ticket returned from the key management exchange
+   discussed in Section 5 of this document is passed to the DHCP Server
+   inside the DHCP authentication option with the new Kerberos
+   authenticator type. This is described in Section 6 of this draft.
+
+
+3.3 Related Work
+
+   A prior Internet Draft [3] outlined the use of Kerberos-based
+   authentication for DHCP. The proposal tightly coupled the Kerberos
+   client state machines and the DHCP client state machines. As a
+   result, the Kerberos key management messages were carried in DHCP
+   messages, along with the Kerberos authenticators. In addition, the
+   first DHCP message exchange (request, offer) is not authenticated.
+
+   We propose a protocol exchange where Kerberos key management is
+   decoupled from and precedes authenticated DHCP exchanges. This
+   implies that the Kerberos ticket returned in the initial key
+   management exchange could be used to authenticate servers assigning
+   addresses by non-DHCP address assignment mechanisms like RSIP [4]
+   and for service specific parameter provisioning mechanisms using SLP
+   [5].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+S. Medvinsky, P. Lalwaney                                          -3-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+
+4. System Architecture
+
+
+     Client
+    --------                            --------
+   |        |   5.Authenticated DHCP   |        |
+   |  DHCP  |<------------------------>| DHCP   |
+   | client |                          | server |
+   |        |                          |        |
+   |        |                          |        |
+   |Kerberos|                          |        |
+   | Client |                          |        |
+    --------                            --------
+       ^
+       |
+       |
+       |
+       |                                -------
+        ------------------------------>|       |
+         Kerberos Key Mgmt             | Proxy |
+         messages:                     |       |
+          1. AS Request  / 2.AS Reply   -------
+          3. TGS Request / 4.TGS Reply     ^
+                                           | Kerberos
+                                           | Key Mgmt messages
+                                           v (1, 2, 3, 4)
+                                        --------
+                                       |        |
+                                       |  KDC   |
+                                       |        |
+                                        --------
+
+     Figure 1: System blocks and message interactions between them
+
+
+   In this architecture, the DHCP client obtains a Kerberos ticket from
+   the Key Distribution Center (KDC) using standard Kerberos messages,
+   as specified in [6].  The client, however, contacts the KDC via a
+   proxy server, according to the IAKERB mechanism, described in [7].
+   The are several reasons why a client has to go through this proxy in
+   order to contact the KDC:
+
+  a)The client may not know the host address of the KDC and may be
+     sending its first request message as a broadcast on a local
+     network.  The KDC may not be located on the local network, and
+     even if it were - it will be unable to communicate with a client
+     without an IP address.  This document describes a specific
+     mechanism that may be used by a client to communicate with the
+     Kerberos proxy.
+
+
+
+S. Medvinsky, P. Lalwaney                                          -4-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+  b)The client may not know its Kerberos realm name.  The proxy is
+     able to fill in the missing client realm name in an AS Request
+     message, as specified in IAKERB.  Note that in the case that
+     PKINIT pre-authenticator is used [8], the realm name in the AS
+     Request may be the KDC realm name and not the clientÆs realm name.
+
+  c) The client does not know the realm name of the DHCP server.
+
+     According to IAKERB, when the client sends a TGS Request with a
+     missing server realm name, the proxy will return to the client an
+     error message containing the missing realm name.
+
+     Note that in this case the proxy could return the client a wrong
+     realm name and the client could be fooled into obtaining a ticket
+     for the wrong DHCP server (on the same local network).  However,
+     the wrong DHCP server must still be a registered principal in a
+     KDC database.  In some circumstances this may be an acceptable
+     compromise.  Also, see the security considerations section.
+
+     IAKERB describes the proxy as part of an application server - the
+     DHCP server in this case.  However, in this document we are not
+     requiring the proxy to be integrated with the DHCP server.  The
+     same IAKERB mechanisms apply in the more general case, where the
+     proxy is an independent application.  This proxy, however, MUST be
+     reachable by a client via a local network broadcast.
+
+     After a client has obtained a Kerberos ticket for the DHCP server,
+     it will use it as part of an authentication option in the DHCP
+     messages.  The only extension to the DHCP protocol is the addition
+     of a new authenticator type based on Kerberos tickets.
+
+4.1 Cross-Realm Authentication
+
+   Figure 1 shows a client communicating with a single KDC via a proxy.
+   However, the DHCP clientÆs realm may be different from the DHCP
+   serverÆs realm.  In that case, the client may need to first contact
+   the KDC in its local realm to obtain a cross-realm TGT.  Then, the
+   client would use the cross-realm TGT to contact the KDC in the DHCP
+   serverÆs realm, as specified in [6].
+
+   In the following example a client doesnÆt know its realm or the DHCP
+   serverÆs realm, which happens to be different from the clientÆs
+   realm.  Here are the steps in obtaining the ticket for the DHCP
+   server (based on [6] and [7]):
+
+        1) The client sends AS Request with NULL realm to the proxy.
+        2) The proxy fills in the realm and forwards the AS Request to
+           the KDC in the clientÆs realm.
+        3) The KDC issues a TGT and sends back an AS Reply to the
+           proxy.
+        4) The proxy forwards AS Reply to the client.
+
+
+S. Medvinsky, P. Lalwaney                                          -5-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+        5) The client sends TGS Request for a principal name "dhcpsrvr"
+           with NULL realm to the proxy.
+        6) The proxy returns KRB_AP_ERR_REALM_REQUIRED error with the
+           DHCP serverÆs realm to the client.
+        7) The client sends another TGS Request for a cross-realm TGT
+           to the proxy.
+        8) The proxy forwards the TGS Request to the KDC in the
+           clientÆs realm.
+        9) The KDC issues a cross-realm TGT and sends back a TGS Reply
+           to the proxy.
+       10) The proxy forwards TGS Reply to the client.
+       11) The client sends a TGS Request to the proxy for a principal
+       "dhcpsrvr" with the realm name filled in, using a cross-realm
+       TGT.
+       12) The proxy forwards TGS Request to the KDC in the DHCP      
+       server's realm.
+       13) The KDC issues a ticket for the DHCP server and sends TGS
+       Reply back to the proxy.
+       14) The proxy forwards TGS Reply to the client.
+
+   In a most general case, the client may need to contact any number of
+   KDCs in different realms before it can get a ticket for the DHCP
+   server.  In each case, the client would contact a KDC via the proxy
+   server, as specified in Section 5 of this document.
+
+4.2 Public Key Authentication
+
+   This specification also allows clients to perform public key
+   authentication to the KDC, based on the PKINIT specification [8].
+   In this case, the size of an AS Request and AS Reply messages is
+   likely to exceed the size of typical link MTU's.
+
+   Here is an example, where PKINIT is used by a DHCP client that is
+   not a registered principal in the KDC principal database:
+
+        1) The client sends AS Request with a PKINIT Request pre-
+           authenticator to the proxy.  This includes the clientÆs
+           signature and X.509 certificate.  The KDC realm field is
+           left as NULL.
+        2) The proxy fills in the realm and forwards the AS Request to
+           the KDC in the filled in realm.  This is the realm of the
+           DHCP server.  Here, the clientÆs realm is the name of a
+           Certification Authority - not the same as the KDC realm.
+        3) The KDC issues a TGT and sends back an AS Reply with a
+           PKINIT Reply pre-authenticator to the proxy.
+        4) The proxy forwards the AS Reply to the client.
+        5) The client sends TGS Request for a principal name "dhcpsrvr"
+           with the realm found in the TGT to the proxy.
+        6) The proxy forwards TGS Request to the KDC in the DHCP
+           serverÆs realm.
+        7) The KDC issues a ticket for the DHCP server and sends TGS
+           Reply back to the proxy.
+
+S. Medvinsky, P. Lalwaney                                          -6-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+        8) The proxy forwards TGS Reply to the client.
+
+
+   5. Key Management Exchange that Precedes Network Address Allocation
+
+   An uninitialized host (e.g. on power-on and reset) does not have a
+   network address. It does have a link layer address or hardware
+   address. At this time, the client may not have any information on
+   its realm or the realm of the address allocation server (DHCP
+   Server).
+
+   In the Kerberos key management exchange, a client gets its ticket
+   granting ticket (TGT) by contacting the Authentication Server in the
+   KDC using the AS_Request / Reply messages (shown as messages 1 and 2
+   in Figure 1). The client then contacts the Ticket Granting Server in
+   the KDC to get the DHCP server ticket (to be used for mutual
+   authentication with the DHCP server) using the TGS_REQ / TGS_REP
+   messages (shown as messages 3 and 4 in the above figure).  It is
+   also possible for the client to obtain a DHCP server ticket directly
+   with the AS Request / Reply exchange, without the use of the TGT.
+
+   In the use of Kerberos for DHCP authentication, the client (a) does
+   not have an IP/network address (b) does not know he KDCÆs IP address
+   (c) the KDC may not be on the local network and (d) the client may
+   not know the DHCP ServerÆs IP address and realm.  We therefore
+   require a Kerberos proxy on the local network to accept broadcast
+   Kerberos request messages (AS_REQ and TGS_REQ) from uninitialized
+   clients and relay them to the appropriate KDC.
+
+   The uninitialized client formulates a broadcast AS_REQ or TGS_REQ as
+   follows:
+
+   The request payload contains the client hardware address in
+   addresses field with a negative value for the address type. Kerberos
+   v5 [6] allows for the usage of negative address types for "local"
+   use. Note that IAKERB [7] discourages the use of the addresses field
+   as network addresses may not be known or may change in situation
+   where proxies are used. In this draft we incorporate the negative
+   values permitted in the Kerberos transport in the address type field
+   of both the AS_REQ and TGS_REQ messages. The negative value SHOULD
+   be the negative number of the hardware address type "htype" value
+   (from assigned numbers RFC) used in RFC 2131. The address field of
+   the message contains the clients hardware address.
+
+   The request payload is UDP encapsulated and addressed to port 88 on
+   the server/proxy. The UDP source port is selected by the client. The
+   source and destination network addresses are the all-zeroÆs address
+   and the broadcast address, respectively. For IPv4, the source IP
+   address is set to 0.0.0.0 and the destination IP address is set to
+   255.255.255.255. The data link layer header source address
+   corresponds to the link layer/hardware address of the client. The
+
+
+S. Medvinsky, P. Lalwaney                                          -7-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+   destination link layer address is the broadcast address at the link
+   layer (e.g. for Ethernet the address is ffffffff).
+
+   In the case where AS_REQ message contains a PKINIT pre-authenticator
+   for public key-based client authentication (based on [8]), the
+   message will probably not fit into a single UDP packet given typical
+   link MTU's.
+
+   It is assumed that the proxy server on a network is configured with
+   a list of KDCÆs, their realms and their IP addresses. The proxy
+   server will act as a client to the KDC and forward standard Kerberos
+   messages to/from the KDC using unicast UDP or TCP transport
+   mechanisms, according to [6].
+
+   Upon receiving a broadcast request from a client, the proxy MUST
+   record the clientÆs hardware address that appears as the source
+   address on the frame as well as in the addresses field of the
+   request message. Based on the realm of the KDC specified in the
+   request, the proxy determines the KDC to which this message is
+   relayed as a unicast message from the proxy to the KDC.  In the case
+   that the client left the KDC realm name as NULL, it is up to the
+   proxy to first determine the correct realm name and fill it in the
+   request (according to [7]).
+
+   On receiving a request, the KDC formulates a response (AS_REP or
+   TGS_REP). It includes the clientÆs addresses field in the encrypted
+   part of the ticket (according to [6]). This response is unicast to
+   the proxy.
+
+   Upon receiving the reply, the proxy MUST first determine the
+   previously saved hardware address of the client.  The proxy
+   broadcasts the reply on its local network. This is a network layer
+   broadcast. At the link level, it uses the hardware address obtained
+   from the addresses field of the request.
+
+   The client on receiving the response (link layer destination address
+   as its hardware address, network layer address is the broadcast
+   address) must verify that the hardware address in the ticket
+   corresponds to its link layer address.
+
+   Upon receiving a TGS_REP (or an AS_REP with the application server
+   ticket) from the proxy, the client will have enough information to
+   securely communicate with the application server (the DHCP Server in
+   this case), as specified in the following section.
+
+
+
+
+
+
+
+
+
+S. Medvinsky, P. Lalwaney                                          -8-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+    6. Authenticated Message Exchange Between the DHCP Client and the
+   DHCP Server
+
+   The ticket returned in the TGS response is used by the DHCP client
+   in the construction of the Kerberos authenticator.  The Kerberos
+   ticket serves two purposes: to establish a shared session key with
+   the DHCP server, and is also included as part of a Kerberos
+   authenticator in the DHCP request.
+
+   If the size of the authenticator is greater than 255 bytes, the DHCP
+   authentication option is repeated multiple times.  When the values
+   of all the authentication options are concatenated together, they
+   will make up the complete authenticator.
+
+   Once the session key is established, the Kerberos structure
+   containing the ticket (AP REQ) can be omitted from the authenticator
+   for subsequent messages sent by both the DHCP client and the DHCP
+   server.
+
+   The Kerberos authenticator for a DHCP request message is specified
+   below:
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |    Length     |    Protocol   |   Algorithm   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +              Replay Detection (64 bits)                       +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +              Authentication token (n octets)           ...    +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The format of this authenticator is in accordance with [2]. The code
+   for the authentication option is TBD, and the length field contains
+   the length of the remainder of the option, starting with the
+   protocol field.
+
+   The value of the protocol field for this authenticator MUST be set
+   to 2.
+
+   The algorithm field MUST take one of the following values:
+        1 - HMAC-MD5
+        2 - HMAC-SHA-1
+
+   Replay protection field is a monotonically increasing counter field.
+   When the Kerberos AP REQ structure is present in the authenticator
+   the counter may be set to any value.  The AP REQ contains its own
+   replay protection mechanism in the form of a timestamp.
+
+S. Medvinsky, P. Lalwaney                                          -9-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+
+   Once the session key has been established and the AP REQ is not
+   included in the authenticator, this field MUST be monotonically
+   increasing in the messages sent by the client.
+
+   Kerberos authenticator token consists of type-length-value
+   attributes:
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |  Reserved     |       Payload Length          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           attribute value...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The following attributes are included in the Kerberos authenticator
+   token:
+
+   Type         Attribute Name          Value
+   --------------------------------------------------------------------
+   0            Message Integrity Code  Depends on the value of the
+                                        algorithm field.  Its length is
+                                        16 bytes for HMAC-MD5 [9, 10]
+                                        and 20 bytes for HMAC-SHA-1
+                                        [11, 10].  The HMAC key must be
+                                        derived from Kerberos session
+                                        key found in the Kerberos
+                                        ticket according to the key
+                                        derivation rules in [6]:
+
+                                          HMAC Key = DK(sess key,
+                                                      key usage | 0x99)
+
+                                        Here, DK is defined in [12] and
+                                        the key usage value for DHCP is
+                                        TBD.
+
+                                        The HMAC is calculated over the
+                                        entire DHCP message. The
+                                        Message Integrity Code
+                                        attribute MUST be set to all 0s
+                                        for the computation of the
+                                        HMAC.  Because a DHCP relay
+                                        agent may alter the values of
+                                        the 'giaddr' and 'hops' fields
+                                        in the DHCP message, the
+                                        contents of those two fields
+                                        MUST also be set to zero for
+                                        the computation of the HMAC.
+                                        Rules specified in Section 3 of
+                                        [2] for the exclusion and
+
+S. Medvinsky, P. Lalwaney                                         -10-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+                                        processing of the relay agent
+                                        information are applicable here
+                                        too.
+
+                                        This field MUST always be
+                                        present in the Kerberos
+                                        authenticator.
+
+   1            AP_REQ                  ASN.1 encoding of a Kerberos
+                                        AP_REQ message, as specified
+                                        in [6]. This MUST be included
+                                        by the client when establishing
+                                        a new session key.  In all
+                                        other cases, this attribute
+                                        MUST be omitted.
+
+   AP_REQ contains the Kerberos ticket for the DHCP server and also
+   contains information needed by the DHCP server to authenticate the
+   client.  After verifying the AP_REQ and decrypting the Kerberos
+   ticket, the DHCP server is able to extract a session key which it
+   now shares with the DHCP client.
+
+   The Kerberos authenticator token contains its own replay protection
+   mechanism inside the AP_REQ structure.  The AP_REQ contains a
+   timestamp that must be within an agreed upon time window at the DHCP
+   server.  However, this does not require the DHCP clients to maintain
+   an accurate clock between reboots.  Kerberos allows clients to
+   synchronize their clock with the KDC with the help of Kerberos
+   KRB_AP_ERR_SKEW error message, as specified in [6].
+
+   The DHCP server MUST save both the session key and its associated
+   expiration time found in the Kerberos ticket.  Up until the
+   expiration time, the server must accept client requests with the
+   Kerberos authenticator that does not include the AP REQ, using the
+   saved session key in calculating HMAC values.
+
+   The Kerberos authenticator inside all DHCP server responses MUST NOT
+   contain the AP REQ and MUST use the saved Kerberos session key in
+   calculating HMAC values.
+
+   When the session key expires, it is the client's responsibility to
+   obtain a new ticket from the KDC and to include an AP REQ inside the
+   Kerberos authenticator for the next DHCP request message.
+
+
+
+
+
+
+
+
+
+
+S. Medvinsky, P. Lalwaney                                         -11-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+7. Detailed message flows for Kerberos and DHCP message Exchanges
+
+   The following flow depicts the Kerberos exchange in which a AS REQ
+   message is used to directly request the DHCP Server ticket. There
+   are no changes to transport mechanisms below when the additional
+   phase of using TGS requests/responses with TGTÆs is used.
+
+   Client                         IAKERB Proxy                 KDC
+
+   KB-client-------- AS_REQ ------>
+
+   AS REQ Address type = - (htype)
+   AS REQ Address= hw address
+
+   src UDP port = senders port
+   destination UDP port = 88
+
+   src IP = 0.0.0.0
+   destination IP = 255.255.255.255
+
+   src link layer address =
+   clientÆs HW/link address [e.g Ethernet address]
+
+   destination link layer address =
+   link broadcast address [e.g. ffffffff for Ethernet]
+
+
+                                         --------------------------->
+                                            (unicast to UDP port 88)
+
+
+
+                                          <--------------------------
+                                             (unicast AS REP)
+                                         Encrypted portion of ticket
+                                         Includes clients HW address
+
+
+      <---------------AS_REP -----------
+
+
+     Ticket includes clientÆs hardware address
+
+     src UDP port = 88
+     destination UDP port = copied from src port in AS_REQ
+
+     src IP = ProxyÆs IP address
+     destination IP = 255.255.255.255
+
+     src link layer address = ProxyÆs HW/link address
+     destination link layer address =
+         ClientÆs link layer address from AS_REQ
+
+
+S. Medvinsky, P. Lalwaney                                         -12-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+
+
+
+    The client uses the ticket received from the KDC in the DHCP
+Authentication option as described in Section 6.
+
+
+     Client
+     DHCP-client                                   DHCP Server
+
+             ------DHCPDISCOVER ---->
+             (Auth Protocol = 2, includes Kerberos
+              authenticator with AP REQ )
+                                   -----------------------------------
+                                   |  HMAC  |     AP   REQ           |
+                                    ----------------------------------
+                                            | Ticket| Client Authent |
+                                            --------------------------
+
+                                         1. Server decrypts ticket
+                                         (inside AP REQ) with service
+                                         key
+                                         2. Server decrypts client
+                                         authenticator (inside AP REQ)
+                                         and checks content and
+                                         checksum to validate the
+                                         client.
+                                         3. Recompute HMAC with session
+                                         key and compare.
+
+
+          <-------DHCPOFFER----------
+          (Auth Protocol = 2, no AP REQ )
+
+
+
+         ---------DHCPREQUEST------->
+         (Auth Protocol = 2, no AP REQ)
+
+
+          <--------DHCPACK-------------
+           (Auth Protocol = 2, no AP REQ )
+
+
+
+
+8. Security Considerations
+
+   DHCP clients that do not know the DHCP serverÆs realm name will get
+   it from the proxy, as specified in IAKERB [7].  Since the proxy is
+   not authenticated, a DHCP client can be fooled into obtaining a
+   ticket for the wrong DHCP server in the wrong realm.
+
+S. Medvinsky, P. Lalwaney                                         -13-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+
+   This could happen when the client leaves out the server realm name
+   in a TGS Request message to the proxy.  It is also possible,
+   however, for a client to directly request a DHCP server ticket with
+   an AS Request message.  In those cases, the same situation occurs
+   when the client leaves out the realm name in an AS Request.
+
+   This wrong DHCP server is still registered as a valid principal in a
+   database of a KDC that can be trusted by the client.  In some
+   circumstances a client may assume that a DHCP server that is a
+   Kerberos principal registered with a trusted KDC will not attempt to
+   deliberately misconfigure a client.
+
+   This specification provides a tradeoff between:
+
+        1) The DHCP clients knowing DHCP serverÆs realm ahead of time,
+           which provides for full 2-way authentication at the cost of
+           an additional configuration parameter.
+        2) The DHCP clients not requiring any additional configuration
+           information, besides a password or a key (and a public key
+           certificate if PKINIT is used).  This is at the cost of not
+           being able to fully authenticate the identity of the DHCP
+           server.
+
+
+
+9. References
+
+
+   [1]Droms, R., Arbaugh, W., "Dynamic Host Configuration Protocol",
+      RFC 2131, Bucknell University, March 1997.
+
+   [2]Droms, R., Arbaugh, W., "Authentication for DHCP Messages",
+      draft-ietf-dhc-authentication-13.txt, June 2000.
+
+   [3]Hornstein, K., Lemon, T., "DHCP Authentication Via Kerberos V",
+      draft-hornstein-dhc-kerbauth-02.txt, February 2000.
+
+   [4]Borella, M., Grabelsky, D., Lo, J., Tuniguchi, K., "Realm
+      Specific IP: Protocol Specification ", draft-ietf-nat-rsip-
+      protocol-06.txt, March 2000.
+
+   [5]Guttman, E., Perkins, C., Veizades, J., Day, M., "Service
+      Location Protocol, Version 2", RFC 2608, June 1999.
+
+   [6]Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
+      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
+      05.txt, March 2000.
+
+
+
+
+
+S. Medvinsky, P. Lalwaney                                         -14-        
+
+Kerberos V Authentication Mode for Uninitialized Clients     July 2000
+
+
+
+   [7]Swift, M., Trostle, J., "Initial Authentication and Pass Through
+      Authentication Using Kerberos V5 and the GSS-API (IAKERB)",
+      draft-ietf-cat-iakerb-03.txt, September 1999.
+
+   [8]Tung, B., C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
+      J. Trostle, "Public Key Cryptography for Initial Authentication
+      in Kerberos", draft-ietf-cat-pk-init-11.txt, March 2000.
+
+   [9]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
+      1992.
+
+   [10]Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
+      Message Authentication," RFC 2104, February 1997.
+
+   [11]NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995.
+
+   [12]Horowitz, M., "Key Derivation for Authentication, Integrity, and
+      Privacy", draft-horowitz-key-derivation-02.txt, August 1998.
+
+   [13]Bradner, S. "The Internet Standards Process -- Revision 3", RFC
+   2026.
+
+
+
+ 10. Author's Addresses
+
+   Sasha Medvinsky
+   Motorola
+   6450 Sequence Drive
+   San Diego, CA 92121
+   Email: smedvinsky@gi.com
+
+   Poornima Lalwaney
+   Nokia
+   12278 Scripps Summit Drive
+   San Diego, CA  92131
+   Email: poornima.lalwaney@nokia.com
+
+
+11. Expiration
+
+   This memo is filed as <draft-smedvinsky-dhc-kerbauth-01.txt>, and
+   expires January 1, 2001.
+
+
+
+12. Intellectual Property Notices
+
+
+
+
+
+
+S. Medvinsky, P. Lalwaney                                         -15-        
+
+Kerberos V Authentication Mode for Uninitialized Clients    March 2000
+
+
+      This section contains two notices as required by [13] for
+   standards track documents.  Per [13], section 10.4(A):
+
+     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 implementers or users of this specification
+   can be obtained from the IETF Secretariat.
+
+      Per [13] section 10.4(D):
+
+      The IETF has been notified of intellectual property rights
+   claimed in regard to some or all of the specification contained in
+   this document.  For more information consult the online list of
+   claimed rights.
+
+   13. Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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.
+
+
+
+
+
+S. Medvinsky, P. Lalwaney                                         -16-
+
\ No newline at end of file
diff --git a/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt b/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt
new file mode 100644
index 000000000000..85d745684b2a
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt
@@ -0,0 +1,5 @@
+This Internet-Draft has expired and is no longer available.
+
+Unrevised documents placed in the Internet-Drafts directories have a
+maximum life of six months. After that time, they must be updated, or
+they will be deleted. This document was deleted on July 17, 2000.
diff --git a/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt b/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt
new file mode 100644
index 000000000000..85d745684b2a
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt
@@ -0,0 +1,5 @@
+This Internet-Draft has expired and is no longer available.
+
+Unrevised documents placed in the Internet-Drafts directories have a
+maximum life of six months. After that time, they must be updated, or
+they will be deleted. This document was deleted on July 17, 2000.
diff --git a/crypto/heimdal/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt b/crypto/heimdal/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt
new file mode 100644
index 000000000000..68c170b499ed
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt
@@ -0,0 +1,1140 @@
+
+
+
+
+
+
+INTERNET-DRAFT   Kerberized USM Keying    M. Thomas
+                                          Cisco Systems
+                                          K. McCloghrie
+                                          Cisco Systems
+                                          July 13, 2000
+
+
+
+
+
+
+                         Kerberized USM Keying
+
+                   draft-thomas-snmpv3-kerbusm-00.txt
+
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all 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/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+Abstract
+
+   The KerbUSM MIB provides a means of leveraging a trusted third party
+   authentication and authorization mechanism using Kerberos for SNMP V3
+   USM users and their associated VACM views. The MIB encodes the normal
+   Kerberos AP-REQ and AP-REP means of both authenticating and creating
+   a shared secret between the SNMP V3 Manager and Agent.
+
+The SNMP Management Framework
+
+   The SNMP Management Framework presently consists of five major
+   components:  An overall architecture, described in RFC 2571
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 1]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+   [RFC2571].  Mechanisms for describing and naming objects and events
+   for the purpose of management.  The first version of this Structure
+   of Management Information (SMI) is called SMIv1 and described in STD
+   16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215
+   [RFC1215].  The second version, called SMIv2, is described in STD 58,
+   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
+   [RFC2580].  Message protocols for transferring management
+   information.  The first version of the SNMP message protocol is
+   called SNMPv1 and described in STD 15, RFC 1157 [RFC1157].  A second
+   version of the SNMP message protocol, which is not an Internet
+   standards track protocol, is called SNMPv2c and described in RFC 1901
+   [RFC1901] and RFC 1906 [RFC1906].  The third version of the message
+   protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC
+   2572 [RFC2572] and RFC 2574 [RFC2574].  Protocol operations for
+   accessing management information.  The first set of protocol
+   operations and associated PDU formats is described in STD 15, RFC
+   1157 [RFC1157].  A second set of protocol operations and associated
+   PDU formats is described in RFC 1905 [RFC1905].  A set of fundamental
+   applications described in RFC 2573 [RFC2573] and the view-based
+   access control mechanism described in RFC 2575 [RFC2575].
+
+   A more detailed introduction to the current SNMP Management Framework
+   can be found in RFC 2570 [RFC2570].
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using the mechanisms defined in the SMI.
+
+   This memo specifies a MIB module that is compliant to the SMIv2.  A
+   MIB conforming to the SMIv1 can be produced through the appropriate
+   translations.  The resulting translated MIB must be semantically
+   equivalent, except where objects or events are omitted because no
+   translation is possible (use of Counter64).  Some machine readable
+   information in SMIv2 will be converted into textual descriptions in
+   SMIv1 during the translation process.  However, this loss of machine
+   readable information is not considered to change the semantics of the
+   MIB.
+
+
+Introduction
+
+   The User based Security Model of SNMP V3 (USM) [2] provides a means
+   of associating different users with different access privileges of
+   the various MIB's that an agent supports. In conjunction with the
+   View based Access Control Model of SNMP V3 (VACM) [3], SNMP V3
+   provides a means of providing resistance from various threats both
+   from outside attacks such as spoofing, and inside attacks such as an
+   user having, say, SET access to MIB variable for which they are not
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 2]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+   authorized.
+
+   SNMP V3, unfortunately, does not specify a means of doing key
+   distribution between the managers and the agents. For small numbers
+   of agents and managers, the O(n*m) manual keying is a cumbersome, but
+   possibly tractable problem. For a large number of agents with
+   distribution of managers, the key distribution quickly goes from
+   cumbersome to unmanageable. Also: there is always the lingering
+   concern of the security precautions taken for keys on either local
+   management stations, or even directories.
+
+   Kerberos [1] provides a means of centralizing key management into an
+   authentication and authorization server known as a Key Distribution
+   Center (KDC).  At a minimum, Kerberos changes the key distribution
+   problem from a O(n*m) problem to a O(n) problem since keys are shared
+   between the KDC and the Kerberos principals rather directly between
+   each host pair. Kerberos also provides a means to use public key
+   based authentication which can be used to further scale down the
+   number of pre-shared secrets required. Furthermore, a KDC is intended
+   and explicitly expected to be a standalone server which is managed
+   with a much higher level of security concern than a management
+   station or even a central directory which may host many services and
+   thus be exposed to many more possible vectors of attack.
+
+   The MIB defined in this memo describes a means of using the desirable
+   properties of Kerberos within the context of SNMP V3. Kerberos
+   defines a standardized means of communicating with the KDC as well as
+   a standard format of Kerberos tickets which Kerberos principals
+   exchange in order to authenticate to one another. The actual means of
+   exchanging tickets, however, is left as application specific. This
+   MIB defines the SNMP MIB designed to transport Kerberos tickets and
+   by doing so set up SNMP V3 USM keys for authentication and privacy.
+
+   It should be noted that using Kerberos does introduce reliance on a
+   key network element, the KDC. This flies in the face of one of SNMP's
+   dictums of working when the network is misbehaving. While this is a
+   valid concern, the risk of reliance on the KDC can be significantly
+   diminished with a few common sense actions. Since Kerberos tickets
+   can have long life times (days, weeks) a manager of key network
+   elements can and should maintain Kerberos tickets well ahead ticket
+   expiration so that likelihood of not being able to rekey a session
+   while the network is misbehaving is minimized. For non-critical, but
+   high fanout elements such as user CPE, etc, requiring a pre-fetched
+   ticket may not be practical, which puts the KDC into the critical
+   path. However, if all KDC's are unreachable, the non-critical network
+   elements are probably the least of the worries.
+
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 3]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+Operation
+
+   The normal Kerberos application ticket exchange is accomplished by  a
+   client  first  fetching  a  service ticket from a KDC for the service
+   principal and then sending an AP-REQ  to  a  server  to  authenticate
+   itself  to  the  server. The server then sends a AP-REP to finish the
+   exchange. This MIB maps Kerberos' concept of client and  server  into
+   the  SNMP  V3  concept  of  Manager and Agent by designating that the
+   Kerberos Client is the SNMP V3 Agent. Although  it  could  be  argued
+   that an Agent is really a server, in practice there may be many, many
+   agents and relatively few managers. Also: Kerberos clients  may  make
+   use  of  public  key authentication as defined in [4], and it is very
+   advantageous to take advantage of that capability for  Agents  rather
+   than Managers.
+
+   The MIB is intended to be stateless and map USM users to Kerberos
+   principals. This mapping is explicitly done by putting a Kerberos
+   principal name into the usmUserSecurityName in the usmUser MIB and
+   instatiating the krbUsmMibEntry for the usmUserEntry. MIB variables
+   are accessed with INFORM's or TRAP PDU's and SET's to perform a
+   normal Kerberos AP-REQ/AP-REP exchange transaction which causes the
+   keys for a USM user to be derived and installed. The basic structure
+   of the MIB is a table which augements usmUserEntry's with a Kerberos
+   principal name as well as the transaction varbinds. In the normal
+   case, multiple varbinds should be sent in a single PDU which prevents
+   various race conditions, as well as increasing efficiency.
+
+   It should be noted that this MIB is silent on the subject of how the
+   Agent and Manager find the KDC. In practice, this may be either
+   statically provisioned or use either DNS SRV records (RFC 2782) or
+   Service Location (RFC 2608). This MIB is does not provide for a means
+   of doing cipher suite negotiation either. It is expected that the
+   choices for ciphers in the USM MIB will reflect site specific choices
+   for ciphers. This matches well with the general philosophy of
+   centralized keying.
+
+Keying Transactions
+
+   The following shows an error free transaction:
+
+   Note: optional steps or parameters are shown like [ ]
+
+
+
+
+
+
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 4]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+
+    Agent                       Manager                            KDC
+ +--                                                               --+
+ | 1) <-------------------------------                               |
+ |     SET (krbUsmPrinTable[usmUserName].krbUsmMibNonce = xxxx;      |
+ |          [ krbUsmPrinTable[usmUserName].krbUsmMibTgt =            |
+ |                                  TGT[usmUserSecurityName] ]);     |
+ |                                                                   |
+ | 2) ------------------------------->                               |
+ |    Response                                                       |
+ +--                     (optional)                                --+
+
+   3) --------------------------------------------------------------->
+        TGS-REQ (krbUsmPrinTable[usmUserName].krbUsmMibMgrPrinName
+                 [, krbUsmPrinTable[usmUserName].krbUsmMibTgt]);
+
+   4) <--------------------------------------------------------------
+        Tick[usmUserSecurityName] = TGS-REP ();
+
+   5)  ------------------------------>
+        INFORM (krbUsmPrinTable[usmUserName].krbUsmMibApReq =
+                   AP_REQ[Tick[usmUserSecurityName]];
+                   [ krbUsmPrinTable[usmUserName].krbUsmMibNonce = xxxx]);
+
+   6)  <------------------------------
+        SET (krbUsmPrinTable[usmUserName].krbUsmMibApRep = AP_REP[]);
+
+
+   7)  ------------------------------>
+       Response
+
+
+   The above flow translates to:
+
+
+   1)  This step is used when the Manager does not currently have a ses-
+       sion with the Agent but wishes to start one. The Manager MAY
+       place a ticket granting ticket into the krbUsmMibMgrTgt varbind
+       in the same PDU as the krbUsmMibNonce if it does not share a
+       secret with the KDC (as would be the case if the Manager used
+       PKinit to do initial authentication with the KDC).
+
+
+   2)  This step acknowledges the SET. There are no MIB specific errors
+       which can happen here.
+
+
+   3)  If the Agent is not already in possession of a service ticket for
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 5]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+       the Manager in its ticket cache, it MUST request a service ticket
+       from the Agent's KDC for the service principal given by
+       krbUsmMibMgrPrinName in the row that the krbUsmMibNonce was SET
+       in, optionally adding a krbUsmMibMgrTgt.  If the TGT is speci-
+       fied, the Manager's TGT must be placed in the additional-tickets
+       field with the ENC-TKT-IN-SKEY option set in the TGS-REQ to
+       obtain a service ticket (see section 3.3.3 of [1]).
+
+       Note:   a Kerberos TGS-REQ is but one way to obtain a service
+               ticket. An Agent may use any normal Kerberos means to
+               obtain the service ticket. This flow has also elided ini-
+               tial authentication (ie, AS-REQ) and any cross realm con-
+               siderations, though those may be necessary prerequisites
+               to obtaining the service ticket.
+
+   4)  If step 3 was performed, this step receives the ticket or an
+       error from the KDC.
+
+
+   5)  This step sends a krbUsmMibApReq to the Manager via an INFORM or
+       TRAP PDU.  If the message is the result of a request by the
+       Manager, krbUsmMibNonce received from the Manager MUST be sent in
+       the same PDU. If the Manager did not initiate the transaction,
+       the Agent MUST NOT send a krbUsmMibNonce varbind. The Agent also
+       MUST check krbUsmMibUnsolicitedNotify is not false, otherwise it
+       MUST abort the transaction.  All krbUsmMibApReq's MUST contain a
+       sequence nonce so that the resulting krbUsmMibApRep can provide a
+       proof of the freshness of the message to prevent replay attacks.
+
+       If the Agent encounters an error either generated by the KDC or
+       internally, the Agent MUST send an INFORM or TRAP PDU indicating
+       the error in the form of a KRB-ERROR placed in krbUsmMibApReq
+       with the same rules applied to krbUsmMibNonce and krbUsmMibUnsol-
+       icitedNotify above. If the Agent suspects that it is being
+       attacked by a purported Manager which is generating many failed
+       TGS-REQ's to the KDC, it SHOULD meter its TGS-REQ transactions
+       for that Manager to the KDC using an exponential backoff mechan-
+       ism truncated at 10 seconds.
+
+
+
+   6)  Upon recepit of an INFORM or TRAP PDU with a krbUsmMibApReq, a
+       Manager may accept the AP-REQ. If it is accompanied with a
+       krbUsmMibNonce it MUST correlate it with any outstanding transac-
+       tions using its stored nonce for the transaction. If it does not
+       correlate with a current nonce, the request MUST be rejected as
+       it may be a replay.
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 6]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+       If the Manager chooses to reject an unsolicited keying request,
+       it SHOULD send a WrongValue Error to the Agent with the krbUsmMi-
+       bApReq as the subject of the WrongValue. If an Agent receives a
+       WrongValue Error from a Manager it MUST cease retransmission of
+       the INFORM or TRAP PDU's so as to mitigate event avalanches by
+       Agents. There is a possible denial of service attack here, but it
+       must be weighed against the larger problem of network congestion,
+       flapping, etc. Therefore, if the Agent finds that it cannot can-
+       cel an unsolicited Notify (ie, it must be reliable), it MUST use
+       a truncated exponential backoff mechanism with the maximum trun-
+       cation interval set to 10 minutes.
+
+       Otherwise, the Manager MUST send a SET PDU to the Agent which
+       contains a krbUsmMibApRep.
+
+
+   7)  If the Agent detects an error (including detecting replays) in
+       the final AP-REP, it MUST send a WrongValue error with a pointer
+       to the krbUsmMibApRep varbind to indicate its inability to estab-
+       lish the security association. Otherwise, receipt of the positive
+       acknowledgement from the final SET indicates to the Manager that
+       the proper keys have been installed on the Agent in the USM MIB.
+
+Unsolicited Agent Keying Requests
+
+   An Agent may find that it needs to set up a security association for
+   a USM user in order to notify a Manager of some event. When the Agent
+   engine receives a request for a notify, it SHOULD check to see if
+   keying material has been established for the user and that the keying
+   material is valid. If the keying material is not valid and the USM
+   user has been tagged as being a Kerberos principal in a realm, the
+   Agent SHOULD first try to instantiate a security association by
+   obtaining a service ticket for the USM User and follow steps 3-7 of
+   the flow above. This insures that the USM User will have proper key-
+   ing material and providing a mechanism to allow for casual security
+   associations to be built up and torn down. This is especially useful
+   for Agents which may not normally need to be under constant Manager
+   supervision, such as the case with high fan out user residential CPE
+   and other SNMP managed "appliances". In all cases, the Agent MUST NOT
+   send an unsolicited Notify if krbUsmUnsolicitedNotify is set to
+   false.
+
+   How the Agent obtains the Manager's address, how it determines
+   whether a Manager, realm, and whether it can be keyed using this MIB
+   is outside of the scope of this memo.
+
+   Note:   Although the MIB allows for a Manager to set up a session
+           using User-User mode of Kerberos by sending a TGT along with
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 7]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+           the nonce, this, is limited to Manager initiated sessions
+           only since there is no easy way to store the Manager's ticket
+           in the MIB since it is publicly writable and as such would be
+           subject to denial of service attacks. Another method might be
+           to have the Agent send a krbUsmMibNonce to the Manager which
+           would tell it to instigate a session. Overall, it seems like
+           a marginal feature to allow a PKinit authenticated user be
+           the target of unsolicited informs and it would complicate the
+           transactions. For this reason, this scenario has been omitted
+           in favor of simplicity.
+
+Retransmissions
+
+   Since this MIB defines not only variables, but transactions, discus-
+   sion of the retransmission state machine is in order. There are two
+   similar but different state machines for the Manager Solicited and
+   Agent Unsolicited transactions.  There is one timer Timeout which
+   SHOULD take into consideration round trip considerations and MUST
+   implement a truncated exponential backoff mechanism. In addition, in
+   the case where an Agent makes an unsolicited Agent keying request,
+   the Agent SHOULD perform an initial random backoff if the keying
+   request to the Manager may result in a restart avalanche. A suitable
+   method is described in section 4.3.4 of [5].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 8]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+
+Manager Solicited Retransmission State Machine
+
+                Timeout
+                 +---+
+                 |   |
+                 |   V
+              +-----------+ Set-Ack (2) +----------+
+              |           |------------>|          |
+              | Set-Nonce |             |  Ap-Req  |
+              |   (1)     |<------------|   (5)    |
+              +-----------+   Timeout   +----------+
+                   ^                         |
+                   |                         | Set-Ap-Rep
+                   |      +----------+       |  (6)
+                   +------|          |<------+
+                  Timeout | Estab-wt |
+                          |   (7)    |
+                          +----------+
+                               |
+                               |  Set-Ap-Rep-Ack (7)
+                               V
+                          +----------+
+                          |          |
+                          |  Estab   |
+                          |          |
+
+                          +----------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 9]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+
+Agent Unsolicited Retransmission State Machine
+
+                             Timeout
+                              +---+
+                              |   |
+                              |   V
+                          +----------+
+                          |          |
+                   +----> |  Ap-Req  |-------+
+                   |      |   (5)    |       |
+                   |      +----------+       |
+                   |                         |
+                   |                         | Set-Ap-Rep
+                   |      +----------+       |  (6)
+                   +------|          |<------+
+                  Timeout | Estab-wt |
+                          |   (7)    |
+                          +----------+
+                               |
+                               |  Set-Ap-Rep-Ack (7)
+                               V
+                          +----------+
+                          |          |
+                          |  Estab   |
+                          |          |
+                          +----------+
+
+Session Duration and Failures
+
+   The KerbUsmMib uses the ticket lifetime to determine the life of the
+   USM session. The Agent MUST keep track of whether the ticket which
+   instigated the session is valid whenever it forms PDU's for that par-
+   ticular user. If a session expires, or if it wasn't valid to begin
+   with (from the Agent's perspective), the Agent MUST reject the PDU by
+   sending a XXX Error [mat: help me here Keith... what does USM say
+   about this?].
+
+   Kerberos also inherently implies adding state to the Agent and
+   Manager since they share not only a key, but a lifetime associated
+   with that key. This is in some sense soft state because failure of an
+   Agent will cause it to reject PDU's for Managers with whom it does
+   not share a secret. The Manager can use the Error PDU's as an indica-
+   tion that it needs to reauthenticate with the Agent, taking care not
+   to loop. The Manager is even easier: when it reboots, it can either
+   check its credential cache to reconstruct state or cause the Agent to
+   reauthenticate to the Manager with its service ticket by initiating a
+   authentication transaction with the manager.
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 10]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+Manager Collisions
+
+   Managers may freely set up keys for different USM users using this
+   MIB without problem since they access different rows in the krbUsm-
+   PrinTable. However, multiple Managers trying to set up keys for the
+   same USM user is possible but discouraged. The requirement for the
+   Manager is that they MUST share the same service key with the KDC so
+   that they can all decrypt the same service ticket. There are two race
+   conditions, however, which are not well handled:
+
+
+
+1)  At the end of a ticket lifetime, one manager may request the agent
+    to refresh its service ticket causing a new session key to be
+    installed for the USM user leaving the other managers with stale
+    keys. The workaround here is that the Agent will reject the stale
+    manager's PDU's which should inform them to do their own rekeying
+    operations.
+
+
+2)  If multiple managers try to access the same row at the same time,
+    the Agent SHOULD try to keep the transactions separate based on the
+    nonce values. The Managers or the Agents SHOULD NOT break the
+    krbUsmMibNonce and any other additional varbinds into separate PDU's
+    as this may result in a meta stable state. Given normal MTU sizes,
+    this should not be an issue in practice, and this should  at worst
+    devolve into the case above.
+
+   In all cases, the krbUsmMibNonce MUST be the last value to be
+   transmitted, though its position within a PDU is unimportant.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 11]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+
+   KrbUSM MIB
+
+   KRB-USM-MIB DEFINITIONS ::= BEGIN
+   IMPORTS
+       MODULE-IDENTITY,
+       OBJECT-TYPE, OBJECT-IDENTITY,
+       snmpModules, Counter32, Unsigned32 FROM SNMPv2-SMI
+       TruthValue, DisplayString          FROM SNMPv2-TC
+       usmUserEntry                       FROM SNMP-USER-BASED-SM-MIB
+
+
+
+   krbUsmMib MODULE-IDENTITY
+           LAST-UPDATED "00071300Z"
+           ORGANIZATION "IETF SNMP V3 Working Group"
+           CONTACT-INFO
+             "Michael Thomas
+              Cisco Systems
+              375 E Tasman Drive
+              San Jose, Ca 95134
+              Phone: +1 408-525-5386
+              Fax: +1 801-382-5284
+              email: mat@cisco.com"
+           DESCRIPTION
+              "This MIB contains the MIB variables to
+               exchange Kerberos credentials and a session
+               key to be used to authenticate and set up
+               USM keys"
+
+           ::= { snmpModules nnn }   -- not sure what needs to be here.
+   krbUsmMibObjects OBJECT INDENTIFIER ::= { krbUsmMib 1 }
+
+   krbUsmMibAuthInAttemps
+               SYNTAX      Counter32
+               MAX-ACCESS  read-only
+               STATUS      current
+               DESCRIPTION
+                   "Counter of the number of Kerberos
+                    authorization attempts as defined by
+                    receipt of a PDU from a Manager with a
+                     krbUsmMibNonce set in the principal table."
+               ::= { krbUsmMibObjects 1 }
+
+   krbUsmMibAuthOutAttemps
+               SYNTAX      Counter32
+               MAX-ACCESS  read-only
+               STATUS      current
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 12]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+               DESCRIPTION
+                   "Counter of the number of unsolicited Kerberos
+                    authorization attempts as defined by
+                    an Agent sending an INFORM or TRAP PDU with a
+                    krbUsmMibApRep but without krbUsmApMibNonce
+                    varbind."
+               ::= { krbUsmMibObjects 2 }
+   krbUsmMibAuthInFail
+               SYNTAX      Counter32
+               MAX-ACCESS  read-only
+               STATUS      current
+               DESCRIPTION
+                   "Counter of the number of Kerberos
+                    authorization failures as defined by
+                    a Manager setting the krbUsmMibNonce
+                    in the principal table which results
+                    in some sort of failure to install keys
+                    in the requested USM user entry."
+               ::= { krbUsmMibObjects 3 }
+
+   krbUsmMibAuthOutFail
+               SYNTAX      Counter32
+               MAX-ACCESS  read-only
+               STATUS      current
+               DESCRIPTION
+                   "Counter of the number of unsolicited Kerberos
+                    authorization failures as defined by
+                    an Agent sending an INFORM or TRAP PDU with a
+                    krbUsmMibApRep but without a krbUsmMibNonce
+                    varbind which does not result in keys being
+                    installed for that USM user entry."
+               ::= { krbUsmMibObjects 4 }
+
+   krbUsmMibPrinTable OBJECT-TYPE
+               SYNTAX      SEQUENCE OF krbUsmMibEntry
+               MAX-ACCESS  not-accessible
+               STATUS      current
+               DESCRIPTION
+                   "Table which maps Kerberos principals with USM
+                    users as well as the per user variables to key
+                    up sessions"
+               ::= { krbUsmMibObjects 5 }
+
+   krbUsmMibPrinEntry OBJECT-TYPE
+               SYNTAX     KrbUsmMibPrinEntry
+               MAX-ACCESS  not-accessible
+               STATUS      current
+               DESCRIPTION
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 13]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+                   "an entry into the krbMibPrinTable which is a
+                    parallel table to UsmUserEntry table"
+               AUGMENTS { usmUserEntry }
+               ::= { krbUsmMibPrinTable 1 }
+
+   KrbUsmMibPrinEntry SEQUENCE
+    {
+                   krbUsmMibApReq                  OCTET STRING,
+                   krbUsmMibApRep                  OCTET STRING,
+                   krbUsmMibNonce                  OCTET STRING,
+                   krbUsmMibMgrTGT                 OCTET STRING,
+                   krbUsmMibUnsolicitedNotify      TruthValue,
+    }
+
+
+   krbUsmMibApReq OBJECT-TYPE
+               SYNTAX      OCTET STRING
+               MAX-ACCESS  accessible-for-notify
+               STATUS      current
+               DESCRIPTION
+                   "This variable contains a DER encoded Kerberos
+                    AP-REQ or KRB-ERROR for the USM user which is
+                    to be keyed. This is sent from the Agent to
+                    the Manager in an INFORM or TRAP request.
+                    KRB-ERROR MUST only be sent to the Manager
+                    if it is in response to a keying request from
+                    the Manager.
+                   "
+               ::= { krbUsmMibPrinEntry 1 }
+
+   krbUsmMibApRep OBJECT-TYPE
+               SYNTAX      OCTET STRING
+               MAX-ACCESS  read-write
+               STATUS      current
+               DESCRIPTION
+                   "This variable contains the DER encoded response
+                    to an AP-REQ. This variable is SET by the
+                    Manager to acknowledge receipt of an AP-REQ. If
+                    krbUsmMibApRep contains a Kerberos AP-REP, the
+                    Agent must derive keys from the session key
+                    of the Kerberos ticket in the AP-REQ and place
+                    them in the USM database in a manner specified
+                    by [RFC2574]. If the Manager detects an error,
+                    it will instead place a KRB-ERROR in this
+                    variable to inform the Agent of the error.
+
+                    This variable is in effect a write-only variable.
+                    attempts to read this variable will result in a
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 14]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+                    null octet string being returned"
+               ::= { krbUsmMibPrinEntry 2 }
+
+   krbUsmMibNonce OBJECT-TYPE
+               SYNTAX      OCTET STRING
+               MAX-ACCESS  read-write
+               STATUS      current
+               DESCRIPTION
+                   "SET'ing a krbUsmMibnonce allows a Manager to
+                    determine whether an INFORM or TRAP from an
+                    Agent is an outstanding keying request, or
+                    unsolicited from the Agent. The Manager
+                    initiates keying for a particular USM user
+                    by writing a nonce into the row for which
+                    desires to establish a security association.
+                    The nonce is an ASCII string of the form
+                    ``host:port?nonce'' where:
+
+                    host:  is either an FQDN, or valid ipv4 or ipv6
+                           numerical notation of the Manager which
+                           desires to initiate keying
+                    port:  is the destination port at which that the
+                           Manager may be contacted
+                    nonce: is a number generated by the Manager to
+                           correlate the transaction
+
+                    The same nonce MUST be sent to the Manager in a
+                    subsequent INFORM or TRAP with a krbUsmApReq.
+                    The Agent MUST use the host address and port
+                    supplied in the nonce as the destination of a
+                    subsequent INFORM or TRAP. Unsolicited keying
+                    requests MUST NOT contain a nonce, and should
+                    instead use the destination stored Notifies of
+                    this type.
+
+                    Nonces MUST be highly collision resistant either
+                    using a time based method or a suitable random
+                    number generator. Managers MUST never create
+                    nonces which are 0.
+
+                    This variable is in effect a write-only variable.
+                    Attempts to read this variable will result in a
+                    nonce of value 0 being returned"
+
+
+               ::= { krbUsmMibPrinEntry 3 }
+
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 15]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+   krbUsmMibMgrTgt OBJECT-TYPE
+               SYNTAX      OCTET STRING
+               MAX-ACCESS  read-write
+               STATUS      current
+               DESCRIPTION
+                   "If the Manager does not possess a symmetric
+                    key with the KDC as would be the case with
+                    a Manager using PKinit for authentication,
+                    the Manager MUST SET its DER encoded ticket
+                    granting ticket into KrbUsmMgrTgt along
+                    with krbUsmMibNonce.
+
+                    The agent will then attach the Manager's TGT
+                    into the additional tickets field of the
+                    TGS-REQ message to the KDC to get a User-User
+                    service ticket.
+
+                    This variable is in effect a write-only variable.
+                    Attempts to read this variable will result in a
+                    null octet string being returned"
+               ::= { krbUsmMibPrinEntry 4 }
+
+
+   krbUsmMibUnsolicitedNotify OBJECT-TYPE
+               SYNTAX      TruthValue
+               MAX-ACCESS  read-write
+               STATUS      current
+               DESCRIPTION
+                   "If this variable is false, the Agent MUST NOT
+                    send unsolicited INFORM or TRAP PDU's to the
+                    Manager.
+
+                    Attempts to SET this variable by the no-auth
+                    no-priv user MUST be rejected."
+               ::= { krbUsmMibPrinEntry 5 }
+
+   --
+   -- Conformance section... nothing optional.
+
+   krbUsmMibCompliences MODULE-COMPLIANCE
+               STATUS       current
+               DESCRIPTION "The compliance statement for SNMP
+                            engines whichimplement the KRB-USM-MIB
+                   "
+               MODULE       -- this module
+                       MANDATORY-GROUPS { krbUsmMib }
+       ::= { krbUsmMibCompliances 1 }
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 16]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+   END
+
+
+Key Derivation
+
+   The session key provides the basis for the keying material for the
+   USM user specified in the AP-REQ.  The actual keys for use for the
+   authentication and privacy are produced using the cryptographic hash-
+   ing function used to protect the ticket itself.  The keying material
+   is derived using this function, F(key, salt), using successive
+   interations of F over the salt string "SNMPV3RULZ%d", where %d is a
+   monotonic counter starting at zero. The bits are taken directly from
+   the successive interations to produce two keys of appropriate size
+   (as specified in the USM user row) for the authentication transform
+   first, and the privacy transform second. If the authentication
+   transform is null, the first bits of the derived key are used for the
+   privacy transform.
+
+Security Considerations
+
+   Various elements of this MIB must be readable and writable as the
+   no-auth, no-priv user. Unless specifically necessary for the key
+   negotiation, elements of this MIB SHOULD be protected by VACM views
+   which limit access. In particular, there is no reason anything in
+   this MIB should be visible to a no-auth, no-priv user with the excep-
+   tion of KrbUsmMibApReq, KrbUsmMibApRep, KrbUsmMibNonce, and
+   KrbUsmMibMgrTgt, and then only with the restrictions placed on them
+   in the MIB. As such, probing attacks are still possible, but should
+   not be profitable: all of the writable variables with interesting
+   information in them are defined in such a way as to be write only.
+
+   There are some interesting denial of service attacks which are possi-
+   ble by attackers spoofing managers and putting load on the KDC to
+   generate unnecessary tickets. For large numbers or agents this could
+   be problematic. This can probably be mitigated by the KDC prioritiz-
+   ing TGS-REQ's though.
+
+
+References
+
+[1]         The CAT Working Group,  J.  Kohl,  C.Neuman,  "The  Kerberos
+            Network  Authentication  Service  (V5)", RFC 1510, September
+            1993
+
+[2]         The SNMPV3 Working Group, U.  Blumenthal,  B.  Wijnen,  "The
+            User-based Security Model of SNMP V3", RFC 2574, April 1999
+
+[3]         The SNMPV3 Working Group, B. Wijnen, R. Presuhn,
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 17]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+            K.McCloghrie, "The View-based Access Control Model of SNMP
+            V3", RFC 2575, April 1999
+
+[4]         The CAT Working Group, Tung, et al, "Public Key Cryptography
+            for Initial Authentication in Kerberos", draft-ietf-cat-pk-
+            init-11, November 1999
+
+[5]         Arango, et al, "Media Gateway Control Protocl (MGCP)", RFC
+            2705, October 1999
+
+
+[RFC2571]   Harrington, D., Presuhn, R., and B. Wijnen, An Architecture
+            for Describing SNMP Management Frameworks, RFC 2571, April
+            1999.
+
+[RFC1155]   Rose, M., and K. McCloghrie, Structure and Identification of
+            Management Information for TCP/IP-based Internets, STD 16,
+            RFC 1155, May 1990.
+
+[RFC1212]   Rose, M., and K. McCloghrie, Concise MIB Definitions, STD
+            16, RFC 1212, March 1991.
+
+[RFC1215]   M. Rose, A Convention for Defining Traps for use with the
+            SNMP, RFC 1215, March 1991.
+
+[RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+            Rose, M., and S. Waldbusser, Structure of Management Infor-
+            mation Version 2 (SMIv2), STD 58, RFC 2578, April 1999.
+
+[RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+            Rose, M., and S. Waldbusser, Textual Conventions for SMIv2,
+            STD 58, RFC 2579, April 1999.
+
+[RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+            Rose, M., and S. Waldbusser, Conformance Statements for
+            SMIv2, STD 58, RFC 2580, April 1999.
+
+[RFC1157]   Case, J., Fedor, M., Schoffstall, M., and J. Davin, Simple
+            Network Management Protocol, STD 15, RFC 1157, May 1990.
+
+[RFC1901]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
+            Introduction to Community-based SNMPv2, RFC 1901, January
+            1996.
+
+[RFC1906]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, Tran-
+            sport Mappings for Version 2 of the Simple Network Manage-
+            ment Protocol (SNMPv2), RFC 1906, January 1996.
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 18]
+
+
+
+
+
+INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
+
+
+[RFC2572]   Case, J., Harrington D., Presuhn R., and B. Wijnen, Message
+            Processing and Dispatching for the Simple Network Management
+            Protocol (SNMP), RFC 2572, April 1999.
+
+[RFC2574]   Blumenthal, U., and B. Wijnen, User-based Security Model
+            (USM) for version 3 of the Simple Network Management Proto-
+            col (SNMPv3), RFC 2574, April 1999.
+
+[RFC1905]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, Pro-
+            tocol Operations for Version 2 of the Simple Network Manage-
+            ment Protocol (SNMPv2), RFC 1905, January 1996.
+
+[RFC2573]   Levi, D., Meyer, P., and B. Stewart, SNMPv3 Applications,
+            RFC 2573, April 1999.
+
+[RFC2575]   Wijnen, B., Presuhn, R., and K. McCloghrie, View-based
+            Access Control Model (VACM) for the Simple Network Manage-
+            ment Protocol (SNMP), RFC 2575, April 1999.
+
+[RFC2570]   Case, J., Mundy, R., Partain, D., and B. Stewart, Introduc-
+            tion to Version 3 of the Internet-standard Network Manage-
+            ment Framework, RFC 2570, April 1999.
+
+Author's Address
+
+          Michael Thomas
+          Cisco Systems
+          375 E Tasman Rd
+          San Jose, Ca, 95134, USA
+          Tel: +1 408-525-5386
+          email: mat@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 19]
+
+
diff --git a/crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt b/crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt
new file mode 100644
index 000000000000..b89108a53be9
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt
@@ -0,0 +1,227 @@
+
+CAT Working Group                                     Mike Swift 
+draft-trostle-win2k-cat-kerberos-set-passwd-00.txt    Microsoft               
+February 2000                                         Jonathan Trostle
+Category: Informational                               Cisco Systems
+                                                      John Brezak
+                                                      Microsoft
+
+         Extending Change Password for Setting Kerberos Passwords
+
+
+0. Status Of This Memo
+
+   This document is an Internet-Draft and is in full conformance with 
+   all 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/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   Comments and suggestions on this document are encouraged.  Comments 
+   on this document should be sent to the CAT working group discussion 
+   list:
+                       ietf-cat-wg@stanford.edu
+
+1. Abstract
+
+   The Kerberos [1] change password protocol [2], does not allow for 
+   an administrator to set a password for a new user. This functionality
+   is useful in some environments, and this proposal extends [2] to
+   allow password setting. The changes are: adding new fields to the 
+   request message to indicate the principal which is having its 
+   password set, not requiring the initial flag in the service ticket, 
+   using a new protocol version number, and adding three new result 
+   codes. 
+   
+2. The Protocol
+
+   The service must accept requests on UDP port 464 and TCP port 464 as 
+   well. The protocol consists of a single request message followed by 
+   a single reply message.  For UDP transport, each message must be fully 
+   contained in a single UDP packet.
+
+   For TCP transport, there is a 4 octet header in network byte order
+   precedes the message and specifies the length of the message. This
+
+   requirement is consistent with the TCP transport header in 1510bis.
+
+Request Message
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         message length        |    protocol version number    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          AP_REQ length        |         AP_REQ data           /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                        KRB-PRIV message                       /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   All 16 bit fields are in big-endian order. 
+
+   message length field: contains the number of bytes in the message 
+   including this field.
+
+   protocol version number: contains the hex constant 0xff80 (big-endian 
+   integer).
+
+   AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, 
+   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
+   message.
+
+   AP-REQ data: (see [1]) The AP-REQ message must be for the service 
+   principal kadmin/changepw@REALM, where REALM is the REALM of the user 
+   who wishes to change/set his password. The ticket in the AP-REQ must 
+   must include a subkey in the Authenticator. To enable setting of 
+   passwords, it is not required that the initial flag be set in the 
+   Kerberos service ticket.
+
+   KRB-PRIV message (see [1]) This KRB-PRIV message must be generated 
+   using the subkey from the authenticator in the AP-REQ data. 
+
+   The user-data component of the message consists of the following ASN.1 
+   structure encoded as an OCTET STRING:
+
+   ChangePasswdData ::=  SEQUENCE {
+                       newpasswd[0]   OCTET STRING,
+                       targname[2]    PrincipalName OPTIONAL,
+                       targrealm[3]   Realm OPTIONAL
+                       }  
+
+   The server must verify the AP-REQ message, check whether the client 
+   principal in the ticket is authorized to set/change the password 
+   (either for that principal, or for the principal in the targname 
+   field if present), and decrypt the new password. The server also 
+   checks whether the initial flag is required for this request, 
+   replying with status 0x0007 if it is not set and should be. An 
+   authorization failure is cause to respond with status 0x0005. For 
+   forward compatibility, the server should be prepared to ignore fields 
+   after targrealm in the structure that it does not understand. 
+
+   The newpasswd field contains the cleartext password, and the server 
+   should apply any local policy checks including password policy checks. 
+   The server then generates the appropriate keytypes from the password
+
+   and stores them in the KDC database. If all goes well, status 0x0000 
+   is returned to the client in the reply message (see below).
+
+Reply Message
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         message length        |    protocol version number    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          AP_REP length        |         AP-REP data           /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                         KRB-PRIV message                      /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   All 16 bit fields are in big-endian order. 
+
+   message length field: contains the number of bytes in the message 
+   including this field.
+
+   protocol version number: contains the hex constant 0x0001 (big-endian 
+   integer). (The reply message has the same format as in [2]).
+
+   AP-REP length: length of AP-REP data, in bytes. If the length is zero, 
+   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
+   message.
+
+   AP-REP data: the AP-REP is the response to the AP-REQ in the request 
+   packet.
+   
+   KRB-PRIV from [2]: This KRB-PRIV message must be generated using the 
+   subkey in the authenticator in the AP-REQ data.
+
+   The server will respond with a KRB-PRIV message unless it cannot
+   decode the client AP-REQ or KRB-PRIV message, in which case it will
+   respond with a KRB-ERROR message. NOTE: Unlike change password version
+   1, the KRB-ERROR message will be sent back without any encapsulation.
+
+   The user-data component of the KRB-PRIV message, or e-data component 
+   of the KRB-ERROR message, must consist of the following data.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          result code          |        result string          /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      result code (16 bits) (result codes 0-4 are from [2]):
+         The result code must have one of the following values (big-
+         endian integer):
+         KRB5_KPASSWD_SUCCESS      0 request succeeds (This value is not 
+                                     allowed in a KRB-ERROR message)
+         KRB5_KPASSWD_MALFORMED    1 request fails due to being malformed
+         KRB5_KPASSWD_HARDERROR    2 request fails due to "hard" error in
+                                     processing the request (for example, 
+                                     there is a resource or other problem 
+                                     causing the request to fail)
+
+         KRB5_KPASSWD_AUTHERROR    3 request fails due to an error in 
+                                     authentication processing
+         KRB5_KPASSWD_SOFTERROR    4 request fails due to a "soft" error 
+                                     in processing the request 
+         KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
+         KRB5_KPASSWD_BAD_VERSION  6 protocol version unsupported
+         KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required
+         0xFFFF if the request fails for some other reason.
+         Although only a few non-zero result codes are specified here,
+         the client should accept any non-zero result code as indicating
+         failure.
+      result string - from [2]:
+         This field should contain information which the server thinks
+         might be useful to the user, such as feedback about policy
+         failures.  The string must be encoded in UTF-8.  It may be
+         omitted if the server does not wish to include it.  If it is
+         present, the client should display the string to the user.
+         This field is analogous to the string which follows the numeric
+         code in SMTP, FTP, and similar protocols.
+
+3. References
+ 
+   [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
+   Service (V5). Request for Comments 1510.
+
+   [2] M. Horowitz. Kerberos Change Password Protocol.
+   ftp://ds.internic.net/internet-drafts/
+   draft-ietf-cat-kerb-chg-password-02.txt
+
+4. Expiration Date
+
+   This draft expires in August 2000.   
+
+5. Authors' Addresses
+
+   Jonathan Trostle
+   Cisco Systems
+   170 W. Tasman Dr.
+   San Jose, CA 95134
+   Email: jtrostle@cisco.com
+
+   Mike Swift 
+   1 Microsoft Way
+   Redmond, WA 98052
+   mikesw@microsoft.com
+
+   John Brezak
+   1 Microsoft Way
+   Redmond, WA 98052
+   jbrezak@microsoft.com
diff --git a/crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt b/crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt
new file mode 100644
index 000000000000..e9611e395bfd
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt
@@ -0,0 +1,327 @@
+Network Working Group                                    T. Ts'o, Editor
+Internet-Draft                     Massachusetts Institute of Technology
+draft-tso-telnet-krb5-04.txt                                  April 2000
+
+               Telnet Authentication: Kerberos Version 5
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all 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 mate-
+   rial 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.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119.
+
+0. Abstract
+
+   This document describes how Kerberos Version 5 [1] is used with the
+   telnet protocol.   It describes an telnet authentication sub-option
+   to be used with the telnet authentication option [2].   This mecha-
+   nism can also used to provide keying material to provide data confi-
+   dentiality services in conjuction with the telnet encryption option
+   [3].
+
+1. Command Names and Codes
+
+   Authentication Types
+
+      KERBEROS_V5    2
+
+   Sub-option Commands
+
+                           Expires Sept 2000                    [Page 1]
+
+Internet-Draft        Kerberos Version 5 for Telnet           April 2000
+
+      AUTH               0
+      REJECT             1
+      ACCEPT             2
+      RESPONSE           3
+      FORWARD            4
+      FORWARD_ACCEPT     5
+      FORWARD_REJECT     6
+
+2.  Command Meanings
+
+   IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5
+   KRB_AP_REQ message> IAC SE
+
+      This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the
+      remote side of the connection.  The first octet of the <authenti-
+      cation-type-pair> value is KERBEROS_V5, to indicate that Version 5
+      of Kerberos is being used.  The Kerberos V5 authenticator in the
+      KRB_AP_REQ message     must contain a Kerberos V5 checksum of the
+      two-byte authentication type pair.  This checksum must be verified
+      by the server to assure that the authentication type pair was cor-
+      rectly negotiated.  The Kerberos V5 authenticator must also in-
+      clude the optional subkey field, which shall be filled in with a
+      randomly chosen key.  This key shall be used for encryption pur-
+      poses if encryption is negotiated, and shall be used as the nego-
+      tiated session key (i.e., used as keyid 0) for the purposes of the
+      telnet encryption option; if the subkey is not filled in, then the
+      ticket session key will be used instead.
+
+      If data confidentiality services is desired the ENCRYPT_US-
+      ING_TELOPT flag must be set in the authentication-type-pair as
+      specified in [2].
+
+   IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE
+
+      This command indicates that the authentication was successful.
+
+      If the AUTH_HOW_MUTUAL bit is set in the second octet of the au-
+      thentication-type-pair, the RESPONSE command must be sent before
+      the ACCEPT command is sent.
+
+   IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT <op-
+   tional reason for rejection> IAC SE
+
+      This command indicates that the authentication was not successful,
+      and if there is any more data in the sub-option, it is an ASCII
+      text message of the reason for the rejection.
+
+   IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE
+   <KRB_AP_REP message> IAC SE
+
+                           Expires Sept 2000                    [Page 2]
+
+Internet-Draft        Kerberos Version 5 for Telnet           April 2000
+
+      This command is used to perform mutual authentication.  It is only
+      used when the AUTH_HOW_MUTUAL bit is set in the second octet of
+      the authentication-type-pair.  After an AUTH command is verified,
+      a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP
+      message to perform the mutual authentication.
+
+   IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED
+   message> IAC SE
+
+      This command is used to forward kerberos credentials for use by
+      the remote session.  The credentials are passed as a Kerberos V5
+      KRB_CRED message which includes, among other things, the forwarded
+      Kerberos ticket and a session key associated with the ticket. Part
+      of the KRB_CRED message is encrypted in the key previously ex-
+      changed for the telnet session by the AUTH suboption.
+
+   IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC
+   SE
+
+      This command indicates that the credential forwarding was success-
+      ful.
+
+   IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT <op-
+   tional reason for rejection> IAC SE
+
+      This command indicates that the credential forwarding was not suc-
+      cessful, and if there is any more data in the sub-option, it is an
+      ASCII text message of the reason for the rejection.
+
+3.  Implementation Rules
+
+   If the second octet of the authentication-type-pair has the AUTH_WHO
+   bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial
+   AUTH command, and the server responds with either ACCEPT or REJECT.
+   In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the serv-
+   er will send a RESPONSE before it sends the ACCEPT.
+
+   If the second octet of the authentication-type-pair has the AUTH_WHO
+   bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial
+   AUTH command, and the client responds with either ACCEPT or REJECT.
+   In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the
+   client will send a RESPONSE before it sends the ACCEPT.
+
+   The Kerberos principal used by the server will generally be of the
+   form "host/<hostname>@realm".  That is, the first component of the
+   Kerberos principal is "host"; the second component is the fully qual-
+   ified lower-case hostname of the server; and the realm is the Ker-
+   beros realm to which the server belongs.
+
+                           Expires Sept 2000                    [Page 3]
+
+Internet-Draft        Kerberos Version 5 for Telnet           April 2000
+
+   Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP
+   messages, the KRB_CRED structure, or the optional rejection text
+   string must be doubled as specified in [4].  Otherwise the following
+   byte might be mis-interpreted as a Telnet command.
+
+4.  Examples
+
+   User "joe" may wish to log in as user "pete" on machine "foo".  If
+   "pete" has set things up on "foo" to allow "joe" access to his ac-
+   count, then the client would send IAC SB AUTHENTICATION NAME "pete"
+   IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE>
+   IAC SE
+
+   The server would then authenticate the user as "joe" from the
+   KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by
+   Kerberos, and if "pete" has allowed "joe" to use his account, the
+   server would then continue the authentication sequence by sending a
+   RESPONSE (to do mutual authentication, if it was requested) followed
+   by the ACCEPT.
+
+   If forwarding has been requested, the client then sends IAC SB AU-
+   THENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED structure
+   with credentials to be forwarded> IAC SE.  If the server succeeds in
+   reading the forwarded credentials, the server sends FORWARD_ACCEPT
+   else, a FORWARD_REJECT is sent back.
+
+       Client                           Server
+                                        IAC DO AUTHENTICATION
+       IAC WILL AUTHENTICATION
+
+       [ The server is now free to request authentication information.
+         ]
+
+                                        IAC SB AUTHENTICATION SEND
+                                        KERBEROS_V5 CLIENT|MUTUAL
+                                        KERBEROS_V5 CLIENT|ONE_WAY IAC
+                                        SE
+
+       [ The server has requested mutual Version 5 Kerberos
+         authentication.  If mutual authentication is not supported,
+         then the server is willing to do one-way authentication.
+
+         The client will now respond with the name of the user that it
+         wants to log in as, and the Kerberos ticket.  ]
+
+       IAC SB AUTHENTICATION NAME
+       "pete" IAC SE
+       IAC SB AUTHENTICATION IS
+       KERBEROS_V5 CLIENT|MUTUAL AUTH
+       <KRB_AP_REQ message> IAC SE
+
+                           Expires Sept 2000                    [Page 4]
+
+Internet-Draft        Kerberos Version 5 for Telnet           April 2000
+
+       [ Since mutual authentication is desired, the server sends across
+         a RESPONSE to prove that it really is the right server.  ]
+
+                                        IAC SB AUTHENTICATION REPLY
+                                        KERBEROS_V5 CLIENT|MUTUAL
+                                        RESPONSE <KRB_AP_REP message>
+                                        IAC SE
+
+       [ The server responds with an ACCEPT command to state that the
+         authentication was successful.  ]
+
+                                        IAC SB AUTHENTICATION REPLY KER-
+                                        BEROS_V5 CLIENT|MUTUAL ACCEPT
+                                        IAC SE
+
+       [ If so requested, the client now sends the FORWARD command to
+         forward credentials to the remote site.  ]
+
+       IAC SB AUTHENTICATION IS KER-
+       BEROS_V5 CLIENT|MUTUAL
+       FORWARD <KRB_CRED message> IAC
+       SE
+
+       [ The server responds with a FORWARD_ACCEPT command to state that
+         the credential forwarding was successful.  ]
+
+                           Expires Sept 2000                    [Page 5]
+
+Internet-Draft        Kerberos Version 5 for Telnet           April 2000
+
+                                        IAC SB AUTHENTICATION REPLY KER-
+                                        BEROS_V5 CLIENT|MUTUAL FOR-
+                                        WARD_ACCEPT IAC SE
+
+5. Security Considerations
+
+   The selection of the random session key in the Kerberos V5 authenti-
+   cator is critical, since this key will be used for encrypting the
+   telnet data stream if encryption is enabled.  It is strongly advised
+   that the random key selection be done using cryptographic techniques
+   that involve the Kerberos ticket's session key.  For example, using
+   the current time, encrypting it with the ticket session key, and then
+   correcting for key parity is a strong way to generate a subsession
+   key, since the ticket session key is assumed to be never disclosed to
+   an attacker.
+
+   Care should be taken before forwarding a user's Kerberos credentials
+   to the remote server.  If the remote server is not trustworthy, this
+   could result in the user's credentials being compromised.  Hence, the
+   user interface should not forward credentials by default; it would be
+   far safer to either require the user to explicitly request creden-
+   tials forwarding for each connection, or to have a trusted list of
+   hosts for which credentials forwarding is enabled, but to not enable
+   credentials forwarding by default for all machines.
+
+6. IANA Considerations
+
+   The authentication type KERBEROS_V5 and its associated suboption values
+   are registered with IANA.  Any suboption values used to extend 
+   the protocol as described in this document must be registered
+   with IANA before use.  IANA is instructed not to issue new suboption
+   values without submission of documentation of their use.
+
+7. Acknowledgments
+
+   This document was originally written by Dave Borman of Cray Research,
+   Inc.  Theodore Ts'o of MIT revised it to reflect the latest implemen-
+   tation experience.  Cliff Neuman and Prasad Upasani of USC's Informa-
+   tion Sciences Institute developed the credential forwarding support.
+
+   In addition, the contributions of the Telnet Working Group are also
+   gratefully acknowledged.
+
+8. References
+
+   [1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Sys-
+       tem (V5)", RFC 1510, USC/Information Sciences Institute, Septem-
+       ber 1993.
+
+   [2] Internet Engineering Task Force, "Telnet Authentication", draft-
+       tso-telnet-auth-enc-04.txt, T. Ts'o, Editor, VA Linux Systems,
+           April 2000.
+
+   [3] Internet Engineering Task Force, "Telnet Data Encryption Option",
+       draft-tso-telnet-encryption-04.txt, T. Ts'o, Editor, VA Linux
+       Systems,     April 2000.
+
+   [4] Postel, J.B. and J. Reynolds, "Telnet Option Specifications", RFC
+
+                           Expires Sept 2000                    [Page 6]
+
+Internet-Draft        Kerberos Version 5 for Telnet           April 2000
+
+       855, STD 8, USC/Information Sciences Institute, May 1983.
+
+Editor's Address
+
+   Theodore Ts'o
+   Massachusetts Institute of Technology
+   MIT Room E40-343
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+
+   Phone: (617) 253-8091
+   EMail: tytso@mit.edu
+
+                           Expires Sept 2000                    [Page 7]
+
+
+    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
+                 The Kermit Project * Columbia University
+              612 West 115th St #716 * New York, NY * 10025
+  http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org
+
+
diff --git a/crypto/heimdal/doc/standardisation/rc4-hmac.txt b/crypto/heimdal/doc/standardisation/rc4-hmac.txt
new file mode 100644
index 000000000000..202d44e8639c
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/rc4-hmac.txt
@@ -0,0 +1,587 @@
+CAT working group                                              M. Swift 
+Internet Draft                                                J. Brezak 
+Document: draft-brezak-win2k-krb-rc4-hmac-03.txt              Microsoft 
+Category: Informational                                       June 2000 
+ 
+ 
+           The Windows 2000 RC4-HMAC Kerberos encryption type 
+ 
+ 
+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 Windows 2000 implementation of Kerberos introduces a new 
+   encryption type based on the RC4 encryption algorithm and using an 
+   MD5 HMAC for checksum. This is offered as an alternative to using 
+   the existing DES based encryption types. 
+    
+   The RC4-HMAC encryption types are used to ease upgrade of existing 
+   Windows NT environments, provide strong crypto (128-bit key 
+   lengths), and provide exportable (meet United States government 
+   export restriction requirements) encryption. 
+    
+   The Windows 2000 implementation of Kerberos contains new encryption 
+   and checksum types for two reasons: for export reasons early in the 
+   development process, 56 bit DES encryption could not be exported, 
+   and because upon upgrade from Windows NT 4.0 to Windows 2000, 
+   accounts will not have the appropriate DES keying material to do the 
+   standard DES encryption. Furthermore, 3DES is not available for 
+   export, and there was a desire to use a single flavor of encryption 
+   in the product for both US and international products. 
+    
+   As a result, there are two new encryption types and one new checksum 
+   type introduced in Windows 2000. 
+    
+    
+2. Conventions used in this document 
+    
+
+  
+Swift                  Category - Informational                      1 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC-2119 [2]. 
+    
+3. Key Generation 
+    
+   On upgrade from existing Windows NT domains, the user accounts would 
+   not have a DES based key available to enable the use of DES base 
+   encryption types specified in RFC 1510. The key used for RC4-HMAC is 
+   the same as the existing Windows NT key (NT Password Hash) for 
+   compatibility reasons. Once the account password is changed, the DES 
+   based keys are created and maintained. Once the DES keys are 
+   available DES based encryption types can be used with Kerberos.  
+    
+   The RC4-HMAC String to key function is defined as follow: 
+    
+   String2Key(password) 
+    
+        K = MD4(UNICODE(password)) 
+         
+   The RC4-HMAC keys are generated by using the Windows UNICODE version 
+   of the password. Each Windows UNICODE character is encoded in 
+   little-endian format of 2 octets each. Then performing an MD4 [6] 
+   hash operation on just the UNICODE characters of the password (not 
+   including the terminating zero octets). 
+    
+   For an account with a password of "foo", this String2Key("foo") will 
+   return: 
+    
+        0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, 
+        0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc 
+    
+4. Basic Operations 
+    
+   The MD5 HMAC function is defined in [3]. It is used in this 
+   encryption type for checksum operations. Refer to [3] for details on 
+   its operation. In this document this function is referred to as 
+   HMAC(Key, Data) returning the checksum using the specified key on 
+   the data. 
+    
+   The basic MD5 hash operation is used in this encryption type and 
+   defined in [7]. In this document this function is referred to as 
+   MD5(Data) returning the checksum of the data. 
+    
+   RC4 is a stream cipher licensed by RSA Data Security [RSADSI]. A       
+   compatible cipher is described in [8]. In this document the function 
+   is referred to as RC4(Key, Data) returning the encrypted data using 
+   the specified key on the data. 
+    
+   These encryption types use key derivation as defined in [9] (RFC-
+   1510BIS) in Section titled "Key Derivation". With each message, the 
+   message type (T) is used as a component of the keying material. This 
+   summarizes the different key derivation values used in the various 
+  
+Swift                  Category - Informational                      2 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+   operations. Note that these differ from the key derivations used in 
+   other Kerberos encryption types. 
+    
+        T = 1 for TS-ENC-TS in the AS-Request 
+        T = 8 for the AS-Reply  
+        T = 7 for the Authenticator in the TGS-Request 
+        T = 8 for the TGS-Reply  
+        T = 2 for the Server Ticket in the AP-Request 
+        T = 11 for the Authenticator in the AP-Request 
+        T = 12 for the Server returned AP-Reply 
+        T = 15 in the generation of checksum for the MIC token 
+        T = 0 in the generation of sequence number for the MIC token  
+        T = 13 in the generation of checksum for the WRAP token 
+        T = 0 in the generation of sequence number for the WRAP token  
+        T = 0 in the generation of encrypted data for the WRAPPED token 
+    
+   All strings in this document are ASCII unless otherwise specified. 
+   The lengths of ASCII encoded character strings include the trailing 
+   terminator character (0). 
+    
+   The concat(a,b,c,...) function will return the logical concatenation 
+   (left to right) of the values of the arguments. 
+    
+   The nonce(n) function returns a pseudo-random number of "n" octets. 
+    
+5. Checksum Types 
+    
+   There is one checksum type used in this encryption type. The 
+   Kerberos constant for this type is: 
+        #define KERB_CHECKSUM_HMAC_MD5 (-138) 
+    
+   The function is defined as follows: 
+    
+   K - is the Key 
+   T - the message type, encoded as a little-endian four byte integer 
+    
+   CHKSUM(K, T, data) 
+    
+        Ksign = HMAC(K, "signaturekey")  //includes zero octet at end 
+        tmp = MD5(concat(T, data)) 
+        CHKSUM = HMAC(Ksign, tmp) 
+    
+    
+6. Encryption Types 
+    
+   There are two encryption types used in these encryption types. The 
+   Kerberos constants for these types are: 
+        #define KERB_ETYPE_RC4_HMAC             23 
+        #define KERB_ETYPE_RC4_HMAC_EXP         24 
+    
+   The basic encryption function is defined as follow: 
+    
+   T = the message type, encoded as a little-endian four byte integer. 
+  
+Swift                  Category - Informational                      3 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+    
+        BYTE L40[14] = "fortybits"; 
+        BYTE SK = "signaturekey"; 
+         
+        ENCRYPT (K, fRC4_EXP, T, data, data_len, edata, edata_len) 
+        { 
+            if (fRC4_EXP){ 
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 10 + 4, K1); 
+            }else{ 
+                HMAC (K, &T, 4, K1); 
+            } 
+            memcpy (K2, K1, 16); 
+            if (fRC4_EXP) memset (K1+7, 0xAB, 9); 
+            add_8_random_bytes(data, data_len, conf_plus_data); 
+            HMAC (K2, conf_plus_data, 8 + data_len, checksum); 
+            HMAC (K1, checksum, 16, K3); 
+            RC4(K3, conf_plus_data, 8 + data_len, edata + 16); 
+            memcpy (edata, checksum, 16); 
+            edata_len = 16 + 8 + data_len; 
+        }         
+         
+        DECRYPT (K, fRC4_EXP, T, edata, edata_len, data, data_len) 
+        { 
+            if (fRC4_EXP){ 
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 14, K1); 
+            }else{ 
+                HMAC (K, &T, 4, K1); 
+            } 
+            memcpy (K2, K1, 16); 
+            if (fRC4_EXP) memset (K1+7, 0xAB, 9); 
+            HMAC (K1, edata, 16, K3); // checksum is at edata 
+            RC4(K3, edata + 16, edata_len - 16, edata + 16); 
+            data_len = edata_len - 16 - 8; 
+            memcpy (data, edata + 16 + 8, data_len); 
+             
+            // verify generated and received checksums 
+            HMAC (K2, edata + 16, edata_len - 16, checksum); 
+            if (memcmp(edata, checksum, 16) != 0)  
+                printf("CHECKSUM ERROR  !!!!!!\n"); 
+        } 
+    
+   The header field on the encrypted data in KDC messages is: 
+    
+        typedef struct _RC4_MDx_HEADER { 
+            UCHAR Checksum[16]; 
+            UCHAR Confounder[8]; 
+        } RC4_MDx_HEADER, *PRC4_MDx_HEADER; 
+         
+   The KDC message is encrypted using the ENCRYPT function not 
+   including the Checksum in the RC4_MDx_HEADER. 
+    
+  
+Swift                  Category - Informational                      4 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+   The character constant "fortybits" evolved from the time when a 40-
+   bit key length was all that was exportable from the United States. 
+   It is now used to recognize that the key length is of "exportable" 
+   length. In this description, the key size is actually 56-bits. 
+    
+7. Key Strength Negotiation 
+    
+   A Kerberos client and server can negotiate over key length if they 
+   are using mutual authentication. If the client is unable to perform 
+   full strength encryption, it may propose a key in the "subkey" field 
+   of the authenticator, using a weaker encryption type. The server 
+   must then either return the same key or suggest its own key in the 
+   subkey field of the AP reply message. The key used to encrypt data 
+   is derived from the key returned by the server. If the client is 
+   able to perform strong encryption but the server is not, it may 
+   propose a subkey in the AP reply without first being sent a subkey 
+   in the authenticator. 
+ 
+8. GSSAPI Kerberos V5 Mechanism Type  
+ 
+8.1 Mechanism Specific Changes 
+    
+   The GSSAPI per-message tokens also require new checksum and 
+   encryption types. The GSS-API per-message tokens must be changed to 
+   support these new encryption types (See [5] Section 1.2.2). The 
+   sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption 
+   is: 
+        Byte 4..5 SEAL_ALG      0x10 0x00 - RC4 
+    
+   The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: 
+        Byte 2..3 SGN ALG       0x11 0x00 - HMAC 
+    
+   The only support quality of protection is: 
+        #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0 
+    
+   In addition, when using an RC4 based encryption type, the sequence 
+   number is sent in big-endian rather than little-endian order. 
+    
+   The Windows 2000 implementation also defines new GSSAPI flags in the 
+   initial token passed when initializing a security context. These 
+   flags are passed in the checksum field of the authenticator (See [5] 
+   Section 1.1.1). 
+    
+   GSS_C_DCE_STYLE - This flag was added for use with Microsoft’s 
+   implementation of DCE RPC, which initially expected three legs of 
+   authentication. Setting this flag causes an extra AP reply to be 
+   sent from the client back to the server after receiving the server’s 
+   AP reply. In addition, the context negotiation tokens do not have 
+   GSSAPI framing - they are raw AP message and do not include object 
+   identifiers. 
+        #define GSS_C_DCE_STYLE                 0x1000 
+    
+
+  
+Swift                  Category - Informational                      5 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+   GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the 
+   server that it should only allow the server application to identify 
+   the client by name and ID, but not to impersonate the client. 
+        #define GSS_C_IDENTIFY_FLAG             0x2000 
+         
+   GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the 
+   client wants to be informed of extended error information. In 
+   particular, Windows 2000 status codes may be returned in the data 
+   field of a Kerberos error message. This allows the client to 
+   understand a server failure more precisely. In addition, the server 
+   may return errors to the client that are normally handled at the 
+   application layer in the server, in order to let the client try to 
+   recover. After receiving an error message, the client may attempt to 
+   resubmit an AP request. 
+        #define GSS_C_EXTENDED_ERROR_FLAG       0x4000 
+    
+   These flags are only used if a client is aware of these conventions 
+   when using the SSPI on the Windows platform, they are not generally 
+   used by default. 
+    
+   When NetBIOS addresses are used in the GSSAPI, they are identified 
+   by the GSS_C_AF_NETBIOS value. This value is defined as: 
+        #define GSS_C_AF_NETBIOS                0x14 
+   NetBios addresses are 16-octet addresses typically composed of 1 to 
                                                                 th
   15 characters, trailing blank (ascii char 20) filled, with a 16  
+   octet of 0x0. 
+    
+8.2 GSSAPI Checksum Type 
+    
+   The GSSAPI checksum type and algorithm is defined in Section 5. Only 
+   the first 8 octets of the checksum are used. The resulting checksum 
+   is stored in the SGN_CKSUM field (See [5] Section 1.2) for 
+   GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). 
+    
+        MIC (K, fRC4_EXP, seq_num, MIC_hdr, msg, msg_len, 
+             MIC_seq, MIC_checksum) 
+        { 
+            HMAC (K, SK, 13, K4); 
+            T = 15; 
+            memcpy (T_plus_hdr_plus_msg + 00, &T, 4); 
+            memcpy (T_plus_hdr_plus_msg + 04, MIC_hdr, 8);  
+                                                // 0101 1100 FFFFFFFF 
+            memcpy (T_plus_hdr_plus_msg + 12, msg, msg_len); 
+            MD5 (T_hdr_msg, 4 + 8 + msg_len, MD5_of_T_hdr_msg); 
+            HMAC (K4, MD5_of_T_hdr_msg, CHKSUM); 
+            memcpy (MIC_checksum, CHKSUM, 8); // use only first 8 bytes 
+          
+            T = 0; 
+            if (fRC4_EXP){  
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 14, K5); 
+            }else{ 
+                HMAC (K, &T, 4, K5); 
+  
+Swift                  Category - Informational                      6 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+            } 
+            if (fRC4_EXP) memset(K5+7, 0xAB, 9); 
+            HMAC(K5, MIT_checksum, 8, K6); 
+            copy_seq_num_in_big_endian(seq_num, seq_plus_direction); 
+        //0x12345678 
+            copy_direction_flag (direction_flag, seq_plus_direction + 
+        4); //0x12345678FFFFFFFF 
+            RC4(K6, seq_plus_direction, 8, MIC_seq); 
+        } 
+    
+8.3 GSSAPI Encryption Types 
+    
+   There are two encryption types for GSSAPI message tokens, one that 
+   is 128 bits in strength, and one that is 56 bits in strength as 
+   defined in Section 6. 
+    
+   All padding is rounded up to 1 byte. One byte is needed to say that 
+   there is 1 byte of padding. The DES based mechanism type uses 8 byte 
+   padding. See [5] Section 1.2.2.3. 
+    
+   The encryption mechanism used for GSS wrap based messages is as 
+   follow: 
+    
+    
+        WRAP (K, fRC4_EXP, seq_num, WRAP_hdr, msg, msg_len, 
+              WRAP_seq, WRAP_checksum, edata, edata_len) 
+        { 
+            HMAC (K, SK, 13, K7); 
+            T = 13; 
+            PAD = 1; 
+            memcpy (T_hdr_conf_msg_pad + 00, &T, 4); 
+            memcpy (T_hdr_conf_msg_pad + 04, WRAP_hdr, 8); // 0101 1100 
+        FFFFFFFF 
+            memcpy (T_hdr_conf_msg_pad + 12, msg, msg_len); 
+            memcpy (T_hdr_conf_msg_pad + 12 + msg_len, &PAD, 1); 
+            MD5 (T_hdr_conf_msg_pad, 
+                 4 + 8 + 8 + msg_len + 1, 
+                 MD5_of_T_hdr_conf_msg_pad); 
+            HMAC (K7, MD5_of_T_hdr_conf_msg_pad, CHKSUM); 
+            memcpy (WRAP_checksum, CHKSUM, 8); // use only first 8 
+        bytes 
+          
+            T = 0; 
+            if (fRC4_EXP){  
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 14, K8); 
+            }else{ 
+                HMAC (K, &T, 4, K8); 
+            } 
+            if (fRC4_EXP) memset(K8+7, 0xAB, 9); 
+            HMAC(K8, WRAP_checksum, 8, K9); 
+            copy_seq_num_in_big_endian(seq_num, seq_plus_direction); 
+        //0x12345678 
+  
+Swift                  Category - Informational                      7 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+            copy_direction_flag (direction_flag, seq_plus_direction + 
+        4); //0x12345678FFFFFFFF 
+            RC4(K9, seq_plus_direction, 8, WRAP_seq); 
+          
+            for (i = 0; i < 16; i++) K10 [i] ^= 0xF0; // XOR each byte 
+        of key with 0xF0 
+            T = 0; 
+            if (fRC4_EXP){ 
+                *(DWORD *)(L40+10) = T; 
+                HMAC(K10, L40, 14, K11); 
+                memset(K11+7, 0xAB, 9); 
+            }else{ 
+                HMAC(K10, &T, 4, K11);  
+            } 
+            HMAC(K11, seq_num, 4, K12); 
+            RC4(K12, T_hdr_conf_msg_pad + 4 + 8, 8 + msg_len + 1, 
+        edata); /* skip T & hdr */ 
+            edata_len = 8 + msg_len + 1; // conf + msg_len + pad 
+         } 
+          
+    
+   The character constant "fortybits" evolved from the time when a 40-
+   bit key length was all that was exportable from the United States. 
+   It is now used to recognize that the key length is of "exportable" 
+   length. In this description, the key size is actually 56-bits. 
+    
+9. Security Considerations 
+ 
+   Care must be taken in implementing this encryption type because it 
+   uses a stream cipher. If a different IV isn’t used in each direction 
+   when using a session key, the encryption is weak. By using the 
+   sequence number as an IV, this is avoided. 
+    
+10. Acknowledgements 
+    
+   We would like to thank Salil Dangi for the valuable input in 
+   refining the descriptions of the functions and review input. 
+     
+11. References 
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997 
+    
+   3  Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for 
+      Message Authentication", RFC 2104, February 1997 
+    
+   4  Kohl, J., Neuman, C., "The Kerberos Network Authentication 
+      Service (V5)", RFC 1510, September 1993 
+ 
+ 
+  
+Swift                  Category - Informational                      8 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+ 
+ 
+ 
+   5  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, 
+      June 1996 
+ 
+   6  R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April 
+      1992 
+ 
+   7  R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April 
+      1992 
+ 
+   8  Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption             
+      Algorithm", Work in Progress. 
+ 
+   9  RC4 is a proprietary encryption algorithm available under license 
+      from RSA Data Security Inc.  For licensing information, contact: 
+       
+         RSA Data Security, Inc. 
+         100 Marine Parkway 
+         Redwood City, CA 94065-1031 
+ 
+   10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 
+      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
+      04.txt, June 25, 1999 
+ 
+    
+12. Author's Addresses 
+    
+   Mike Swift 
+   Dept. of Computer Science 
+   Sieg Hall 
+   University of Washington 
+   Seattle, WA 98105 
+   Email: mikesw@cs.washington.edu  
+    
+   John Brezak 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@microsoft.com 
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                      9 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
+ 
+ 
+    
+13. 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. 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                     10 
+