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

move to subdirectory

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@7228 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Johan Danielsson
1999-10-24 18:30:33 +00:00
parent 6af0299aec
commit 1a34ba71b9
31 changed files with 0 additions and 64628 deletions
Download Patch File Download Diff File Expand all files Collapse all files

412
doc/draft-brezak-win2k-krb-rc4-hmac-00.txt
View File

@@ -1,412 +0,0 @@
CAT working group M. Swift
Internet Draft J. Brezak
Document: draft-brezak-win2k-krb-rc4-hmac-00.txt Microsoft
Category: Informational September, 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 desired 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 July 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 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(Key, Data) returning the checksum using the specified key on 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.
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 July 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(Ksign, concat(T, data))
CHKSUM = HMAC(K, 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 = "fiftysixbits" //includes zero octet at end
Else
L = "" // one octet of zero
Ksign = HMAC(K, concat(L, T))
Confounder = nonce(8) // get an 8 octet nonce for a confounder
Checksum = HMAC(Ksign, concat(Confounder, data))
Ke = Ksign
if (L == "fiftysixbits") 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 July 1999
The character constant "fiftysixbits" evolved from the time when a
56-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.
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 July 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:
GSS-ENCRYPT(K, T, data)
IV = SND_SEQ
K = XOR(K, 0xf0f0f0f0f0f0f0f0f0f0f0f0f0f0f0)
if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP)
L = "fortybits" //includes zero octet at end
else
L = "" // one octet of zero
Ksign = HMAC(K, concat(L, T))
Ke = Ksign
if (L == "fortybits") 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.
8. Security Considerations
Care must be taken in implementing this encryption type because it
uses a stream cipher. If a different IV isn<73>t used in each direction
when using a session key, the encryption is weak. By using the
sequence number as an IV, this is avoided.
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
5 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964,
June 1996
Swift Category - Informational 5
Windows 2000 RC4-HMAC Kerberos E-Type July 1999
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 July 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

171
doc/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
doc/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
doc/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
doc/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
doc/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
doc/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

244
doc/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
doc/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
doc/draft-ietf-cat-gssv2-cbind-04.txt
View File

File diff suppressed because it is too large Load Diff

311
doc/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
doc/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
doc/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
doc/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

282
doc/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

589
doc/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

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

File diff suppressed because it is too large Load Diff

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

File diff suppressed because it is too large Load Diff

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

File diff suppressed because it is too large Load Diff

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

File diff suppressed because it is too large Load Diff

250
doc/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]

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

File diff suppressed because it is too large Load Diff

2747
doc/rfc1508.txt
View File

File diff suppressed because it is too large Load Diff

2691
doc/rfc1509.txt
View File

File diff suppressed because it is too large Load Diff

6275
doc/rfc1510.txt
View File

File diff suppressed because it is too large Load Diff

1683
doc/rfc1750.txt
View File

File diff suppressed because it is too large Load Diff

1011
doc/rfc1831.txt
View File

File diff suppressed because it is too large Load Diff

1123
doc/rfc1964.txt
View File

File diff suppressed because it is too large Load Diff

4763
doc/rfc2078.txt
View File

File diff suppressed because it is too large Load Diff

1291
doc/rfc2203.txt
View File

File diff suppressed because it is too large Load Diff

1515
doc/rfc2228.txt
View File

File diff suppressed because it is too large Load Diff