d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

These RFCs and internet-drafts are not really needed in the base

Browse Source 
system, and I've not been importing them lately.  cvs rm them now
so they can be cleaned out of the attic later.

Requested by:	obrien
This commit is contained in:
Jacques Vidrine 2002-09-18 14:17:14 +00:00
parent 3f2e06c5e1
commit 0bd4a81b2e
60 changed files with 0 additions and 103705 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

412
crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-01.txt
View File

@ -1,412 +0,0 @@
CAT working group M. Swift
Internet Draft J. Brezak
Document: draft-brezak-win2k-krb-rc4-hmac-01.txt Microsoft
Category: Informational October 1999
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 October 1999
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).
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.
The basic RC4 encryption operation is used in this encryption type
and defined 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.
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.
Swift Category - Informational 2
Windows 2000 RC4-HMAC Kerberos E-Type October 1999
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, "signature key") //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.
ENCRYPT(K, T, data)
if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP)
L = concat("fortybits", T) //includes zero octet at
//end of string constant
Else
L = T
Ksign = HMAC(K,L)
Confounder = nonce(8) // get an 8 octet nonce for a confounder
Checksum = HMAC(Ksign, concat(Confounder, data))
Ke = Ksign
if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP)
memset(&Ke[7], 0x0ab, 9)
Ke2 = HMAC(Ke, Checksum)
data = RC4(Ke2, data)
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;
Swift Category - Informational 3
Windows 2000 RC4-HMAC Kerberos E-Type October 1999
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.
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).
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.
Swift Category - Informational 4
Windows 2000 RC4-HMAC Kerberos E-Type October 1999
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 based messages is as follow:
T = the message type, encoded as a little-endian four byte integer.
GSS-ENCRYPT(K, T, data)
IV = SND_SEQ
K = XOR(K, 0xf0f0f0f0f0f0f0f0f0f0f0f0f0f0f0)
if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP)
L = concat("fortybits", T) //includes zero octet at end
else
L = T
Ksign = HMAC(K, L)
Ke = Ksign
if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP)
memset(&Ke[7], 0x0ab, 9)
Ke2 = HMAC(Ke, IV)
Data = RC4(Ke2, data)
SND_SEQ = RC4(Ke, seq#)
The sequence number (SND_SEQ) and IV are used as defined in [5]
Section 1.2.2.
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.
8. Security Considerations
Care must be taken in implementing this encryption type because it
uses a stream cipher. If a different IV isnÆt used in each direction
when using a session key, the encryption is weak. By using the
sequence number as an IV, this is avoided.
9. 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 5
Windows 2000 RC4-HMAC Kerberos E-Type October 1999
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 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
9 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
04.txt, June 25, 1999
10. Author's Addresses
Mike Swift
Microsoft
One Microsoft Way
Redmond, Washington
Email: mikesw@microsoft.com
John Brezak
Microsoft
One Microsoft Way
Redmond, Washington
Email: jbrezak@microsoft.com
Swift Category - Informational 6
Windows 2000 RC4-HMAC Kerberos E-Type October 1999
11. 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."
Swift Category - Informational 7

589
crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt
View File

@ -1,589 +0,0 @@
CAT working group M. Swift
Internet Draft J. Brezak
Document: draft-brezak-win2k-krb-rc4-hmac-02.txt Microsoft
Category: Informational November 2000
The Windows 2000 RC4-HMAC Kerberos encryption type
tatus 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.
. 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.
. Conventions used in this document
wift 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].
. 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
. 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
wift 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.
. 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)
. 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.
wift 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.
wift 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.
. 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.
. GSSAPI Kerberos V5 Mechanism Type
.1 Mechanism Specific Changes
The GSSAPI per-message tokens also require new checksum and
encryption types. The GSS-API per-message tokens must be changed to
support these new encryption types (See [5] Section 1.2.2). The
sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption
is:
Byte 4..5 SEAL_ALG 0x10 0x00 - RC4
The signing algorithm identifier (SGN_ALG) for MD5 HMAC is:
Byte 2..3 SGN ALG 0x11 0x00 - HMAC
The only support quality of protection is:
#define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0
In addition, when using an RC4 based encryption type, the sequence
number is sent in big-endian rather than little-endian order.
The Windows 2000 implementation also defines new GSSAPI flags in the
initial token passed when initializing a security context. These
flags are passed in the checksum field of the authenticator (See [5]
Section 1.1.1).
GSS_C_DCE_STYLE - This flag was added for use with MicrosoftÆs
implementation of DCE RPC, which initially expected three legs of
authentication. Setting this flag causes an extra AP reply to be
sent from the client back to the server after receiving the serverÆs
AP reply. In addition, the context negotiation tokens do not have
GSSAPI framing - they are raw AP message and do not include object
identifiers.
#define GSS_C_DCE_STYLE 0x1000
wift 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.
.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);
wift 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);
}
.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
wift 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.
. Security Considerations
Care must be taken in implementing this encryption type because it
uses a stream cipher. If a different IV isnÆt used in each direction
when using a session key, the encryption is weak. By using the
sequence number as an IV, this is avoided.
0. Acknowledgements
We would like to thank Salil Dangi for the valuable input in
refining the descriptions of the functions and review input.
1. 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
wift 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
2. 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
wift Category - Informational 9
Windows 2000 RC4-HMAC Kerberos E-Type October 1999
3. 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.
wift Category - Informational 10

587
crypto/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt
View File

@ -1,587 +0,0 @@
CAT working group M. Swift
Internet Draft J. Brezak
Document: draft-brezak-win2k-krb-rc4-hmac-03.txt Microsoft
Category: Informational June 2000
The Windows 2000 RC4-HMAC Kerberos encryption type
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. Internet-Drafts are
draft documents valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It
is inappropriate to use Internet- Drafts as reference material or to
cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
The Windows 2000 implementation of Kerberos introduces a new
encryption type based on the RC4 encryption algorithm and using an
MD5 HMAC for checksum. This is offered as an alternative to using
the existing DES based encryption types.
The RC4-HMAC encryption types are used to ease upgrade of existing
Windows NT environments, provide strong crypto (128-bit key
lengths), and provide exportable (meet United States government
export restriction requirements) encryption.
The Windows 2000 implementation of Kerberos contains new encryption
and checksum types for two reasons: for export reasons early in the
development process, 56 bit DES encryption could not be exported,
and because upon upgrade from Windows NT 4.0 to Windows 2000,
accounts will not have the appropriate DES keying material to do the
standard DES encryption. Furthermore, 3DES is not available for
export, and there was a desire to use a single flavor of encryption
in the product for both US and international products.
As a result, there are two new encryption types and one new checksum
type introduced in Windows 2000.
2. Conventions used in this document
Swift Category - Informational 1
Windows 2000 RC4-HMAC Kerberos E-Type June 2000
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
3. Key Generation
On upgrade from existing Windows NT domains, the user accounts would
not have a DES based key available to enable the use of DES base
encryption types specified in RFC 1510. The key used for RC4-HMAC is
the same as the existing Windows NT key (NT Password Hash) for
compatibility reasons. Once the account password is changed, the DES
based keys are created and maintained. Once the DES keys are
available DES based encryption types can be used with Kerberos.
The RC4-HMAC String to key function is defined as follow:
String2Key(password)
K = MD4(UNICODE(password))
The RC4-HMAC keys are generated by using the Windows UNICODE version
of the password. Each Windows UNICODE character is encoded in
little-endian format of 2 octets each. Then performing an MD4 [6]
hash operation on just the UNICODE characters of the password (not
including the terminating zero octets).
For an account with a password of "foo", this String2Key("foo") will
return:
0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe,
0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc
4. Basic Operations
The MD5 HMAC function is defined in [3]. It is used in this
encryption type for checksum operations. Refer to [3] for details on
its operation. In this document this function is referred to as
HMAC(Key, Data) returning the checksum using the specified key on
the data.
The basic MD5 hash operation is used in this encryption type and
defined in [7]. In this document this function is referred to as
MD5(Data) returning the checksum of the data.
RC4 is a stream cipher licensed by RSA Data Security [RSADSI]. A
compatible cipher is described in [8]. In this document the function
is referred to as RC4(Key, Data) returning the encrypted data using
the specified key on the data.
These encryption types use key derivation as defined in [9] (RFC-
1510BIS) in Section titled "Key Derivation". With each message, the
message type (T) is used as a component of the keying material. This
summarizes the different key derivation values used in the various
Swift Category - Informational 2
Windows 2000 RC4-HMAC Kerberos E-Type June 2000
operations. Note that these differ from the key derivations used in
other Kerberos encryption types.
T = 1 for TS-ENC-TS in the AS-Request
T = 8 for the AS-Reply
T = 7 for the Authenticator in the TGS-Request
T = 8 for the TGS-Reply
T = 2 for the Server Ticket in the AP-Request
T = 11 for the Authenticator in the AP-Request
T = 12 for the Server returned AP-Reply
T = 15 in the generation of checksum for the MIC token
T = 0 in the generation of sequence number for the MIC token
T = 13 in the generation of checksum for the WRAP token
T = 0 in the generation of sequence number for the WRAP token
T = 0 in the generation of encrypted data for the WRAPPED token
All strings in this document are ASCII unless otherwise specified.
The lengths of ASCII encoded character strings include the trailing
terminator character (0).
The concat(a,b,c,...) function will return the logical concatenation
(left to right) of the values of the arguments.
The nonce(n) function returns a pseudo-random number of "n" octets.
5. Checksum Types
There is one checksum type used in this encryption type. The
Kerberos constant for this type is:
#define KERB_CHECKSUM_HMAC_MD5 (-138)
The function is defined as follows:
K - is the Key
T - the message type, encoded as a little-endian four byte integer
CHKSUM(K, T, data)
Ksign = HMAC(K, "signaturekey") //includes zero octet at end
tmp = MD5(concat(T, data))
CHKSUM = HMAC(Ksign, tmp)
6. Encryption Types
There are two encryption types used in these encryption types. The
Kerberos constants for these types are:
#define KERB_ETYPE_RC4_HMAC 23
#define KERB_ETYPE_RC4_HMAC_EXP 24
The basic encryption function is defined as follow:
T = the message type, encoded as a little-endian four byte integer.
Swift Category - Informational 3
Windows 2000 RC4-HMAC Kerberos E-Type June 2000
BYTE L40[14] = "fortybits";
BYTE SK = "signaturekey";
ENCRYPT (K, fRC4_EXP, T, data, data_len, edata, edata_len)
{
if (fRC4_EXP){
*((DWORD *)(L40+10)) = T;
HMAC (K, L40, 10 + 4, K1);
}else{
HMAC (K, &T, 4, K1);
}
memcpy (K2, K1, 16);
if (fRC4_EXP) memset (K1+7, 0xAB, 9);
add_8_random_bytes(data, data_len, conf_plus_data);
HMAC (K2, conf_plus_data, 8 + data_len, checksum);
HMAC (K1, checksum, 16, K3);
RC4(K3, conf_plus_data, 8 + data_len, edata + 16);
memcpy (edata, checksum, 16);
edata_len = 16 + 8 + data_len;
}
DECRYPT (K, fRC4_EXP, T, edata, edata_len, data, data_len)
{
if (fRC4_EXP){
*((DWORD *)(L40+10)) = T;
HMAC (K, L40, 14, K1);
}else{
HMAC (K, &T, 4, K1);
}
memcpy (K2, K1, 16);
if (fRC4_EXP) memset (K1+7, 0xAB, 9);
HMAC (K1, edata, 16, K3); // checksum is at edata
RC4(K3, edata + 16, edata_len - 16, edata + 16);
data_len = edata_len - 16 - 8;
memcpy (data, edata + 16 + 8, data_len);
// verify generated and received checksums
HMAC (K2, edata + 16, edata_len - 16, checksum);
if (memcmp(edata, checksum, 16) != 0)
printf("CHECKSUM ERROR !!!!!!\n");
}
The header field on the encrypted data in KDC messages is:
typedef struct _RC4_MDx_HEADER {
UCHAR Checksum[16];
UCHAR Confounder[8];
} RC4_MDx_HEADER, *PRC4_MDx_HEADER;
The KDC message is encrypted using the ENCRYPT function not
including the Checksum in the RC4_MDx_HEADER.
Swift Category - Informational 4
Windows 2000 RC4-HMAC Kerberos E-Type June 2000
The character constant "fortybits" evolved from the time when a 40-
bit key length was all that was exportable from the United States.
It is now used to recognize that the key length is of "exportable"
length. In this description, the key size is actually 56-bits.
7. Key Strength Negotiation
A Kerberos client and server can negotiate over key length if they
are using mutual authentication. If the client is unable to perform
full strength encryption, it may propose a key in the "subkey" field
of the authenticator, using a weaker encryption type. The server
must then either return the same key or suggest its own key in the
subkey field of the AP reply message. The key used to encrypt data
is derived from the key returned by the server. If the client is
able to perform strong encryption but the server is not, it may
propose a subkey in the AP reply without first being sent a subkey
in the authenticator.
8. GSSAPI Kerberos V5 Mechanism Type
8.1 Mechanism Specific Changes
The GSSAPI per-message tokens also require new checksum and
encryption types. The GSS-API per-message tokens must be changed to
support these new encryption types (See [5] Section 1.2.2). The
sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption
is:
Byte 4..5 SEAL_ALG 0x10 0x00 - RC4
The signing algorithm identifier (SGN_ALG) for MD5 HMAC is:
Byte 2..3 SGN ALG 0x11 0x00 - HMAC
The only support quality of protection is:
#define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0
In addition, when using an RC4 based encryption type, the sequence
number is sent in big-endian rather than little-endian order.
The Windows 2000 implementation also defines new GSSAPI flags in the
initial token passed when initializing a security context. These
flags are passed in the checksum field of the authenticator (See [5]
Section 1.1.1).
GSS_C_DCE_STYLE - This flag was added for use with Microsoft’s
implementation of DCE RPC, which initially expected three legs of
authentication. Setting this flag causes an extra AP reply to be
sent from the client back to the server after receiving the server’s
AP reply. In addition, the context negotiation tokens do not have
GSSAPI framing - they are raw AP message and do not include object
identifiers.
#define GSS_C_DCE_STYLE 0x1000
Swift Category - Informational 5
Windows 2000 RC4-HMAC Kerberos E-Type June 2000
GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the
server that it should only allow the server application to identify
the client by name and ID, but not to impersonate the client.
#define GSS_C_IDENTIFY_FLAG 0x2000
GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the
client wants to be informed of extended error information. In
particular, Windows 2000 status codes may be returned in the data
field of a Kerberos error message. This allows the client to
understand a server failure more precisely. In addition, the server
may return errors to the client that are normally handled at the
application layer in the server, in order to let the client try to
recover. After receiving an error message, the client may attempt to
resubmit an AP request.
#define GSS_C_EXTENDED_ERROR_FLAG 0x4000
These flags are only used if a client is aware of these conventions
when using the SSPI on the Windows platform, they are not generally
used by default.
When NetBIOS addresses are used in the GSSAPI, they are identified
by the GSS_C_AF_NETBIOS value. This value is defined as:
#define GSS_C_AF_NETBIOS 0x14
NetBios addresses are 16-octet addresses typically composed of 1 to th 15 characters, trailing blank (ascii char 20) filled, with a 16
octet of 0x0.
8.2 GSSAPI Checksum Type
The GSSAPI checksum type and algorithm is defined in Section 5. Only
the first 8 octets of the checksum are used. The resulting checksum
is stored in the SGN_CKSUM field (See [5] Section 1.2) for
GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE).
MIC (K, fRC4_EXP, seq_num, MIC_hdr, msg, msg_len,
MIC_seq, MIC_checksum)
{
HMAC (K, SK, 13, K4);
T = 15;
memcpy (T_plus_hdr_plus_msg + 00, &T, 4);
memcpy (T_plus_hdr_plus_msg + 04, MIC_hdr, 8);
// 0101 1100 FFFFFFFF
memcpy (T_plus_hdr_plus_msg + 12, msg, msg_len);
MD5 (T_hdr_msg, 4 + 8 + msg_len, MD5_of_T_hdr_msg);
HMAC (K4, MD5_of_T_hdr_msg, CHKSUM);
memcpy (MIC_checksum, CHKSUM, 8); // use only first 8 bytes
T = 0;
if (fRC4_EXP){
*((DWORD *)(L40+10)) = T;
HMAC (K, L40, 14, K5);
}else{
HMAC (K, &T, 4, K5);
Swift Category - Informational 6
Windows 2000 RC4-HMAC Kerberos E-Type June 2000
}
if (fRC4_EXP) memset(K5+7, 0xAB, 9);
HMAC(K5, MIT_checksum, 8, K6);
copy_seq_num_in_big_endian(seq_num, seq_plus_direction);
//0x12345678
copy_direction_flag (direction_flag, seq_plus_direction +
4); //0x12345678FFFFFFFF
RC4(K6, seq_plus_direction, 8, MIC_seq);
}
8.3 GSSAPI Encryption Types
There are two encryption types for GSSAPI message tokens, one that
is 128 bits in strength, and one that is 56 bits in strength as
defined in Section 6.
All padding is rounded up to 1 byte. One byte is needed to say that
there is 1 byte of padding. The DES based mechanism type uses 8 byte
padding. See [5] Section 1.2.2.3.
The encryption mechanism used for GSS wrap based messages is as
follow:
WRAP (K, fRC4_EXP, seq_num, WRAP_hdr, msg, msg_len,
WRAP_seq, WRAP_checksum, edata, edata_len)
{
HMAC (K, SK, 13, K7);
T = 13;
PAD = 1;
memcpy (T_hdr_conf_msg_pad + 00, &T, 4);
memcpy (T_hdr_conf_msg_pad + 04, WRAP_hdr, 8); // 0101 1100
FFFFFFFF
memcpy (T_hdr_conf_msg_pad + 12, msg, msg_len);
memcpy (T_hdr_conf_msg_pad + 12 + msg_len, &PAD, 1);
MD5 (T_hdr_conf_msg_pad,
4 + 8 + 8 + msg_len + 1,
MD5_of_T_hdr_conf_msg_pad);
HMAC (K7, MD5_of_T_hdr_conf_msg_pad, CHKSUM);
memcpy (WRAP_checksum, CHKSUM, 8); // use only first 8
bytes
T = 0;
if (fRC4_EXP){
*((DWORD *)(L40+10)) = T;
HMAC (K, L40, 14, K8);
}else{
HMAC (K, &T, 4, K8);
}
if (fRC4_EXP) memset(K8+7, 0xAB, 9);
HMAC(K8, WRAP_checksum, 8, K9);
copy_seq_num_in_big_endian(seq_num, seq_plus_direction);
//0x12345678
Swift Category - Informational 7
Windows 2000 RC4-HMAC Kerberos E-Type June 2000
copy_direction_flag (direction_flag, seq_plus_direction +
4); //0x12345678FFFFFFFF
RC4(K9, seq_plus_direction, 8, WRAP_seq);
for (i = 0; i < 16; i++) K10 [i] ^= 0xF0; // XOR each byte
of key with 0xF0
T = 0;
if (fRC4_EXP){
*(DWORD *)(L40+10) = T;
HMAC(K10, L40, 14, K11);
memset(K11+7, 0xAB, 9);
}else{
HMAC(K10, &T, 4, K11);
}
HMAC(K11, seq_num, 4, K12);
RC4(K12, T_hdr_conf_msg_pad + 4 + 8, 8 + msg_len + 1,
edata); /* skip T & hdr */
edata_len = 8 + msg_len + 1; // conf + msg_len + pad
}
The character constant "fortybits" evolved from the time when a 40-
bit key length was all that was exportable from the United States.
It is now used to recognize that the key length is of "exportable"
length. In this description, the key size is actually 56-bits.
9. Security Considerations
Care must be taken in implementing this encryption type because it
uses a stream cipher. If a different IV isn’t used in each direction
when using a session key, the encryption is weak. By using the
sequence number as an IV, this is avoided.
10. Acknowledgements
We would like to thank Salil Dangi for the valuable input in
refining the descriptions of the functions and review input.
11. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for
Message Authentication", RFC 2104, February 1997
4 Kohl, J., Neuman, C., "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993
Swift Category - Informational 8
Windows 2000 RC4-HMAC Kerberos E-Type June 2000
5 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964,
June 1996
6 R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April
1992
7 R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April
1992
8 Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption
Algorithm", Work in Progress.
9 RC4 is a proprietary encryption algorithm available under license
from RSA Data Security Inc. For licensing information, contact:
RSA Data Security, Inc.
100 Marine Parkway
Redwood City, CA 94065-1031
10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
04.txt, June 25, 1999
12. Author's Addresses
Mike Swift
Dept. of Computer Science
Sieg Hall
University of Washington
Seattle, WA 98105
Email: mikesw@cs.washington.edu
John Brezak
Microsoft
One Microsoft Way
Redmond, Washington
Email: jbrezak@microsoft.com
Swift Category - Informational 9
Windows 2000 RC4-HMAC Kerberos E-Type October 1999
13. Full Copyright Statement
"Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
Swift Category - Informational 10

171
crypto/heimdal/doc/standardisation/draft-foo
View File

