d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
0c8fa35435
freebsd-skq/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt

524 lines
22 KiB
Plaintext
Raw Normal View History

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