oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity

some more drafts

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@8936 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Assar Westerlund
2000-08-11 01:47:11 +00:00
parent e6bb86aa0f
commit e250cf5cdb
13 changed files with 6861 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt Normal file
View File

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

589
doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt Normal file
View File

@@ -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<66>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<65>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<73>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

1594
doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt Normal file
View File

File diff suppressed because it is too large Load Diff

301
doc/standardisation/draft-ietf-cat-iakerb-04.txt Normal file
View File

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

1080
doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt Normal file
View File

File diff suppressed because it is too large Load Diff

378
doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt Normal file
View File

@@ -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<65>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<6E>s signature) and
seals it along with the signed information using the server<65>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<EFBFBD>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<49>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

281
doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt Normal file
View File

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

929
doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt Normal file
View File

@@ -0,0 +1,929 @@
DHC Working Group S. Medvinsky
Internet Draft Motorola
Document: <draft-smedvinsky-dhc-kerbauth-01.txt>
Category: Standards Track P.Lalwaney
Expires: January 2001 Nokia
July 2000
Kerberos V Authentication Mode for Uninitialized Clients
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The distribution of this memo is unlimited. It is filed as <draft-
smedvinsky-dhc-kerbauth-01.txt>, and expires January 2001. Please
send comments to the authors.
1. Abstract
The Dynamic Host Configuration Protocol (DHCP) [1] includes an
option that allows authentication of all DHCP messages, as specified
in [2]. This document specifies a DHCP authentication mode based on
Kerberos V tickets. This provides mutual authentication between a
DHCP client and server, as well as authentication of all DHCP
messages.
This document specifies Kerberos message exchanges between an
uninitialized client and the KDC (Key Distribution Center) using an
IAKERB proxy [7] so that the Kerberos key management phase is
decoupled from, and precedes the address allocation and network
configuration phase that uses the DHCP authentication option. In
order to make use of the IAKERB proxy, this document specifies a
transport mechanism that works with an uninitialized client (i.e. a
Kerberos V Authentication Mode for Uninitialized Clients July 2000
client without an assigned IP address). In addition, the document
specifies the format of the Kerberos authenticator to be used with
the DHCP authentication option.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119.
3. Introduction
3.1 Terminology
o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain configuration
parameters such as a network address.
o "DHCP server"
A DHCP server is an Internet host that returns configuration
parameters to DHCP clients.
O "Ticket"
A Kerberos term for a record that helps a client authenticate itself
to a server; it contains the client's identity, a session key, a
timestamp, and other information, all sealed using the server's
secret key. It only serves to authenticate a client when presented
along with a fresh Authenticator.
o "Key Distribution Center"
Key Distribution Center, a network service that supplies tickets and
temporary session keys; or an instance of that service or the host
on which it runs. The KDC services both initial ticket and Ticket-
Granting Ticket (TGT) requests. The initial ticket portion is
sometimes referred to as the Authentication Server (or service. The
Ticket-Granting Ticket portion is sometimes referred to as the
Ticket-Granting Server (or service).
o "Realm"
A Kerberos administrative domain that represents a group of
principals registered at a KDC. A single KDC may be responsible for
one or more realms. A fully qualified principal name includes a
realm name along with a principal name unique within that realm.
3.2 Protocol Overview
S. Medvinsky, P. Lalwaney -2-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
DHCP as defined in [1] defines the protocol exchanges for a client
to obtain its IP address and network configuration information from
a DHCP Server. Kerberos V5 as described in [6] defines the protocol
and message exchanges to mutually authenticate two parties. It is
our goal to provide authentication support for DHCP using Kerberos.
This implies that the Kerberos key management exchange has to take
place before a client gets its IP address from the DHCP Server.
Kerberos assumes that the client has a network address and can
contact the Key Distribution Center to obtain its credentials for
authenticated communication with an application server.
In this specification we utilize the key exchange using an IAKERB
proxy described in [7]. This does not require any changes to either
the IAKERB or the Kerberos V5 specification. This document also
specifies a particular transport that allows an uninitialized client
to contact an IAKERB proxy.
The Kerberos ticket returned from the key management exchange
discussed in Section 5 of this document is passed to the DHCP Server
inside the DHCP authentication option with the new Kerberos
authenticator type. This is described in Section 6 of this draft.
3.3 Related Work
A prior Internet Draft [3] outlined the use of Kerberos-based
authentication for DHCP. The proposal tightly coupled the Kerberos
client state machines and the DHCP client state machines. As a
result, the Kerberos key management messages were carried in DHCP
messages, along with the Kerberos authenticators. In addition, the
first DHCP message exchange (request, offer) is not authenticated.
We propose a protocol exchange where Kerberos key management is
decoupled from and precedes authenticated DHCP exchanges. This
implies that the Kerberos ticket returned in the initial key
management exchange could be used to authenticate servers assigning
addresses by non-DHCP address assignment mechanisms like RSIP [4]
and for service specific parameter provisioning mechanisms using SLP
[5].
S. Medvinsky, P. Lalwaney -3-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
4. System Architecture
Client
-------- --------
| | 5.Authenticated DHCP | |
| DHCP |<------------------------>| DHCP |
| client | | server |
| | | |
| | | |
|Kerberos| | |
| Client | | |
-------- --------
^
|
|
|
| -------
------------------------------>| |
Kerberos Key Mgmt | Proxy |
messages: | |
1. AS Request / 2.AS Reply -------
3. TGS Request / 4.TGS Reply ^
| Kerberos
| Key Mgmt messages
v (1, 2, 3, 4)
--------
| |
| KDC |
| |
--------
Figure 1: System blocks and message interactions between them
In this architecture, the DHCP client obtains a Kerberos ticket from
the Key Distribution Center (KDC) using standard Kerberos messages,
as specified in [6]. The client, however, contacts the KDC via a
proxy server, according to the IAKERB mechanism, described in [7].
The are several reasons why a client has to go through this proxy in
order to contact the KDC:
a)The client may not know the host address of the KDC and may be
sending its first request message as a broadcast on a local
network. The KDC may not be located on the local network, and
even if it were - it will be unable to communicate with a client
without an IP address. This document describes a specific
mechanism that may be used by a client to communicate with the
Kerberos proxy.
S. Medvinsky, P. Lalwaney -4-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
b)The client may not know its Kerberos realm name. The proxy is
able to fill in the missing client realm name in an AS Request
message, as specified in IAKERB. Note that in the case that
PKINIT pre-authenticator is used [8], the realm name in the AS
Request may be the KDC realm name and not the client<6E>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<6E>s realm may be different from the DHCP
server<65>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<65>s realm, as specified in [6].
In the following example a client doesn<73>t know its realm or the DHCP
server<65>s realm, which happens to be different from the client<6E>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<6E>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<65>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<6E>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<6E>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<6E>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<65>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<44>s IP address
(c) the KDC may not be on the local network and (d) the client may
not know the DHCP Server<65>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<72>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<44>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<6E>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<6E>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<47>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<6E>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<6E>s hardware address
src UDP port = 88
destination UDP port = copied from src port in AS_REQ
src IP = Proxy<78>s IP address
destination IP = 255.255.255.255
src link layer address = Proxy<78>s HW/link address
destination link layer address =
Client<6E>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<65>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<65>s realm ahead of time,
which provides for full 2-way authentication at the cost of
an additional configuration parameter.
2) The DHCP clients not requiring any additional configuration
information, besides a password or a key (and a public key
certificate if PKINIT is used). This is at the cost of not
being able to fully authenticate the identity of the DHCP
server.
9. References
[1]Droms, R., Arbaugh, W., "Dynamic Host Configuration Protocol",
RFC 2131, Bucknell University, March 1997.
[2]Droms, R., Arbaugh, W., "Authentication for DHCP Messages",
draft-ietf-dhc-authentication-13.txt, June 2000.
[3]Hornstein, K., Lemon, T., "DHCP Authentication Via Kerberos V",
draft-hornstein-dhc-kerbauth-02.txt, February 2000.
[4]Borella, M., Grabelsky, D., Lo, J., Tuniguchi, K., "Realm
Specific IP: Protocol Specification ", draft-ietf-nat-rsip-
protocol-06.txt, March 2000.
[5]Guttman, E., Perkins, C., Veizades, J., Day, M., "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[6]Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
05.txt, March 2000.
S. Medvinsky, P. Lalwaney -14-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
[7]Swift, M., Trostle, J., "Initial Authentication and Pass Through
Authentication Using Kerberos V5 and the GSS-API (IAKERB)",
draft-ietf-cat-iakerb-03.txt, September 1999.
[8]Tung, B., C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
J. Trostle, "Public Key Cryptography for Initial Authentication
in Kerberos", draft-ietf-cat-pk-init-11.txt, March 2000.
[9]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[10]Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication," RFC 2104, February 1997.
[11]NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995.
[12]Horowitz, M., "Key Derivation for Authentication, Integrity, and
Privacy", draft-horowitz-key-derivation-02.txt, August 1998.
[13]Bradner, S. "The Internet Standards Process -- Revision 3", RFC
2026.
10. Author's Addresses
Sasha Medvinsky
Motorola
6450 Sequence Drive
San Diego, CA 92121
Email: smedvinsky@gi.com
Poornima Lalwaney
Nokia
12278 Scripps Summit Drive
San Diego, CA 92131
Email: poornima.lalwaney@nokia.com
11. Expiration
This memo is filed as <draft-smedvinsky-dhc-kerbauth-01.txt>, and
expires January 1, 2001.
12. Intellectual Property Notices
S. Medvinsky, P. Lalwaney -15-
Kerberos V Authentication Mode for Uninitialized Clients March 2000
This section contains two notices as required by [13] for
standards track documents. Per [13], section 10.4(A):
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
Per [13] section 10.4(D):
The IETF has been notified of intellectual property rights
claimed in regard to some or all of the specification contained in
this document. For more information consult the online list of
claimed rights.
13. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
S. Medvinsky, P. Lalwaney -16-

