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

more rfc/drafts

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@1560 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Assar Westerlund
1997-04-12 21:32:36 +00:00
parent 2cce29a0c7
commit 11a75fc89d
23 changed files with 28951 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/draft-ietf-cat-gssv2-08.txt
+62
View File
@@ -0,0 +1,62 @@
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
doc/draft-ietf-cat-gssv2-cbind-04.txt
+6188
View File
File diff suppressed because it is too large Load Diff
doc/draft-ietf-cat-kerb-chg-password-00.txt
+252
View File
@@ -0,0 +1,252 @@
Network Working Group M. Horowitz
<draft-ietf-cat-kerb-chg-password-00.txt> Cygnus Solutions
Internet-Draft March, 1997
Expire in six months
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 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
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 March, 1997
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 March, 1997
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 four 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. No particular format is mandated,
and the field may be omitted if the server does not wish to
include it. 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 March, 1997
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, stolen, or
modified messages. An attacker (or simply a lossy network) could
cause either the request or reply to be dropped, or substitute a KRB-
ERROR message in the reply.
If a reply is dropped, it is reasonable for the client to construct a
new authenticator, re-encrypt the request, and retransmit. If the
request was lost, the server will treat this as a valid request, and
all should work normally. If the reply was lost, then the server
should take care to notice that the request was a duplicate of the
prior request, and indicate success without actually changing the
password or any other information (such as modification timestamps).
If a success reply was replaced with an error reply, then one would
expect that the user would attempt the operation again. Again, the
server should recognize the request as a duplicate and indicate
success without changing the password. If the user is required to
provide the old password again, but the password was actually changed
successfully, then some user confusion could result. This is,
unfortunately, impossible to prevent.
References
[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]
doc/draft-ietf-cat-kerb-des3-hmac-sha1-00.txt
+127
View File
@@ -0,0 +1,127 @@
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]
doc/draft-ietf-cat-kerb-key-derivation-00.txt
+250
View File
@@ -0,0 +1,250 @@
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]
doc/draft-ietf-cat-kerb5gss-07.txt
+61
View File
@@ -0,0 +1,61 @@
A new Request for Comments is now available in online RFC libraries.
RFC 1964:
Title: The Kerberos Version 5 GSS-API Mechanism
Author: J. Linn
Date: June 1996
Mailbox: John.Linn@ov.com
Pages: 20
Characters: 47,413
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1964.txt
This specification defines protocols, procedures, and conventions to
be employed by peers implementing the Generic Security Service
Application Program Interface (as specified in RFCs 1508 and 1509)
when using Kerberos Version 5 technology (as specified in RFC 1510).
This RFC is the product of the Common Authentication Technology
Working Group of the IETF.
This 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
USC/Information Sciences Institute
doc/draft-ietf-cat-kerberos-err-msg-00.txt
+252
View File
@@ -0,0 +1,252 @@
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
doc/draft-ietf-cat-kerberos-passwords-02.txt
+16
View File
@@ -0,0 +1,16 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories.
doc/draft-ietf-cat-kerberos-pk-cross-01.txt
+282
View File
@@ -0,0 +1,282 @@
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
doc/draft-ietf-cat-kerberos-pk-init-03.txt
+589
View File
@@ -0,0 +1,589 @@
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
doc/rfc1508.txt
+2747
View File
File diff suppressed because it is too large Load Diff
doc/rfc1509.txt
+2691
View File
File diff suppressed because it is too large Load Diff
doc/rfc1964.txt
+1123
View File
File diff suppressed because it is too large Load Diff
doc/standardisation/draft-ietf-cat-gssv2-08.txt
+62
View File
@@ -0,0 +1,62 @@
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
doc/standardisation/draft-ietf-cat-gssv2-cbind-04.txt
+6188
View File
File diff suppressed because it is too large Load Diff
doc/standardisation/draft-ietf-cat-kerb-des3-hmac-sha1-00.txt
+127
View File
@@ -0,0 +1,127 @@
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]
doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt
+250
View File
@@ -0,0 +1,250 @@
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]
doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt
+252
View File
@@ -0,0 +1,252 @@
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
doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt
+282
View File
@@ -0,0 +1,282 @@
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
doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt
+589
View File
@@ -0,0 +1,589 @@
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
doc/standardisation/rfc1508.txt
+2747
View File
File diff suppressed because it is too large Load Diff
doc/standardisation/rfc1509.txt
+2691
View File
File diff suppressed because it is too large Load Diff
doc/standardisation/rfc1964.txt
+1123
View File
File diff suppressed because it is too large Load Diff