From e250cf5cdbc0c46af6712cc06b84c464d03b3f3e Mon Sep 17 00:00:00 2001 From: Assar Westerlund Date: Fri, 11 Aug 2000 01:47:11 +0000 Subject: [PATCH] some more drafts git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@8936 ec53bebd-3082-4978-b11e-865c3cabbd6b --- .../draft-brezak-win2k-krb-rc4-hmac-02.txt | 5 + .../draft-brezak-win2k-krb-rc4-hmac-03.txt | 589 ++++++ .../draft-hornstein-dhc-kerbauth-02.txt | 1594 +++++++++++++++++ .../draft-ietf-cat-iakerb-04.txt | 301 ++++ .../draft-ietf-cat-kerberos-pk-init-12.txt | 1080 +++++++++++ .../draft-ietf-cat-kerberos-pk-tapp-03.txt | 378 ++++ .../draft-raeburn-cat-gssapi-krb5-3des-00.txt | 281 +++ .../draft-smedvinsky-dhc-kerbauth-01.txt | 929 ++++++++++ .../draft-swift-win2k-krb-referrals-01.txt | 5 + .../draft-swift-win2k-krb-user2user-01.txt | 5 + .../draft-thomas-snmpv3-kerbusm-00.txt | 1140 ++++++++++++ ...ostle-win2k-cat-kerberos-set-passwd-00.txt | 227 +++ .../draft-tso-telnet-krb5-04.txt | 327 ++++ 13 files changed, 6861 insertions(+) create mode 100644 doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt create mode 100644 doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt create mode 100644 doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt create mode 100644 doc/standardisation/draft-ietf-cat-iakerb-04.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt create mode 100644 doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt create mode 100644 doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt create mode 100644 doc/standardisation/draft-swift-win2k-krb-referrals-01.txt create mode 100644 doc/standardisation/draft-swift-win2k-krb-user2user-01.txt create mode 100644 doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt create mode 100644 doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt create mode 100644 doc/standardisation/draft-tso-telnet-krb5-04.txt diff --git a/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt b/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt new file mode 100644 index 000000000..85d745684 --- /dev/null +++ b/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/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt b/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt new file mode 100644 index 000000000..9ebe39e0a --- /dev/null +++ b/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt @@ -0,0 +1,589 @@ +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/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt b/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt new file mode 100644 index 000000000..89e64524c --- /dev/null +++ b/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 + 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 , and +expires October 1, 2000. + + + + + + + + + + + + +Hornstein, et al. Standards Track [Page 28] + + diff --git a/doc/standardisation/draft-ietf-cat-iakerb-04.txt b/doc/standardisation/draft-ietf-cat-iakerb-04.txt new file mode 100644 index 000000000..208d057f2 --- /dev/null +++ b/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/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt new file mode 100644 index 000000000..b1e596836 --- /dev/null +++ b/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: + + + ":" + + + 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/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt new file mode 100644 index 000000000..6581dd581 --- /dev/null +++ b/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/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt b/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt new file mode 100644 index 000000000..24325fdbd --- /dev/null +++ b/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/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt b/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt new file mode 100644 index 000000000..321c5ba09 --- /dev/null +++ b/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt @@ -0,0 +1,929 @@ + + +DHC Working Group S. Medvinsky +Internet Draft Motorola +Document: +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 , 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 , 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/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt b/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt new file mode 100644 index 000000000..85d745684 --- /dev/null +++ b/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/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt b/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt new file mode 100644 index 000000000..85d745684 --- /dev/null +++ b/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/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt b/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt new file mode 100644 index 000000000..68c170b49 --- /dev/null +++ b/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/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt b/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt new file mode 100644 index 000000000..b89108a53 --- /dev/null +++ b/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/doc/standardisation/draft-tso-telnet-krb5-04.txt b/doc/standardisation/draft-tso-telnet-krb5-04.txt new file mode 100644 index 000000000..e9611e395 --- /dev/null +++ b/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 AUTH 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 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 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 REJECT 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 RESPONSE + 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 FORWARD 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 FORWARD_ACCEPT IAC + SE + + This command indicates that the credential forwarding was success- + ful. + + IAC SB AUTHENTICATION FORWARD_REJECT 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/@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 + 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 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 + 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 + 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 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 + +