5
doc/standardisation/draft-swift-win2k-krb-referrals-01.txt Normal file
View File

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

5
doc/standardisation/draft-swift-win2k-krb-user2user-01.txt Normal file
View File

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

1140
doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt Normal file
View File

File diff suppressed because it is too large Load Diff

227
doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt Normal file
View File

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

327
doc/standardisation/draft-tso-telnet-krb5-04.txt Normal file
View File

@@ -0,0 +1,327 @@
Network Working Group T. Ts'o, Editor
Internet-Draft Massachusetts Institute of Technology
draft-tso-telnet-krb5-04.txt April 2000
Telnet Authentication: Kerberos Version 5
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
0. Abstract
This document describes how Kerberos Version 5 [1] is used with the
telnet protocol. It describes an telnet authentication sub-option
to be used with the telnet authentication option [2]. This mecha-
nism can also used to provide keying material to provide data confi-
dentiality services in conjuction with the telnet encryption option
[3].
1. Command Names and Codes
Authentication Types
KERBEROS_V5 2
Sub-option Commands
Expires Sept 2000 [Page 1]
Internet-Draft Kerberos Version 5 for Telnet April 2000
AUTH 0
REJECT 1
ACCEPT 2
RESPONSE 3
FORWARD 4
FORWARD_ACCEPT 5
FORWARD_REJECT 6
2. Command Meanings
IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5
KRB_AP_REQ message> IAC SE
This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the
remote side of the connection. The first octet of the <authenti-
cation-type-pair> value is KERBEROS_V5, to indicate that Version 5
of Kerberos is being used. The Kerberos V5 authenticator in the
KRB_AP_REQ message must contain a Kerberos V5 checksum of the
two-byte authentication type pair. This checksum must be verified
by the server to assure that the authentication type pair was cor-
rectly negotiated. The Kerberos V5 authenticator must also in-
clude the optional subkey field, which shall be filled in with a
randomly chosen key. This key shall be used for encryption pur-
poses if encryption is negotiated, and shall be used as the nego-
tiated session key (i.e., used as keyid 0) for the purposes of the
telnet encryption option; if the subkey is not filled in, then the
ticket session key will be used instead.
If data confidentiality services is desired the ENCRYPT_US-
ING_TELOPT flag must be set in the authentication-type-pair as
specified in [2].
IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE
This command indicates that the authentication was successful.
If the AUTH_HOW_MUTUAL bit is set in the second octet of the au-
thentication-type-pair, the RESPONSE command must be sent before
the ACCEPT command is sent.
IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT <op-
tional reason for rejection> IAC SE
This command indicates that the authentication was not successful,
and if there is any more data in the sub-option, it is an ASCII
text message of the reason for the rejection.
IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE
<KRB_AP_REP message> IAC SE
Expires Sept 2000 [Page 2]
Internet-Draft Kerberos Version 5 for Telnet April 2000
This command is used to perform mutual authentication. It is only
used when the AUTH_HOW_MUTUAL bit is set in the second octet of
the authentication-type-pair. After an AUTH command is verified,
a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP
message to perform the mutual authentication.
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED
message> IAC SE
This command is used to forward kerberos credentials for use by
the remote session. The credentials are passed as a Kerberos V5
KRB_CRED message which includes, among other things, the forwarded
Kerberos ticket and a session key associated with the ticket. Part
of the KRB_CRED message is encrypted in the key previously ex-
changed for the telnet session by the AUTH suboption.
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC
SE
This command indicates that the credential forwarding was success-
ful.
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT <op-
tional reason for rejection> IAC SE
This command indicates that the credential forwarding was not suc-
cessful, and if there is any more data in the sub-option, it is an
ASCII text message of the reason for the rejection.
3. Implementation Rules
If the second octet of the authentication-type-pair has the AUTH_WHO
bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial
AUTH command, and the server responds with either ACCEPT or REJECT.
In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the serv-
er will send a RESPONSE before it sends the ACCEPT.
If the second octet of the authentication-type-pair has the AUTH_WHO
bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial
AUTH command, and the client responds with either ACCEPT or REJECT.
In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the
client will send a RESPONSE before it sends the ACCEPT.
The Kerberos principal used by the server will generally be of the
form "host/<hostname>@realm". That is, the first component of the
Kerberos principal is "host"; the second component is the fully qual-
ified lower-case hostname of the server; and the realm is the Ker-
beros realm to which the server belongs.
Expires Sept 2000 [Page 3]
Internet-Draft Kerberos Version 5 for Telnet April 2000
Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP
messages, the KRB_CRED structure, or the optional rejection text
string must be doubled as specified in [4]. Otherwise the following
byte might be mis-interpreted as a Telnet command.
4. Examples
User "joe" may wish to log in as user "pete" on machine "foo". If
"pete" has set things up on "foo" to allow "joe" access to his ac-
count, then the client would send IAC SB AUTHENTICATION NAME "pete"
IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE>
IAC SE
The server would then authenticate the user as "joe" from the
KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by
Kerberos, and if "pete" has allowed "joe" to use his account, the
server would then continue the authentication sequence by sending a
RESPONSE (to do mutual authentication, if it was requested) followed
by the ACCEPT.
If forwarding has been requested, the client then sends IAC SB AU-
THENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED structure
with credentials to be forwarded> IAC SE. If the server succeeds in
reading the forwarded credentials, the server sends FORWARD_ACCEPT
else, a FORWARD_REJECT is sent back.
Client Server
IAC DO AUTHENTICATION
IAC WILL AUTHENTICATION
[ The server is now free to request authentication information.
]
IAC SB AUTHENTICATION SEND
KERBEROS_V5 CLIENT|MUTUAL
KERBEROS_V5 CLIENT|ONE_WAY IAC
SE
[ The server has requested mutual Version 5 Kerberos
authentication. If mutual authentication is not supported,
then the server is willing to do one-way authentication.
The client will now respond with the name of the user that it
wants to log in as, and the Kerberos ticket. ]
IAC SB AUTHENTICATION NAME
"pete" IAC SE
IAC SB AUTHENTICATION IS
KERBEROS_V5 CLIENT|MUTUAL AUTH
<KRB_AP_REQ message> IAC SE
Expires Sept 2000 [Page 4]
Internet-Draft Kerberos Version 5 for Telnet April 2000
[ Since mutual authentication is desired, the server sends across
a RESPONSE to prove that it really is the right server. ]
IAC SB AUTHENTICATION REPLY
KERBEROS_V5 CLIENT|MUTUAL
RESPONSE <KRB_AP_REP message>
IAC SE
[ The server responds with an ACCEPT command to state that the
authentication was successful. ]
IAC SB AUTHENTICATION REPLY KER-
BEROS_V5 CLIENT|MUTUAL ACCEPT
IAC SE
[ If so requested, the client now sends the FORWARD command to
forward credentials to the remote site. ]
IAC SB AUTHENTICATION IS KER-
BEROS_V5 CLIENT|MUTUAL
FORWARD <KRB_CRED message> IAC
SE
[ The server responds with a FORWARD_ACCEPT command to state that
the credential forwarding was successful. ]
Expires Sept 2000 [Page 5]
Internet-Draft Kerberos Version 5 for Telnet April 2000
IAC SB AUTHENTICATION REPLY KER-
BEROS_V5 CLIENT|MUTUAL FOR-
WARD_ACCEPT IAC SE
5. Security Considerations
The selection of the random session key in the Kerberos V5 authenti-
cator is critical, since this key will be used for encrypting the
telnet data stream if encryption is enabled. It is strongly advised
that the random key selection be done using cryptographic techniques
that involve the Kerberos ticket's session key. For example, using
the current time, encrypting it with the ticket session key, and then
correcting for key parity is a strong way to generate a subsession
key, since the ticket session key is assumed to be never disclosed to
an attacker.
Care should be taken before forwarding a user's Kerberos credentials
to the remote server. If the remote server is not trustworthy, this
could result in the user's credentials being compromised. Hence, the
user interface should not forward credentials by default; it would be
far safer to either require the user to explicitly request creden-
tials forwarding for each connection, or to have a trusted list of
hosts for which credentials forwarding is enabled, but to not enable
credentials forwarding by default for all machines.
6. IANA Considerations
The authentication type KERBEROS_V5 and its associated suboption values
are registered with IANA. Any suboption values used to extend
the protocol as described in this document must be registered
with IANA before use. IANA is instructed not to issue new suboption
values without submission of documentation of their use.
7. Acknowledgments
This document was originally written by Dave Borman of Cray Research,
Inc. Theodore Ts'o of MIT revised it to reflect the latest implemen-
tation experience. Cliff Neuman and Prasad Upasani of USC's Informa-
tion Sciences Institute developed the credential forwarding support.
In addition, the contributions of the Telnet Working Group are also
gratefully acknowledged.
8. References
[1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Sys-
tem (V5)", RFC 1510, USC/Information Sciences Institute, Septem-
ber 1993.
[2] Internet Engineering Task Force, "Telnet Authentication", draft-
tso-telnet-auth-enc-04.txt, T. Ts'o, Editor, VA Linux Systems,
April 2000.
[3] Internet Engineering Task Force, "Telnet Data Encryption Option",
draft-tso-telnet-encryption-04.txt, T. Ts'o, Editor, VA Linux
Systems, April 2000.
[4] Postel, J.B. and J. Reynolds, "Telnet Option Specifications", RFC
Expires Sept 2000 [Page 6]
Internet-Draft Kerberos Version 5 for Telnet April 2000
855, STD 8, USC/Information Sciences Institute, May 1983.
Editor's Address
Theodore Ts'o
Massachusetts Institute of Technology
MIT Room E40-343
77 Massachusetts Avenue
Cambridge, MA 02139
Phone: (617) 253-8091
EMail: tytso@mit.edu
Expires Sept 2000 [Page 7]
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org