@ -1,171 +0,0 @@
Network Working Group Assar Westerlund
<draft-ietf-cat-krb5-ipv6.txt> SICS
Internet-Draft October, 1997
Expire in six months
Kerberos over IPv6
Status of this Memo
This document is an Internet-Draft. 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."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited. Please send comments to the
<cat-ietf@mit.edu> mailing list.
Abstract
This document specifies the address types and transport types
necessary for using Kerberos [RFC1510] over IPv6 [RFC1883].
Specification
IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB
order. The type of IPv6 addresses is twenty-four (24).
The following addresses (see [RFC1884]) MUST not appear in any
Kerberos packet:
the Unspecified Address
the Loopback Address
Link-Local addresses
IPv4-mapped IPv6 addresses MUST be represented as addresses of type
2.
Westerlund [Page 1]
Internet Draft Kerberos over IPv6 October, 1997
Communication with the KDC over IPv6 MUST be done as in section 8.2.1
of [RFC1510].
Discussion
[RFC1510] suggests using the address family constants in
<sys/socket.h> from BSD. This cannot be done for IPv6 as these
numbers have diverged and are different on different BSD-derived
systems. [RFC2133] does not either specify a value for AF_INET6.
Thus a value has to be decided and the implementations have to
convert between the value used in Kerberos HostAddress and the local
AF_INET6.
There are a few different address types in IPv6, see [RFC1884]. Some
of these are used for quite special purposes and it makes no sense to
include them in Kerberos packets.
It is necessary to represent IPv4-mapped addresses as Internet
addresses (type 2) to be compatible with Kerberos implementations
that only support IPv4.
Security considerations
This memo does not introduce any known security considerations in
addition to those mentioned in [RFC1510].
References
[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[RFC1883] Deering, S., Hinden, R., "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995.
[RFC1884] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture", RFC 1884, December 1995.
[RFC2133] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic
Socket Interface Extensions for IPv6", RFC2133, April 1997.
Author's Address
Assar Westerlund
Swedish Institute of Computer Science
Box 1263
S-164 29 KISTA
Sweden
Westerlund [Page 2]
Internet Draft Kerberos over IPv6 October, 1997
Phone: +46-8-7521526
Fax: +46-8-7517230
EMail: assar@sics.se
Westerlund [Page 3]

136
crypto/heimdal/doc/standardisation/draft-foo.ms
View File

@ -1,136 +0,0 @@
.pl 10.0i
.po 0
.ll 7.2i
.lt 7.2i
.nr LL 7.2i
.nr LT 7.2i
.ds LF Westerlund
.ds RF [Page %]
.ds CF
.ds LH Internet Draft
.ds RH October, 1997
.ds CH Kerberos over IPv6
.hy 0
.ad l
.in 0
.ta \n(.luR
Network Working Group Assar Westerlund
<draft-ietf-cat-krb5-ipv6.txt> SICS
Internet-Draft October, 1997
Expire in six months
.ce
Kerberos over IPv6
.ti 0
Status of this Memo
.in 3
This document is an Internet-Draft. 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."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited. Please send comments to the
<cat-ietf@mit.edu> mailing list.
.ti 0
Abstract
.in 3
This document specifies the address types and transport types
necessary for using Kerberos [RFC1510] over IPv6 [RFC1883].
.ti 0
Specification
.in 3
IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB
order. The type of IPv6 addresses is twenty-four (24).
The following addresses (see [RFC1884]) MUST not appear in any
Kerberos packet:
the Unspecified Address
.br
the Loopback Address
.br
Link-Local addresses
IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
Communication with the KDC over IPv6 MUST be done as in section
8.2.1 of [RFC1510].
.ti 0
Discussion
.in 3
[RFC1510] suggests using the address family constants in
<sys/socket.h> from BSD. This cannot be done for IPv6 as these
numbers have diverged and are different on different BSD-derived
systems. [RFC2133] does not either specify a value for AF_INET6.
Thus a value has to be decided and the implementations have to convert
between the value used in Kerberos HostAddress and the local AF_INET6.
There are a few different address types in IPv6, see [RFC1884]. Some
of these are used for quite special purposes and it makes no sense to
include them in Kerberos packets.
It is necessary to represent IPv4-mapped addresses as Internet
addresses (type 2) to be compatible with Kerberos implementations that
only support IPv4.
.ti 0
Security considerations
.in 3
This memo does not introduce any known security considerations in
addition to those mentioned in [RFC1510].
.ti 0
References
.in 3
[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[RFC1883] Deering, S., Hinden, R., "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995.
[RFC1884] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture", RFC 1884, December 1995.
[RFC2133] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic
Socket Interface Extensions for IPv6", RFC2133, April 1997.
.ti 0
Author's Address
Assar Westerlund
.br
Swedish Institute of Computer Science
.br
Box 1263
.br
S-164 29 KISTA
.br
Sweden
Phone: +46-8-7521526
.br
Fax: +46-8-7517230
.br
EMail: assar@sics.se

171
crypto/heimdal/doc/standardisation/draft-foo2
View File

@ -1,171 +0,0 @@
Network Working Group Assar Westerlund
<draft-ietf-cat-krb5-tcp.txt> SICS
Internet-Draft Johan Danielsson
November, 1997 PDC, KTH
Expire in six months
Kerberos over TCP
Status of this Memo
This document is an Internet-Draft. 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."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited. Please send comments to the
<cat-ietf@mit.edu> mailing list.
Abstract
This document specifies how the communication should be done between
a client and a KDC using Kerberos [RFC1510] with TCP as the transport
protocol.
Specification
This draft specifies an extension to section 8.2.1 of RFC1510.
A Kerberos server MAY accept requests on TCP port 88 (decimal).
The data sent from the client to the KDC should consist of 4 bytes
containing the length, in network byte order, of the Kerberos
request, followed by the request (AS-REQ or TGS-REQ) itself. The
reply from the KDC should consist of the length of the reply packet
(4 bytes, network byte order) followed by the packet itself (AS-REP,
TGS-REP, or KRB-ERROR).
Westerlund, Danielsson [Page 1]
Internet Draft Kerberos over TCP November, 1997
C->S: Open connection to TCP port 88 at the server
C->S: length of request
C->S: AS-REQ or TGS-REQ
S->C: length of reply
S->C: AS-REP, TGS-REP, or KRB-ERROR
Discussion
Even though the preferred way of sending kerberos packets is over UDP
there are several occasions when it's more practical to use TCP.
Mainly, it's usually much less cumbersome to get TCP through
firewalls than UDP.
In theory, there's no reason for having explicit length fields, that
information is already encoded in the ASN1 encoding of the Kerberos
packets. But having explicit lengths makes it unnecessary to have to
decode the ASN.1 encoding just to know how much data has to be read.
Another way of signaling the end of the request of the reply would be
to do a half-close after the request and a full-close after the
reply. This does not work well with all kinds of firewalls.
Security considerations
This memo does not introduce any known security considerations in
addition to those mentioned in [RFC1510].
References
[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
Authors' Addresses
Assar Westerlund
Swedish Institute of Computer Science
Box 1263
S-164 29 KISTA
Sweden
Phone: +46-8-7521526
Fax: +46-8-7517230
EMail: assar@sics.se
Johan Danielsson
PDC, KTH
S-100 44 STOCKHOLM
Westerlund, Danielsson [Page 2]
Internet Draft Kerberos over TCP November, 1997
Sweden
Phone: +46-8-7907885
Fax: +46-8-247784
EMail: joda@pdc.kth.se
Westerlund, Danielsson [Page 3]

145
crypto/heimdal/doc/standardisation/draft-foo2.ms
View File

@ -1,145 +0,0 @@
.pl 10.0i
.po 0
.ll 7.2i
.lt 7.2i
.nr LL 7.2i
.nr LT 7.2i
.ds LF Westerlund, Danielsson
.ds RF [Page %]
.ds CF
.ds LH Internet Draft
.ds RH November, 1997
.ds CH Kerberos over TCP
.hy 0
.ad l
.in 0
.ta \n(.luR
.nf
Network Working Group Assar Westerlund
<draft-ietf-cat-krb5-tcp.txt> SICS
Internet-Draft Johan Danielsson
November, 1997 PDC, KTH
Expire in six months
.fi
.ce
Kerberos over TCP
.ti 0
Status of this Memo
.in 3
This document is an Internet-Draft. 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."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited. Please send comments to the
<cat-ietf@mit.edu> mailing list.
.ti 0
Abstract
.in 3
This document specifies how the communication should be done between a
client and a KDC using Kerberos [RFC1510] with TCP as the transport
protocol.
.ti 0
Specification
This draft specifies an extension to section 8.2.1 of RFC1510.
A Kerberos server MAY accept requests on TCP port 88 (decimal).
The data sent from the client to the KDC should consist of 4 bytes
containing the length, in network byte order, of the Kerberos request,
followed by the request (AS-REQ or TGS-REQ) itself. The reply from
the KDC should consist of the length of the reply packet (4 bytes,
network byte order) followed by the packet itself (AS-REP, TGS-REP, or
KRB-ERROR).
.nf
C->S: Open connection to TCP port 88 at the server
C->S: length of request
C->S: AS-REQ or TGS-REQ
S->C: length of reply
S->C: AS-REP, TGS-REP, or KRB-ERROR
.fi
.ti 0
Discussion
Even though the preferred way of sending kerberos packets is over UDP
there are several occasions when it's more practical to use TCP.
Mainly, it's usually much less cumbersome to get TCP through firewalls
than UDP.
In theory, there's no reason for having explicit length fields, that
information is already encoded in the ASN1 encoding of the Kerberos
packets. But having explicit lengths makes it unnecessary to have to
decode the ASN.1 encoding just to know how much data has to be read.
Another way of signaling the end of the request of the reply would be
to do a half-close after the request and a full-close after the reply.
This does not work well with all kinds of firewalls.
.ti 0
Security considerations
.in 3
This memo does not introduce any known security considerations in
addition to those mentioned in [RFC1510].
.ti 0
References
.in 3
[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
.ti 0
Authors' Addresses
Assar Westerlund
.br
Swedish Institute of Computer Science
.br
Box 1263
.br
S-164 29 KISTA
.br
Sweden
Phone: +46-8-7521526
.br
Fax: +46-8-7517230
.br
EMail: assar@sics.se
Johan Danielsson
.br
PDC, KTH
.br
S-100 44 STOCKHOLM
.br
Sweden
Phone: +46-8-7907885
.br
Fax: +46-8-247784
.br
EMail: joda@pdc.kth.se

227
crypto/heimdal/doc/standardisation/draft-foo3
View File

@ -1,227 +0,0 @@
Network Working Group Assar Westerlund
<draft-ietf-cat-krb5-firewalls.txt> SICS
Internet-Draft Johan Danielsson
November, 1997 PDC, KTH
Expire in six months
Kerberos vs firewalls
Status of this Memo
This document is an Internet-Draft. 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."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited. Please send comments to the
<cat-ietf@mit.edu> mailing list.
Abstract
Introduction
Kerberos[RFC1510] is a protocol for authenticating parties
communicating over insecure networks.
Firewalling is a technique for achieving an illusion of security by
putting restrictions on what kinds of packets and how these are sent
between the internal (so called "secure") network and the global (or
"insecure") Internet.
Definitions
client: the user, process, and host acquiring tickets from the KDC
and authenticating itself to the kerberised server.
KDC: the Kerberos Key Distribution Center
Westerlund, Danielsson [Page 1]
Internet Draft Kerberos vs firewalls November, 1997
Kerberised server: the server using Kerberos to authenticate the
client, for example telnetd.
Firewalls
A firewall is usually placed between the "inside" and the "outside"
networks, and is supposed to protect the inside from the evils on the
outside. There are different kinds of firewalls. The main
differences are in the way they forward packets.
o+ The most straight forward type is the one that just imposes
restrictions on incoming packets. Such a firewall could be
described as a router that filters packets that match some
criteria.
o+ They may also "hide" some or all addresses on the inside of the
firewall, replacing the addresses in the outgoing packets with the
address of the firewall (aka network address translation, or NAT).
NAT can also be used without any packet filtering, for instance
when you have more than one host sharing a single address (for
example, with a dialed-in PPP connection).
There are also firewalls that does NAT both on the inside and the
outside (a server on the inside will see this as a connection from
the firewall).
o+ A third type is the proxy type firewall, that parses the contents
of the packets, basically acting as a server to the client, and as
a client to the server (man-in-the-middle). If Kerberos is to be
used with this kind of firewall, a protocol module that handles
KDC requests has to be written.
This type of firewall might also cause extra trouble when used with
kerberised versions of protocols that the proxy understands, in
addition to the ones mentioned below. This is the case with the FTP
Security Extensions [RFC2228], that adds a new set of commands to the
FTP protocol [RFC959], for integrity, confidentiality, and privacy
protecting commands. When transferring data, the FTP protocol uses a
separate data channel, and an FTP proxy will have to look out for
commands that start a data transfer. If all commands are encrypted,
this is impossible. A protocol that doesn't suffer from this is the
Telnet Authentication Option [RFC1416] that does all authentication
and encryption in-bound.
Scenarios
Here the different scenarios we have considered are described, the
problems they introduce and the proposed ways of solving them.
Westerlund, Danielsson [Page 2]
Internet Draft Kerberos vs firewalls November, 1997
Combinations of these can also occur.
Client behind firewall
This is the most typical and common scenario. First of all the
client needs some way of communicating with the KDC. This can be
done with whatever means and is usually much simpler when the KDC is
able to communicate over TCP.
Apart from that, the client needs to be sure that the ticket it will
acquire from the KDC can be used to authenticate to a server outside
its firewall. For this, it needs to add the address(es) of potential
firewalls between itself and the KDC/server, to the list of its own
addresses when requesting the ticket. We are not aware of any
protocol for determining this set of addresses, thus this will have
to be manually configured in the client.
The client could also request a ticket with no addresses, but some
KDCs and servers might not accept such a ticket.
With the ticket in possession, communication with the kerberised
server will not need to be any different from communicating between a
non-kerberised client and server.
Kerberised server behind firewall
The kerberised server does not talk to the KDC at all so nothing
beyond normal firewall-traversal techniques for reaching the server
itself needs to be applied.
The kerberised server needs to be able to retrieve the original
address (before its firewall) that the request was sent for. If this
is done via some out-of-band mechanism or it's directly able to see
it doesn't matter.
KDC behind firewall
The same restrictions applies for a KDC as for any other server.
Specification
Security considerations
This memo does not introduce any known security considerations in
addition to those mentioned in [RFC1510].
References
Westerlund, Danielsson [Page 3]
Internet Draft Kerberos vs firewalls November, 1997
[RFC959] Postel, J. and Reynolds, J., "File Transfer Protocol (FTP)",
RFC 969, October 1985
[RFC1416] Borman, D., "Telnet Authentication Option", RFC 1416,
February 1993.
[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[RFC2228] Horowitz, M. and Lunt, S., "FTP Security Extensions",
RFC2228, October 1997.
Authors' Addresses
Assar Westerlund
Swedish Institute of Computer Science
Box 1263
S-164 29 KISTA
Sweden
Phone: +46-8-7521526
Fax: +46-8-7517230
EMail: assar@sics.se
Johan Danielsson
PDC, KTH
S-100 44 STOCKHOLM
Sweden
Phone: +46-8-7907885
Fax: +46-8-247784
EMail: joda@pdc.kth.se
Westerlund, Danielsson [Page 4]

260
crypto/heimdal/doc/standardisation/draft-foo3.ms
View File

@ -1,260 +0,0 @@
.\" even if this file is called .ms, it's using the me macros.
.\" to format try something like `nroff -me'
.\" level 2 heading
.de HH
.$p "\\$2" "" "\\$1"
.$0 "\\$2"
..
.\" make sure footnotes produce the right thing with nroff
.ie t \
\{\
.ds { \v'-0.4m'\x'\\n(0x=0*-0.2m'\s-3
.ds } \s0\v'0.4m'
.\}
.el \
\{\
.ds { [
.ds } ]
.\}
.ds * \\*{\\n($f\\*}\k*
.\" page footer
.fo 'Westerlund, Danielsson''[Page %]'
.\" date
.ds RH \*(mo, 19\n(yr
.\" left margin
.nr lm 6
.\" heading indent per level
.nr si 3n
.\" footnote indent
.nr fi 0
.\" paragraph indent
.nr po 0
.\" don't hyphenate
.hy 0
.\" left adjustment
.ad l
.\" indent 0
.in 0
.\" line length 16cm and page length 25cm (~10 inches)
.ll 16c
.pl 25c
.ta \n(.luR
.nf
Network Working Group Assar Westerlund
<draft-ietf-cat-krb5-firewalls.txt> SICS
Internet-Draft Johan Danielsson
\*(RH PDC, KTH
Expire in six months
.fi
.\" page header, has to be set here so it won't appear on page 1
.he 'Internet Draft'Kerberos vs firewalls'\*(RH'
.ce
.b "Kerberos vs firewalls"
.HH 1 "Status of this Memo"
.lp
This document is an Internet-Draft. 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.
.lp
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 \*(lqwork in progress.\*(rq
.lp
To view the entire list of current Internet-Drafts, please check the
\*(lq1id-abstracts.txt\*(rq listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
.lp
Distribution of this memo is unlimited. Please send comments to the
<cat-ietf@mit.edu> mailing list.
.HH 1 "Abstract"
.lp
Kerberos and firewalls both deal with security, but doesn't get along
very well. This memo discusses ways to use Kerberos in a firewalled
environment.
.HH 1 "Introduction"
.lp
Kerberos[RFC1510]
.(d
[RFC1510]
Kohl, J. and Neuman, C., \*(lqThe Kerberos Network Authentication
Service (V5)\*(rq, RFC 1510, September 1993.
.)d
is a protocol for authenticating parties communicating over insecure
networks. Firewalling is a technique for achieving an illusion of
security by putting restrictions on what kinds of packets and how
these are sent between the internal (so called \*(lqsecure\*(rq)
network and the global (or \*(lqinsecure\*(rq) Internet. The problems
with firewalls are many, but to name a few:
.np
Firewalls usually doesn't allow people to use UDP. The reason for this
is that UDP is (by firewall advocates) considered insecure. This
belief is probably based on the fact that many \*(lqinsecure\*(rq
protocols (like NFS) use UDP. UDP packets are also considered easy to
fake.
.np
Firewalls usually doesn't allow people to connect to arbitrary ports,
such as the ports used when talking to the KDC.
.np
In many non-computer organisations, the computer staff isn't what
you'd call \*(lqwizards\*(rq; a typical case is an academic
institution, where someone is taking care of the computers part time,
and is doing research the rest of the time. Adding a complex device
like a firewall to an environment like this, often leads to poorly run
systems that is more a hindrance for the legitimate users than to
possible crackers.
.lp
The easiest way to deal with firewalls is to ignore them, however in
some cases this just isn't possible. You might have users that are
stuck behind a firewall, but also has to access your system, or you
might find yourself behind a firewall, for instance when out
travelling.
.lp
To make it possible for people to use Kerberos from behind a firewall,
there are several things to consider.
.(q
.i
Add things to do when stuck behind a firewall, like talking about the
problem with local staff, making them open some port in the firewall,
using some other port, or proxy.
.r
.)q
.HH 1 "Firewalls"
.lp
A firewall is usually placed between the \*(lqinside\*(rq and the
\*(lqoutside\*(rq networks, and is supposed to protect the inside from the
evils on the outside. There are different kinds of firewalls. The
main differences are in the way they forward (or doesn't) packets.
.ip \(bu
The most straight forward type is the one that just imposes
restrictions on incoming packets. Such a firewall could be described
as a router that filters packets that match some criteria.
.ip \(bu
They may also \*(lqhide\*(rq some or all addresses on the inside of the
firewall, replacing the addresses in the outgoing packets with the
address of the firewall (aka network address translation, or NAT). NAT
can also be used without any packet filtering, for instance when you
have more than one host sharing a single address (e.g with a dialed-in
PPP connection).
.ip
There are also firewalls that does NAT both on the inside and the
outside (a server on the inside will see this as a connection from the
firewall).
.ip \(bu
A third type is the proxy type firewall, that parses the contents of
the packets, basically acting as a server to the client, and as a
client to the server (man-in-the-middle). If Kerberos is to be used
with this kind of firewall, a protocol module that handles KDC
requests has to be written\**.
.(f
\**Instead of writing a new module for Kerberos, it can be possible to
hitch a ride on some other protocol, that's already beeing handled by
the proxy.
.)f
.lp
The last type of firewall might also cause extra trouble when used
with kerberised versions of protocols that the proxy understands, in
addition to the ones mentioned below. This is the case with the FTP
Security Extensions [RFC2228],
.(d
[RFC2228]
Horowitz, M. and Lunt, S., \*(lqFTP Security Extensions\*(rq, RFC2228,
October 1997.
.)d
that adds a new set of commands to the FTP protocol [RFC959],
.(d
[RFC959] Postel, J. and Reynolds, J., \*(lqFile Transfer Protocol
(FTP)\*(rq, RFC 969, October 1985
.)d
for integrity, confidentiality, and privacy protecting commands, and
data. When transferring data, the FTP protocol uses a separate data
channel, and an FTP proxy will have to look out for commands that
start a data transfer. If all commands are encrypted, this is
impossible. A protocol that doesn't suffer from this is the Telnet
Authentication Option [RFC1416]
.(d
[RFC1416]
Borman, D., \*(lqTelnet Authentication Option\*(rq, RFC 1416, February
1993.
.)d
that does all
authentication and encryption in-bound.
.HH 1 "Scenarios"
.lp
Here the different scenarios we have considered are described, the
problems they introduce and the proposed ways of solving them.
Combinations of these can also occur.
.HH 2 "Client behind firewall"
.lp
This is the most typical and common scenario. First of all the client
needs some way of communicating with the KDC. This can be done with
whatever means and is usually much simpler when the KDC is able to
communicate over TCP.
.lp
Apart from that, the client needs to be sure that the ticket it will
acquire from the KDC can be used to authenticate to a server outside
its firewall. For this, it needs to add the address(es) of potential
firewalls between itself and the KDC/server, to the list of its own
addresses when requesting the ticket. We are not aware of any
protocol for determining this set of addresses, thus this will have to
be manually configured in the client.
.lp
The client could also request a ticket with no addresses. This is not
a recommended way to solve this problem. The address was put into the
ticket to make it harder to use a stolen ticket. A ticket without
addresses will therefore be less \*(lqsecure.\*(rq RFC1510 also says that
the KDC may refuse to issue, and the server may refuse to accept an
address-less ticket.
.lp
With the ticket in possession, communication with the kerberised
server will not need to be any different from communicating between a
non-kerberised client and server.
.HH 2 "Kerberised server behind firewall"
.lp
The kerberised server does not talk to the KDC at all, so nothing
beyond normal firewall-traversal techniques for reaching the server
itself needs to be applied.
.lp
If the firewall rewrites the clients address, the server will have to
use some other (possibly firewall specific) protocol to retrieve the
original address. If this is not possible, the address field will have
to be ignored. This has the same effect as if there were no addresses
in the ticket (see the discussion above).
.HH 2 "KDC behind firewall"
.lp
The KDC is in this respect basically just like any other server.
.\" .uh "Specification"
.HH 1 "Security considerations"
.lp
Since the whole network behind a NAT-type firewall looks like one
computer from the outside, any security added by the addresses in the
ticket will be lost.
.HH 1 "References"
.lp
.pd
.HH 1 "Authors' Addresses"
.lp
.nf
Assar Westerlund
Swedish Institute of Computer Science
Box 1263
S-164 29 KISTA
.sp
Phone: +46-8-7521526
Fax: +46-8-7517230
EMail: assar@sics.se
.sp 2
Johan Danielsson
Center for Parallel Computers
KTH
S-100 44 STOCKHOLM
.sp
Phone: +46-8-7906356
Fax: +46-8-247784
EMail: joda@pdc.kth.se
.fi

1594
crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt
View File

File diff suppressed because it is too large Load Diff

244
crypto/heimdal/doc/standardisation/draft-horowitz-key-derivation-01.txt
View File

@ -1,244 +0,0 @@
Network Working Group M. Horowitz
<draft-horowitz-key-derivation-01.txt> Cygnus Solutions
Internet-Draft March, 1997
Key Derivation for Authentication, Integrity, and Privacy
Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Distribution of this memo is unlimited. Please send comments to the
author.
Abstract
Recent advances in cryptography have made it desirable to use longer
cryptographic keys, and to make more careful use of these keys. In
particular, it is considered unwise by some cryptographers to use the
same key for multiple purposes. Since most cryptographic-based
systems perform a range of functions, such as authentication, key
exchange, integrity, and encryption, it is desirable to use different
cryptographic keys for these purposes.
This RFC does not define a particular protocol, but defines a set of
cryptographic transformations for use with arbitrary network
protocols and block cryptographic algorithm.
Deriving Keys
In order to use multiple keys for different functions, there are two
possibilities:
- Each protocol ``key'' contains multiple cryptographic keys. The
implementation would know how to break up the protocol ``key'' for
use by the underlying cryptographic routines.
- The protocol ``key'' is used to derive the cryptographic keys.
The implementation would perform this derivation before calling
Horowitz [Page 1]
Internet Draft Key Derivation March, 1997
the underlying cryptographic routines.
In the first solution, the system has the opportunity to provide
separate keys for different functions. This has the advantage that
if one of these keys is broken, the others remain secret. However,
this comes at the cost of larger ``keys'' at the protocol layer. In
addition, since these ``keys'' may be encrypted, compromising the
cryptographic key which is used to encrypt them compromises all the
component keys. Also, the not all ``keys'' are used for all possible
functions. Some ``keys'', especially those derived from passwords,
are generated from limited amounts of entropy. Wasting some of this
entropy on cryptographic keys which are never used is unwise.
The second solution uses keys derived from a base key to perform
cryptographic operations. By carefully specifying how this key is
used, all of the advantages of the first solution can be kept, while
eliminating some disadvantages. In particular, the base key must be
used only for generating the derived keys, and this derivation must
be non-invertible and entropy-preserving. Given these restrictions,
compromise of one derived keys does not compromise the other subkeys.
Attack of the base key is limited, since it is only used for
derivation, and is not exposed to any user data.
Since the derived key has as much entropy as the base keys (if the
cryptosystem is good), password-derived keys have the full benefit of
all the entropy in the password.
To generate a derived key from a base key:
Derived Key = DK(Base Key, Well-Known Constant)
where
DK(Key, Constant) = n-truncate(E(Key, Constant))
In this construction, E(Key, Plaintext) is a block cipher, Constant
is a well-known constant defined by the protocol, and n-truncate
truncates its argument by taking the first n bits; here, n is the key
size of E.
If the output of E is is shorter than n bits, then some entropy in
the key will be lost. If the Constant is smaller than the block size
of E, then it must be padded so it may be encrypted. If the Constant
is larger than the block size, then it must be folded down to the
block size to avoid chaining, which affects the distribution of
entropy.
In any of these situations, a variation of the above construction is
used, where the folded Constant is encrypted, and the resulting
output is fed back into the encryption as necessary (the | indicates
concatentation):
K1 = E(Key, n-fold(Constant))
K2 = E(Key, K1)
Horowitz [Page 2]
Internet Draft Key Derivation March, 1997
K3 = E(Key, K2)
K4 = ...
DK(Key, Constant) = n-truncate(K1 | K2 | K3 | K4 ...)
n-fold is an algorithm which takes m input bits and ``stretches''
them to form n output bits with no loss of entropy, as described in
[Blumenthal96]. In this document, n-fold is always used to produce n
bits of output, where n is the key size of E.
If the size of the Constant is not equal to the block size of E, then
the Constant must be n-folded to the block size of E. This number is
used as input to E. If the block size of E is less than the key
size, then the output from E is taken as input to a second invocation
of E. This process is repeated until the number of bits accumulated
is greater than or equal to the key size of E. When enough bits have
been computed, the first n are taken as the derived key.
Since the derived key is the result of one or more encryptions in the
base key, deriving the base key from the derived key is equivalent to
determining the key from a very small number of plaintext/ciphertext
pairs. Thus, this construction is as strong as the cryptosystem
itself.
Deriving Keys from Passwords
When protecting information with a password or other user data, it is
necessary to convert an arbitrary bit string into an encryption key.
In addition, it is sometimes desirable that the transformation from
password to key be difficult to reverse. A simple variation on the
construction in the prior section can be used:
Key = DK(n-fold(Password), Well-Known Constant)
The n-fold algorithm is reversible, so recovery of the n-fold output
is equivalent to recovery of Password. However, recovering the n-
fold output is difficult for the same reason recovering the base key
from a derived key is difficult.
Traditionally, the transformation from plaintext to ciphertext, or
vice versa, is determined by the cryptographic algorithm and the key.
A simple way to think of derived keys is that the transformation is
determined by the cryptographic algorithm, the constant, and the key.
For interoperability, the constants used to derive keys for different
purposes must be specified in the protocol specification. The
constants must not be specified on the wire, or else an attacker who
determined one derived key could provide the associated constant and
spoof data using that derived key, rather than the one the protocol
designer intended.
Horowitz [Page 3]
Internet Draft Key Derivation March, 1997
Determining which parts of a protocol require their own constants is
an issue for the designer of protocol using derived keys.
Security Considerations
This entire document deals with security considerations relating to
the use of cryptography in network protocols.
Acknowledgements
I would like to thank Uri Blumenthal, Hugo Krawczyk, and Bill
Sommerfeld for their contributions to this document.
References
[Blumenthal96] Blumenthal, U., "A Better Key Schedule for DES-Like
Ciphers", Proceedings of PRAGOCRYPT '96, 1996.
Author's Address
Marc Horowitz
Cygnus Solutions
955 Massachusetts Avenue
Cambridge, MA 02139
Phone: +1 617 354 7688
Email: marc@cygnus.com
Horowitz [Page 4]

62
crypto/heimdal/doc/standardisation/draft-ietf-cat-gssv2-08.txt
View File

@ -1,62 +0,0 @@
A new Request for Comments is now available in online RFC libraries.
RFC 2078
Title: Generic Security Service Application Program
Interface, Version 2
Author: J. Linn
Date: January 1997
Mailbox: John.Linn@ov.com
Pages: 85
Characters: 185990
Obsoletes: 1508
URL: ftp://ds.internic.net/rfc/rfc2078.txt
This memo revises RFC-1508, making specific, incremental changes in
response to implementation experience and liaison requests. It is
intended, therefore, that this memo or a successor version thereto
will become the basis for subsequent progression of the GSS-API
specification on the standards track. This document is a product of
the Common Authentication Technology Working Group.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info@ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute

6188
crypto/heimdal/doc/standardisation/draft-ietf-cat-gssv2-cbind-04.txt
View File

File diff suppressed because it is too large Load Diff

301
crypto/heimdal/doc/standardisation/draft-ietf-cat-iakerb-04.txt
View File

@ -1,301 +0,0 @@
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

311
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerb-chg-password-02.txt
View File

@ -1,311 +0,0 @@
Network Working Group M. Horowitz
<draft-ietf-cat-kerb-chg-password-02.txt> Stonecast, Inc.
Internet-Draft August, 1998
Kerberos Change Password Protocol
Status of this Memo
This document is an Internet-Draft. 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.''
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).
Distribution of this memo is unlimited. Please send comments to the
<cat-ietf@mit.edu> mailing list.
Abstract
The Kerberos V5 protocol [RFC1510] does not describe any mechanism
for users to change their own passwords. In order to promote
interoperability between workstations, personal computers, terminal
servers, routers, and KDC's from multiple vendors, a common password
changing protocol is required.
Overview
When a user wishes to change his own password, or is required to by
local policy, a simple request of a password changing service is
necessary. This service must be implemented on at least one host for
each Kerberos realm, probably on one of the kdc's for that realm.
The service must accept requests on UDP port 464 (kpasswd), and may
accept requests on TCP port 464 as well.
The protocol itself 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.
Horowitz [Page 1]
Internet Draft Kerberos Change Password Protocol August, 1998
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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
message length (16 bits)
Contains the length of the message, including this field, in bytes
(big-endian integer)
protocol version number (16 bits)
Contains the hex constant 0x0001 (big-endian integer)
AP-REQ length (16 bits)
length (big-endian integer) of AP-REQ data, in bytes.
AP-REQ data, as described in RFC1510 (variable length)
This AP-REQ must be for the service principal
kadmin/changepw@REALM, where REALM is the REALM of the user who
wishes to change his password. The Ticket in the AP-REQ must be
derived from an AS request (thus having the INITIAL flag set), and
must include a subkey in the Authenticator.
KRB-PRIV message, as described in RFC1510 (variable length)
This KRB-PRIV message must be generated using the subkey in the
Authenticator in the AP-REQ data. The user-data component of the
message must consist of the user's new password.
The server must verify the AP-REQ message, decrypt the new password,
perform any local policy checks (such as password quality, history,
authorization, etc.) required, then set the password to the new value
specified.
The principal whose password is to be changed is the principal which
authenticated to the password changing service. This protocol does
not address administrators who want to change passwords of principal
besides their own.
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 or KRB-ERROR message /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
message length (16 bits)
Horowitz [Page 2]
Internet Draft Kerberos Change Password Protocol August, 1998
Contains the length of the message, including this field, in bytes
(big-endian integer),
protocol version number (16 bits)
Contains the hex constant 0x0001 (big-endian integer)
AP-REP length (16 bits)
length of AP-REP data, in bytes. If the the length is zero, then
the last field will contain a KRB-ERROR message instead of a KRB-
PRIV message.
AP-REP data, as described in RFC1510 (variable length)
The AP-REP corresponding to the AP-REQ in the request packet.
KRB-PRIV or KRB-ERROR message, as described in RFC1510 (variable
length)
If the AP-REP length is zero, then this field contains a KRB-ERROR
message. Otherwise, it contains a KRB-PRIV message. This KRB-
PRIV message must be generated using the subkey in the
Authenticator in the AP-REQ data.
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)
The result code must have one of the following values (big-
endian integer):
0x0000 if the request succeeds. (This value is not permitted
in a KRB-ERROR message.)
0x0001 if the request fails due to being malformed
0x0002 if the request fails due to a "hard" error processing
the request (for example, there is a resource or other
problem causing the request to fail)
0x0003 if the request fails due to an error in authentication
processing
0x0004 if the request fails due to a "soft" error processing
the request (for example, some policy or other similar
consideration is causing the request to be rejected).
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 (variable length)
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.
Horowitz [Page 3]
Internet Draft Kerberos Change Password Protocol August, 1998
Dropped and Modified Messages
An attacker (or simply a lossy network) could cause either the
request or reply to be dropped, or modified by substituting a KRB-
ERROR message in the reply.
If a request is dropped, no modification of the password/key database
will take place. If a reply is dropped, the server will (assuming a
valid request) make the password change. However, the client cannot
distinguish between these two cases.
In this situation, the client should construct a new authenticator,
re-encrypt the request, and retransmit. If the original request was
lost, the server will treat this as a valid request, and the password
will be changed normally. If the reply was lost, then the server
should take care to notice that the request was a duplicate of the
prior request, because the "new" password is the current password,
and the password change time is within some implementation-defined
replay time window. The server should then return a success reply
(an AP-REP message with result code == 0x0000) without actually
changing the password or any other information (such as modification
timestamps).
If a success reply was replaced with an error reply, then the
application performing the request would return an error to the user.
In this state, the user's password has been changed, but the user
believes that it has not. If the user attempts to change the
password again, this will probably fail, because the user cannot
successfully provide the old password to get an INITIAL ticket to
make the request. This situation requires administrative
intervention as if a password was lost. This situation is,
unfortunately, impossible to prevent.
Security Considerations
This document deals with changing passwords for Kerberos. Because
Kerberos is used for authentication and key distribution, it is
important that this protocol use the highest level of security
services available to a particular installation. Mutual
authentication is performed, so that the server knows the request is
valid, and the client knows that the request has been received and
processed by the server.
There are also security issues relating to dropped or modified
messages which are addressed explicitly.
References
[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
Horowitz [Page 4]
Internet Draft Kerberos Change Password Protocol August, 1998
Author's Address
Marc Horowitz
Stonecast, Inc.
108 Stow Road
Harvard, MA 01451
Phone: +1 978 456 9103
Email: marc@stonecast.net
Horowitz [Page 5]

127
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerb-des3-hmac-sha1-00.txt
View File

@ -1,127 +0,0 @@
Network Working Group M. Horowitz
<draft-ietf-cat-kerb-des3-hmac-sha1-00.txt> Cygnus Solutions
Internet-Draft November, 1996
Triple DES with HMAC-SHA1 Kerberos Encryption Type
Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Distribution of this memo is unlimited. Please send comments to the
<cat-ietf@mit.edu> mailing list.
Abstract
This document defines a new encryption type and a new checksum type
for use with Kerberos V5 [RFC1510]. This encryption type is based on
the Triple DES cryptosystem and the HMAC-SHA1 [Krawczyk96] message
authentication algorithm.
The des3-cbc-hmac-sha1 encryption type has been assigned the value 7.
The hmac-sha1-des3 checksum type has been assigned the value 12.
Encryption Type des3-cbc-hmac-sha1
EncryptedData using this type must be generated as described in
[Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC
mode. The keyed hash algorithm is HMAC-SHA1. Unless otherwise
specified, a zero IV must be used. If the length of the input data
is not a multiple of the block size, zero octets must be used to pad
the plaintext to the next eight-octet boundary. The counfounder must
be eight random octets (one block).
Checksum Type hmac-sha1-des3
Checksums using this type must be generated as described in
[Horowitz96]. The keyed hash algorithm is HMAC-SHA1.
Horowitz [Page 1]
Internet Draft Kerberos Triple DES with HMAC-SHA1 November, 1996
Common Requirements
Where the Triple DES key is represented as an EncryptionKey, it shall
be represented as three DES keys, with parity bits, concatenated
together. The key shall be represented with the most significant bit
first.
When keys are generated by the derivation function, a key length of
168 bits shall be used. The output bit string will be converted to a
valid Triple DES key by inserting DES parity bits after every seventh
bit.
Any implementation which implements either of the encryption or
checksum types in this document must support both.
Security Considerations
This entire document defines encryption and checksum types for use
with Kerberos V5.
References
[Horowitz96] Horowitz, M., "Key Derivation for Kerberos V5", draft-
horowitz-kerb-key-derivation-00.txt, November 1996.
[Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC:
Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac-
md5-01.txt, August, 1996.
[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
Author's Address
Marc Horowitz
Cygnus Solutions
955 Massachusetts Avenue
Cambridge, MA 02139
Phone: +1 617 354 7688
Email: marc@cygnus.com
Horowitz [Page 2]

250
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt
View File

@ -1,250 +0,0 @@
Network Working Group M. Horowitz
<draft-ietf-cat-kerb-key-derivation-00.txt> Cygnus Solutions
Internet-Draft November, 1996
Key Derivation for Kerberos V5
Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Distribution of this memo is unlimited. Please send comments to the
<cat-ietf@mit.edu> mailing list.
Abstract
In the Kerberos protocol [RFC1510], cryptographic keys are used in a
number of places. In order to minimize the effect of compromising a
key, it is desirable to use a different key for each of these places.
Key derivation [Horowitz96] can be used to construct different keys
for each operation from the keys transported on the network. For
this to be possible, a small change to the specification is
necessary.
Overview
Under RFC1510 as stated, key derivation could be specified as a set
of encryption types which share the same key type. The constant for
each derivation would be a function of the encryption type. However,
it is generally accepted that, for interoperability, key types and
encryption types must map one-to-one onto each other. (RFC 1510 is
being revised to address this issue.) Therefore, to use key
derivcation with Kerberos V5 requires a small change to the
specification.
For each place where a key is used in Kerberos, a ``key usage'' must
be specified for that purpose. The key, key usage, and
encryption/checksum type together describe the transformation from
plaintext to ciphertext, or plaintext to checksum. For backward
Horowitz [Page 1]
Internet Draft Key Derivation for Kerberos V5 November, 1996
compatibility, old encryption types would be defined independently of
the key usage.
Key Usage Values
This is a complete list of places keys are used in the kerberos
protocol, with key usage values and RFC 1510 section numbers:
1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the
client key (section 5.4.1)
2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or
application session key), encrypted with the service key
(section 5.4.2)
3. AS-REP encrypted part (includes tgs session key or application
session key), encrypted with the client key (section 5.4.2)
4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
session key (section 5.4.1)
5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
authenticator subkey (section 5.4.1)
6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
with the tgs session key (sections 5.3.2, 5.4.1)
7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs
authenticator subkey), encrypted with the tgs session key
(section 5.3.2)
8. TGS-REP encrypted part (includes application session key),
encrypted with the tgs session key (section 5.4.2)
9. TGS-REP encrypted part (includes application session key),
encrypted with the tgs authenticator subkey (section 5.4.2)
10. AP-REQ Authenticator cksum, keyed with the application session
key (section 5.3.2)
11. AP-REQ Authenticator (includes application authenticator
subkey), encrypted with the application session key (section
5.3.2)
12. AP-REP encrypted part (includes application session subkey),
encrypted with the application session key (section 5.5.2)
13. KRB-PRIV encrypted part, encrypted with a key chosen by the
application (section 5.7.1)
14. KRB-CRED encrypted part, encrypted with a key chosen by the
application (section 5.6.1)
15. KRB-SAVE cksum, keyed with a key chosen by the application
(section 5.8.1)
16. Data which is defined in some specification outside of
Kerberos to be encrypted using an RFC1510 encryption type.
17. Data which is defined in some specification outside of
Kerberos to be checksummed using an RFC1510 checksum type.
A few of these key usages need a little clarification. A service
which receives an AP-REQ has no way to know if the enclosed Ticket
was part of an AS-REP or TGS-REP. Therefore, key usage 2 must always
Horowitz [Page 2]
Internet Draft Key Derivation for Kerberos V5 November, 1996
be used for generating a Ticket, whether it is in response to an AS-
REQ or TGS-REQ.
There might exist other documents which define protocols in terms of
the RFC1510 encryption types or checksum types. Such documents would
not know about key usages. In order that these documents continue to
be meaningful until they are updated, key usages 16 and 17 must be
used to derive keys for encryption and checksums, respectively. New
protocols defined in terms of the Kerberos encryption and checksum
types should use their own key usages. Key usages may be registered
with IANA to avoid conflicts. Key usages shall be unsigned 32 bit
integers. Zero is not permitted.
Defining Cryptosystems Using Key Derivation
Kerberos requires that the ciphertext component of EncryptedData be
tamper-resistant as well as confidential. This implies encryption
and integrity functions, which must each use their own separate keys.
So, for each key usage, two keys must be generated, one for
encryption (Ke), and one for integrity (Ki):
Ke = DK(protocol key, key usage | 0xAA)
Ki = DK(protocol key, key usage | 0x55)
where the key usage is represented as a 32 bit integer in network
byte order. The ciphertest must be generated from the plaintext as
follows:
ciphertext = E(Ke, confounder | length | plaintext | padding) |
H(Ki, confounder | length | plaintext | padding)
The confounder and padding are specific to the encryption algorithm
E.
When generating a checksum only, there is no need for a confounder or
padding. Again, a new key (Kc) must be used. Checksums must be
generated from the plaintext as follows:
Kc = DK(protocol key, key usage | 0x99)
MAC = H(Kc, length | plaintext)
Note that each enctype is described by an encryption algorithm E and
a keyed hash algorithm H, and each checksum type is described by a
keyed hash algorithm H. HMAC, with an appropriate hash, is
recommended for use as H.
Security Considerations
This entire document addresses shortcomings in the use of
cryptographic keys in Kerberos V5.
Horowitz [Page 3]
Internet Draft Key Derivation for Kerberos V5 November, 1996
Acknowledgements
I would like to thank Uri Blumenthal, Sam Hartman, and Bill
Sommerfeld for their contributions to this document.
References
[Horowitz96] Horowitz, M., "Key Derivation for Authentication,
Integrity, and Privacy", draft-horowitz-key-derivation-00.txt,
November 1996. [RFC1510] Kohl, J. and Neuman, C., "The Kerberos
Network Authentication Service (V5)", RFC 1510, September 1993.
Author's Address
Marc Horowitz
Cygnus Solutions
955 Massachusetts Avenue
Cambridge, MA 02139
Phone: +1 617 354 7688
Email: marc@cygnus.com
Horowitz [Page 4]

252
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt
View File

@ -1,252 +0,0 @@
INTERNET-DRAFT Ari Medvinsky
draft-ietf-cat-kerberos-err-msg-00.txt Matt Hur
Updates: RFC 1510 Dominique Brezinski
expires September 30, 1997 CyberSafe Corporation
Gene Tsudik
Brian Tung
ISI
Integrity Protection for the Kerberos Error Message
0. Status Of this Memo
This document is an Internet-Draft. 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."
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ds.internic.net (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-03.txt, and expires June xx, 1997.
Please send comments to the authors.
1. Abstract
The Kerberos error message, as defined in RFC 1510, is transmitted
to the client without any integrity assurance. Therefore, the
client has no means to distinguish between a valid error message
sent from the KDC and one sent by an attacker. This draft describes
a method for assuring the integrity of Kerberos error messages, and
proposes a consistent format for the e-data field in the KRB_ERROR
message. This e-data format enables the storage of cryptographic
checksums by providing an extensible mechanism for specifying e-data
types.
2. Motivation
In the Kerberos protocol [1], if an error occurs for AS_REQ,
TGS_REQ, or AP_REQ, a clear text error message is returned to the
client. An attacker may exploit this vulnerability by sending a
false error message as a reply to any of the above requests. For
example, an attacker may send the KDC_ERR_KEY_EXPIRED error message
in order to force a user to change their password in hope that the
new key will not be as strong as the current key, and thus, easier
to break.
Since false error messages may be utilized by an attacker, a
Kerberos client should have a means for determining how much trust
to place in a given error message. The rest of this draft
describes a method for assuring the integrity of Kerberos error
messages.
3. Approach
We propose taking a cryptographic checksum over the entire KRB-ERROR
message. This checksum would be returned as part of the error
message and would enable the client to verify the integrity of the
error message. For interoperability reasons, no new fields are
added to the KRB-ERROR message. Instead, the e-data field (see
figure 1) is utilized to carry the cryptographic checksum.
3.1 Cryptographic checksums in error messages for AS_REQ,
TGS_REQ & AP_REQ
If an error occurs for the AS request, the only key that is
available to the KDC is the shared secret (the key derived from the
clients password) registered in the KDCs database. The KDC will
use this key to sign the error message, if and only if, the client
already proved knowledge of the shared secret in the AS request
(e.g. via PA-ENC-TIMESTAMP in preauth data). This policy is needed
to prevent an attacker from getting the KDC to send a signed error
message and then launching an off-line attack in order to obtain a
key of a given principal.
If an error occurs for a TGS or an AP request, the server will use
the session key sealed in the clients ticket granting ticket to
compute the checksum over the error message. If the checksum could
not be computed (e.g. error while decrypting the ticket) the error
message is returned to the client without the checksum. The client
then has the option to treat unprotected error messages differently.
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno [0] integer,
msg-type [1] integer,
ctime [2] KerberosTime OPTIONAL,
cusec [3] INTEGER OPTIONAL,
stime [4] KerberosTime,
susec [5] INTEGER,
error-code [6] INTEGER,
crealm [7] Realm OPTIONAL,
cname [8] PrincipalName OPTIONAL,
realm [9] Realm, --Correct realm
sname [10] PrincipalName, --Correct name
e-text [11] GeneralString OPTIONAL,
e-data [12] OCTET STRING OPTIONAL
}
Figure 1
3.2 Format of the e-data field
We propose to place the cryptographic checksum in the e-data field.
First, we review the format of the e-data field, as specified in
RFC 1510. The format of e-data is specified only in two cases [2].
"If the error code is KDC_ERR_PREAUTH_REQUIRED, then the e-data
field will contain an encoding of a sequence of padata fields":
METHOD-DATA ::= SEQUENCE of PA-DATA
PA-DATA ::= SEQUENCE {
padata-type [1] INTEGER,
padata-value [2] OCTET STRING
}
The second case deals with the KRB_AP_ERR_METHOD error code. The
e-data field will contain an encoding of the following sequence:
METHOD-DATA ::= SEQUENCE {
method-type [0] INTEGER,
method-data [1] OCTET STRING OPTIONAL
}
method-type indicates the required alternate authentication method.
It should be noted that, in the case of KRB_AP_ERR_METHOD, a signed
checksum is not returned as part of the error message, since the
error code indicates that the Kerberos credentials provided in the
AP_REQ message are unacceptable.
We propose that the e-data field have the following format for all
error-codes (except KRB_AP_ERR_METHOD):
E-DATA ::= SEQUENCE {
data-type [1] INTEGER,
data-value [2] OCTET STRING,
}
The data-type field specifies the type of information that is
carried in the data-value field. Thus, to send a cryptographic
checksum back to the client, the data-type is set to CHECKSUM, the
data-value is set to the ASN.1 encoding of the following sequence:
Checksum ::= SEQUENCE {
cksumtype [0] INTEGER,
checksum [1] OCTET STRING
}
3.3 Computing the checksum
After the error message is filled out, the error structure is
converted into ASN.1 representation. A cryptographic checksum is
then taken over the encoded error message; the result is placed in
the error message structure, as the last item in the e-data field.
To send the error message, ASN.1 encoding is again performed over
the error message, which now includes the cryptographic checksum.
3.4 Verifying the integrity of the error message
In addition to verifying the cryptographic checksum for the error
message, the client must verify that the error message is bound to
its request. This is done by comparing the ctime field in the
error message to its counterpart in the request message.
4. E-DATA types
Since the e-data types must not conflict with preauthentication data
types, we propose that the preauthentication data types in the range
of 2048 and above be reserved for use as e-data types.
We define the following e-data type in support of integrity checking
for the Kerberos error message:
CHECKSUM = 2048 -- the keyed checksum described above
5. Discussion
5.1 e-data types
The extension for Kerberos error messages, as outlined above, is
extensible to allow for definition of other error data types.
We propose that the following e-data types be reserved:
KDCTIME = 2049
The error data would consist of the KDCs time in KerberosTime.
This data would be used by the client to adjust for clock skew.
REDIRECT = 2050
The error data would consist of a hostname. The hostname would
indicate the authoritative KDC from which to obtain a TGT.
5.2 e-data types vs. error code specific data formats
Since RFC 1510 does not define an error data type, the data format
must be explicitly specified for each error code. This draft has
proposed an extension to RFC 1510 that would introduce the concept
of error data types. This would allow for a manageable set of data
types to be used for any error message. The authors assume that
the introduction of this e-data structure will not break any
existing Kerberos implementations.
6. Bibliography
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication
Service (V5). Request for Comments: 1510
[2] J. Kohl, C. Neuman. The Kerberos Network Authentication
Service (V5). Request for Comments: 1510 p.67
7. Authors
Ari Medvinsky <ari.medvinsky@cybersafe.com>
Matthew Hur <matt.hur@cybersafe.com>
Dominique Brezinski <dominique.brezinski@cybersafe.com>
CyberSafe Corporation
1605 NW Sammamish Road
Suite 310
Issaquah, WA 98027-5378
Phone: (206) 391-6000
Fax: (206) 391-0508
http:/www.cybersafe.com
Brian Tung <brian@isi.edu>
Gene Tsudik <gts@isi.edu>
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey CA 90292-6695
Phone: (310) 822-1511

174
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt
View File

@ -1,174 +0,0 @@
INTERNET-DRAFT Jonathan Trostle
draft-ietf-cat-kerberos-extra-tgt-02.txt Cisco Systems
Updates: RFC 1510 Michael M. Swift
expires January 30, 2000 University of WA
Extension to Kerberos V5 For Additional Initial Encryption
0. Status Of This Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This document defines an extension to the Kerberos protocol
specification (RFC 1510) [1] to enable a preauthentication field in
the AS_REQ message to carry a ticket granting ticket. The session
key from this ticket granting ticket will be used to
cryptographically strengthen the initial exchange in either the
conventional Kerberos V5 case or in the case the user stores their
encrypted private key on the KDC [2].
2. Motivation
In Kerberos V5, the initial exchange with the KDC consists of the
AS_REQ and AS_REP messages. For users, the encrypted part of the
AS_REP message is encrypted in a key derived from a password.
Although a password policy may be in place to prevent dictionary
attacks, brute force attacks may still be a concern due to
insufficient key length.
This draft specifies an extension to the Kerberos V5 protocol to
allow a ticket granting ticket to be included in an AS_REQ message
preauthentication field. The session key from this ticket granting
ticket will be used to cryptographically strengthen the initial
exchange in either the conventional Kerberos V5 case or in the case
the user stores their encrypted private key on the KDC [2]. The
session key from the ticket granting ticket is combined with the
user password key (key K2 in the encrypted private key on KDC
option) using HMAC to obtain a new triple des key that is used in
place of the user key in the initial exchange. The ticket granting
ticket could be obtained by the workstation using its host key.
3. The Extension
The following new preauthentication type is proposed:
PA-EXTRA-TGT 22
The preauthentication-data field contains a ticket granting ticket
encoded as an ASN.1 octet string. The server realm of the ticket
granting ticket must be equal to the realm in the KDC-REQ-BODY of
the AS_REQ message. In the absence of a trust relationship, the
local Kerberos client should send the AS_REQ message without this
extension.
In the conventional (non-pkinit) case, we require the RFC 1510
PA-ENC-TIMESTAMP preauthentication field in the AS_REQ message.
If neither it or the PA-PK-KEY-REQ preauthentication field is
included in the AS_REQ message, the KDC will reply with a
KDC_ERR_PREAUTH_FAILED error message.
We propose the following new etypes:
des3-cbc-md5-xor 16
des3-cbc-sha1-xor 17
The encryption key is obtained by:
(1) Obtaining an output M from the HMAC-SHA1 function [3] using
the user password key (the key K2 in the encrypted private
key on KDC option of pkinit) as the text and the triple des
session key as the K input in HMAC:
M = H(K XOR opad, H(K XOR ipad, text)) where H = SHA1.
The session key from the accompanying ticket granting ticket
must be a triple des key when one of the triple des xor
encryption types is used.
(2) Concatenate the output M (20 bytes) with the first 8 non-parity
bits of the triple-des ticket granting ticket session key to
get 168 bits that will be used for the new triple-des encryption
key.
(3) Set the parity bits of the resulting key.
The resulting triple des key is used to encrypt the timestamp
for the PA-ENC-TIMESTAMP preauthentication value (or in the
encrypted private key on KDC option of pkinit, it is used in
place of the key K2 to both sign in the PA-PK-KEY-REQ and for
encryption in the PA-PK-KEY-REP preauthentication types).
If the KDC decrypts the encrypted timestamp and it is not within
the appropriate clock skew period, the KDC will reply with the
KDC_ERR_PREAUTH_FAILED error. The same error will also be sent if
the above ticket granting ticket fails to decrypt properly, or if
it is not a valid ticket.
The KDC will create the shared triple des key from the ticket
granting ticket session key and the user password key (the key K2
in the encrypted private key on KDC case) using HMAC as specified
above and use it to validate the AS_REQ message and then to
encrypt the encrypted part of the AS_REP message (use it in place
of the key K2 for encryption in the PA-PK-KEY-REP preauthentication
field).
Local workstation policy will determine the exact behaviour of
the Kerberos client with respect to the extension protocol. For
example, the client should consult policy to decide when to use
use the extension. This policy could be dependent on the user
identity, or whether the workstation is in the same realm as the
user. One possibility is for the workstation logon to fail if
the extension is not used. Another possibility is for the KDC
to set a flag in tickets issued when this extension is used.
A similar idea was proposed in OSF DCE RFC 26.0 [4]; there a
preauthentication field containing a ticket granting ticket,
a randomly generated subkey encrypted in the session key from
the ticket, and a timestamp structure encrypted in the user
password and then the randomly generated subkey was proposed.
Some advantages of the current proposal are that the KDC has two
fewer decryptions to perform per request and the client does not
have to generate a random key.
4. Bibliography
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication
Service (V5). Request for Comments 1510.
[2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle.
Public Key Cryptography for Initial Authentication in Kerberos.
ftp://ds.internic.net/internet-drafts/
draft-ietf-cat-kerberos-pkinit-08.txt
[3] H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for
Message Authentication. Request for Comments 2104.
[4] J. Pato. Using Pre-authentication to Avoid Password Guessing
Attacks. OSF DCE SIG Request for Comments 26.0.
5. Acknowledgement: We thank Ken Hornstein for some helpful comments.
6. Expires January 30, 2000.
7. Authors' Addresses
Jonathan Trostle
170 W. Tasman Dr.
San Jose, CA 95134, U.S.A.
Email: jtrostle@cisco.com
Phone: (408) 527-6201
Michael Swift
Email: mikesw@cs.washington.edu

5
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt
View File

@ -1,5 +0,0 @@
This Internet-Draft has expired and is no longer available.
Unrevised documents placed in the Internet-Drafts directories have a
maximum life of six months. After that time, they must be updated, or
they will be deleted. This document was deleted on March 20, 2000.

282
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt
View File

@ -1,282 +0,0 @@
INTERNET-DRAFT Brian Tung
draft-ietf-cat-kerberos-pk-cross-01.txt Tatyana Ryutov
Updates: RFC 1510 Clifford Neuman
expires September 30, 1997 Gene Tsudik
ISI
Bill Sommerfeld
Hewlett-Packard
Ari Medvinsky
Matthew Hur
CyberSafe Corporation
Public Key Cryptography for Cross-Realm Authentication in Kerberos
0. Status Of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ds.internic.net (US East Coast),
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as
draft-ietf-cat-kerberos-pk-cross-01.txt, and expires September 30,
1997. Please send comments to the authors.
1. Abstract
This document defines extensions to the Kerberos protocol
specification (RFC 1510, "The Kerberos Network Authentication
Service (V5)", September 1993) to provide a method for using
public key cryptography during cross-realm authentication. The
methods defined here specify the way in which message exchanges
are to be used to transport cross-realm secret keys protected by
encryption under public keys certified as belonging to KDCs.
2. Motivation
The advantages provided by public key cryptography--ease of
recoverability in the event of a compromise, the possibility of
an autonomous authentication infrastructure, to name a few--have
produced a demand for use by Kerberos authentication protocol. A
draft describing the use of public key cryptography in the initial
authentication exchange in Kerberos has already been submitted.
This draft describes its use in cross-realm authentication.
The principal advantage provided by public key cryptography in
cross-realm authentication lies in the ability to leverage the
existing public key infrastructure. It frees the Kerberos realm
administrator from having to maintain separate keys for each other
realm with which it wishes to exchange authentication information,
or to utilize a hierarchical arrangement, which may pose problems
of trust.
Even with the multi-hop cross-realm authentication, there must be
some way to locate the path by which separate realms are to be
transited. The current method, which makes use of the DNS-like
realm names typical to Kerberos, requires trust of the intermediate
KDCs.
The methods described in this draft allow a realm to specify, at
the time of authentication, which certification paths it will
trust. A shared key for cross-realm authentication can be
established, for a period of time. Furthermore, these methods are
transparent to the client, so that only the KDC's need to be
modified to use them.
It is not necessary to implement the changes described in the
"Public Key Cryptography for Initial Authentication" draft to make
use of the changes in this draft. We solicit comments about the
interaction between the two protocol changes, but as of this
writing, the authors do not perceive any obstacles to using both.
3. Protocol Amendments
We assume that the user has already obtained a TGT. To perform
cross-realm authentication, the user sends a request to the local
KDC as per RFC 1510. If the two realms share a secret key, then
cross-realm authentication proceeds as usual. Otherwise, the
local KDC may attempt to establish a shared key with the remote
KDC using public key cryptography, and exchange this key through
the cross-realm ticket granting ticket.
We will consider the specific channel on which the message
exchanges take place in Section 5 below.
3.1. Changes to the Cross-Realm Ticket Granting Ticket
In order to avoid the need for changes to the "installed base" of
Kerberos application clients and servers, the only protocol change
is to the way in which cross-realm ticket granting tickets (TGTs)
are encrypted; as these tickets are opaque to clients and servers,
the only change visible to them will be the increased size of the
tickets.
Cross-realm TGTs are granted by a local KDC to authenticate a user
to a remote KDC's ticket granting service. In standard Kerberos,
they are encrypted using a shared secret key manually configured
into each KDC.
In order to incorporate public key cryptography, we define a new
encryption type, "ENCTYPE_PK_CROSS". Operationally, this encryption
type transforms an OCTET STRING of plaintext (normally an EncTktPart)
into the following SEQUENCE:
PKCrossOutput ::= SEQUENCE {
certificate [0] OCTET STRING OPTIONAL,
-- public key certificate
-- of local KDC
encSharedKey [1] EncryptedData,
-- of type EncryptionKey
-- containing random symmetric key
-- encrypted using public key
-- of remote KDC
sigSharedKey [2] Signature,
-- of encSharedKey
-- using signature key
-- of local KDC
pkEncData [3] EncryptedData,
-- (normally) of type EncTktPart
-- encrypted using encryption key
-- found in encSharedKey
}
PKCROSS operates as follows: when a client submits a request for
cross-realm authentication, the local KDC checks to see if it has
a long-term shared key established for that realm. If so, it uses
this key as per RFC 1510.
If not, it sends a request for information to the remote KDC. The
content of this message is immaterial, as it does not need to be
processed by the remote KDC; for the sake of consistency, we define
it as follows:
RemoteRequest ::= [APPLICATION 41] SEQUENCE {
nonce [0] INTEGER
}
The remote KDC replies with a list of all trusted certifiers and
all its (the remote KDC's) certificates. We note that this response
is universal and does not depend on which KDC makes the request:
RemoteReply ::= [APPLICATION 42] SEQUENCE {
trustedCertifiers [0] SEQUENCE OF PrincipalName,
certificates[1] SEQUENCE OF Certificate,
encTypeToUse [1] SEQUENCE OF INTEGER
-- encryption types usable
-- for encrypting pkEncData
}
Certificate ::= SEQUENCE {
CertType [0] INTEGER,
-- type of certificate
-- 1 = X.509v3 (DER encoding)
-- 2 = PGP (per PGP draft)
CertData [1] OCTET STRING
-- actual certificate
-- type determined by CertType
} -- from pk-init draft
Upon receiving this reply, the local KDC determines whether it has
a certificate the remote KDC trusts, and whether the remote KDC has
a certificate the local KDC trusts. If so, it issues a ticket
encrypted using the ENCTYPE_PK_CROSS encryption type defined above.
3.2. Profile Caches
We observe that using PKCROSS as specified above requires two
private key operations: a signature generation by the local KDC and
a decryption by the remote KDC. This cost can be reduced in the
long term by judicious caching of the encSharedKey and the
sigSharedKey.
Let us define a "profile" as the encSharedKey and sigSharedKey, in
conjunction with the associated remote realm name and decrypted
shared key (the key encrypted in the encSharedKey).
To optimize these interactions, each KDC maintains two caches, one
for outbound profiles and one for inbound profiles. When generating
an outbound TGT for another realm, the local KDC first checks to see
if the corresponding entry exists in the outbound profile cache; if
so, it uses its contents to form the first three fields of the
PKCrossOutput; the shared key is used to encrypt the data for the
fourth field. If not, the components are generated fresh and stored
in the outbound profile cache.
Upon receipt of the TGT, the remote realm checks its inbound profile
cache for the corresponding entry. If it exists, then it uses the
contents of the entry to decrypt the data encrypted in the pkEncData.
If not, then it goes through the full process of verifying and
extracting the shared key; if this is successful, then a new entry
is created in the inbound profile cache.
The inbound profile cache should support multiple entries per realm,
in the event that the initiating realm is replicated.
4. Finding Realms Supporting PKCROSS
If either the local realm or the destination realm does not support
PKCROSS, or both do not, the mechanism specified in Section 3 can
still be used in obtaining the desired remote TGT.
In the reference Kerberos implementations, the default behavior is
to traverse a path up and down the realm name hierarchy, if the
two realms do not share a key. There is, however, the possibility
of using cross links--i.e., keys shared between two realms that
are non-contiguous in the realm name hierarchy--to shorten the
path, both to minimize delay and the number of intermediate realms
that need to be trusted.
PKCROSS can be used as a way to provide cross-links even in the
absence of shared keys. If the client is aware that one or two
intermediate realms support PKCROSS, then a combination of
PKCROSS and conventional cross-realm authentication can be used
to reach the final destination realm.
We solicit discussion on the best methods for clients and KDCs to
determine or advertise support for PKCROSS.
5. Message Ports
We have not specified the port on which KDCs supporting PKCROSS
should listen to receive the request for information messages noted
above. We solicit discussion on which port should be used. We
propose to use the standard Kerberos ports (well-known 88 or 750),
but another possibility is to use a completely different port.
We also solicit discussion on what other approaches can be taken to
obtain the information in the RemoteReply (e.g., secure DNS or some
other repository).
6. Expiration Date
This Internet-Draft will expire on September 30, 1997.
7. Authors' Addresses
Brian Tung
Tatyana Ryutov
Clifford Neuman
Gene Tsudik
USC/Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey, CA 90292-6695
Phone: +1 310 822 1511
E-Mail: {brian, tryutov, bcn, gts}@isi.edu
Bill Sommerfeld
Hewlett Packard
300 Apollo Drive
Chelmsford MA 01824
Phone: +1 508 436 4352
E-Mail: sommerfeld@apollo.hp.com
Ari Medvinsky
Matthew Hur
CyberSafe Corporation
1605 NW Sammamish Road Suite 310
Issaquah WA 98027-5378
Phone: +1 206 391 6000
E-mail: {ari.medvinsky, matt.hur}@cybersafe.com

523
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt
View File

@ -1,523 +0,0 @@
INTERNET-DRAFT Matthew Hur
draft-ietf-cat-kerberos-pk-cross-06.txt CyberSafe Corporation
Updates: RFC 1510 Brian Tung
expires October 10, 2000 Tatyana Ryutov
Clifford Neuman
Gene Tsudik
ISI
Ari Medvinsky
Keen.com
Bill Sommerfeld
Hewlett-Packard
Public Key Cryptography for Cross-Realm Authentication in Kerberos
0. Status Of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may
also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as ``work in
progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.ietf.org (US East Coast),
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as
draft-ietf-cat-kerberos-pk-cross-06.txt, and expires May 15, 1999.
Please send comments to the authors.
1. Abstract
This document defines extensions to the Kerberos protocol
specification [1] to provide a method for using public key
cryptography to enable cross-realm authentication. The methods
defined here specify the way in which message exchanges are to be
used to transport cross-realm secret keys protected by encryption
under public keys certified as belonging to KDCs.
2. Introduction
The Kerberos authentication protocol [2] can leverage the
advantages provided by public key cryptography. PKINIT [3]
describes the use of public key cryptography in the initial
authentication exchange in Kerberos. PKTAPP [4] describes how an
application service can essentially issue a kerberos ticket to
itself after utilizing public key cryptography for authentication.
Another informational document species the use of public key
crypography for anonymous authentication in Kerberos [5]. This
specification describes the use of public key crpytography in cross-
realm authentication.
Without the use of public key cryptography, administrators must
maintain separate keys for every realm which wishes to exchange
authentication information with another realm (which implies n(n-1)
keys), or they must utilize a hierachichal arrangement of realms,
which may complicate the trust model by requiring evaluation of
transited realms.
Even with the multi-hop cross-realm authentication, there must be
some way to locate the path by which separate realms are to be
transited. The current method, which makes use of the DNS-like
realm names typical to Kerberos, requires trust of the intermediate
KDCs.
PKCROSS utilizes a public key infrastructure (PKI) [6] to simplify
the administrative burden of maintaining cross-realm keys. Such
usage leverages a PKI for a non-centrally-administratable environment
(namely, inter-realm). Thus, a shared key for cross-realm
authentication can be established for a set period of time, and a
remote realm is able to issue policy information that is returned to
itself when a client requests cross-realm authentication. Such policy
information may be in the form of restrictions [7]. Furthermore,
these methods are transparent to the client; therefore, only the KDCs
need to be modified to use them. In this way, we take advantage of
the the distributed trust management capabilities of public key
crypography while maintaining the advantages of localized trust
management provided by Kerberos.
Although this specification utilizes the protocol specfied in the
PKINIT specification, it is not necessary to implement client
changes in order to make use of the changes in this document.
3. Objectives
The objectives of this specification are as follows:
1. Simplify the administration required to establish Kerberos
cross-realm keys.
2. Avoid modification of clients and application servers.
3. Allow remote KDC to control its policy on cross-realm
keys shared between KDCs, and on cross-realm tickets
presented by clients.
4. Remove any need for KDCs to maintain state about keys
shared with other KDCs.
5. Leverage the work done for PKINIT to provide the public key
protocol for establishing symmetric cross realm keys.
4. Definitions
The following notation is used throughout this specification:
KDC_l ........... local KDC
KDC_r ........... remote KDC
XTKT_(l,r) ...... PKCROSS ticket that the remote KDC issues to the
local KDC
TGT_(c,r) ....... cross-realm TGT that the local KDC issues to the
client for presentation to the remote KDC
This specification defines the following new types to be added to the
Kerberos specification:
PKCROSS kdc-options field in the AS_REQ is bit 9
TE-TYPE-PKCROSS-KDC 2
TE-TYPE-PKCROSS-CLIENT 3
This specification defines the following ASN.1 type for conveying
policy information:
CrossRealmTktData ::= SEQUENCE OF TypedData
This specification defines the following types for policy information
conveyed in CrossRealmTktData:
PLC_LIFETIME 1
PLC_SET_TKT_FLAGS 2
PLC_NOSET_TKT_FLAGS 3
TicketExtensions are defined per the Kerberos specification [8]:
TicketExtensions ::= SEQUENCE OF TypedData
Where
TypedData ::= SEQUENCE {
data-type[0] INTEGER,
data-value[1] OCTET STRING OPTIONAL
}
5. Protocol Specification
We assume that the client has already obtained a TGT. To perform
cross-realm authentication, the client does exactly what it does
with ordinary (i.e. non-public-key-enabled) Kerberos; the only
changes are in the KDC; although the ticket which the client
forwards to the remote realm may be changed. This is acceptable
since the client treats the ticket as opaque.
5.1. Overview of Protocol
The basic operation of the PKCROSS protocol is as follows:
1. The client submits a request to the local KDC for
credentials for the remote realm. This is just a typical
cross realm request that may occur with or without PKCROSS.
2. The local KDC submits a PKINIT request to the remote KDC to
obtain a "special" PKCROSS ticket. This is a standard
PKINIT request, except that PKCROSS flag (bit 9) is set in
the kdc-options field in the AS_REQ.
3. The remote KDC responds as per PKINIT, except that
the ticket contains a TicketExtension, which contains
policy information such as lifetime of cross realm tickets
issued by KDC_l to a client. The local KDC must reflect
this policy information in the credentials it forwards to
the client. Call this ticket XTKT_(l,r) to indicate that
this ticket is used to authenticate the local KDC to the
remote KDC.
4. The local KDC passes a ticket, TGT_(c,r) (the cross realm
TGT between the client and remote KDC), to the client.
This ticket contains in its TicketExtension field the
ticket, XTKT_(l,r), which contains the cross-realm key.
The TGT_(c,r) ticket is encrypted using the key sealed in
XTKT_(l,r). (The TicketExtension field is not encrypted.)
The local KDC may optionally include another TicketExtension
type that indicates the hostname and/or IP address for the
remote KDC.
5. The client submits the request directly to the remote
KDC, as before.
6. The remote KDC extracts XTKT_(l,r) from the TicketExtension
in order to decrypt the encrypted part of TGT_(c,r).
--------------------------------------------------------------------
Client Local KDC (KDC_l) Remote KDC (KDC_r)
------ ----------------- ------------------
Normal Kerberos
request for
cross-realm
ticket for KDC_r
---------------------->
PKINIT request for
XTKT(l,r) - PKCROSS flag
set in the AS-REQ
* ------------------------->
PKINIT reply with
XTKT_(l,r) and
policy info in
ticket extension
<-------------------------- *
Normal Kerberos reply
with TGT_(c,r) and
XTKT(l,r) in ticket
extension
<---------------------------------
Normal Kerberos
cross-realm TGS-REQ
for remote
application
service with
TGT_(c,r) and
XTKT(l,r) in ticket
extension
------------------------------------------------->
Normal Kerberos
cross-realm
TGS-REP
<---------------------------------------------------------------
* Note that the KDC to KDC messages occur only periodically, since
the local KDC caches the XTKT_(l,r).
--------------------------------------------------------------------
Sections 5.2 through 5.4 describe in detail steps 2 through 4
above. Section 5.6 describes the conditions under which steps
2 and 3 may be skipped.
Note that the mechanism presented above requires infrequent KDC to
KDC communication (as dictated by policy - this is discussed
later). Without such an exchange, there are the following issues:
1) KDC_l would have to issue a ticket with the expectation that
KDC_r will accept it.
2) In the message that the client sends to KDC_r, KDC_l would have
to authenticate KDC_r with credentials that KDC_r trusts.
3) There is no way for KDC_r to convey policy information to KDC_l.
4) If, based on local policy, KDC_r does not accept a ticket from
KDC_l, then the client gets stuck in the middle. To address such
an issue would require modifications to standard client
processing behavior.
Therefore, the infreqeunt use of KDC to KDC communication assures
that inter-realm KDC keys may be established in accordance with local
policies and that clients may continue to operate without
modification.
5.2. Local KDC's Request to Remote KDC
When the local KDC receives a request for cross-realm authentication,
it first checks its ticket cache to see if it has a valid PKCROSS
ticket, XTKT_(l,r). If it has a valid XTKT_(l,r), then it does not
need to send a request to the remote KDC (see section 5.5).
If the local KDC does not have a valid XTKT_(l,r), it sends a
request to the remote KDC in order to establish a cross realm key and
obtain the XTKT_(l,r). This request is in fact a PKINIT request as
described in the PKINIT specification; i.e., it consists of an AS-REQ
with a PA-PK-AS-REQ included as a preauthentication field. Note,
that the AS-REQ MUST have the PKCROSS flag (bit 9) set in the
kdc_options field of the AS-REQ. Otherwise, this exchange exactly
follows the description given in the PKINIT specification. In
addition, the naming
5.3. Remote KDC's Response to Local KDC
When the remote KDC receives the PKINIT/PKCROSS request from the
local KDC, it sends back a PKINIT response as described in
the PKINIT specification with the following exception: the encrypted
part of the Kerberos ticket is not encrypted with the krbtgt key;
instead, it is encrypted with the ticket granting server's PKCROSS
key. This key, rather than the krbtgt key, is used because it
encrypts a ticket used for verifying a cross realm request rather
than for issuing an application service ticket. Note that, as a
matter of policy, the session key for the XTKT_(l,r) MAY be of
greater strength than that of a session key for a normal PKINIT
reply, since the XTKT_(l,r) SHOULD be much longer lived than a
normal application service ticket.
In addition, the remote KDC SHOULD include policy information in the
XTKT_(l,r). This policy information would then be reflected in the
cross-realm TGT, TGT_(c,r). Otherwise, the policy for TGT_(c,r)
would be dictated by KDC_l rather than by KDC_r. The local KDC MAY
enforce a more restrictive local policy when creating a cross-realm
ticket, TGT_(c,r). For example, KDC_r may dictate a lifetime
policy of eight hours, but KDC_l may create TKT_(c,r) with a
lifetime of four hours, as dictated by local policy. Also, the
remote KDC MAY include other information about itself along with the
PKCROSS ticket. These items are further discussed in section 6
below.
5.4. Local KDC's Response to Client
Upon receipt of the PKINIT/CROSS response from the remote KDC,
the local KDC formulates a response to the client. This reply
is constructed exactly as in the Kerberos specification, except
for the following:
A) The local KDC places XTKT_(l,r) in the TicketExtension field of
the client's cross-realm, ticket, TGT_(c,r), for the remote realm.
Where
data-type equals 3 for TE-TYPE-PKCROSS-CLIENT
data-value is ASN.1 encoding of XTKT_(l,r)
B) The local KDC adds the name of its CA to the transited field of
TGT_(c,r).
5.5 Remote KDC's Processing of Client Request
When the remote KDC, KDC_r, receives a cross-realm ticket,
TGT_(c,r), and it detects that the ticket contains a ticket
extension of type TE-TYPE-PKCROSS-CLIENT, KDC_r must first decrypt
the ticket, XTKT_(l,r), that is encoded in the ticket extension.
KDC_r uses its PKCROSS key in order to decrypt XTKT_(l,r). KDC_r
then uses the key obtained from XTKT_(l,r) in order to decrypt the
cross-realm ticket, TGT_(c,r).
KDC_r MUST verify that the cross-realm ticket, TGT_(c,r) is in
compliance with any policy information contained in XTKT_(l,r) (see
section 6). If the TGT_(c,r) is not in compliance with policy, then
the KDC_r responds to the client with a KRB-ERROR message of type
KDC_ERR_POLICY.
5.6. Short-Circuiting the KDC-to-KDC Exchange
As we described earlier, the KDC to KDC exchange is required only
for establishing a symmetric, inter-realm key. Once this key is
established (via the PKINIT exchange), no KDC to KDC communication
is required until that key needs to be renewed. This section
describes the circumstances under which the KDC to KDC exchange
described in Sections 5.2 and 5.3 may be skipped.
The local KDC has a known lifetime for TGT_(c,r). This lifetime may
be determined by policy information included in XTKT_(l,r), and/or
it may be determined by local KDC policy. If the local KDC already
has a ticket XTKT(l,r), and the start time plus the lifetime for
TGT_(c,r) does not exceed the expiration time for XTGT_(l,r), then
the local KDC may skip the exchange with the remote KDC, and issue a
cross-realm ticket to the client as described in Section 5.4.
Since the remote KDC may change its PKCROSS key (referred to in
Section 5.2) while there are PKCROSS tickets still active, it SHOULD
cache the old PKCROSS keys until the last issued PKCROSS ticket
expires. Otherwise, the remote KDC will respond to a client with a
KRB-ERROR message of type KDC_ERR_TGT_REVOKED.
6. Extensions for the PKCROSS Ticket
As stated in section 5.3, the remote KDC SHOULD include policy
information in XTKT_(l,r). This policy information is contained in
a TicketExtension, as defined by the Kerberos specification, and the
authorization data of the ticket will contain an authorization
record of type AD-IN-Ticket-Extensions. The TicketExtension defined
for use by PKCROSS is TE-TYPE-PKCROSS-KDC.
Where
data-type equals 2 for TE-TYPE-PKCROSS-KDC
data-value is ASN.1 encoding of CrossRealmTktData
CrossRealmTktData ::= SEQUENCE OF TypedData
------------------------------------------------------------------
CrossRealmTktData types and the corresponding data are interpreted
as follows:
ASN.1 data
type value interpretation encoding
---------------- ----- -------------- ----------
PLC_LIFETIME 1 lifetime (in seconds) INTEGER
for TGT_(c,r)
- cross-realm tickets
issued for clients by
TGT_l
PLC_SET_TKT_FLAGS 2 TicketFlags that must BITSTRING
be set
- format defined by
Kerberos specification
PLC_NOSET_TKT_FLAGS 3 TicketFlags that must BITSTRING
not be set
- format defined by
Kerberos specification
Further types may be added to this table.
------------------------------------------------------------------
7. Usage of Certificates
In the cases of PKINIT and PKCROSS, the trust in a certification
authority is equivalent to Kerberos cross realm trust. For this
reason, an implementation MAY choose to use the same KDC certificate
when the KDC is acting in any of the following three roles:
1) KDC is authenticating clients via PKINIT
2) KDC is authenticating another KDC for PKCROSS
3) KDC is the client in a PKCROSS exchange with another KDC
Note that per PKINIT, the KDC X.509 certificate (the server in a
PKINIT exchange) MUST contain the principal name of the KDC in the
subjectAltName field.
8. Transport Issues
Because the messages between the KDCs involve PKINIT exchanges, and
PKINIT recommends TCP as a transport mechanism (due to the length of
the messages and the likelihood that they will fragment), the same
recommendation for TCP applies to PKCROSS as well.
9. Security Considerations
Since PKCROSS utilizes PKINIT, it is subject to the same security
considerations as PKINIT. Administrators should assure adherence
to security policy - for example, this affects the PKCROSS policies
for cross realm key lifetime and for policy propogation from the
PKCROSS ticket, issued from a remote KDC to a local KDC, to
cross realm tickets that are issued by a local KDC to a client.
10. Bibliography
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
(V5). Request for Comments 1510.
[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
for Computer Networks, IEEE Communications, 32(9):33-38. September
1994.
[3] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S.Medvinsky, J. Wray
J. Trostle. Public Key Cryptography for Initial Authentication
in Kerberos.
draft-ietf-cat-kerberos-pk-init-11.txt
[4] A. Medvinsky, M. Hur, S. Medvinsky, B. Clifford Neuman. Public
Key Utilizing Tickets for Application Servers (PKTAPP). draft-ietf-
cat-pktapp-02.txt
[5] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in
Kerberos. draft-ietf-cat-kerberos-anoncred-01.txt
[6] ITU-T (formerly CCITT) Information technology - Open Systems
Interconnection - The Directory: Authentication Framework
Recommendation X.509 ISO/IEC 9594-8
[7] B.C. Neuman, Proxy-Based Authorization and Accounting for
Distributed Systems. In Proceedings of the 13th International
Conference on Distributed Computing Systems, May 1993.
[8] C.Neuman, J. Kohl, T. Ts'o. The Kerberos Network Authentication
Service (V5). draft-ietf-cat-kerberos-revisions-05.txt
11. Authors' Addresses
Matthew Hur
CyberSafe Corporation
1605 NW Sammamish Road
Issaquah WA 98027-5378
Phone: +1 425 391 6000
E-mail: matt.hur@cybersafe.com
Brian Tung
Tatyana Ryutov
Clifford Neuman
Gene Tsudik
USC/Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey, CA 90292-6695
Phone: +1 310 822 1511
E-Mail: {brian, tryutov, bcn, gts}@isi.edu
Ari Medvinsky
Keen.com
2480 Sand Hill Road, Suite 200
Menlo Park, CA 94025
Phone +1 650 289 3134
E-mail: ari@keen.com
Bill Sommerfeld
Hewlett Packard
300 Apollo Drive
Chelmsford MA 01824
Phone: +1 508 436 4352
E-Mail: sommerfeld@apollo.hp.com

589
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt
View File

@ -1,589 +0,0 @@
INTERNET-DRAFT Clifford Neuman
draft-ietf-cat-kerberos-pk-init-03.txt Brian Tung
Updates: RFC 1510 ISI
expires September 30, 1997 John Wray
Digital Equipment Corporation
Ari Medvinsky
Matthew Hur
CyberSafe Corporation
Jonathan Trostle
Novell
Public Key Cryptography for Initial Authentication in Kerberos
0. Status Of this Memo
This document is an Internet-Draft. 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."
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ds.internic.net (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-03.txt, and expires September 30,
1997. Please send comments to the authors.
1. Abstract
This document defines extensions (PKINIT) to the Kerberos protocol
specification (RFC 1510 [1]) to provide a method for using public
key cryptography during initial authentication. The methods
defined specify the ways in which preauthentication data fields and
error data fields in Kerberos messages are to be used to transport
public key data.
2. Introduction
The popularity of public key cryptography has produced a desire for
its support in Kerberos [2]. The advantages provided by public key
cryptography include simplified key management (from the Kerberos
perspective) and the ability to leverage existing and developing
public key certification infrastructures.
Public key cryptography can be integrated into Kerberos in a number
of ways. One is to to associate a key pair with each realm, which
can then be used to facilitate cross-realm authentication; this is
the topic of another draft proposal. Another way is to allow users
with public key certificates to use them in initial authentication.
This is the concern of the current document.
One of the guiding principles in the design of PKINIT is that
changes should be as minimal as possible. As a result, the basic
mechanism of PKINIT is as follows: The user sends a request to the
KDC as before, except that if that user is to use public key
cryptography in the initial authentication step, his certificate
accompanies the initial request, in the preauthentication fields.
Upon receipt of this request, the KDC verifies the certificate and
issues a ticket granting ticket (TGT) as before, except that instead
of being encrypted in the user's long-term key (which is derived
from a password), it is encrypted in a randomly-generated key. This
random key is in turn encrypted using the public key certificate
that came with the request and signed using the KDC's signature key,
and accompanies the reply, in the preauthentication fields.
PKINIT also allows for users with only digital signature keys to
authenticate using those keys, and for users to store and retrieve
private keys on the KDC.
The PKINIT specification may also be used for direct peer to peer
authentication without contacting a central KDC. This application
of PKINIT is described in PKTAPP [4] and is based on concepts
introduced in [5, 6]. For direct client-to-server authentication,
the client uses PKINIT to authenticate to the end server (instead
of a central KDC), which then issues a ticket for itself. This
approach has an advantage over SSL [7] 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 [8]).
3. Proposed Extensions
This section describes extensions to RFC 1510 for supporting the
use of public key cryptography in the initial request for a ticket
granting ticket (TGT).
In summary, the following changes to RFC 1510 are proposed:
--> Users may authenticate using either a public key pair or a
conventional (symmetric) key. If public key cryptography is
used, public key data is transported in preauthentication
data fields to help establish identity.
--> Users may store private keys on the KDC for retrieval during
Kerberos initial authentication.
This proposal addresses two ways that users may use public key
cryptography for initial authentication. Users may present public
key certificates, or they may generate their own session key,
signed by their digital signature key. In either case, the end
result is that the user obtains an ordinary TGT that may be used for
subsequent authentication, with such authentication using only
conventional cryptography.
Section 3.1 provides definitions to help specify message formats.
Section 3.2 and 3.3 describe the extensions for the two initial
authentication methods. Section 3.3 describes a way for the user to
store and retrieve his private key on the KDC.
3.1. Definitions
Hash and encryption types will be specified using ENCTYPE tags; we
propose the addition of the following types:
#define ENCTYPE_SIGN_DSA_GENERATE 0x0011
#define ENCTYPE_SIGN_DSA_VERIFY 0x0012
#define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021
#define ENCTYPE_ENCRYPT_RSA_PUB 0x0022
allowing further signature types to be defined in the range 0x0011
through 0x001f, and further encryption types to be defined in the
range 0x0021 through 0x002f.
The extensions involve new preauthentication fields. The
preauthentication data types are in the range 17 through 21.
These values are also specified along with their corresponding
ASN.1 definition.
#define PA-PK-AS-REQ 17
#define PA-PK-AS-REP 18
#define PA-PK-AS-SIGN 19
#define PA-PK-KEY-REQ 20
#define PA-PK-KEY-REP 21
The extensions also involve new error types. The new error types
are in the range 227 through 229. They are:
#define KDC_ERROR_CLIENT_NOT_TRUSTED 227
#define KDC_ERROR_KDC_NOT_TRUSTED 228
#define KDC_ERROR_INVALID_SIG 229
In the exposition below, we use the following terms: encryption key,
decryption key, signature key, verification key. It should be
understood that encryption and verification keys are essentially
public keys, and decryption and signature keys are essentially
private keys. The fact that they are logically distinct does
not preclude the assignment of bitwise identical keys.
3.2. Standard Public Key Authentication
Implementation of the changes in this section is REQUIRED for
compliance with pk-init.
It is assumed that all public keys are signed by some certification
authority (CA). The initial authentication request is sent as per
RFC 1510, except that a preauthentication field containing data
signed by the user's signature key accompanies the request:
PA-PK-AS-REQ ::- SEQUENCE {
-- PA TYPE 17
signedPKAuth [0] SignedPKAuthenticator,
userCert [1] SEQUENCE OF Certificate OPTIONAL,
-- the user's certificate
-- optionally followed by that
-- certificate's certifier chain
trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL
-- CAs that the client trusts
}
SignedPKAuthenticator ::= SEQUENCE {
pkAuth [0] PKAuthenticator,
pkAuthSig [1] Signature,
-- of pkAuth
-- using user's signature key
}
PKAuthenticator ::= SEQUENCE {
cusec [0] INTEGER,
-- for replay prevention
ctime [1] KerberosTime,
-- for replay prevention
nonce [2] INTEGER,
-- binds response to this request
kdcName [3] PrincipalName,
clientPubValue [4] SubjectPublicKeyInfo OPTIONAL,
-- for Diffie-Hellman algorithm
}
Signature ::= SEQUENCE {
signedHash [0] EncryptedData
-- of type Checksum
-- encrypted under signature key
}
Checksum ::= SEQUENCE {
cksumtype [0] INTEGER,
checksum [1] OCTET STRING
} -- as specified by RFC 1510
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm [0] algorithmIdentifier,
subjectPublicKey [1] BIT STRING
} -- as specified by the X.509 recommendation [9]
Certificate ::= SEQUENCE {
CertType [0] INTEGER,
-- type of certificate
-- 1 = X.509v3 (DER encoding)
-- 2 = PGP (per PGP draft)
CertData [1] OCTET STRING
-- actual certificate
-- type determined by CertType
}
Note: If the signature uses RSA keys, then it is to be performed
as per PKCS #1.
The PKAuthenticator carries information to foil replay attacks,
to bind the request and response, and to optionally pass the
client's Diffie-Hellman public value (i.e. for using DSA in
combination with Diffie-Hellman). The PKAuthenticator is signed
with the private key corresponding to the public key in the
certificate found in userCert (or cached by the KDC).
In the PKAuthenticator, the client may specify the KDC name in one
of two ways: 1) a Kerberos principal name, or 2) the name in the
KDC's certificate (e.g., an X.500 name, or a PGP name). Note that
case #1 requires that the certificate name and the Kerberos principal
name be bound together (e.g., via an X.509v3 extension).
The userCert field is a sequence of certificates, the first of which
must be the user's public key certificate. Any subsequent
certificates will be certificates of the certifiers of the user's
certificate. These cerificates may be used by the KDC to verify the
user's public key. This field is empty if the KDC already has the
user's certifcate.
The trustedCertifiers field contains a list of certification
authorities trusted by the client, in the case that the client does
not possess the KDC's public key certificate.
Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
type, the KDC attempts to verify the user's certificate chain
(userCert), if one is provided in the request. This is done by
verifying the certification path against the KDC's policy of
legitimate certifiers. This may be based on a certification
hierarchy, or it may be simply a list of recognized certifiers in a
system like PGP. If the certification path does not match one of
the KDC's trusted certifiers, the KDC sends back an error message of
type KDC_ERROR_CLIENT_NOT_TRUSTED, and it includes in the error data
field a list of its own trusted certifiers, upon which the client
resends the request.
If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
verifies that it has a certificate issued by one of the certifiers
trusted by the client. If it does not have a suitable certificate,
the KDC returns an error message of type KDC_ERROR_KDC_NOT_TRUSTED
to the client.
If a trust relationship exists, the KDC then verifies the client's
signature on PKAuthenticator. If that fails, the KDC returns an
error message of type KDC_ERROR_INVALID_SIG. Otherwise, the KDC
uses the timestamp in the PKAuthenticator to assure that the request
is not a replay. The KDC also verifies that its name is specified
in PKAuthenticator.
Assuming no errors, the KDC replies as per RFC 1510, except that it
encrypts the reply not with the user's key, but with a random key
generated only for this particular response. This random key
is sealed in the preauthentication field:
PA-PK-AS-REP ::= SEQUENCE {
-- PA TYPE 18
kdcCert [0] SEQUENCE OF Certificate OPTIONAL,
-- the KDC's certificate
-- optionally followed by that
-- certificate's certifier chain
encPaReply [1] EncryptedData,
-- of type PaReply
-- using either the client public
-- key or the Diffie-Hellman key
-- specified by SignedDHPublicValue
signedDHPublicValue [2] SignedDHPublicValue OPTIONAL
}
PaReply ::= SEQUENCE {
replyEncKeyPack [0] ReplyEncKeyPack,
replyEncKeyPackSig [1] Signature,
-- of replyEncKeyPack
-- using KDC's signature key
}
ReplyEncKeyPack ::= SEQUENCE {
replyEncKey [0] EncryptionKey,
-- used to encrypt main reply
nonce [1] INTEGER
-- binds response to the request
-- passed in the PKAuthenticator
}
SignedDHPublicValue ::= SEQUENCE {
dhPublicValue [0] SubjectPublicKeyInfo,
dhPublicValueSig [1] Signature
-- of dhPublicValue
-- using KDC's signature key
}
The kdcCert field is a sequence of certificates, the first of which
must have as its root certifier one of the certifiers sent to the
KDC in the PA-PK-AS-REQ. Any subsequent certificates will be
certificates of the certifiers of the KDC's certificate. These
cerificates may be used by the client to verify the KDC's public
key. This field is empty if the client did not send to the KDC a
list of trusted certifiers (the trustedCertifiers field was empty).
Since each certifier in the certification path of a user's
certificate is essentially a separate realm, the name of each
certifier shall be added to the transited field of the ticket. The
format of these realm names shall follow the naming constraints set
forth in RFC 1510 (sections 7.1 and 3.3.3.1). Note that this will
require new nametypes to be defined for PGP certifiers and other
types of realms as they arise.
The KDC's certificate must bind the public key to a name derivable
from the name of the realm for that KDC. The client then extracts
the random key used to encrypt the main reply. This random key (in
encPaReply) is encrypted with either the client's public key or
with a key derived from the DH values exchanged between the client
and the KDC.
3.3. Digital Signature
Implementation of the changes in this section are OPTIONAL for
compliance with pk-init.
We offer this option with the warning that it requires the client to
generate a random key; the client may not be able to guarantee the
same level of randomness as the KDC.
If the user registered a digital signature key with the KDC instead
of an encryption key, then a separate exchange must be used. The
client sends a request for a TGT as usual, except that it (rather
than the KDC) generates the random key that will be used to encrypt
the KDC response. This key is sent to the KDC along with the
request in a preauthentication field:
PA-PK-AS-SIGN ::= SEQUENCE {
-- PA TYPE 19
encSignedKeyPack [0] EncryptedData
-- of SignedKeyPack
-- using the KDC's public key
}
SignedKeyPack ::= SEQUENCE {
signedKey [0] KeyPack,
signedKeyAuth [1] PKAuthenticator,
signedKeySig [2] Signature
-- of signedKey.signedKeyAuth
-- using user's signature key
}
KeyPack ::= SEQUENCE {
randomKey [0] EncryptionKey,
-- will be used to encrypt reply
nonce [1] INTEGER
}
where the nonce is copied from the request.
Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
the randomKey. It then replies as per RFC 1510, except that the
reply is encrypted not with a password-derived user key, but with
the randomKey sent in the request. Since the client already knows
this key, there is no need to accompany the reply with an extra
preauthentication field. The transited field of the ticket should
specify the certification path as described in Section 3.2.
3.4. Retrieving the Private Key From the KDC
Implementation of the changes in this section is RECOMMENDED for
compliance with pk-init.
When the user's private key is not stored local to the user, he may
choose to store the private key (normally encrypted using a
password-derived key) on the KDC. We provide this option to present
the user with an alternative to storing the private key on local
disk at each machine where he expects to authenticate himself using
pk-init. It should be noted that it replaces the added risk of
long-term storage of the private key on possibly many workstations
with the added risk of storing the private key on the KDC in a
form vulnerable to brute-force attack.
In order to obtain a private key, the client includes a
preauthentication field with the AS-REQ message:
PA-PK-KEY-REQ ::= SEQUENCE {
-- PA TYPE 20
patimestamp [0] KerberosTime OPTIONAL,
-- used to address replay attacks.
pausec [1] INTEGER OPTIONAL,
-- used to address replay attacks.
nonce [2] INTEGER,
-- binds the reply to this request
privkeyID [3] SEQUENCE OF KeyID OPTIONAL
-- constructed as a hash of
-- public key corresponding to
-- desired private key
}
KeyID ::= SEQUENCE {
KeyIdentifier [0] OCTET STRING
}
The client may request a specific private key by sending the
corresponding ID. If this field is left empty, then all
private keys are returned.
If all checks out, the KDC responds as described in the above
sections, except that an additional preauthentication field,
containing the user's private key, accompanies the reply:
PA-PK-KEY-REP ::= SEQUENCE {
-- PA TYPE 21
nonce [0] INTEGER,
-- binds the reply to the request
KeyData [1] SEQUENCE OF KeyPair
}
KeyPair ::= SEQUENCE {
privKeyID [0] OCTET STRING,
-- corresponding to encPrivKey
encPrivKey [1] OCTET STRING
}
3.4.1. Additional Protection of Retrieved Private Keys
We solicit discussion on the following proposal: that the client may
optionally include in its request additional data to encrypt the
private key, which is currently only protected by the user's
password. One possibility is that the client might generate a
random string of bits, encrypt it with the public key of the KDC (as
in the SignedKeyPack, but with an ordinary OCTET STRING in place of
an EncryptionKey), and include this with the request. The KDC then
XORs each returned key with this random bit string. (If the bit
string is too short, the KDC could either return an error, or XOR
the returned key with a repetition of the bit string.)
In order to make this work, additional means of preauthentication
need to be devised in order to prevent attackers from simply
inserting their own bit string. One way to do this is to store
a hash of the password-derived key (the one used to encrypt the
private key). This hash is then used in turn to derive a second
key (called the hash-key); the hash-key is used to encrypt an ASN.1
structure containing the generated bit string and a nonce value
that binds it to the request.
Since the KDC possesses the hash, it can generate the hash-key and
verify this (weaker) preauthentication, and yet cannot reproduce
the private key itself, since the hash is a one-way function.
4. Logistics and Policy Issues
We solicit discussion on how clients and KDCs should be configured
in order to determine which of the options described above (if any)
should be used. One possibility is to set the user's database
record to indicate that authentication is to use public key
cryptography; this will not work, however, in the event that the
client needs to know before making the initial request.
5. Compatibility with One-Time Passcodes
We solicit discussion on how the protocol changes proposed in this
draft will interact with the proposed use of one-time passcodes
discussed in draft-ietf-cat-kerberos-passwords-00.txt.
6. Strength of Cryptographic Schemes
In light of recent findings on the strength of MD5 and DES,
we solicit discussion on which encryption types to incorporate
into the protocol changes.
7. Bibliography
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication
Service (V5). Request for Comments: 1510
[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
for Computer Networks, IEEE Communications, 32(9):33-38.
September 1994.
[3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to
Transport Layer Security (TLS).
draft-ietf-tls-kerb-cipher-suites-00.txt
[4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
Tickets for Application Servers (PKTAPP).
draft-ietf-cat-pktapp-00.txt
[5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using
Public Key Cryptography. Symposium On Network and Distributed System
Security, 1997.
[6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
Protocol. In Proceedings of the USENIX Workshop on Electronic Commerce,
July 1995.
[7] Alan O. Freier, Philip Karlton and Paul C. Kocher.
The SSL Protocol, Version 3.0 - IETF Draft.
[8] B.C. Neuman, Proxy-Based Authorization and Accounting for
Distributed Systems. In Proceedings of the 13th International
Conference on Distributed Computing Systems, May 1993
[9] ITU-T (formerly CCITT)
Information technology - Open Systems Interconnection -
The Directory: Authentication Framework Recommendation X.509
ISO/IEC 9594-8
8. Acknowledgements
Some of the ideas on which this proposal is based arose during
discussions over several years between members of the SAAG, the IETF
CAT working group, and the PSRG, regarding integration of Kerberos
and SPX. Some ideas have also been drawn from the DASS system.
These changes are by no means endorsed by these groups. This is an
attempt to revive some of the goals of those groups, and this
proposal approaches those goals primarily from the Kerberos
perspective. Lastly, comments from groups working on similar ideas
in DCE have been invaluable.
9. Expiration Date
This draft expires September 30, 1997.
10. Authors
Clifford Neuman
Brian Tung
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey CA 90292-6695
Phone: +1 310 822 1511
E-mail: {bcn, brian}@isi.edu
John Wray
Digital Equipment Corporation
550 King Street, LKG2-2/Z7
Littleton, MA 01460
Phone: +1 508 486 5210
E-mail: wray@tuxedo.enet.dec.com
Ari Medvinsky
Matthew Hur
CyberSafe Corporation
1605 NW Sammamish Road Suite 310
Issaquah WA 98027-5378
Phone: +1 206 391 6000
E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
Jonathan Trostle
Novell
E-mail: jonathan.trostle@novell.com

1059
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt
View File

File diff suppressed because it is too large Load Diff

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

File diff suppressed because it is too large Load Diff

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

@ -1,378 +0,0 @@
INTERNET-DRAFT Ari Medvinsky
draft-ietf-cat-kerberos-pk-tapp-03.txt Keen.com, Inc.
Expires January 14, 2001 Matthew Hur
Informational CyberSafe Corporation
Sasha Medvinsky
Motorola
Clifford Neuman
USC/ISI
Public Key Utilizing Tickets for Application Servers (PKTAPP)
0. Status Of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.ietf.org (US East Coast),
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as
draft-ietf-cat-kerberos-pk-init-10.txt, and expires April 30,
2000. Please send comments to the authors.
1. Abstract
Public key based Kerberos for Distributed Authentication[1], (PKDA)
proposed by Sirbu & Chuang, describes PK based authentication that
eliminates the use of a centralized key distribution center while
retaining the advantages of Kerberos tickets. This draft describes how,
without any modification, the PKINIT specification[2] may be used to
implement the ideas introduced in PKDA. The benefit is that only a
single PK Kerberos extension is needed to address the goals of PKINIT &
PKDA.
2. Introduction
With the proliferation of public key cryptography, a number of public
key extensions to Kerberos have been proposed to provide
interoperability with the PK infrastructure and to improve the Kerberos
authentication system [4]. Among these are PKINIT[2] (under development
in the CAT working group) and more recently PKDA [1] proposed by Sirbu &
Chuang of CMU. One of the principal goals of PKINIT is to provide for
interoperability between a PK infrastructure and Kerberos. Using
PKINIT, a user can authenticate to the KDC via a public key certificate.
A ticket granting ticket (TGT), returned by the KDC, enables a PK user
to obtain tickets and authenticate to kerberized services. The PKDA
proposal goes a step further. It supports direct client to server
authentication, eliminating the need for an online key distribution
center. In this draft, we describe how, without any modification, the
PKINIT protocol may be applied to achieve the goals of PKDA. For direct
client to server authentication, the client will use PKINIT to
authenticate to the end server (instead of a central KDC), which then,
will issue a ticket for itself. The benefit of this proposal, is that a
single PK extension to Kerberos can addresses the goals of PKINIT and
PKDA.
3. PKDA background
The PKDA proposal provides direct client to server authentication, thus
eliminating the need for an online key distribution center. A client
and server take part in an initial PK based authentication exchange,
with an added caveat that the server acts as a Kerberos ticket granting
service and issues a traditional Kerberos ticket for itself. In
subsequent communication, the client makes use of the Kerberos ticket,
thus eliminating the need for public key operations on the server. This
approach has an advantage over SSL in that the server does not need to
save state (cache session keys). Furthermore, an additional benefit, is
that Kerberos tickets can facilitate delegation (see Neuman[3]).
Below is a brief overview of the PKDA protocol. For a more detailed
description see [1].
SCERT_REQ: Client to Server
The client requests a certificate from the server. If the serverÆs
certificate is cached locally, SCERT_REQ and SCERT_REP are omitted.
SCERT_REP: Server to Client
The server returns its certificate to the client.
PKTGS_REQ: Client to Server
The client sends a request for a service ticket to the server. To
authenticate the request, the client signs, among other fields, a time
stamp and a newly generated symmetric key . The time stamp is used to
foil replay attacks; the symmetric key is used by the server to secure
the PKTGS_REP message.
The client provides a certificate in the request (the certificate
enables the server to verify the validity of the clientÆs signature) and
seals it along with the signed information using the serverÆs public
key.
PKTGS_REP: Server to Client
The server returns a service ticket (which it issued for itself) along
with the session key for the ticket. The session key is protected by
the client-generated key from the PKTGS_REQ message.
AP_REQ: Client to Server
After the above exchange, the client can proceed in a normal fashion,
using the conventional Kerberos ticket in an AP_REQ message.
4. PKINIT background
One of the principal goals of PKINIT is to provide for interoperability
between a public key infrastructure and Kerberos. Using a public key
certificate, a client can authenticate to the KDC and receive a TGT
which enables the client to obtain service tickets to kerberized
services.. In PKINIT, the AS-REQ and AS-REP messages remain the same;
new preauthentication data types are used to conduct the PK exchange.
Client and server certificates are exchanged via the preauthentication
data. Thus, the exchange of certificates , PK authentication, and
delivery of a TGT can occur in two messages.
Below is a brief overview of the PKINIT protocol. For a more detailed
description see [2].
PreAuthentication data of AS-REQ: Client to Server
The client sends a list of trusted certifiers, a signed PK
authenticator, and its certificate. The PK authenticator, based on the
Kerberos authenticator, contains the name of the KDC, a timestamp, and a
nonce.
PreAuthentication data of AS-REP: Server to Client
The server responds with its certificate and the key used for decrypting
the encrypted part of the AS-REQ. This key is encrypted with the
clientÆs public key.
AP_REQ: Client to Server
After the above exchange, the client can proceed in a normal fashion,
using the conventional Kerberos ticket in an AP_REQ message.
5. Application of PKINIT to achieve equivalence to PKDA
While PKINIT is normally used to retrieve a ticket granting ticket
(TGT), it may also be used to request an end service ticket. When used
in this fashion, PKINIT is functionally equivalent to PKDA. We
introduce the concept of a local ticket granting server (LTGS) to
illustrate how PKINIT may be used for issuing end service tickets based
on public key authentication. It is important to note that the LTGS may
be built into an application server, or it may be a stand-alone server
used for issuing tickets within a well-defined realm, such as a single
machine. We will discuss both of these options.
5.1. The LTGS
The LTGS processes the Kerberos AS-REQ and AS-REP messages with PKINIT
preauthentication data. When a client submits an AS-REQ to the LTGS, it
specifies an application server, in order to receive an end service
ticket instead of a TGT.
5.1.1. The LTGS as a standalone server
The LTGS may run as a separate process that serves applications which
reside on the same machine. This serves to consolidate administrative
functions and provide an easier migration path for a heterogeneous
environment consisting of both public key and Kerberos. The LTGS would
use one well-known port (port #88 - same as the KDC) for all message
traffic and would share a symmetric with each service. After the client
receives a service ticket, it then contacts the application server
directly. This approach is similar to the one suggested by Sirbu , et
al [1].
5.1.1.1. Ticket Policy for PKTAPP Clients
It is desirable for the LTGS to have access to a PKTAPP client ticket
policy. This policy will contain information for each client, such as
the maximum lifetime of a ticket, whether or not a ticket can be
forwardable, etc. PKTAPP clients, however, use the PKINIT protocol for
authentication and are not required to be registered as Kerberos
principals.
As one possible solution, each public key Certification Authority could
be registered in a secure database, along with the ticket policy
information for all PKTAPP clients that are certified by this
Certification Authority.
5.1.1.2. LTGS as a Kerberos Principal
Since the LTGS serves only PKTAPP clients and returns only end service
tickets for other services, it does not require a Kerberos service key
or a Kerberos principal identity. It is therefore not necessary for the
LTGS to even be registered as a Kerberos principal.
The LTGS still requires public key credentials for the PKINIT exchange,
and it may be desired to have some global restrictions on the Kerberos
tickets that it can issue. It is recommended (but not required) that
this information be associated with a Kerberos principal entry for the
LTGS.
5.1.1.3. Kerberos Principal Database
Since the LTGS issues tickets for Kerberos services, it will require
access to a Kerberos principal database containing entries for at least
the end services. Each entry must contain a service key and may also
contain restrictions on the service tickets that are issued to clients.
It is recommended that (for ease of administration) this principal
database be centrally administered and distributed (replicated) to all
hosts where an LTGS may be running.
In the case that there are other clients that do not support PKINIT
protocol, but still need access to the same Kerberos services, this
principal database will also require entries for Kerberos clients and
for the TGS entries.
5.1.2. The LTGS as part of an application server
The LTGS may be combined with an application server. This accomplishes
direct client to application server authentication; however, it requires
that applications be modified to process AS-REQ and AS-REP messages.
The LTGS would communicate over the port assigned to the application
server or over the well known Kerberos port for that particular
application.
5.1.2.2. Ticket Policy for PKTAPP Clients
Application servers normally do not have access to a distributed
principal database. Therefore, they will have to find another means of
keeping track of the ticket policy information for PKTAPP clients. It is
recommended that this ticket policy be kept in a directory service (such
as LDAP).
It is critical, however, that both read and write access to this ticket
policy is restricted with strong authentication and encryption to only
the correct application server. An unauthorized party should not have
the authority to modify the ticket policy. Disclosing the ticket policy
to a 3rd party may aid an adversary in determining the best way to
compromise the network.
It is just as critical for the application server to authenticate the
directory service. Otherwise an adversary could use a man-in-the-middle
attack to substitute a false ticket policy with a false directory
service.
5.1.2.3. LTGS Credentials
Each LTGS (combined with an application service) will require public key
credentials in order to use the PKINIT protocol. These credentials can
be stored in a single file that is both encrypted with a password-
derived symmetric key and also secured by an operating system. This
symmetric key may be stashed somewhere on the machine for convenience,
although such practice potentially weakens the overall system security
and is strongly discouraged.
For added security, it is recommended that the LTGS private keys are
stored inside a temper-resistant hardware module that requires a pin
code for access.
5.1.2.4. Compatibility With Standard Kerberos
Even though an application server is combined with the LTGS, for
backward compatibility it should still accept service tickets that have
been issued by the KDC. This will allow Kerberos clients that do not
support PKTAPP to authenticate to the same application server (with the
help of a KDC).
5.1.3. Cross-Realm Authentication
According to the PKINIT draft, the client's realm is the X.500 name of
the Certification Authority that issued the client certificate. A
Kerberos application service will be in a standard Kerberos realm, which
implies that the LTGS will need to issue cross-realm end service
tickets. This is the only case, where cross-realm end service tickets
are issued. In a standard Kerberos model, a client first acquires a
cross-realm TGT, and then gets an end service ticket from the KDC that
is in the same realm as the application service.
6. Protocol differences between PKINIT and PKDA
Both PKINIT and PKDA will accomplish the same goal of issuing end
service tickets, based on initial public key authentication. A PKINIT-
based implementation and a PKDA implementation would be functionally
equivalent. The primary differences are that 1)PKDA requires the client
to create the symmetric key while PKINIT requires the server to create
the key and 2)PKINIT accomplishes in two messages what PKDA accomplishes
in four messages.
7. Summary
The PKINIT protocol can be used, without modification to facilitate
client to server authentication without the use of a central KDC. The
approach described in this draft (and originally proposed in PKDA[1])
is essentially a public key authentication protocol that retains the
advantages of Kerberos tickets.
Given that PKINIT has progressed through the CAT working group of the
IETF, with plans for non-commercial distribution (via MITÆs v5 Kerberos)
as well as commercial support, it is worthwhile to provide PKDA
functionality, under the PKINIT umbrella.
8. Security Considerations
PKTAPP is based on the PKINIT protocol and all security considerations
already listed in [2] apply here.
When the LTGS is implemented as part of each application server, the
secure storage of its public key credentials and of its ticket policy
are both a concern. The respective security considerations are already
covered in sections 5.1.2.3 and 5.1.2.2 of this document.
9. Bibliography
[1] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using
Public Key Cryptography. Symposium On Network and Distributed System
Security, 1997.
[2] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
J. Trostle. Public Key Cryptography for Initial Authentication in
Kerberos. Internet Draft, October 1999.
(ftp://ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-10.txt)
[3] C. Neuman, Proxy-Based Authorization and Accounting for
Distributed Systems. In Proceedings of the 13th International
Conference on Distributed Computing Systems, May 1993.
[4] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
(V5). Request for Comments 1510.
10. Expiration Date
This draft expires April 24, 2000.
11. Authors
Ari Medvinsky
Keen.com, Inc.
150 Independence Dr.
Menlo Park, CA 94025
Phone +1 650 289 3134
E-mail: ari@keen.com
Matthew Hur
CyberSafe Corporation
1605 NW Sammamish Road
Issaquah, WA 98027-5378
Phone: +1 425 391 6000
E-mail: matt.hur@cybersafe.com
Alexander Medvinsky
Motorola
6450 Sequence Dr.
San Diego, CA 92121
Phone: +1 858 404 2367
E-mail: smedvinsky@gi.com
Clifford Neuman
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey CA 90292-6695
Phone: +1 310 822 1511
E-mail: bcn@isi.edu

8277
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt
View File

File diff suppressed because it is too large Load Diff

6214
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-01.txt
View File

File diff suppressed because it is too large Load Diff

6766
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-03.txt
View File

File diff suppressed because it is too large Load Diff

6780
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-04.txt
View File

File diff suppressed because it is too large Load Diff

6866
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt
View File

File diff suppressed because it is too large Load Diff

7301
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt
View File

File diff suppressed because it is too large Load Diff

325
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt
View File

@ -1,325 +0,0 @@
INTERNET-DRAFT Mike Swift
draft-ietf-cat-kerberos-set-passwd-02.txt Microsoft
March 2000 Jonathan Trostle
Cisco Systems
John Brezak
Microsoft
Bill Gossman
Cybersafe
Kerberos Set/Change Password: Version 2
0. Status Of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Comments and suggestions on this document are encouraged. Comments
on this document should be sent to the CAT working group discussion
list:
ietf-cat-wg@stanford.edu
1. Abstract
The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]),
does not allow for an administrator to set a password for a new user.
This functionality is useful in some environments, and this proposal
extends [4] to allow password setting. The changes are: adding new
fields to the request message to indicate the principal which is
having its password set, not requiring the initial flag in the service
ticket, using a new protocol version number, and adding three new
result codes. We also extend the set/change protocol to allow a
client to send a sequence of keys to the KDC instead of a cleartext
password. If in the cleartext password case, the cleartext password
fails to satisfy password policy, the server should use the result
code KRB5_KPASSWD_POLICY_REJECT.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
3. The Protocol
The service must accept requests on UDP port 464 and TCP port 464 as
well. The protocol consists of a single request message followed by
a single reply message. For UDP transport, each message must be fully
contained in a single UDP packet.
For TCP transport, there is a 4 octet header in network byte order
precedes the message and specifies the length of the message. This
requirement is consistent with the TCP transport header in 1510bis.
Request Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message length | protocol version number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AP_REQ length | AP-REQ data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ KRB-PRIV message /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All 16 bit fields are in network byte order.
message length field: contains the number of bytes in the message
including this field.
protocol version number: contains the hex constant 0x0002 (network
byte order).
AP-REQ length: length of AP-REQ data, in bytes. If the length is zero,
then the last field contains a KRB-ERROR message instead of a KRB-PRIV
message.
AP-REQ data: (see [3]) The AP-REQ message must be for the service
principal kadmin/changepw@REALM, where REALM is the REALM of the user
who wishes to change/set his password. The ticket in the AP-REQ must
must include a subkey in the Authenticator. To enable setting of
passwords/keys, it is not required that the initial flag be set in the
Kerberos service ticket. The initial flag is required for change requests,
but not for set password requests. We have the following definitions:
old passwd initial flag target principal can be
in request? required? distinct from
authenticating principal?
change password: yes yes no
set password: no no yes
set key: no policy yes
determined
KRB-PRIV message (see [3]) This KRB-PRIV message must be generated
using the subkey from the authenticator in the AP-REQ data.
The user-data component of the message consists of the following ASN.1
structure encoded as an OCTET STRING:
ChangePasswdData :: = SEQUENCE {
newpasswdorkeys[0] NewPasswdOrKeys,
targname[1] PrincipalName OPTIONAL,
-- only present in set password: the principal
-- which will have its password set
targrealm[2] Realm OPTIONAL,
-- only present in set password: the realm for
-- the principal which will have its password set
}
NewPasswdOrKeys :: = CHOICE {
passwords[0] PasswordSequence,
keyseq[1] KeySequences
}
KeySequences :: = SEQUENCE OF KeySequence
KeySequence :: = SEQUENCE {
key[0] EncryptionKey,
salt[1] OCTET STRING OPTIONAL,
salt-type[2] INTEGER OPTIONAL
}
PasswordSequence :: = SEQUENCE {
newpasswd[0] OCTET STRING,
oldpasswd[1] OCTET STRING OPTIONAL
-- oldpasswd always present for change password
-- but not present for set password
}
The server must verify the AP-REQ message, check whether the client
principal in the ticket is authorized to set or change the password
(either for that principal, or for the principal in the targname
field if present), and decrypt the new password/keys. The server
also checks whether the initial flag is required for this request,
replying with status 0x0007 if it is not set and should be. An
authorization failure is cause to respond with status 0x0005. For
forward compatibility, the server should be prepared to ignore fields
after targrealm in the structure that it does not understand.
The newpasswdorkeys field contains either the new cleartext password
(with the old cleartext password for a change password operation),
or a sequence of encryption keys with their respective salts.
In the cleartext password case, if the old password is sent in the
request, the request is defined to be a change password request. If
the old password is not present in the request, the request is a set
password request. The server should apply policy checks to the old
and new password after verifying that the old password is valid.
The server can check validity by obtaining a key from the old
password with a keytype that is present in the KDC database for the
user and comparing the keys for equality. The server then generates
the appropriate keytypes from the password and stores them in the KDC
database. If all goes well, status 0x0000 is returned to the client
in the reply message (see below). For a change password operation,
the initial flag in the service ticket MUST be set.
In the key sequence case, the sequence of keys is sent to the set
password service. For a principal that can act as a server, its
preferred keytype should be sent as the first key in the sequence,
but the KDC is not required to honor this preference. Application
servers should use the key sequence option for changing/setting their
keys. The set password service should check that all keys are in the
proper format, returning the KRB5_KPASSWD_MALFORMED error otherwise.
Reply Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message length | protocol version number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AP_REP length | AP-REP data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ KRB-PRIV message /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All 16 bit fields are in network byte order.
message length field: contains the number of bytes in the message
including this field.
protocol version number: contains the hex constant 0x0002 (network
byte order). (The reply message has the same format as in [4]).
AP-REP length: length of AP-REP data, in bytes. If the length is zero,
then the last field contains a KRB-ERROR message instead of a KRB-PRIV
message.
AP-REP data: the AP-REP is the response to the AP-REQ in the request
packet.
KRB-PRIV from [4]: This KRB-PRIV message must be generated using the
subkey in the authenticator in the AP-REQ data.
The server will respond with a KRB-PRIV message unless it cannot
validate the client AP-REQ or KRB-PRIV message, in which case it will
respond with a KRB-ERROR message. NOTE: Unlike change password version
1, the KRB-ERROR message will be sent back without any encapsulation.
The user-data component of the KRB-PRIV message, or e-data component
of the KRB-ERROR message, must consist of the following data.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| result code | result string /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| edata /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
result code (16 bits) (result codes 0-4 are from [4]):
The result code must have one of the following values (network
byte order):
KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not
allowed in a KRB-ERROR message)
KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed
KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in
processing the request (for example,
there is a resource or other problem
causing the request to fail)
KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in
authentication processing
KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft error
in processing the request
KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported
KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required
KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy;
the result string should include a text message to be presented
to the user.
KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist
(only in response to a set password request).
KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence
containing at least one etype that is not supported by the KDC.
The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO
type that specifies the etypes that the KDC supports:
KERB-ETYPE-INFO-ENTRY :: = SEQUENCE {
encryption-type[0] INTEGER,
salt[1] OCTET STRING OPTIONAL -- not sent
}
PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY
The client should retry the request using only etypes (keytypes)
that are contained within the PKERB-ETYPE-INFO structure in the
previous response.
0xFFFF if the request fails for some other reason.
The client must interpret any non-zero result code as a failure.
result string - from [4]:
This field is a UTF-8 encoded string which should be displayed
to the user by the client. Specific reasons for a password
set/change policy failure is one use for this string.
edata: used to convey additional information as defined by the
result code.
4. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[3] J. Kohl, C. Neuman. The Kerberos Network Authentication
Service (V5), Request for Comments 1510.
[4] M. Horowitz. Kerberos Change Password Protocol,
ftp://ds.internic.net/internet-drafts/
draft-ietf-cat-kerb-chg-password-02.txt
5. Expiration Date
This draft expires in September 2000.
6. Authors' Addresses
Jonathan Trostle
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
Email: jtrostle@cisco.com
Mike Swift
1 Microsoft Way
Redmond, WA 98052
Email: mikesw@microsoft.com
John Brezak
1 Microsoft Way
Redmond, WA 98052
Email: jbrezak@microsoft.com
Bill Gossman
Cybersafe Corporation
1605 NW Sammamish Rd.
Issaquah, WA 98027-5378
Email: bill.gossman@cybersafe.com

345
crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt
View File

@ -1,345 +0,0 @@
INTERNET-DRAFT Mike Swift
draft-ietf-cat-kerberos-set-passwd-03.txt Microsoft
April 2000 Jonathan Trostle
Cisco Systems
John Brezak
Microsoft
Bill Gossman
Cybersafe
Kerberos Set/Change Password: Version 2
0. Status Of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Comments and suggestions on this document are encouraged. Comments
on this document should be sent to the CAT working group discussion
list:
ietf-cat-wg@stanford.edu
1. Abstract
The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]),
does not allow for an administrator to set a password for a new user.
This functionality is useful in some environments, and this proposal
extends [4] to allow password setting. The changes are: adding new
fields to the request message to indicate the principal which is
having its password set, not requiring the initial flag in the service
ticket, using a new protocol version number, and adding three new
result codes. We also extend the set/change protocol to allow a
client to send a sequence of keys to the KDC instead of a cleartext
password. If in the cleartext password case, the cleartext password
fails to satisfy password policy, the server should use the result
code KRB5_KPASSWD_POLICY_REJECT.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
3. The Protocol
The service must accept requests on UDP port 464 and TCP port 464 as
well. The protocol consists of a single request message followed by
a single reply message. For UDP transport, each message must be fully
contained in a single UDP packet.
For TCP transport, there is a 4 octet header in network byte order
precedes the message and specifies the length of the message. This
requirement is consistent with the TCP transport header in 1510bis.
Request Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message length | protocol version number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AP_REQ length | AP-REQ data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ KRB-PRIV message /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All 16 bit fields are in network byte order.
message length field: contains the number of bytes in the message
including this field.
protocol version number: contains the hex constant 0x0002 (network
byte order).
AP-REQ length: length of AP-REQ data, in bytes. If the length is zero,
then the last field contains a KRB-ERROR message instead of a KRB-PRIV
message.
AP-REQ data: (see [3]) For a change password/key request, the AP-REQ
message service ticket sname, srealm principal identifier is
kadmin/changepw@REALM where REALM is the realm of the change password
service. The same applies to a set password/key request except the
principal identifier is kadmin/setpw@REALM. The ticket in the AP-REQ
must include a subkey in the Authenticator. To enable setting of
passwords/keys, it is not required that the initial flag be set in the
Kerberos service ticket. The initial flag is required for change requests,
but not for set requests. We have the following definitions:
old passwd initial flag target principal can be
in request? required? distinct from
authenticating principal?
change password: yes yes no
set password: no policy (*) yes
set key: no policy (*) yes
change key: no yes no
policy (*): implementations SHOULD allow administrators to set the
initial flag required for set requests policy to either yes or no.
Clients MUST be able to retry set requests that fail due to error 7
(initial flag required) with an initial ticket. Clients SHOULD NOT
cache service tickets targetted at kadmin/changepw.
KRB-PRIV message (see [3]) This KRB-PRIV message must be generated
using the subkey from the authenticator in the AP-REQ data.
The user-data component of the message consists of the following ASN.1
structure encoded as an OCTET STRING:
ChangePasswdData :: = SEQUENCE {
newpasswdorkeys[0] NewPasswdOrKeys,
targname[1] PrincipalName OPTIONAL,
-- only present in set password/key: the principal
-- which will have its password or keys set. Not
-- present in a set request if the client principal
-- from the ticket is the principal having its
-- passwords or keys set.
targrealm[2] Realm OPTIONAL,
-- only present in set password/key: the realm for
-- the principal which will have its password or
-- keys set. Not present in a set request if the
-- client principal from the ticket is the principal
-- having its passwords or keys set.
}
NewPasswdOrKeys :: = CHOICE {
passwords[0] PasswordSequence, -- change/set passwd
keyseq[1] KeySequences -- change/set key
}
KeySequences :: = SEQUENCE OF KeySequence
KeySequence :: = SEQUENCE {
key[0] EncryptionKey,
salt[1] OCTET STRING OPTIONAL,
salt-type[2] INTEGER OPTIONAL
}
PasswordSequence :: = SEQUENCE {
newpasswd[0] OCTET STRING,
oldpasswd[1] OCTET STRING OPTIONAL
-- oldpasswd always present for change password
-- but not present for set password, set key, or
-- change key
}
The server must verify the AP-REQ message, check whether the client
principal in the ticket is authorized to set or change the password
(either for that principal, or for the principal in the targname
field if present), and decrypt the new password/keys. The server
also checks whether the initial flag is required for this request,
replying with status 0x0007 if it is not set and should be. An
authorization failure is cause to respond with status 0x0005. For
forward compatibility, the server should be prepared to ignore fields
after targrealm in the structure that it does not understand.
The newpasswdorkeys field contains either the new cleartext password
(with the old cleartext password for a change password operation),
or a sequence of encryption keys with their respective salts.
In the cleartext password case, if the old password is sent in the
request, the request MUST be a change password request. If the old
password is not present in the request, the request MUST be a set
password request. The server should apply policy checks to the old
and new password after verifying that the old password is valid.
The server can check validity by obtaining a key from the old
password with a keytype that is present in the KDC database for the
user and comparing the keys for equality. The server then generates
the appropriate keytypes from the password and stores them in the KDC
database. If all goes well, status 0x0000 is returned to the client
in the reply message (see below). For a change password operation,
the initial flag in the service ticket MUST be set.
In the key sequence case, the sequence of keys is sent to the change
or set password service (kadmin/changepw or kadmin/setpw respectively).
For a principal that can act as a server, its preferred keytype should
be sent as the first key in the sequence, but the KDC is not required
to honor this preference. Application servers should use the key
sequence option for changing/setting their keys. The change/set password
services should check that all keys are in the proper format, returning
the KRB5_KPASSWD_MALFORMED error otherwise.
Reply Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message length | protocol version number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AP_REP length | AP-REP data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ KRB-PRIV message /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All 16 bit fields are in network byte order.
message length field: contains the number of bytes in the message
including this field.
protocol version number: contains the hex constant 0x0002 (network
byte order). (The reply message has the same format as in [4]).
AP-REP length: length of AP-REP data, in bytes. If the length is zero,
then the last field contains a KRB-ERROR message instead of a KRB-PRIV
message.
AP-REP data: the AP-REP is the response to the AP-REQ in the request
packet.
KRB-PRIV from [4]: This KRB-PRIV message must be generated using the
subkey in the authenticator in the AP-REQ data.
The server will respond with a KRB-PRIV message unless it cannot
validate the client AP-REQ or KRB-PRIV message, in which case it will
respond with a KRB-ERROR message. NOTE: Unlike change password version
1, the KRB-ERROR message will be sent back without any encapsulation.
The user-data component of the KRB-PRIV message, or e-data component
of the KRB-ERROR message, must consist of the following data.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| result code | result string /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| edata /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
result code (16 bits) (result codes 0-4 are from [4]):
The result code must have one of the following values (network
byte order):
KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not
allowed in a KRB-ERROR message)
KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed
KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in
processing the request (for example,
there is a resource or other problem
causing the request to fail)
KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in
authentication processing
KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft error
in processing the request
KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported
KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required
KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy;
the result string should include a text message to be presented
to the user.
KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist
(only in response to a set password request).
KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence
containing at least one etype that is not supported by the KDC.
The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO
type that specifies the etypes that the KDC supports:
KERB-ETYPE-INFO-ENTRY :: = SEQUENCE {
encryption-type[0] INTEGER,
salt[1] OCTET STRING OPTIONAL -- not sent
}
PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY
The client should retry the request using only etypes (keytypes)
that are contained within the PKERB-ETYPE-INFO structure in the
previous response.
0xFFFF if the request fails for some other reason.
The client must interpret any non-zero result code as a failure.
result string - from [4]:
This field is a UTF-8 encoded string which should be displayed
to the user by the client. Specific reasons for a password
set/change policy failure is one use for this string.
edata: used to convey additional information as defined by the
result code.
4. Acknowledgements
The authors thank Tony Andrea for his input to the document.
5. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[3] J. Kohl, C. Neuman. The Kerberos Network Authentication
Service (V5), Request for Comments 1510.
[4] M. Horowitz. Kerberos Change Password Protocol,
ftp://ds.internic.net/internet-drafts/
draft-ietf-cat-kerb-chg-password-02.txt
6. Expiration Date
This draft expires in October 2000.
7. Authors' Addresses
Jonathan Trostle
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
Email: jtrostle@cisco.com
Mike Swift
1 Microsoft Way
Redmond, WA 98052
Email: mikesw@microsoft.com
John Brezak
1 Microsoft Way
Redmond, WA 98052
Email: jbrezak@microsoft.com
Bill Gossman
Cybersafe Corporation
1605 NW Sammamish Rd.
Issaquah, WA 98027-5378
Email: bill.gossman@cybersafe.com

250
crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-00.txt
View File

@ -1,250 +0,0 @@
INTERNET-DRAFT Ken Hornstein
<draft-ietf-cat-krb-dns-locate-00.txt> NRL
June 21, 1999 Jeffrey Altman
Expires: December 21, 1999 Columbia University
Distributing Kerberos KDC and Realm Information with DNS
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. It is filed as <draft-ietf-
cat-krb-dns-locate-00.txt>, and expires on December 21, 1999. Please
send comments to the authors.
Abstract
Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto-
col [RFC????] describe any mechanism for clients to learn critical
configuration information necessary for proper operation of the pro-
tocol. Such information includes the location of Kerberos key dis-
tribution centers or a mapping between DNS domains and Kerberos
realms.
Current Kerberos implementations generally store such configuration
information in a file on each client machine. Experience has shown
this method of storing configuration information presents problems
with out-of-date information and scaling problems, especially when
Hornstein, Altman [Page 1]
RFC DRAFT June 21, 1999
using cross-realm authentication.
This memo describes a method for using the Domain Name System
[RFC1035] for storing such configuration information. Specifically,
methods for storing KDC location and hostname/domain name to realm
mapping information are discussed.
Overview - KDC location information
KDC location information is to be stored using the DNS SRV RR [RFC
2052]. The format of this RR is as follows:
Service.Proto.Realm TTL Class SRV Priority Weight Port Target
The Service name for Kerberos is always "_kerberos".
The Proto can be either "_udp" or "_tcp". If these records are to be
used, a "_udp" record MUST be included. If the Kerberos implementa-
tion supports TCP transport, a "_tcp" record SHOULD be included.
The Realm is the Kerberos realm that this record corresponds to.
TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
meaning as defined in RFC 2052.
Example - KDC location information
These are DNS records for a Kerberos realm ASDF.COM. It has two Ker-
beros servers, kdc1.asdf.com and kdc2.asdf.com. Queries should be
directed to kdc1.asdf.com first as per the specified priority.
Weights are not used in these records.
_kerberos._udp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com.
_kerberos._udp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com.
Overview - KAdmin location information
Kadmin location information is to be stored using the DNS SRV RR [RFC
2052]. The format of this RR is as follows:
Service.Proto.Realm TTL Class SRV Priority Weight Port Target
The Service name for Kadmin is always "_kadmin".
The Proto can be either "_udp" or "_tcp". If these records are to be
used, a "_tcp" record MUST be included. If the Kadmin implementation
supports UDP transport, a "_udp" record SHOULD be included.
Hornstein, Altman [Page 2]
RFC DRAFT June 21, 1999
The Realm is the Kerberos realm that this record corresponds to.
TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
meaning as defined in RFC 2052.
Example - Kadmin location information
These are DNS records for a Kerberos realm ASDF.COM. It has one Kad-
min server, kdc1.asdf.com.
_kadmin._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com.
Overview - Hostname/domain name to Kerberos realm mapping
Information on the mapping of DNS hostnames and domain names to Ker-
beros realms is stored using DNS TXT records [RFC 1035]. These
records have the following format.
Service.Name TTL Class TXT Realm
The Service field is always "_kerberos", and prefixes all entries of
this type.
The Name is a DNS hostname or domain name. This is explained in
greater detail below.
TTL, Class, and TXT have the standard DNS meaning as defined in RFC
1035.
The Realm is the data for the TXT RR, and consists simply of the Ker-
beros realm that corresponds to the Name specified.
When a Kerberos client wishes to utilize a host-specific service, it
will perform a DNS TXT query, using the hostname in the Name field of
the DNS query. If the record is not found, the first label of the
name is stripped and the query is retried.
Compliant implementations MUST query the full hostname and the most
specific domain name (the hostname with the first label removed).
Compliant implementations SHOULD try stripping all subsequent labels
until a match is found or the Name field is empty.
Example - Hostname/domain name to Kerberos realm mapping
For the previously mentioned ASDF.COM realm and domain, some sample
records might be as follows:
_kerberos.asdf.com. IN TXT "ASDF.COM"
Hornstein, Altman [Page 3]
RFC DRAFT June 21, 1999
_kerberos.mrkserver.asdf.com. IN TXT "MARKETING.ASDF.COM"
_kerberos.salesserver.asdf.com. IN TXT "SALES.ASDF.COM"
Let us suppose that in this case, a Kerberos client wishes to use a
Kerberized service on the host foo.asdf.com. It would first query:
_kerberos.foo.asdf.com. IN TXT
Finding no match, it would then query:
_kerberos.asdf.com. IN TXT
And find an answer of ASDF.COM. This would be the realm that
foo.asdf.com resides in.
If another Kerberos client wishes to use a Kerberized service on the
host salesserver.asdf.com, it would query:
_kerberos.salesserver.asdf.com IN TXT
And find an answer of SALES.ASDF.COM.
Security considerations
As DNS is deployed today, it is an unsecure service. Thus the infor-
mation returned by it cannot be trusted. However, the use of DNS to
store this configuration information does not introduce any new secu-
rity risks to the Kerberos protocol.
Current practice is to use hostnames to indicate KDC hosts (stored in
some implementation-dependent location, but generally a local config
file). These hostnames are vulnerable to the standard set of DNS
attacks (denial of service, spoofed entries, etc). The design of the
Kerberos protocol limits attacks of this sort to denial of service.
However, the use of SRV records does not change this attack in any
way. They have the same vulnerabilities that already exist in the
common practice of using hostnames for KDC locations.
The same holds true for the TXT records used to indicate the domain
name to realm mapping. Current practice is to configure these map-
pings locally. But this again is vulnerable to spoofing via CNAME
records that point to hosts in other domains. This has the same
effect as a spoofed TXT record.
While the described protocol does not introduce any new security
risks to the best of our knowledge, implementations SHOULD provide a
way of specifying this information locally without the use of DNS.
However, to make this feature worthwhile a lack of any configuration
Hornstein, Altman [Page 4]
RFC DRAFT June 21, 1999
information on a client should be interpretted as permission to use
DNS.
Expiration
This Internet-Draft expires on December 21, 1999.
References
[RFC1510]
The Kerberos Network Authentication System; Kohl, Newman; Sep-
tember 1993.
[RFC1035]
Domain Names - Implementation and Specification; Mockapetris;
November 1987
[RFC2052]
A DNS RR for specifying the location of services (DNS SRV); Gul-
brandsen, Vixie; October 1996
Authors' Addresses
Ken Hornstein
US Naval Research Laboratory
Bldg A-49, Room 2
4555 Overlook Avenue
Washington DC 20375 USA
Phone: +1 (202) 404-4765
EMail: kenh@cmf.nrl.navy.mil
Jeffrey Altman
The Kermit Project
Columbia University
612 West 115th Street #716
New York NY 10025-7799 USA
Phone: +1 (212) 854-1344
EMail: jaltman@columbia.edu
Hornstein, Altman [Page 5]

339
crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt
View File

@ -1,339 +0,0 @@
INTERNET-DRAFT Ken Hornstein
<draft-ietf-cat-krb-dns-locate-02.txt> NRL
March 10, 2000 Jeffrey Altman
Expires: September 10, 2000 Columbia University
Distributing Kerberos KDC and Realm Information with DNS
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. It is filed as <draft-ietf-
cat-krb-dns-locate-02.txt>, and expires on September 10, 2000. Please
send comments to the authors.
Abstract
Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto-
col [RFC????] describe any mechanism for clients to learn critical
configuration information necessary for proper operation of the pro-
tocol. Such information includes the location of Kerberos key dis-
tribution centers or a mapping between DNS domains and Kerberos
realms.
Current Kerberos implementations generally store such configuration
information in a file on each client machine. Experience has shown
this method of storing configuration information presents problems
with out-of-date information and scaling problems, especially when
Hornstein, Altman [Page 1]
RFC DRAFT March 10, 2000
using cross-realm authentication.
This memo describes a method for using the Domain Name System
[RFC1035] for storing such configuration information. Specifically,
methods for storing KDC location and hostname/domain name to realm
mapping information are discussed.
DNS vs. Kerberos - Case Sensitivity of Realm Names
In Kerberos, realm names are case sensitive. While it is strongly
encouraged that all realm names be all upper case this recommendation
has not been adopted by all sites. Some sites use all lower case
names and other use mixed case. DNS on the other hand is case insen-
sitive for queries but is case preserving for responses to TXT
queries. Since "MYREALM", "myrealm", and "MyRealm" are all different
it is necessary that the DNS entries be distinguishable.
Since the recommend realm names are all upper case, we will not
require any quoting to be applied to upper case names. If the realm
name contains lower case characters each character is to be quoted by
a '=' character. So "MyRealm" would be represented as "M=yR=e=a=l=m"
and "myrealm" as "=m=y=r=e=a=l=m". If the realm name contains the
'=' character it will be represented as "==".
Overview - KDC location information
KDC location information is to be stored using the DNS SRV RR [RFC
2052]. The format of this RR is as follows:
Service.Proto.Realm TTL Class SRV Priority Weight Port Target
The Service name for Kerberos is always "_kerberos".
The Proto can be either "_udp" or "_tcp". If these records are to be
used, a "_udp" record MUST be included. If the Kerberos implementa-
tion supports TCP transport, a "_tcp" record SHOULD be included.
The Realm is the Kerberos realm that this record corresponds to.
TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
meaning as defined in RFC 2052.
Example - KDC location information
These are DNS records for a Kerberos realm ASDF.COM. It has two Ker-
beros servers, kdc1.asdf.com and kdc2.asdf.com. Queries should be
directed to kdc1.asdf.com first as per the specified priority.
Hornstein, Altman [Page 2]
RFC DRAFT March 10, 2000
Weights are not used in these records.
_kerberos._udp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com.
_kerberos._udp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com.
Overview - Kerberos password changing server location information
Kerberos password changing server [KERB-CHG] location is to be stored
using the DNS SRV RR [RFC 2052]. The format of this RR is as fol-
lows:
Service.Proto.Realm TTL Class SRV Priority Weight Port Target
The Service name for the password server is always "_kpasswd".
The Proto MUST be "_udp".
The Realm is the Kerberos realm that this record corresponds to.
TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
meaning as defined in RFC 2052.
Overview - Kerberos admin server location information
Kerberos admin location information is to be stored using the DNS SRV
RR [RFC 2052]. The format of this RR is as follows:
Service.Proto.Realm TTL Class SRV Priority Weight Port Target
The Service name for the admin server is always "_kerberos-adm".
The Proto can be either "_udp" or "_tcp". If these records are to be
used, a "_tcp" record MUST be included. If the Kerberos admin imple-
mentation supports UDP transport, a "_udp" record SHOULD be included.
The Realm is the Kerberos realm that this record corresponds to.
TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
meaning as defined in RFC 2052.
Note that there is no formal definition of a Kerberos admin protocol,
so the use of this record is optional and implementation-dependent.
Example - Kerberos administrative server location information
These are DNS records for a Kerberos realm ASDF.COM. It has one
administrative server, kdc1.asdf.com.
Hornstein, Altman [Page 3]
RFC DRAFT March 10, 2000
_kerberos-adm._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com.
Overview - Hostname/domain name to Kerberos realm mapping
Information on the mapping of DNS hostnames and domain names to Ker-
beros realms is stored using DNS TXT records [RFC 1035]. These
records have the following format.
Service.Name TTL Class TXT Realm
The Service field is always "_kerberos", and prefixes all entries of
this type.
The Name is a DNS hostname or domain name. This is explained in
greater detail below.
TTL, Class, and TXT have the standard DNS meaning as defined in RFC
1035.
The Realm is the data for the TXT RR, and consists simply of the Ker-
beros realm that corresponds to the Name specified.
When a Kerberos client wishes to utilize a host-specific service, it
will perform a DNS TXT query, using the hostname in the Name field of
the DNS query. If the record is not found, the first label of the
name is stripped and the query is retried.
Compliant implementations MUST query the full hostname and the most
specific domain name (the hostname with the first label removed).
Compliant implementations SHOULD try stripping all subsequent labels
until a match is found or the Name field is empty.
Example - Hostname/domain name to Kerberos realm mapping
For the previously mentioned ASDF.COM realm and domain, some sample
records might be as follows:
_kerberos.asdf.com. IN TXT "ASDF.COM"
_kerberos.mrkserver.asdf.com. IN TXT "MARKETING.ASDF.COM"
_kerberos.salesserver.asdf.com. IN TXT "SALES.ASDF.COM"
Let us suppose that in this case, a Kerberos client wishes to use a
Kerberized service on the host foo.asdf.com. It would first query:
_kerberos.foo.asdf.com. IN TXT
Finding no match, it would then query:
Hornstein, Altman [Page 4]
RFC DRAFT March 10, 2000
_kerberos.asdf.com. IN TXT
And find an answer of ASDF.COM. This would be the realm that
foo.asdf.com resides in.
If another Kerberos client wishes to use a Kerberized service on the
host salesserver.asdf.com, it would query:
_kerberos.salesserver.asdf.com IN TXT
And find an answer of SALES.ASDF.COM.
Security considerations
As DNS is deployed today, it is an unsecure service. Thus the infor-
mation returned by it cannot be trusted.
Current practice for REALM to KDC mapping is to use hostnames to
indicate KDC hosts (stored in some implementation-dependent location,
but generally a local config file). These hostnames are vulnerable
to the standard set of DNS attacks (denial of service, spoofed
entries, etc). The design of the Kerberos protocol limits attacks of
this sort to denial of service. However, the use of SRV records does
not change this attack in any way. They have the same vulnerabili-
ties that already exist in the common practice of using hostnames for
KDC locations.
Current practice for HOSTNAME to REALM mapping is to provide a local
configuration of mappings of hostname or domain name to realm which
are then mapped to KDCs. But this again is vulnerable to spoofing
via CNAME records that point to hosts in other domains. This has the
same effect as when a TXT record is spoofed. In a realm with no
cross-realm trusts this is a DoS attack. However, when cross-realm
trusts are used it is possible to redirect a client to use a comprom-
ised realm.
This is not an exploit of the Kerberos protocol but of the Kerberos
trust model. The same can be done to any application that must
resolve the hostname in order to determine which domain a non-FQDN
belongs to.
Implementations SHOULD provide a way of specifying this information
locally without the use of DNS. However, to make this feature
worthwhile a lack of any configuration information on a client should
be interpretted as permission to use DNS.
Hornstein, Altman [Page 5]
RFC DRAFT March 10, 2000
Expiration
This Internet-Draft expires on September 10, 2000.
References
[RFC1510]
The Kerberos Network Authentication System; Kohl, Newman; Sep-
tember 1993.
[RFC1035]
Domain Names - Implementation and Specification; Mockapetris;
November 1987
[RFC2782]
A DNS RR for specifying the location of services (DNS SRV); Gul-
brandsen, Vixie; Feburary 2000
[KERB-CHG]
Kerberos Change Password Protocol; Horowitz;
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-
password-02.txt
Authors' Addresses
Ken Hornstein
US Naval Research Laboratory
Bldg A-49, Room 2
4555 Overlook Avenue
Washington DC 20375 USA
Phone: +1 (202) 404-4765
EMail: kenh@cmf.nrl.navy.mil
Jeffrey Altman
The Kermit Project
Columbia University
612 West 115th Street #716
New York NY 10025-7799 USA
Phone: +1 (212) 854-1344
EMail: jaltman@columbia.edu
Hornstein, Altman [Page 6]

1333
crypto/heimdal/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt
View File

File diff suppressed because it is too large Load Diff

3415
crypto/heimdal/doc/standardisation/draft-ietf-ftpext-mlst-08.txt
View File

File diff suppressed because it is too large Load Diff

725
crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-00.txt
View File

@ -1,725 +0,0 @@
Kerberos Working Group M. Swift
Internet Draft University of WA
Document: draft-ietf-krb-wg-kerberos-referrals-00.txt J. Brezak
Category: Standards Track Microsoft
J. Trostle
Cisco Systems
K. Raeburn
MIT
February 2001
Generating KDC Referrals to locate Kerberos realms
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 draft documents a new method for a Kerberos Key Distribution
Center (KDC) to respond to client requests for kerberos tickets when
the client does not have detailed configuration information on the
realms of users or services. The KDC will handle requests for
principals in other realms by returning either a referral error or a
cross-realm TGT to another realm on the referral path. The clients
will use this referral information to reach the realm of the target
principal and then receive the ticket.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
3. Introduction
Swift Category - Standards Track 1
KDC Referrals February 2001
Current implementations of the Kerberos AS and TGS protocols, as
defined in RFC 1510 [3], use principal names constructed from a
known user or service name and realm. A service name is typically
constructed from a name of the service and the DNS host name of the
computer that is providing the service. Many existing deployments of
Kerberos use a single Kerberos realm where all users and services
would be using the same realm. However in an environment where there
are multiple trusted Kerberos realms, the client needs to be able to
determine what realm a particular user or service is in before
making an AS or TGS request. Traditionally this requires client
configuration to make this possible.
When having to deal with multiple trusted realms, users are forced
to know what realm they are in before they can obtain a ticket
granting ticket (TGT) with an AS request. However, in many cases the
user would like to use a more familiar name that is not directly
related to the realm of their Kerberos principal name. A good
example of this is an RFC-822 style email name. This document
describes a mechanism that would allow a user to specify a user
principal name that is an alias for the user's Kerberos principal
name. In practice this would be the name that the user specifies to
obtain a TGT from a Kerberos KDC. The user principal name no longer
has a direct relationship with the Kerberos principal or realm. Thus
the administrator is able to move the user's principal to other
realms without the user having to know that it happened.
Once a user has a TGT, they would like to be able to access services
in any trusted Kerberos realm. To do this requires that the client
be able to determine what realm the target service's host is in
before making the TGS request. Current implementations of Kerberos
typically have a table that maps DNS host names to corresponding
Kerberos realms. In order for this to work on the client, each
application canonicalizes the host name of the service by doing a
DNS lookup followed by a reverse lookup using the returned IP
address. The returned primary host name is then used in the
construction of the principal name for the target service. In order
for the correct realm to be added for the target host, the mapping
table [domain_to_realm] is consulted for the realm corresponding to
the DNS host name. The corresponding realm is then used to complete
the target service principal name.
This traditional mechanism requires that each client have very
detailed configuration information about the hosts that are
providing services and their corresponding realms. Having client
side configuration information can be very costly from an
administration point of view - especially if there are many realms
and computers in the environment.
Current implementations of Kerberos also have difficulty with
services on hosts that can have multiple host names (multi-homed
hosts). Traditionally, each host name would need to have a distinct
principal and a corresponding key. An extreme example of this would
be a Web server with multiple host names for each domain that it is
Swift Category - Standards Track 2
KDC Referrals February 2001
supporting. Principal aliases allow multi-homed hosts to have a
single Kerberos principal (with a single key) that can have
identities for each distinct host name. This mechanism allows the
Kerberos client to request a service ticket for the distinct
hostname and allows the KDC to return a ticket for the single
principal that the host is using. This canonical principal name
allows the host to only have to manage a single key for all of the
identities that it supports. In addition, the client only needs to
know the realm of the canonical service name, not all of the
identities.
This draft proposes a solution for these problems and simplifies
administration by minimizing the configuration information needed on
each computer using Kerberos. Specifically it describes a mechanism
to allow the KDC to handle Canonicalization of names, provide for
principal aliases for users and services and provide a mechanism for
the KDC to determine the trusted realm authentication path by being
able to generate referrals to other realms in order to locate
principals.
To rectify these problems, this draft introduces three new kinds of
KDC referrals:
1. AS ticket referrals, in which the client doesn't know which realm
contains a user account.
2. TGS ticket referrals, in which the client doesn't know which
realm contains a server account.
3. Cross realm shortcut referrals, in which the KDC chooses the next
path on a referral chain
4. Realm Organization Model
This draft assumes that the world of principals is arranged on
multiple levels: the realm, the enterprise, and the world. A KDC may
issue tickets for any principal in its realm or cross-realm tickets
for realms with which it has a direct trust relationship. The KDC
also has access to a trusted name service that can resolve any name
from within its enterprise into a realm. This trusted name service
removes the need to use an untrusted DNS lookup for name resolution.
For example, consider the following configuration, where lines
indicate trust relationships:
MS.COM
/ \
/ \
OFFICE.MS.COM NT.MS.COM
In this configuration, all users in the MS.COM enterprise could have
a principal name such as alice@MS.COM, with the same realm portion.
In addition, servers at MS.COM should be able to have DNS host names
from any DNS domain independent of what Kerberos realm their
principal resides in.
Swift Category - Standards Track 3
KDC Referrals February 2001
5. Principal Names
5.1 Service Principal Names
The standard Kerberos model in RFC 1510 [3] gives each Kerberos
principal a single name. However, if a service is reachable by
several addresses, it is useful for a principal to have multiple
names. Consider a service running on a multi-homed machine. Rather
than requiring a separate principal and password for each name it
exports, a single account with multiple names could be used.
Multiple names are also useful for services in that clients need not
perform DNS lookups to resolve a host name into a full DNS address.
Instead, the service may have a name for each of its supported host
names, including its IP address. Nonetheless, it is still convenient
for the service to not have to be aware of all these names. Thus a
new name may be added to DNS for a service by updating DNS and the
KDC database without having to notify the service. In addition, it
implies that these aliases are globally unique: they do not include
a specifier dictating what realm contains the principal. Thus, an
alias for a server is of the form "class/instance/name" and may be
transmitted as any name type.
5.2 Client Principal Names
Similarly, a client account may also have multiple principal names.
More useful, though, is a globally unique name that allows
unification of email and security principal names. For example, all
users at MS may have a client principal name of the form
"joe@MS.COM" even though the principals are contained in multiple
realms. This global name is again an alias for the true client
principal name, which is indicates what realm contains the
principal. Thus, accounts "alice" in the realm ntdev.MS.COM and
"bob" in office.MS.COM may logon as "alice@MS.COM" and "bob@MS.COM".
This requires a new client principal name type, as the AS-REQ
message only contains a single realm field, and the realm portion of
this name doesn't correspond to any Kerberos realm. Thus, the entire
name "alice@MS.COM" is transmitted in the client name field of the
AS-REQ message, with a name type of KRB-NT-ENTERPRISE-PRINCIPAL.
KRB-NT-ENTERPRISE-PRINCIPAL 10
5.3 Name Canonicalization
In order to support name aliases, the Kerberos client must
explicitly request the name-canonicalization KDC option (bit 15) in
the ticket flags for the TGS-REQ. This flag indicates to the KDC
that the client is prepared to receive a reply with a different
client or server principal name than the request. Thus, the
KDCOptions types is redefined as:
KDCOptions ::= BIT STRING {
Swift Category - Standards Track 4
KDC Referrals February 2001
reserved(0),
forwardable(1),
forwarded(2),
proxiable(3),
proxy(4),
allow-postdate(5),
postdated(6),
unused7(7),
renewable(8),
unused9(9),
unused10(10),
unused11(11),
name-canonicalize(15),
renewable-ok(27),
enc-tkt-in-skey(28),
renew(30),
validate(31)
}
6. Client Referrals
The simplest form of ticket referral is for a user requesting a
ticket using an AS-REQ. In this case, the client machine will send
the AS request to a convenient trusted realm, either the realm of
the client machine or the realm of the client name. In the case of
the name Alice@MS.COM, the client may optimistically choose to send
the request to MS.COM.
The client will send the string "alice@MS.COM" in the client
principal name field using the KRB-NT-ENTERPRISE-PRINCIPAL name type
with the crealm set to MS.COM. The KDC will try to lookup the name
in its local account database. If the account is present in the
crealm of the request, it MUST return a KDC reply structure with the
appropriate ticket. If the account is not present in the crealm
specified in the request and the name-canonicalize flag in the
KDCoptions is set, the KDC will try to lookup the entire name,
Alice@MS.COM, using a name service. If this lookup is unsuccessful,
it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup
is successful, it MUST return an error KDC_ERR_WRONG_REALM (0x44)
and in the error message the cname and crealm field MUST contain the
client name and the true realm of the client. If the KDC contains
the account locally, it MUST return a normal ticket. The client name
and realm portions of the ticket and KDC reply message MUST be the
client's true name in the realm, not the globally unique name.
If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
new AS request with the same client principal name used to generate
the first referral to the realm specified by the crealm field of the
kerberos error message from the first request. This request MUST
produce a valid AS response with a ticket for the canonical user
name. The ticket MUST also include the ticket extension containing
the TE-REFERRAL-DATA with the referred-names set to the name from
Swift Category - Standards Track 5
KDC Referrals February 2001
the AS request. Any other error or referral will terminate the
request and result in a failed AS request.
7. Server Referrals
The server referral mechanism is a bit more complex than the client
referral mechanism. The primary problem is that the KDC must return
a referral ticket rather than an error message, so it will include
in the TGS response information about what realm contains the
service. This is done by returning information about the server name
in the pre-auth data field of the KDC reply.
If the KDC resolves the server principal name into a principal in
its realm, it may return a normal ticket. If the name-canonicalize
flag in the KDCoptions is not set, then the KDC MUST only look up
the name as a normal principal name. Otherwise, it MUST search all
aliases as well. The server principal name in both the ticket and
the KDC reply MUST be the true server principal name instead of one
of the aliases. This frees the application server from needing to
know about all its aliases.
If the name-canonicalize flag in the KDCoptions is set and the KDC
doesn't find the principal locally, the KDC can return a cross-realm
ticket granting ticket to the next hop on the trust path towards a
realm that may be able to resolve the principal name.
If the KDC can determine the service principal's realm, it can
return the server realm as ticket extension data. The ticket
extension MUST be encrypted using the session key from the ticket,
and the same etype as is used to protect the TGS reply body.
The data itself is an ASN.1 encoded structure containing the
server's realm, and if known, canonical principal name and alias
names. The first name in the sequence is the canonical principal
name.
TE-REFERRAL-INFO 20
TE-REFERRAL-DATA ::= SEQUENCE {
referred-server-realm[0] KERB-REALM
referred-names[1] SEQUENCE OF
PrincipalNames OPTIONAL
}
The client can use this information to request a chain of cross-
realm ticket granting tickets until it reaches the realm of the
server, and can then expect to receive a valid service ticket.
In order to facilitate cross-realm interoperability, a client SHOULD
NOT send short names in TGS requests to the KDC. A short name is
defined as a Kerberos name that includes a DNS name that is not
fully qualified. The client MAY use forward DNS lookups to obtain
Swift Category - Standards Track 6
KDC Referrals February 2001
the long name that corresponds to the user entered short name (the
short name will be a prefix of the corresponding long name).
The client may use the referred-names field to tell if it already
has a ticket to the server in its ticket cache.
The client can use this information to request a chain of cross-
realm ticket granting tickets until it reaches the realm of the
server, and can then expect to receive a valid service ticket.
However an implementation should limit the number of referrals that
it processes to avoid infinite referral loops. A suggested limit is
5 referrals before giving up.
8. Cross Realm Routing
The current Kerberos protocol requires the client to explicitly
request a cross-realm TGT for each pair of realms on a referral
chain. As a result, the client machines need to be aware of the
trust hierarchy and of any short-cut trusts (those that aren't
parent-child trusts). This requires more configurations on the
client. Instead, the client should be able to request a TGT to the
target realm from each realm on the route. The KDC will determine
the best path for the client and return a cross-realm TGT. The
client has to be aware that a request for a cross-realm TGT may
return a TGT for a realm different from the one requested.
9. Security Considerations
The original Kerberos specification stated that the server principal
name in the KDC reply was the same as the server name in the
request. These protocol changes break that assumption, so the client
may be vulnerable to a denial of service attack by an attacker that
replays replies from previous requests. It can verify that the
request was one of its own by checking the client-address field or
authtime field, though, so the damage is limited and detectable.
For the AS exchange case, it is important that the logon mechanism
not trust a name that has not been used to authenticate the user.
For example, the name that the user enters as part of a logon
exchange may not be the name that the user authenticates as, given
that the KDC_ERR_WRONG_REALM error may have been returned. The
relevant Kerberos naming information for logon (if any), is the
client name and client realm in the service ticket targeted at the
workstation that was obtained using the user's initial TGT.
How the client name and client realm is mapped into a local account
for logon is a local matter, but the client logon mechanism MUST use
additional information such as the client realm and/or authorization
attributes from the service ticket presented to the workstation by
the user, when mapping the logon credentials to a local account on
the workstation.
10. Discussion
Swift Category - Standards Track 7
KDC Referrals February 2001
This section contains issues and suggestions that need to be
incorporated into this draft. From Ken Raeburn [raeburn@mit.edu]:
1) No means to do name canonicalization if you're not
authenticating. Is it okay to require credentials in order to do
canonicalization? If so, how about this: Send a TGS_REQ for the
service name you have. If you get back a TGS_REP for a service,
great; pull out the name and throw out the credentials. If you
get back a TGS_REP for a TGT service, ask again in the specified
realm. If you get back a KRB_ERROR because policy prohibits you
from authenticating to that service, we can add to the
specification that the {realm,sname} in the KRB_ERROR must be the
canonical name, and the checksum must be used. As long as the
checksum is present, it's still a secure exchange with the KDC.
If we have to be able to do name canonicalization without any
sort of credentials, either client-side (tickets) or server-side
(tickets automatically acquired via service key), I think we just
lose. But maybe GSSAPI should be changed if that's the case.
2) Can't refer to another realm and specify a different service name
to give to that realm's KDC. The local KDC can tell you a
different service name or a different realm name, but not both.
This comes up in the "gnuftp.raeburn.org CNAME ftp.gnu.org" type
of case I've mentioned.
Except ... the KDC-REP structure includes padata and ticket
extensions fields that are extensible. We could add a required
value to one of them -- perhaps only in the case where you return
a TGT when not asked -- that contains signed information about
the principal name to ask for in the other realm. (It would have
to be required, otherwise a man-in-the-middle could make it go
away.) Signing would be done using the session key for the TGS.
3) Secure canonicalization of service name in AS_REQ. If the
response is an AS_REP, we need a way to tell that the altered
server name wasn't a result of a MITM attack on the AS_REQ
message. Again, the KDC-REP extensible fields could have a new
required value added when name canonicalization happens,
indicating what the original principal name (in the AS_REQ
message) was, and signed using the same key as protects the
AS_REP. If it doesn't match what the client requested, the
messages were altered in transit.
4) Client name needs referral to another realm, and server name
needs canonicalization of some sort. The above fixes wouldn't
work for this case, and I'm not even sure which KDC should be
doing the canonicalization anyways.
The other-principal-name datum would probably look something like:
Swift Category - Standards Track 8
KDC Referrals February 2001
PrincipalAndNonce ::= SEQUENCE {
name[0] PrincipalName,
nonce[1] INTEGER -- copied from KDC_REQ
}
SignedPrincipal ::= SEQUENCE {
name-and-nonce[0] PrincipalAndNonce,
cksum[1] Checksum
}
{PA,TE}-ORIGINAL-SERVER-PRINCIPAL ::= SignedPrincipal
{PA,TE}-REMOTE-SERVER-PRINCIPAL ::= SignedPrincipal
with the checksum computed over the encoding of the 'name-and-nonce'
field, and appropriate PA- or TE- numbers assigned. I don't have a
strong opinion on whether it'd be a pa-data or ticket extension;
conceptually it seems like an abuse of either, but, well, I think
I'd rather abuse them than leave the facility both in and
inadequate.
The nonce is needed because multiple exchanges may be made with the
same key, and these extension fields aren't packed in with the other
encrypted data in the same response, so a MITM could pick apart
multiple messages and mix-and-match components. (In a TGS_REQ
exchange, a subsession key would help, but it's not required.)
The extension field would be required to prevent a MITM from
discarding the field from a response; a flag bit in a protected part
of the message (probably in 'flags' in EncKDCRepPart) could also let
us know of a cases where the information can be omitted, namely,
when no name change is done. Perhaps the bit should be set to
indicate that a name change *was* done, and clear if it wasn't,
making the no-change case more directly compatible with RFC1510.
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 Kohl, J., Neuman, C., "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993
12. Author's Addresses
Michael Swift
University of Washington
Seattle, Washington
Email: mikesw@cs.washington.edu
John Brezak
Swift Category - Standards Track 9
KDC Referrals February 2001
Microsoft
One Microsoft Way
Redmond, Washington
Email: jbrezak@Microsoft.com
Jonathan Trostle
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
Email: jtrostle@cisco.com
Kenneth Raeburn
Massachusetts Institute of Technology 77
Massachusetts Avenue
Cambridge, Massachusetts 02139
Email: raeburn@mit.edu
Swift Category - Standards Track 10
KDC Referrals February 2001
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."
Swift Category - Standards Track 11

339
crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt
View File

@ -1,339 +0,0 @@
INTERNET-DRAFT Ken Hornstein
<draft-ietf-krb-wg-krb-dns-locate-02.txt> NRL
February 28, 2001 Jeffrey Altman
Expires: August 28, 2001 Columbia University
Distributing Kerberos KDC and Realm Information with DNS
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. It is filed as <draft-ietf-
krb-wg-krb-dns-locate-02.txt>, and expires on August 28, 2001.
Please send comments to the authors.
Abstract
Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto-
col [RFC????] describe any mechanism for clients to learn critical
configuration information necessary for proper operation of the pro-
tocol. Such information includes the location of Kerberos key dis-
tribution centers or a mapping between DNS domains and Kerberos
realms.
Current Kerberos implementations generally store such configuration
information in a file on each client machine. Experience has shown
this method of storing configuration information presents problems
with out-of-date information and scaling problems, especially when
Hornstein, Altman [Page 1]
RFC DRAFT February 28, 2001
using cross-realm authentication.
This memo describes a method for using the Domain Name System
[RFC1035] for storing such configuration information. Specifically,
methods for storing KDC location and hostname/domain name to realm
mapping information are discussed.
DNS vs. Kerberos - Case Sensitivity of Realm Names
In Kerberos, realm names are case sensitive. While it is strongly
encouraged that all realm names be all upper case this recommendation
has not been adopted by all sites. Some sites use all lower case
names and other use mixed case. DNS on the other hand is case insen-
sitive for queries but is case preserving for responses to TXT
queries. Since "MYREALM", "myrealm", and "MyRealm" are all different
it is necessary that only one of the possible combinations of upper
and lower case characters be used. This restriction may be lifted in
the future as the DNS naming scheme is expanded to support non-ASCII
names.
Overview - KDC location information
KDC location information is to be stored using the DNS SRV RR [RFC
2052]. The format of this RR is as follows:
Service.Proto.Realm TTL Class SRV Priority Weight Port Target
The Service name for Kerberos is always "_kerberos".
The Proto can be either "_udp" or "_tcp". If these records are to be
used, a "_udp" record MUST be included. If the Kerberos implementa-
tion supports TCP transport, a "_tcp" record SHOULD be included.
The Realm is the Kerberos realm that this record corresponds to.
TTL, Class, SRV, Priority, Weight, and Target have the standard mean-
ing as defined in RFC 2052.
As per RFC 2052 the Port number should be the value assigned to "ker-
beros" by the Internet Assigned Number Authority (88).
Example - KDC location information
These are DNS records for a Kerberos realm ASDF.COM. It has two Ker-
beros servers, kdc1.asdf.com and kdc2.asdf.com. Queries should be
directed to kdc1.asdf.com first as per the specified priority.
Weights are not used in these records.
Hornstein, Altman [Page 2]
RFC DRAFT February 28, 2001
_kerberos._udp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com.
_kerberos._udp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com.
Overview - Kerberos password changing server location information
Kerberos password changing server [KERB-CHG] location is to be stored
using the DNS SRV RR [RFC 2052]. The format of this RR is as fol-
lows:
Service.Proto.Realm TTL Class SRV Priority Weight Port Target
The Service name for the password server is always "_kpasswd".
The Proto MUST be "_udp".
The Realm is the Kerberos realm that this record corresponds to.
TTL, Class, SRV, Priority, Weight, and Target have the standard mean-
ing as defined in RFC 2052.
As per RFC 2052 the Port number should be the value assigned to
"kpasswd" by the Internet Assigned Number Authority (464).
Overview - Kerberos admin server location information
Kerberos admin location information is to be stored using the DNS SRV
RR [RFC 2052]. The format of this RR is as follows:
Service.Proto.Realm TTL Class SRV Priority Weight Port Target
The Service name for the admin server is always "_kerberos-adm".
The Proto can be either "_udp" or "_tcp". If these records are to be
used, a "_tcp" record MUST be included. If the Kerberos admin imple-
mentation supports UDP transport, a "_udp" record SHOULD be included.
The Realm is the Kerberos realm that this record corresponds to.
TTL, Class, SRV, Priority, Weight, and Target have the standard mean-
ing as defined in RFC 2052.
As per RFC 2052 the Port number should be the value assigned to
"kerberos-adm" by the Internet Assigned Number Authority (749).
Note that there is no formal definition of a Kerberos admin protocol,
so the use of this record is optional and implementation-dependent.
Hornstein, Altman [Page 3]
RFC DRAFT February 28, 2001
Example - Kerberos administrative server location information
These are DNS records for a Kerberos realm ASDF.COM. It has one
administrative server, kdc1.asdf.com.
_kerberos-adm._tcp.ASDF.COM. IN SRV 0 0 749 kdc1.asdf.com.
Overview - Hostname/domain name to Kerberos realm mapping
Information on the mapping of DNS hostnames and domain names to Ker-
beros realms is stored using DNS TXT records [RFC 1035]. These
records have the following format.
Service.Name TTL Class TXT Realm
The Service field is always "_kerberos", and prefixes all entries of
this type.
The Name is a DNS hostname or domain name. This is explained in
greater detail below.
TTL, Class, and TXT have the standard DNS meaning as defined in RFC
1035.
The Realm is the data for the TXT RR, and consists simply of the Ker-
beros realm that corresponds to the Name specified.
When a Kerberos client wishes to utilize a host-specific service, it
will perform a DNS TXT query, using the hostname in the Name field of
the DNS query. If the record is not found, the first label of the
name is stripped and the query is retried.
Compliant implementations MUST query the full hostname and the most
specific domain name (the hostname with the first label removed).
Compliant implementations SHOULD try stripping all subsequent labels
until a match is found or the Name field is empty.
Example - Hostname/domain name to Kerberos realm mapping
For the previously mentioned ASDF.COM realm and domain, some sample
records might be as follows:
_kerberos.asdf.com. IN TXT "ASDF.COM"
_kerberos.mrkserver.asdf.com. IN TXT "MARKETING.ASDF.COM"
_kerberos.salesserver.asdf.com. IN TXT "SALES.ASDF.COM"
Let us suppose that in this case, a Kerberos client wishes to use a
Kerberized service on the host foo.asdf.com. It would first query:
Hornstein, Altman [Page 4]
RFC DRAFT February 28, 2001
_kerberos.foo.asdf.com. IN TXT
Finding no match, it would then query:
_kerberos.asdf.com. IN TXT
And find an answer of ASDF.COM. This would be the realm that
foo.asdf.com resides in.
If another Kerberos client wishes to use a Kerberized service on the
host salesserver.asdf.com, it would query:
_kerberos.salesserver.asdf.com IN TXT
And find an answer of SALES.ASDF.COM.
Security considerations
As DNS is deployed today, it is an unsecure service. Thus the infor-
mation returned by it cannot be trusted.
Current practice for REALM to KDC mapping is to use hostnames to
indicate KDC hosts (stored in some implementation-dependent location,
but generally a local config file). These hostnames are vulnerable
to the standard set of DNS attacks (denial of service, spoofed
entries, etc). The design of the Kerberos protocol limits attacks of
this sort to denial of service. However, the use of SRV records does
not change this attack in any way. They have the same vulnerabili-
ties that already exist in the common practice of using hostnames for
KDC locations.
Current practice for HOSTNAME to REALM mapping is to provide a local
configuration of mappings of hostname or domain name to realm which
are then mapped to KDCs. But this again is vulnerable to spoofing
via CNAME records that point to hosts in other domains. This has the
same effect as when a TXT record is spoofed. In a realm with no
cross-realm trusts this is a DoS attack. However, when cross-realm
trusts are used it is possible to redirect a client to use a comprom-
ised realm.
This is not an exploit of the Kerberos protocol but of the Kerberos
trust model. The same can be done to any application that must
resolve the hostname in order to determine which domain a non-FQDN
belongs to.
Implementations SHOULD provide a way of specifying this information
locally without the use of DNS. However, to make this feature
worthwhile a lack of any configuration information on a client should
Hornstein, Altman [Page 5]
RFC DRAFT February 28, 2001
be interpretted as permission to use DNS.
Expiration
This Internet-Draft expires on August 28, 2001.
References
[RFC1510]
The Kerberos Network Authentication System; Kohl, Newman; Sep-
tember 1993.
[RFC1035]
Domain Names - Implementation and Specification; Mockapetris;
November 1987
[RFC2782]
A DNS RR for specifying the location of services (DNS SRV); Gul-
brandsen, Vixie; Feburary 2000
[KERB-CHG]
Kerberos Change Password Protocol; Horowitz;
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-
password-02.txt
Authors' Addresses
Ken Hornstein
US Naval Research Laboratory
Bldg A-49, Room 2
4555 Overlook Avenue
Washington DC 20375 USA
Phone: +1 (202) 404-4765
EMail: kenh@cmf.nrl.navy.mil
Jeffrey Altman
The Kermit Project
Columbia University
612 West 115th Street #716
New York NY 10025-7799 USA
Phone: +1 (212) 854-1344
EMail: jaltman@columbia.edu
Hornstein, Altman [Page 6]

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

@ -1,281 +0,0 @@
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."

395
crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt
View File

@ -1,395 +0,0 @@
Kerberos Working Group K. Raeburn
Category: Informational MIT
Document: draft-raeburn-krb-gssapi-krb5-3des-01.txt November 24, 2000
Triple-DES Support for the Kerberos 5 GSSAPI Mechanism
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. Internet-Drafts are
draft documents valid for a maximum of six months and may be updated,
replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5] specifically
enumerates encryption and checksum types, independently of how such
schemes may be used in Kerberos. In the long run, a new Kerberos-
based mechanism, which does not require separately enumerating for
the GSSAPI mechanism each of the various encryption types defined by
Kerberos, is probably a better approach. Various people have
expressed interest in designing one, but the work has not yet been
completed.
The MIT Kerberos 5 release version 1.2 includes support for triple-
DES with key derivation [KrbRev]. Recent work by the EFF [EFF] has
demonstrated the vulnerability of single-DES mechanisms to brute-
force attacks by sufficiently motivated and well-funded parties. So,
in the interest of providing increased security in the near term, MIT
is adding support for triple-DES to the existing mechanism
implementation we ship, as an interim measure.
Raeburn [Page 1]
INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000
2. New Algorithm Identifiers
One new sealing algorithm is defined, for use in Wrap tokens.
+--------------------------------------------------------------------+
| name octet values |
+--------------------------------------------------------------------+
| DES3-KD 02 00 |
+--------------------------------------------------------------------+
This algorithm uses triple-DES with key derivation, with a usage
value KG_USAGE_SEAL. (Unlike the EncryptedData definition in
[KrbRev], no integrity protection is needed, so this is "raw" triple-
DES, with no checksum attached to the encrypted data.) Padding is
still to 8-byte multiples, and the IV for encrypting application data
is zero.
One new signing algorithm is defined, for use in MIC, Wrap, and
Delete tokens.
+--------------------------------------------------------------------+
| name octet values |
+--------------------------------------------------------------------+
| HMAC SHA1 DES3-KD 04 00 |
+--------------------------------------------------------------------+
This algorithm generates an HMAC using SHA-1 and a derived DES3 key
with usage KG_USAGE_SIGN, as described in [KrbRev].
[N.B.: The current [KrbRev] description refers to expired I-Ds from
Marc Horowitz. The text in [KrbRev] may be inadequate to produce an
interoperable implementation.]
The checksum size for this algorithm is 20 octets. See section 4.3
below for the use of checksum lengths of other than eight bytes.
Raeburn [Page 2]
INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000
3. Key Derivation
For purposes of key derivation, we add three new usage values to the
list defined in [KrbRev]; one for signing messages, one for sealing
messages, and one for encrypting sequence numbers:
+--------------------------------------------------------------------+
| name value |
+--------------------------------------------------------------------+
| KG_USAGE_SEAL 22 |
| KG_USAGE_SIGN 23 |
| KG_USAGE_SEQ 24 |
+--------------------------------------------------------------------+
4. Adjustments to Previous Definitions
4.1. Quality of Protection
The GSSAPI specification [GSSAPI] says that a zero QOP value
indicates the "default". The original specification for the Kerberos
5 mechanism says that a zero QOP value (or a QOP value with the
appropriate bits clear) means DES encryption.
Rather than forcing the use of plain DES when the application doesn't
use mechanism-specific QOP values, we redefine the explicit DES QOP
value as a non-zero value, and define a triple-DES value as well.
Then a zero value continues to imply the default, which would be
triple-DES protection when given a triple-DES session key.
Our values are:
+--------------------------------------------------------------------+
| name value meaning |
+--------------------------------------------------------------------+
| GSS_KRB5_INTEG_C_QOP_HMAC_SHA1 0x0004 SHA-1 HMAC, using |
| key derivation |
| |
| GSS_KRB5_CONF_C_QOP_DES 0x0100 plain DES encryption |
| |
| GSS_KRB5_CONF_C_QOP_DES3_KD 0x0200 triple-DES with key |
| derivation |
+--------------------------------------------------------------------+
Rather than attempt to specify a generic mechanism for deriving a key
of one type given a key of another type, and evaluate the security
implications of using a short key to generate a longer key to satisfy
the requested quality of protection, our implementation will simply
Raeburn [Page 3]
INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000
return an error if the nonzero QOP value specified does not
correspond to the session key type.
4.2. MIC Sequence Number Encryption
The sequence numbers are encrypted in the context key (as defined in
[GSSAPI-KRB5] -- this will be either the Kerberos session key or
asubkey provided by the context initiator), using whatever encryption
system is designated by the type of that context key. The IV is
formed from the first N bytes of the SGN_CKSUM field, where N is the
number of bytes needed for the IV. (With all algorithms described
here and in [GSSAPI-KRB5], the checksum is at least as large as the
IV.)
4.3. Message Layout
Both MIC and Wrap tokens, as defined in [GSSAPI-KRB5], contain an
checksum field SGN_CKSUM. In [GSSAPI-KRB5], this field was specified
as being 8 bytes long. We now change this size to be "defined by the
checksum algorithm", and retroactively amend the descriptions of all
the checksum algorithms described in [GSSAPI-KRB5] to explicitly
specify 8-byte output. Application data continues to immediately
follow the checksum field in the Wrap token.
The revised message descriptions are thus:
MIC token:
Byte # Name Description
----------------------------------------------------------------------
0..1 TOK_ID Identification field.
2..3 SGN_ALG Integrity algorithm indicator.
4..7 Filler Contains ff ff ff ff
8..15 SND_SEQ Sequence number field.
16..s+15 SGN_CKSUM Checksum of "to-be-signed
data", calculated according to
algorithm specified in SGN_ALG
field.
Raeburn [Page 4]
INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000
Wrap token:
Byte # Name Description
----------------------------------------------------------------------
0..1 TOK_ID Identification field. Tokens
emitted by GSS_Wrap() contain the
hex value 02 01 in this field.
2..3 SGN_ALG Checksum algorithm indicator.
4..5 SEAL_ALG Sealing algorithm indicator.
6..7 Filler Contains ff ff
8..15 SND_SEQ Encrypted sequence number field.
16..s+15 SGN_CKSUM Checksum of plaintext padded data,
calculated according to algorithm
specified in SGN_ALG field.
s+16..last Data encrypted or plaintext padded data
Where "s" indicates the size of the checksum.
As indicated above in section 2, we define the HMAC SHA1 DES3-KD
checksum algorithm to produce a 20-byte output, so encrypted data
begins at byte 36.
5. Backwards Compatibility Considerations
The context initiator should request of the KDC credentials using
session-key cryptosystem types supported by that implementation; if
the only types returned by the KDC are not supported by the mechanism
implementation, it should indicate a failure. This may seem obvious,
but early implementations of both Kerberos and the GSSAPI Kerberos
mechanism supported only DES keys, so the cryptosystem compatibility
question was easy to overlook.
Under the current mechanism, no negotiation of algorithm types
occurs, so server-side (acceptor) implementations cannot request that
clients not use algorithm types not understood by the server.
However, administration of the server's Kerberos data (e.g., the
service key) has to be done in communication with the KDC, and it is
from the KDC that the client will request credentials. The KDC could
therefore be tasked with limiting session keys for a given service to
types actually supported by the Kerberos and GSSAPI software on the
server.
This does have a drawback for cases where a service principal name is
used both for GSSAPI-based and non-GSSAPI-based communication (most
notably the "host" service key), if the GSSAPI implementation does
not understand triple-DES but the Kerberos implementation does. It
means that triple-DES session keys cannot be issued for that service
Raeburn [Page 5]
INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000
principal, which keeps the protection of non-GSSAPI services weaker
than necessary.
It would also be possible to have clients attempt to get single-DES
session keys before trying to get triple-DES session keys, and have
the KDC refuse to issue the single-DES keys only for the most
critical of services, for which single-DES protection is considered
inadequate. However, that would eliminate the possibility of
connecting with the more secure cryptosystem to any service that can
be accessed with the weaker cryptosystem.
For MIT's 1.2 release, we chose to go with the former approach,
putting the burden on the KDC administration and gaining the best
protection possible for GSSAPI services, possibly at the cost of
weaker protection of non-GSSAPI Kerberos services running earlier
versions of the software.
6. Security Considerations
Various tradeoffs arise regarding the mixing of new and old software,
or GSSAPI-based and non-GSSAPI Kerberos authentication. They are
discussed in section 5.
7. References
[EFF] Electronic Frontier Foundation, "Cracking DES: Secrets of
Encryption Research, Wiretap Politics, and Chip Design", O'Reilly &
Associates, Inc., May, 1998.
[GSSAPI] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January, 2000.
[GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June, 1996.
[KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
Authentication Service (V5)", draft-ietf-cat-kerberos-
revisions-06.txt, July 4, 2000.
8. Author's Address
Kenneth Raeburn Massachusetts Institute of Technology 77
Massachusetts Avenue Cambridge, MA 02139
9. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
Raeburn [Page 6]
INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
10. Document Change History
>From -00 to -01:
Converted master to GNU troff and tbl, rewriting tables in the
process.
Specify informational category only. Modify some text to emphasize
that this document intends to describe MIT's extensions.
Point out that while EncryptedData for 3des-kd includes a checksum,
DES3-KD GSS encryption does not.
Shorten backwards-compatibility descriptions a little.
Submit to Kerberos working group rather than CAT.
Raeburn [Page 7]

929
crypto/heimdal/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt
View File

@ -1,929 +0,0 @@
DHC Working Group S. Medvinsky
Internet Draft Motorola
Document: <draft-smedvinsky-dhc-kerbauth-01.txt>
Category: Standards Track P.Lalwaney
Expires: January 2001 Nokia
July 2000
Kerberos V Authentication Mode for Uninitialized Clients
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The distribution of this memo is unlimited. It is filed as <draft-
smedvinsky-dhc-kerbauth-01.txt>, and expires January 2001. Please
send comments to the authors.
1. Abstract
The Dynamic Host Configuration Protocol (DHCP) [1] includes an
option that allows authentication of all DHCP messages, as specified
in [2]. This document specifies a DHCP authentication mode based on
Kerberos V tickets. This provides mutual authentication between a
DHCP client and server, as well as authentication of all DHCP
messages.
This document specifies Kerberos message exchanges between an
uninitialized client and the KDC (Key Distribution Center) using an
IAKERB proxy [7] so that the Kerberos key management phase is
decoupled from, and precedes the address allocation and network
configuration phase that uses the DHCP authentication option. In
order to make use of the IAKERB proxy, this document specifies a
transport mechanism that works with an uninitialized client (i.e. a
Kerberos V Authentication Mode for Uninitialized Clients July 2000
client without an assigned IP address). In addition, the document
specifies the format of the Kerberos authenticator to be used with
the DHCP authentication option.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119.
3. Introduction
3.1 Terminology
o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain configuration
parameters such as a network address.
o "DHCP server"
A DHCP server is an Internet host that returns configuration
parameters to DHCP clients.
O "Ticket"
A Kerberos term for a record that helps a client authenticate itself
to a server; it contains the client's identity, a session key, a
timestamp, and other information, all sealed using the server's
secret key. It only serves to authenticate a client when presented
along with a fresh Authenticator.
o "Key Distribution Center"
Key Distribution Center, a network service that supplies tickets and
temporary session keys; or an instance of that service or the host
on which it runs. The KDC services both initial ticket and Ticket-
Granting Ticket (TGT) requests. The initial ticket portion is
sometimes referred to as the Authentication Server (or service. The
Ticket-Granting Ticket portion is sometimes referred to as the
Ticket-Granting Server (or service).
o "Realm"
A Kerberos administrative domain that represents a group of
principals registered at a KDC. A single KDC may be responsible for
one or more realms. A fully qualified principal name includes a
realm name along with a principal name unique within that realm.
3.2 Protocol Overview
S. Medvinsky, P. Lalwaney -2-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
DHCP as defined in [1] defines the protocol exchanges for a client
to obtain its IP address and network configuration information from
a DHCP Server. Kerberos V5 as described in [6] defines the protocol
and message exchanges to mutually authenticate two parties. It is
our goal to provide authentication support for DHCP using Kerberos.
This implies that the Kerberos key management exchange has to take
place before a client gets its IP address from the DHCP Server.
Kerberos assumes that the client has a network address and can
contact the Key Distribution Center to obtain its credentials for
authenticated communication with an application server.
In this specification we utilize the key exchange using an IAKERB
proxy described in [7]. This does not require any changes to either
the IAKERB or the Kerberos V5 specification. This document also
specifies a particular transport that allows an uninitialized client
to contact an IAKERB proxy.
The Kerberos ticket returned from the key management exchange
discussed in Section 5 of this document is passed to the DHCP Server
inside the DHCP authentication option with the new Kerberos
authenticator type. This is described in Section 6 of this draft.
3.3 Related Work
A prior Internet Draft [3] outlined the use of Kerberos-based
authentication for DHCP. The proposal tightly coupled the Kerberos
client state machines and the DHCP client state machines. As a
result, the Kerberos key management messages were carried in DHCP
messages, along with the Kerberos authenticators. In addition, the
first DHCP message exchange (request, offer) is not authenticated.
We propose a protocol exchange where Kerberos key management is
decoupled from and precedes authenticated DHCP exchanges. This
implies that the Kerberos ticket returned in the initial key
management exchange could be used to authenticate servers assigning
addresses by non-DHCP address assignment mechanisms like RSIP [4]
and for service specific parameter provisioning mechanisms using SLP
[5].
S. Medvinsky, P. Lalwaney -3-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
4. System Architecture
Client
-------- --------
| | 5.Authenticated DHCP | |
| DHCP |<------------------------>| DHCP |
| client | | server |
| | | |
| | | |
|Kerberos| | |
| Client | | |
-------- --------
^
|
|
|
| -------
------------------------------>| |
Kerberos Key Mgmt | Proxy |
messages: | |
1. AS Request / 2.AS Reply -------
3. TGS Request / 4.TGS Reply ^
| Kerberos
| Key Mgmt messages
v (1, 2, 3, 4)
--------
| |
| KDC |
| |
--------
Figure 1: System blocks and message interactions between them
In this architecture, the DHCP client obtains a Kerberos ticket from
the Key Distribution Center (KDC) using standard Kerberos messages,
as specified in [6]. The client, however, contacts the KDC via a
proxy server, according to the IAKERB mechanism, described in [7].
The are several reasons why a client has to go through this proxy in
order to contact the KDC:
a)The client may not know the host address of the KDC and may be
sending its first request message as a broadcast on a local
network. The KDC may not be located on the local network, and
even if it were - it will be unable to communicate with a client
without an IP address. This document describes a specific
mechanism that may be used by a client to communicate with the
Kerberos proxy.
S. Medvinsky, P. Lalwaney -4-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
b)The client may not know its Kerberos realm name. The proxy is
able to fill in the missing client realm name in an AS Request
message, as specified in IAKERB. Note that in the case that
PKINIT pre-authenticator is used [8], the realm name in the AS
Request may be the KDC realm name and not the clientÆs realm name.
c) The client does not know the realm name of the DHCP server.
According to IAKERB, when the client sends a TGS Request with a
missing server realm name, the proxy will return to the client an
error message containing the missing realm name.
Note that in this case the proxy could return the client a wrong
realm name and the client could be fooled into obtaining a ticket
for the wrong DHCP server (on the same local network). However,
the wrong DHCP server must still be a registered principal in a
KDC database. In some circumstances this may be an acceptable
compromise. Also, see the security considerations section.
IAKERB describes the proxy as part of an application server - the
DHCP server in this case. However, in this document we are not
requiring the proxy to be integrated with the DHCP server. The
same IAKERB mechanisms apply in the more general case, where the
proxy is an independent application. This proxy, however, MUST be
reachable by a client via a local network broadcast.
After a client has obtained a Kerberos ticket for the DHCP server,
it will use it as part of an authentication option in the DHCP
messages. The only extension to the DHCP protocol is the addition
of a new authenticator type based on Kerberos tickets.
4.1 Cross-Realm Authentication
Figure 1 shows a client communicating with a single KDC via a proxy.
However, the DHCP clientÆs realm may be different from the DHCP
serverÆs realm. In that case, the client may need to first contact
the KDC in its local realm to obtain a cross-realm TGT. Then, the
client would use the cross-realm TGT to contact the KDC in the DHCP
serverÆs realm, as specified in [6].
In the following example a client doesnÆt know its realm or the DHCP
serverÆs realm, which happens to be different from the clientÆs
realm. Here are the steps in obtaining the ticket for the DHCP
server (based on [6] and [7]):
1) The client sends AS Request with NULL realm to the proxy.
2) The proxy fills in the realm and forwards the AS Request to
the KDC in the clientÆs realm.
3) The KDC issues a TGT and sends back an AS Reply to the
proxy.
4) The proxy forwards AS Reply to the client.
S. Medvinsky, P. Lalwaney -5-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
5) The client sends TGS Request for a principal name "dhcpsrvr"
with NULL realm to the proxy.
6) The proxy returns KRB_AP_ERR_REALM_REQUIRED error with the
DHCP serverÆs realm to the client.
7) The client sends another TGS Request for a cross-realm TGT
to the proxy.
8) The proxy forwards the TGS Request to the KDC in the
clientÆs realm.
9) The KDC issues a cross-realm TGT and sends back a TGS Reply
to the proxy.
10) The proxy forwards TGS Reply to the client.
11) The client sends a TGS Request to the proxy for a principal
"dhcpsrvr" with the realm name filled in, using a cross-realm
TGT.
12) The proxy forwards TGS Request to the KDC in the DHCP
server's realm.
13) The KDC issues a ticket for the DHCP server and sends TGS
Reply back to the proxy.
14) The proxy forwards TGS Reply to the client.
In a most general case, the client may need to contact any number of
KDCs in different realms before it can get a ticket for the DHCP
server. In each case, the client would contact a KDC via the proxy
server, as specified in Section 5 of this document.
4.2 Public Key Authentication
This specification also allows clients to perform public key
authentication to the KDC, based on the PKINIT specification [8].
In this case, the size of an AS Request and AS Reply messages is
likely to exceed the size of typical link MTU's.
Here is an example, where PKINIT is used by a DHCP client that is
not a registered principal in the KDC principal database:
1) The client sends AS Request with a PKINIT Request pre-
authenticator to the proxy. This includes the clientÆs
signature and X.509 certificate. The KDC realm field is
left as NULL.
2) The proxy fills in the realm and forwards the AS Request to
the KDC in the filled in realm. This is the realm of the
DHCP server. Here, the clientÆs realm is the name of a
Certification Authority - not the same as the KDC realm.
3) The KDC issues a TGT and sends back an AS Reply with a
PKINIT Reply pre-authenticator to the proxy.
4) The proxy forwards the AS Reply to the client.
5) The client sends TGS Request for a principal name "dhcpsrvr"
with the realm found in the TGT to the proxy.
6) The proxy forwards TGS Request to the KDC in the DHCP
serverÆs realm.
7) The KDC issues a ticket for the DHCP server and sends TGS
Reply back to the proxy.
S. Medvinsky, P. Lalwaney -6-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
8) The proxy forwards TGS Reply to the client.
5. Key Management Exchange that Precedes Network Address Allocation
An uninitialized host (e.g. on power-on and reset) does not have a
network address. It does have a link layer address or hardware
address. At this time, the client may not have any information on
its realm or the realm of the address allocation server (DHCP
Server).
In the Kerberos key management exchange, a client gets its ticket
granting ticket (TGT) by contacting the Authentication Server in the
KDC using the AS_Request / Reply messages (shown as messages 1 and 2
in Figure 1). The client then contacts the Ticket Granting Server in
the KDC to get the DHCP server ticket (to be used for mutual
authentication with the DHCP server) using the TGS_REQ / TGS_REP
messages (shown as messages 3 and 4 in the above figure). It is
also possible for the client to obtain a DHCP server ticket directly
with the AS Request / Reply exchange, without the use of the TGT.
In the use of Kerberos for DHCP authentication, the client (a) does
not have an IP/network address (b) does not know he KDCÆs IP address
(c) the KDC may not be on the local network and (d) the client may
not know the DHCP ServerÆs IP address and realm. We therefore
require a Kerberos proxy on the local network to accept broadcast
Kerberos request messages (AS_REQ and TGS_REQ) from uninitialized
clients and relay them to the appropriate KDC.
The uninitialized client formulates a broadcast AS_REQ or TGS_REQ as
follows:
The request payload contains the client hardware address in
addresses field with a negative value for the address type. Kerberos
v5 [6] allows for the usage of negative address types for "local"
use. Note that IAKERB [7] discourages the use of the addresses field
as network addresses may not be known or may change in situation
where proxies are used. In this draft we incorporate the negative
values permitted in the Kerberos transport in the address type field
of both the AS_REQ and TGS_REQ messages. The negative value SHOULD
be the negative number of the hardware address type "htype" value
(from assigned numbers RFC) used in RFC 2131. The address field of
the message contains the clients hardware address.
The request payload is UDP encapsulated and addressed to port 88 on
the server/proxy. The UDP source port is selected by the client. The
source and destination network addresses are the all-zeroÆs address
and the broadcast address, respectively. For IPv4, the source IP
address is set to 0.0.0.0 and the destination IP address is set to
255.255.255.255. The data link layer header source address
corresponds to the link layer/hardware address of the client. The
S. Medvinsky, P. Lalwaney -7-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
destination link layer address is the broadcast address at the link
layer (e.g. for Ethernet the address is ffffffff).
In the case where AS_REQ message contains a PKINIT pre-authenticator
for public key-based client authentication (based on [8]), the
message will probably not fit into a single UDP packet given typical
link MTU's.
It is assumed that the proxy server on a network is configured with
a list of KDCÆs, their realms and their IP addresses. The proxy
server will act as a client to the KDC and forward standard Kerberos
messages to/from the KDC using unicast UDP or TCP transport
mechanisms, according to [6].
Upon receiving a broadcast request from a client, the proxy MUST
record the clientÆs hardware address that appears as the source
address on the frame as well as in the addresses field of the
request message. Based on the realm of the KDC specified in the
request, the proxy determines the KDC to which this message is
relayed as a unicast message from the proxy to the KDC. In the case
that the client left the KDC realm name as NULL, it is up to the
proxy to first determine the correct realm name and fill it in the
request (according to [7]).
On receiving a request, the KDC formulates a response (AS_REP or
TGS_REP). It includes the clientÆs addresses field in the encrypted
part of the ticket (according to [6]). This response is unicast to
the proxy.
Upon receiving the reply, the proxy MUST first determine the
previously saved hardware address of the client. The proxy
broadcasts the reply on its local network. This is a network layer
broadcast. At the link level, it uses the hardware address obtained
from the addresses field of the request.
The client on receiving the response (link layer destination address
as its hardware address, network layer address is the broadcast
address) must verify that the hardware address in the ticket
corresponds to its link layer address.
Upon receiving a TGS_REP (or an AS_REP with the application server
ticket) from the proxy, the client will have enough information to
securely communicate with the application server (the DHCP Server in
this case), as specified in the following section.
S. Medvinsky, P. Lalwaney -8-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
6. Authenticated Message Exchange Between the DHCP Client and the
DHCP Server
The ticket returned in the TGS response is used by the DHCP client
in the construction of the Kerberos authenticator. The Kerberos
ticket serves two purposes: to establish a shared session key with
the DHCP server, and is also included as part of a Kerberos
authenticator in the DHCP request.
If the size of the authenticator is greater than 255 bytes, the DHCP
authentication option is repeated multiple times. When the values
of all the authentication options are concatenated together, they
will make up the complete authenticator.
Once the session key is established, the Kerberos structure
containing the ticket (AP REQ) can be omitted from the authenticator
for subsequent messages sent by both the DHCP client and the DHCP
server.
The Kerberos authenticator for a DHCP request message is specified
below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Protocol | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Replay Detection (64 bits) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication token (n octets) ... +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of this authenticator is in accordance with [2]. The code
for the authentication option is TBD, and the length field contains
the length of the remainder of the option, starting with the
protocol field.
The value of the protocol field for this authenticator MUST be set
to 2.
The algorithm field MUST take one of the following values:
1 - HMAC-MD5
2 - HMAC-SHA-1
Replay protection field is a monotonically increasing counter field.
When the Kerberos AP REQ structure is present in the authenticator
the counter may be set to any value. The AP REQ contains its own
replay protection mechanism in the form of a timestamp.
S. Medvinsky, P. Lalwaney -9-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
Once the session key has been established and the AP REQ is not
included in the authenticator, this field MUST be monotonically
increasing in the messages sent by the client.
Kerberos authenticator token consists of type-length-value
attributes:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| attribute value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following attributes are included in the Kerberos authenticator
token:
Type Attribute Name Value
--------------------------------------------------------------------
0 Message Integrity Code Depends on the value of the
algorithm field. Its length is
16 bytes for HMAC-MD5 [9, 10]
and 20 bytes for HMAC-SHA-1
[11, 10]. The HMAC key must be
derived from Kerberos session
key found in the Kerberos
ticket according to the key
derivation rules in [6]:
HMAC Key = DK(sess key,
key usage | 0x99)
Here, DK is defined in [12] and
the key usage value for DHCP is
TBD.
The HMAC is calculated over the
entire DHCP message. The
Message Integrity Code
attribute MUST be set to all 0s
for the computation of the
HMAC. Because a DHCP relay
agent may alter the values of
the 'giaddr' and 'hops' fields
in the DHCP message, the
contents of those two fields
MUST also be set to zero for
the computation of the HMAC.
Rules specified in Section 3 of
[2] for the exclusion and
S. Medvinsky, P. Lalwaney -10-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
processing of the relay agent
information are applicable here
too.
This field MUST always be
present in the Kerberos
authenticator.
1 AP_REQ ASN.1 encoding of a Kerberos
AP_REQ message, as specified
in [6]. This MUST be included
by the client when establishing
a new session key. In all
other cases, this attribute
MUST be omitted.
AP_REQ contains the Kerberos ticket for the DHCP server and also
contains information needed by the DHCP server to authenticate the
client. After verifying the AP_REQ and decrypting the Kerberos
ticket, the DHCP server is able to extract a session key which it
now shares with the DHCP client.
The Kerberos authenticator token contains its own replay protection
mechanism inside the AP_REQ structure. The AP_REQ contains a
timestamp that must be within an agreed upon time window at the DHCP
server. However, this does not require the DHCP clients to maintain
an accurate clock between reboots. Kerberos allows clients to
synchronize their clock with the KDC with the help of Kerberos
KRB_AP_ERR_SKEW error message, as specified in [6].
The DHCP server MUST save both the session key and its associated
expiration time found in the Kerberos ticket. Up until the
expiration time, the server must accept client requests with the
Kerberos authenticator that does not include the AP REQ, using the
saved session key in calculating HMAC values.
The Kerberos authenticator inside all DHCP server responses MUST NOT
contain the AP REQ and MUST use the saved Kerberos session key in
calculating HMAC values.
When the session key expires, it is the client's responsibility to
obtain a new ticket from the KDC and to include an AP REQ inside the
Kerberos authenticator for the next DHCP request message.
S. Medvinsky, P. Lalwaney -11-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
7. Detailed message flows for Kerberos and DHCP message Exchanges
The following flow depicts the Kerberos exchange in which a AS REQ
message is used to directly request the DHCP Server ticket. There
are no changes to transport mechanisms below when the additional
phase of using TGS requests/responses with TGTÆs is used.
Client IAKERB Proxy KDC
KB-client-------- AS_REQ ------>
AS REQ Address type = - (htype)
AS REQ Address= hw address
src UDP port = senders port
destination UDP port = 88
src IP = 0.0.0.0
destination IP = 255.255.255.255
src link layer address =
clientÆs HW/link address [e.g Ethernet address]
destination link layer address =
link broadcast address [e.g. ffffffff for Ethernet]
--------------------------->
(unicast to UDP port 88)
<--------------------------
(unicast AS REP)
Encrypted portion of ticket
Includes clients HW address
<---------------AS_REP -----------
Ticket includes clientÆs hardware address
src UDP port = 88
destination UDP port = copied from src port in AS_REQ
src IP = ProxyÆs IP address
destination IP = 255.255.255.255
src link layer address = ProxyÆs HW/link address
destination link layer address =
ClientÆs link layer address from AS_REQ
S. Medvinsky, P. Lalwaney -12-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
The client uses the ticket received from the KDC in the DHCP
Authentication option as described in Section 6.
Client
DHCP-client DHCP Server
------DHCPDISCOVER ---->
(Auth Protocol = 2, includes Kerberos
authenticator with AP REQ )
-----------------------------------
| HMAC | AP REQ |
----------------------------------
| Ticket| Client Authent |
--------------------------
1. Server decrypts ticket
(inside AP REQ) with service
key
2. Server decrypts client
authenticator (inside AP REQ)
and checks content and
checksum to validate the
client.
3. Recompute HMAC with session
key and compare.
<-------DHCPOFFER----------
(Auth Protocol = 2, no AP REQ )
---------DHCPREQUEST------->
(Auth Protocol = 2, no AP REQ)
<--------DHCPACK-------------
(Auth Protocol = 2, no AP REQ )
8. Security Considerations
DHCP clients that do not know the DHCP serverÆs realm name will get
it from the proxy, as specified in IAKERB [7]. Since the proxy is
not authenticated, a DHCP client can be fooled into obtaining a
ticket for the wrong DHCP server in the wrong realm.
S. Medvinsky, P. Lalwaney -13-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
This could happen when the client leaves out the server realm name
in a TGS Request message to the proxy. It is also possible,
however, for a client to directly request a DHCP server ticket with
an AS Request message. In those cases, the same situation occurs
when the client leaves out the realm name in an AS Request.
This wrong DHCP server is still registered as a valid principal in a
database of a KDC that can be trusted by the client. In some
circumstances a client may assume that a DHCP server that is a
Kerberos principal registered with a trusted KDC will not attempt to
deliberately misconfigure a client.
This specification provides a tradeoff between:
1) The DHCP clients knowing DHCP serverÆs realm ahead of time,
which provides for full 2-way authentication at the cost of
an additional configuration parameter.
2) The DHCP clients not requiring any additional configuration
information, besides a password or a key (and a public key
certificate if PKINIT is used). This is at the cost of not
being able to fully authenticate the identity of the DHCP
server.
9. References
[1]Droms, R., Arbaugh, W., "Dynamic Host Configuration Protocol",
RFC 2131, Bucknell University, March 1997.
[2]Droms, R., Arbaugh, W., "Authentication for DHCP Messages",
draft-ietf-dhc-authentication-13.txt, June 2000.
[3]Hornstein, K., Lemon, T., "DHCP Authentication Via Kerberos V",
draft-hornstein-dhc-kerbauth-02.txt, February 2000.
[4]Borella, M., Grabelsky, D., Lo, J., Tuniguchi, K., "Realm
Specific IP: Protocol Specification ", draft-ietf-nat-rsip-
protocol-06.txt, March 2000.
[5]Guttman, E., Perkins, C., Veizades, J., Day, M., "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[6]Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
05.txt, March 2000.
S. Medvinsky, P. Lalwaney -14-
Kerberos V Authentication Mode for Uninitialized Clients July 2000
[7]Swift, M., Trostle, J., "Initial Authentication and Pass Through
Authentication Using Kerberos V5 and the GSS-API (IAKERB)",
draft-ietf-cat-iakerb-03.txt, September 1999.
[8]Tung, B., C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
J. Trostle, "Public Key Cryptography for Initial Authentication
in Kerberos", draft-ietf-cat-pk-init-11.txt, March 2000.
[9]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[10]Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication," RFC 2104, February 1997.
[11]NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995.
[12]Horowitz, M., "Key Derivation for Authentication, Integrity, and
Privacy", draft-horowitz-key-derivation-02.txt, August 1998.
[13]Bradner, S. "The Internet Standards Process -- Revision 3", RFC
2026.
10. Author's Addresses
Sasha Medvinsky
Motorola
6450 Sequence Drive
San Diego, CA 92121
Email: smedvinsky@gi.com
Poornima Lalwaney
Nokia
12278 Scripps Summit Drive
San Diego, CA 92131
Email: poornima.lalwaney@nokia.com
11. Expiration
This memo is filed as <draft-smedvinsky-dhc-kerbauth-01.txt>, and
expires January 1, 2001.
12. Intellectual Property Notices
S. Medvinsky, P. Lalwaney -15-
Kerberos V Authentication Mode for Uninitialized Clients March 2000
This section contains two notices as required by [13] for
standards track documents. Per [13], section 10.4(A):
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
Per [13] section 10.4(D):
The IETF has been notified of intellectual property rights
claimed in regard to some or all of the specification contained in
this document. For more information consult the online list of
claimed rights.
13. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
S. Medvinsky, P. Lalwaney -16-

5
crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt
View File

@ -1,5 +0,0 @@
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
crypto/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt
View File

@ -1,5 +0,0 @@
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
crypto/heimdal/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt
View File

File diff suppressed because it is too large Load Diff

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

@ -1,227 +0,0 @@
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
crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt
View File

@ -1,327 +0,0 @@
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

587
crypto/heimdal/doc/standardisation/rc4-hmac.txt
View File

@ -1,587 +0,0 @@
CAT working group M. Swift
Internet Draft J. Brezak
Document: draft-brezak-win2k-krb-rc4-hmac-03.txt Microsoft
Category: Informational June 2000
The Windows 2000 RC4-HMAC Kerberos encryption type
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. Internet-Drafts are
draft documents valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It
is inappropriate to use Internet- Drafts as reference material or to
cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
The Windows 2000 implementation of Kerberos introduces a new
encryption type based on the RC4 encryption algorithm and using an
MD5 HMAC for checksum. This is offered as an alternative to using
the existing DES based encryption types.
The RC4-HMAC encryption types are used to ease upgrade of existing
Windows NT environments, provide strong crypto (128-bit key
lengths), and provide exportable (meet United States government
export restriction requirements) encryption.
The Windows 2000 implementation of Kerberos contains new encryption
and checksum types for two reasons: for export reasons early in the
development process, 56 bit DES encryption could not be exported,
and because upon upgrade from Windows NT 4.0 to Windows 2000,
accounts will not have the appropriate DES keying material to do the
standard DES encryption. Furthermore, 3DES is not available for
export, and there was a desire to use a single flavor of encryption
in the product for both US and international products.
As a result, there are two new encryption types and one new checksum
type introduced in Windows 2000.
2. Conventions used in this document
Swift Category - Informational 1
Windows 2000 RC4-HMAC Kerberos E-Type June 2000
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
3. Key Generation
On upgrade from existing Windows NT domains, the user accounts would
not have a DES based key available to enable the use of DES base
encryption types specified in RFC 1510. The key used for RC4-HMAC is
the same as the existing Windows NT key (NT Password Hash) for
compatibility reasons. Once the account password is changed, the DES
based keys are created and maintained. Once the DES keys are
available DES based encryption types can be used with Kerberos.
The RC4-HMAC String to key function is defined as follow:
String2Key(password)
K = MD4(UNICODE(password))
The RC4-HMAC keys are generated by using the Windows UNICODE version
of the password. Each Windows UNICODE character is encoded in
little-endian format of 2 octets each. Then performing an MD4 [6]
hash operation on just the UNICODE characters of the password (not
including the terminating zero octets).
For an account with a password of "foo", this String2Key("foo") will
return:
0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe,
0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc
4. Basic Operations
The MD5 HMAC function is defined in [3]. It is used in this
encryption type for checksum operations. Refer to [3] for details on
its operation. In this document this function is referred to as
HMAC(Key, Data) returning the checksum using the specified key on
the data.
The basic MD5 hash operation is used in this encryption type and
defined in [7]. In this document this function is referred to as
MD5(Data) returning the checksum of the data.
RC4 is a stream cipher licensed by RSA Data Security [RSADSI]. A
compatible cipher is described in [8]. In this document the function
is referred to as RC4(Key, Data) returning the encrypted data using
the specified key on the data.
These encryption types use key derivation as defined in [9] (RFC-
1510BIS) in Section titled "Key Derivation". With each message, the
message type (T) is used as a component of the keying material. This
summarizes the different key derivation values used in the various
Swift Category - Informational 2
Windows 2000 RC4-HMAC Kerberos E-Type June 2000
operations. Note that these differ from the key derivations used in
other Kerberos encryption types.
T = 1 for TS-ENC-TS in the AS-Request
T = 8 for the AS-Reply
T = 7 for the Authenticator in the TGS-Request
T = 8 for the TGS-Reply
T = 2 for the Server Ticket in the AP-Request
T = 11 for the Authenticator in the AP-Request
T = 12 for the Server returned AP-Reply
T = 15 in the generation of checksum for the MIC token
T = 0 in the generation of sequence number for the MIC token
T = 13 in the generation of checksum for the WRAP token
T = 0 in the generation of sequence number for the WRAP token
T = 0 in the generation of encrypted data for the WRAPPED token
All strings in this document are ASCII unless otherwise specified.
The lengths of ASCII encoded character strings include the trailing
terminator character (0).
The concat(a,b,c,...) function will return the logical concatenation
(left to right) of the values of the arguments.
The nonce(n) function returns a pseudo-random number of "n" octets.
5. Checksum Types
There is one checksum type used in this encryption type. The
Kerberos constant for this type is:
#define KERB_CHECKSUM_HMAC_MD5 (-138)
The function is defined as follows:
K - is the Key
T - the message type, encoded as a little-endian four byte integer
CHKSUM(K, T, data)
Ksign = HMAC(K, "signaturekey") //includes zero octet at end
tmp = MD5(concat(T, data))
CHKSUM = HMAC(Ksign, tmp)
6. Encryption Types
There are two encryption types used in these encryption types. The
Kerberos constants for these types are:
#define KERB_ETYPE_RC4_HMAC 23
#define KERB_ETYPE_RC4_HMAC_EXP 24
The basic encryption function is defined as follow:
T = the message type, encoded as a little-endian four byte integer.
Swift Category - Informational 3
Windows 2000 RC4-HMAC Kerberos E-Type June 2000
BYTE L40[14] = "fortybits";
BYTE SK = "signaturekey";
ENCRYPT (K, fRC4_EXP, T, data, data_len, edata, edata_len)
{
if (fRC4_EXP){
*((DWORD *)(L40+10)) = T;
HMAC (K, L40, 10 + 4, K1);
}else{
HMAC (K, &T, 4, K1);
}
memcpy (K2, K1, 16);
if (fRC4_EXP) memset (K1+7, 0xAB, 9);
add_8_random_bytes(data, data_len, conf_plus_data);
HMAC (K2, conf_plus_data, 8 + data_len, checksum);
HMAC (K1, checksum, 16, K3);
RC4(K3, conf_plus_data, 8 + data_len, edata + 16);
memcpy (edata, checksum, 16);
edata_len = 16 + 8 + data_len;
}
DECRYPT (K, fRC4_EXP, T, edata, edata_len, data, data_len)
{
if (fRC4_EXP){
*((DWORD *)(L40+10)) = T;
HMAC (K, L40, 14, K1);
}else{
HMAC (K, &T, 4, K1);
}
memcpy (K2, K1, 16);
if (fRC4_EXP) memset (K1+7, 0xAB, 9);
HMAC (K1, edata, 16, K3); // checksum is at edata
RC4(K3, edata + 16, edata_len - 16, edata + 16);
data_len = edata_len - 16 - 8;
memcpy (data, edata + 16 + 8, data_len);
// verify generated and received checksums
HMAC (K2, edata + 16, edata_len - 16, checksum);
if (memcmp(edata, checksum, 16) != 0)
printf("CHECKSUM ERROR !!!!!!\n");
}
The header field on the encrypted data in KDC messages is:
typedef struct _RC4_MDx_HEADER {
UCHAR Checksum[16];
UCHAR Confounder[8];
} RC4_MDx_HEADER, *PRC4_MDx_HEADER;
The KDC message is encrypted using the ENCRYPT function not
including the Checksum in the RC4_MDx_HEADER.
Swift Category - Informational 4
Windows 2000 RC4-HMAC Kerberos E-Type June 2000
The character constant "fortybits" evolved from the time when a 40-
bit key length was all that was exportable from the United States.
It is now used to recognize that the key length is of "exportable"
length. In this description, the key size is actually 56-bits.
7. Key Strength Negotiation
A Kerberos client and server can negotiate over key length if they
are using mutual authentication. If the client is unable to perform
full strength encryption, it may propose a key in the "subkey" field
of the authenticator, using a weaker encryption type. The server
must then either return the same key or suggest its own key in the
subkey field of the AP reply message. The key used to encrypt data
is derived from the key returned by the server. If the client is
able to perform strong encryption but the server is not, it may
propose a subkey in the AP reply without first being sent a subkey
in the authenticator.
8. GSSAPI Kerberos V5 Mechanism Type
8.1 Mechanism Specific Changes
The GSSAPI per-message tokens also require new checksum and
encryption types. The GSS-API per-message tokens must be changed to
support these new encryption types (See [5] Section 1.2.2). The
sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption
is:
Byte 4..5 SEAL_ALG 0x10 0x00 - RC4
The signing algorithm identifier (SGN_ALG) for MD5 HMAC is:
Byte 2..3 SGN ALG 0x11 0x00 - HMAC
The only support quality of protection is:
#define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0
In addition, when using an RC4 based encryption type, the sequence
number is sent in big-endian rather than little-endian order.
The Windows 2000 implementation also defines new GSSAPI flags in the
initial token passed when initializing a security context. These
flags are passed in the checksum field of the authenticator (See [5]
Section 1.1.1).
GSS_C_DCE_STYLE - This flag was added for use with Microsoft’s
implementation of DCE RPC, which initially expected three legs of
authentication. Setting this flag causes an extra AP reply to be
sent from the client back to the server after receiving the server’s
AP reply. In addition, the context negotiation tokens do not have
GSSAPI framing - they are raw AP message and do not include object
identifiers.
#define GSS_C_DCE_STYLE 0x1000
Swift Category - Informational 5
Windows 2000 RC4-HMAC Kerberos E-Type June 2000
GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the
server that it should only allow the server application to identify
the client by name and ID, but not to impersonate the client.
#define GSS_C_IDENTIFY_FLAG 0x2000
GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the
client wants to be informed of extended error information. In
particular, Windows 2000 status codes may be returned in the data
field of a Kerberos error message. This allows the client to
understand a server failure more precisely. In addition, the server
may return errors to the client that are normally handled at the
application layer in the server, in order to let the client try to
recover. After receiving an error message, the client may attempt to
resubmit an AP request.
#define GSS_C_EXTENDED_ERROR_FLAG 0x4000
These flags are only used if a client is aware of these conventions
when using the SSPI on the Windows platform, they are not generally
used by default.
When NetBIOS addresses are used in the GSSAPI, they are identified
by the GSS_C_AF_NETBIOS value. This value is defined as:
#define GSS_C_AF_NETBIOS 0x14
NetBios addresses are 16-octet addresses typically composed of 1 to th 15 characters, trailing blank (ascii char 20) filled, with a 16
octet of 0x0.
8.2 GSSAPI Checksum Type
The GSSAPI checksum type and algorithm is defined in Section 5. Only
the first 8 octets of the checksum are used. The resulting checksum
is stored in the SGN_CKSUM field (See [5] Section 1.2) for
GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE).
MIC (K, fRC4_EXP, seq_num, MIC_hdr, msg, msg_len,
MIC_seq, MIC_checksum)
{
HMAC (K, SK, 13, K4);
T = 15;
memcpy (T_plus_hdr_plus_msg + 00, &T, 4);
memcpy (T_plus_hdr_plus_msg + 04, MIC_hdr, 8);
// 0101 1100 FFFFFFFF
memcpy (T_plus_hdr_plus_msg + 12, msg, msg_len);
MD5 (T_hdr_msg, 4 + 8 + msg_len, MD5_of_T_hdr_msg);
HMAC (K4, MD5_of_T_hdr_msg, CHKSUM);
memcpy (MIC_checksum, CHKSUM, 8); // use only first 8 bytes
T = 0;
if (fRC4_EXP){
*((DWORD *)(L40+10)) = T;
HMAC (K, L40, 14, K5);
}else{
HMAC (K, &T, 4, K5);
Swift Category - Informational 6
Windows 2000 RC4-HMAC Kerberos E-Type June 2000
}
if (fRC4_EXP) memset(K5+7, 0xAB, 9);
HMAC(K5, MIT_checksum, 8, K6);
copy_seq_num_in_big_endian(seq_num, seq_plus_direction);
//0x12345678
copy_direction_flag (direction_flag, seq_plus_direction +
4); //0x12345678FFFFFFFF
RC4(K6, seq_plus_direction, 8, MIC_seq);
}
8.3 GSSAPI Encryption Types
There are two encryption types for GSSAPI message tokens, one that
is 128 bits in strength, and one that is 56 bits in strength as
defined in Section 6.
All padding is rounded up to 1 byte. One byte is needed to say that
there is 1 byte of padding. The DES based mechanism type uses 8 byte
padding. See [5] Section 1.2.2.3.
The encryption mechanism used for GSS wrap based messages is as
follow:
WRAP (K, fRC4_EXP, seq_num, WRAP_hdr, msg, msg_len,
WRAP_seq, WRAP_checksum, edata, edata_len)
{
HMAC (K, SK, 13, K7);
T = 13;
PAD = 1;
memcpy (T_hdr_conf_msg_pad + 00, &T, 4);
memcpy (T_hdr_conf_msg_pad + 04, WRAP_hdr, 8); // 0101 1100
FFFFFFFF
memcpy (T_hdr_conf_msg_pad + 12, msg, msg_len);
memcpy (T_hdr_conf_msg_pad + 12 + msg_len, &PAD, 1);
MD5 (T_hdr_conf_msg_pad,
4 + 8 + 8 + msg_len + 1,
MD5_of_T_hdr_conf_msg_pad);
HMAC (K7, MD5_of_T_hdr_conf_msg_pad, CHKSUM);
memcpy (WRAP_checksum, CHKSUM, 8); // use only first 8
bytes
T = 0;
if (fRC4_EXP){
*((DWORD *)(L40+10)) = T;
HMAC (K, L40, 14, K8);
}else{
HMAC (K, &T, 4, K8);
}
if (fRC4_EXP) memset(K8+7, 0xAB, 9);
HMAC(K8, WRAP_checksum, 8, K9);
copy_seq_num_in_big_endian(seq_num, seq_plus_direction);
//0x12345678
Swift Category - Informational 7
Windows 2000 RC4-HMAC Kerberos E-Type June 2000
copy_direction_flag (direction_flag, seq_plus_direction +
4); //0x12345678FFFFFFFF
RC4(K9, seq_plus_direction, 8, WRAP_seq);
for (i = 0; i < 16; i++) K10 [i] ^= 0xF0; // XOR each byte
of key with 0xF0
T = 0;
if (fRC4_EXP){
*(DWORD *)(L40+10) = T;
HMAC(K10, L40, 14, K11);
memset(K11+7, 0xAB, 9);
}else{
HMAC(K10, &T, 4, K11);
}
HMAC(K11, seq_num, 4, K12);
RC4(K12, T_hdr_conf_msg_pad + 4 + 8, 8 + msg_len + 1,
edata); /* skip T & hdr */
edata_len = 8 + msg_len + 1; // conf + msg_len + pad
}
The character constant "fortybits" evolved from the time when a 40-
bit key length was all that was exportable from the United States.
It is now used to recognize that the key length is of "exportable"
length. In this description, the key size is actually 56-bits.
9. Security Considerations
Care must be taken in implementing this encryption type because it
uses a stream cipher. If a different IV isn’t used in each direction
when using a session key, the encryption is weak. By using the
sequence number as an IV, this is avoided.
10. Acknowledgements
We would like to thank Salil Dangi for the valuable input in
refining the descriptions of the functions and review input.
11. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for
Message Authentication", RFC 2104, February 1997
4 Kohl, J., Neuman, C., "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993
Swift Category - Informational 8
Windows 2000 RC4-HMAC Kerberos E-Type June 2000
5 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964,
June 1996
6 R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April
1992
7 R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April
1992
8 Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption
Algorithm", Work in Progress.
9 RC4 is a proprietary encryption algorithm available under license
from RSA Data Security Inc. For licensing information, contact:
RSA Data Security, Inc.
100 Marine Parkway
Redwood City, CA 94065-1031
10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
04.txt, June 25, 1999
12. Author's Addresses
Mike Swift
Dept. of Computer Science
Sieg Hall
University of Washington
Seattle, WA 98105
Email: mikesw@cs.washington.edu
John Brezak
Microsoft
One Microsoft Way
Redmond, Washington
Email: jbrezak@microsoft.com
Swift Category - Informational 9
Windows 2000 RC4-HMAC Kerberos E-Type October 1999
13. Full Copyright Statement
"Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
Swift Category - Informational 10

2747
crypto/heimdal/doc/standardisation/rfc1508.txt
View File

File diff suppressed because it is too large Load Diff

2691
crypto/heimdal/doc/standardisation/rfc1509.txt
View File

File diff suppressed because it is too large Load Diff

6275
crypto/heimdal/doc/standardisation/rfc1510.txt
View File

File diff suppressed because it is too large Load Diff

1683
crypto/heimdal/doc/standardisation/rfc1750.txt
View File

File diff suppressed because it is too large Load Diff

1011
crypto/heimdal/doc/standardisation/rfc1831.txt
View File

File diff suppressed because it is too large Load Diff

1123
crypto/heimdal/doc/standardisation/rfc1964.txt
View File

File diff suppressed because it is too large Load Diff

4763
crypto/heimdal/doc/standardisation/rfc2078.txt
View File

File diff suppressed because it is too large Load Diff

1291
crypto/heimdal/doc/standardisation/rfc2203.txt
View File

File diff suppressed because it is too large Load Diff

1515
crypto/heimdal/doc/standardisation/rfc2228.txt
View File

File diff suppressed because it is too large Load Diff

5659
crypto/heimdal/doc/standardisation/rfc2743.txt
View File

File diff suppressed because it is too large Load Diff

5659
crypto/heimdal/doc/standardisation/rfc2744.txt
View File

File diff suppressed because it is too large Load Diff