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

new drafts

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@8196 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Assar Westerlund
2000-04-23 17:09:09 +00:00
parent 18180f86f9
commit 35b1450b8d
5 changed files with 2545 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

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

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

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

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

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

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

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

1333
doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt Normal file
View File

File diff suppressed because it is too large Load Diff