[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CVS shishi/doc/specifications
|
From: |
shishi-commit |
|
Subject: |
CVS shishi/doc/specifications |
|
Date: |
Wed, 26 Jan 2005 00:38:26 +0100 |
Update of /home/cvs/shishi/doc/specifications
In directory dopio:/tmp/cvs-serv1448
Added Files:
draft-ietf-krb-wg-rfc1510ter-00.txt
Log Message:
Add.
--- /home/cvs/shishi/doc/specifications/draft-ietf-krb-wg-rfc1510ter-00.txt
2005/01/25 23:38:26 NONE
+++ /home/cvs/shishi/doc/specifications/draft-ietf-krb-wg-rfc1510ter-00.txt
2005/01/25 23:38:26 1.1
INTERNET-DRAFT Tom Yu
draft-ietf-krb-wg-rfc1510ter-00.txt MIT
Expires: 25 July 2005 21 January 2005
The Kerberos Network Authentication Service (Version 5)
Status of This Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document describes version 5 of the Kerberos network
authentication protocol. It describes a framework to allow for
extensions to be made to the protocol without creating
interoperability problems.
Key Words for Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
to be interpreted as described in RFC 2119.
Yu Expires: Jul 2005 [Page 1]
Internet-Draft rfc1510ter-00 21 Jan 2005
Table of Contents
Status of This Memo .............................................. 1
Copyright Notice ................................................. 1
Abstract ......................................................... 1
Key Words for Requirements ....................................... 1
Table of Contents ................................................ 2
1. Introduction ................................................. 5
1.1. Kerberos Protocol Overview ................................. 5
1.2. Document Organization ...................................... 6
2. Compatibility Considerations ................................. 6
2.1. Extensibility .............................................. 7
2.2. Compatibility with RFC 1510 ................................ 7
2.3. Backwards Compatibility .................................... 7
2.4. 1.4.2. Sending Extensible Messages ......................... 8
2.5. Criticality ................................................ 8
2.6. Authenticating Cleartext Portions of Messages .............. 9
2.7. Capability Negotiation ..................................... 10
3. Use of ASN.1 in Kerberos ..................................... 10
3.1. Module Header .............................................. 11
3.2. Top-Level Type ............................................. 11
3.3. Previously Unused ASN.1 Notation (informative) ............. 12
3.3.1. Parameterized Types ...................................... 12
3.3.2. COMPONENTS OF Notation ................................... 12
3.3.3. Constraints .............................................. 12
3.4. New Types .................................................. 13
4. Basic Types .................................................. 14
4.1. Constrained Integer Types .................................. 14
4.2. KerberosTime ............................................... 15
4.3. KerberosString ............................................. 15
4.4. Language Tags .............................................. 16
4.5. KerberosFlags .............................................. 16
4.6. Typed Holes ................................................ 16
4.7. HostAddress and HostAddresses .............................. 17
4.7.1. Internet (IPv4) Addresses ................................ 17
4.7.2. Internet (IPv6) Addresses ................................ 17
4.7.3. DECnet Phase IV addresses ................................ 18
4.7.4. Netbios addresses ........................................ 18
4.7.5. Directional Addresses .................................... 18
5. Principals ................................................... 19
5.1. Name Types ................................................. 19
5.2. Principal Type Definition .................................. 19
5.3. Principal Name Reuse ....................................... 20
5.4. Realm Names ................................................ 20
5.5. Printable Representations of Principal Names ............... 21
5.6. Ticket-Granting Service Principal .......................... 21
5.6.1. Cross-Realm TGS Principals ............................... 21
6. Types Relating to Encryption ................................. 21
6.1. Assigned Numbers for Encryption ............................ 22
6.1.1. EType .................................................... 22
6.1.2. Key Usages ............................................... 22
Yu Expires: Jul 2005 [Page 2]
Internet-Draft rfc1510ter-00 21 Jan 2005
6.2. Which Key to Use ........................................... 23
6.3. EncryptionKey .............................................. 24
6.4. EncryptedData .............................................. 24
6.5. Checksums .................................................. 25
6.5.1. ChecksumOf ............................................... 26
6.5.2. Signed ................................................... 27
7. Tickets ...................................................... 27
7.1. Timestamps ................................................. 28
7.2. Ticket Flags ............................................... 28
7.2.1. Flags Relating to Initial Ticket Acquisition ............. 29
7.2.2. Invalid Tickets .......................................... 29
7.2.3. OK as Delegate ........................................... 30
7.2.4. Renewable Tickets ........................................ 30
7.2.5. Postdated Tickets ........................................ 31
7.2.6. Proxiable and Proxy Tickets .............................. 32
7.2.7. Forwarded and Forwardable Tickets ........................ 33
7.3. Transited Realms ........................................... 34
7.4. Authorization Data ......................................... 34
7.4.1. AD-IF-RELEVANT ........................................... 35
7.4.2. AD-KDCIssued ............................................. 35
7.4.3. AD-AND-OR ................................................ 37
7.4.4. AD-MANDATORY-FOR-KDC ..................................... 37
7.5. Encrypted Part of Ticket ................................... 37
7.6. Cleartext Part of Ticket ................................... 38
8. Credential Acquisition ....................................... 40
8.1. KDC-REQ .................................................... 40
8.2. PA-DATA .................................................... 46
8.3. KDC-REQ Processing ......................................... 46
8.3.1. Handling Replays ......................................... 46
8.3.2. Request Validation ....................................... 47
8.3.2.1. AS-REQ Authentication .................................. 47
8.3.2.2. TGS-REQ Authentication ................................. 47
8.3.2.3. Principal Validation ................................... 47
8.3.2.4. Checking For Revoked or Invalid Tickets ................ 48
8.3.3. Timestamp Handling ....................................... 48
8.3.3.1. AS-REQ Timestamp Processing ............................ 49
8.3.3.2. TGS-REQ Timestamp Processing ........................... 49
8.3.4. Handling Transited Realms ................................ 50
8.3.5. Address Processing ....................................... 50
8.3.6. Ticket Flag Processing ................................... 51
8.3.7. Key Selection ............................................ 52
8.3.7.1. Reply Key and Session Key Selection .................... 52
8.3.7.2. Ticket Key Selection ................................... 52
8.4. KDC-REP .................................................... 52
8.5. Reply Validation ........................................... 55
8.6. IP Transports .............................................. 55
8.6.1. UDP/IP transport ......................................... 55
8.6.2. TCP/IP transport ......................................... 56
8.6.3. KDC Discovery on IP Networks ............................. 57
8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 57
8.6.3.2. DNS SRV records for KDC location ....................... 58
Yu Expires: Jul 2005 [Page 3]
Internet-Draft rfc1510ter-00 21 Jan 2005
8.6.3.3. KDC Discovery for Domain Style Realm Names on IP
Networks ............................................ 58
9. Errors ....................................................... 58
10. Session Key Exchange ........................................ 61
10.1. AP-REQ .................................................... 61
10.2. AP-REP .................................................... 63
11. Session Key Use ............................................. 65
11.1. KRB-SAFE .................................................. 65
11.2. KRB-PRIV .................................................. 65
11.3. KRB-CRED .................................................. 66
12. Security Considerations ..................................... 67
12.1. Time Synchronization ...................................... 67
12.2. Replays ................................................... 67
12.3. Principal Name Reuse ...................................... 67
12.4. Password Guessing ......................................... 67
12.5. Forward Secrecy ........................................... 67
12.6. Authorization ............................................. 68
12.7. Login Authentication ...................................... 68
13. IANA Considerations ......................................... 68
14. Acknowledgments ............................................. 69
Appendices ....................................................... 69
A. ASN.1 Module (Normative) ..................................... 69
B. Kerberos and Character Encodings (Informative) ...............103
C. Kerberos History (Informative) ...............................104
D. Notational Differences from [KCLAR] ..........................105
Normative References .............................................106
Informative References ...........................................106
Author's Address .................................................108
Full Copyright Statement .........................................108
Yu Expires: Jul 2005 [Page 4]
Internet-Draft rfc1510ter-00 21 Jan 2005
1. Introduction
The Kerberos network authentication protocol is a trusted-third-party
protocol utilizing symmetric-key cryptography. It assumes that all
communications between parties in the protocol may be arbitrarily
tampered with or monitored, and that the security of the overall
system depends only on the effectiveness of the cryptographic
techniques and the secrecy of the cryptographic keys used. The
Kerberos protocol authenticates an application client's identity to
an application server, and likewise authenticates the application
server's identity to the application client. These assurances are
made possible by the client and the server sharing secrets with the
trusted third party: the Kerberos server, also known as the Key
Distribution Center (KDC). In addition, the protocol establishes an
ephemeral shared secret (the session key) between the client and the
server, allowing the protection of further communications between
them.
The Kerberos protocol, as originally specified, provides insufficient
means for extending the protocol in a backwards-compatible way. This
deficiency has caused problems for interoperability. This document
describes a framework which enables backwards-compatible extensions
to the Kerberos protocol.
1.1. Kerberos Protocol Overview
Kerberos comprises three main sub-protocols: credentials acquisition,
session key exchange, and session key usage. A client acquires
credentials by asking the KDC for a credential for a service; the KDC
issues the credential, which contains a ticket and a session key.
The ticket, containing the client's identity, timestamps, expiration
time, and a session key, is a encrypted in a key known to the
application server. The KDC encrypts the credential using a key
known to the client, and transmits the credential to the client.
There are two means of requesting credentials: the Authentication
Service (AS) exchange, and the Ticket-Granting Service (TGS)
exchange. In the typical AS exchange, a client uses a password-
derived key to decrypt the response. In the TGS exchange, the KDC
behaves as an application server; the client authenticates to the TGS
by using a Ticket-Granting Ticket (TGT). The client usually obtains
the TGT by using the AS exchange.
Session key exchange consists of the client transmitting the ticket
to the application server, accompanied by an authenticator. The
authenticator contains a timestamp and additional data encrypted
using the ticket's session key. The application server decrypts the
ticket, extracting the session key. The application server then uses
the session key to decrypt the authenticator. Upon successful
decryption of the authenticator, the application server knows that
the data in the authenticator were sent by the client named in the
Yu Expires: Jul 2005 [Page 5]
Internet-Draft rfc1510ter-00 21 Jan 2005
associated ticket. Additionally, since authenticators expire more
quickly than tickets, the application server has some assurance that
the transaction is not a replay. The application server may send an
encrypted acknowledgment to the client, verifying its identity to the
client.
Once session key exchange has occurred, the client and server may use
the established session key to protect further traffic. This
protection may consist of protection of integrity only, or of
protection of confidentiality and integrity. Additional measures
exist for a client to securely forward credentials to a server.
The entire scheme depends on loosely synchronized clocks.
Synchronization of the clock on the KDC with the application server
clock allows the application server to accurately determine whether a
credential is expired. Likewise, synchronization of the clock on the
client with the application server clock prevents replay attacks
utilizing the same credential. Careful design of the application
protocol may allow replay prevention without requiring client-server
clock synchronization.
After establishing a session key, application client and the
application server can exchange Kerberos protocol messages that use
the session key to protect the integrity or confidentiality of
communications between the client and the server. Additionally, the
client may forward credentials to the application server.
The credentials acquisition protocol takes place over specific,
defined transports (UDP and TCP). Application protocols define which
transport to use for the session key establishment protocol and for
messages using the session key; the application may choose to perform
its own encapsulation of the Kerberos messages, for example.
1.2. Document Organization
The remainder of this document begins by describing the general
frameworks for protocol extensibility, including whether to interpret
unknown extensions as critical. It then defines the protocol
messages and exchanges.
The definition of the Kerberos protocol uses Abstract Syntax Notation
One (ASN.1) [X680], which specifies notation for describing the
abstract content of protocol messages. This document defines a
number of base types using ASN.1; these base types subsequently
appear in multiple types which define actual protocol messages.
Definitions of principal names and of tickets, which are central to
the protocol, also appear preceding the protocol message definitions.
Yu Expires: Jul 2005 [Page 6]
Internet-Draft rfc1510ter-00 21 Jan 2005
2. Compatibility Considerations
2.1. Extensibility
In the past, significant interoperability problems have resulted from
conflicting assumptions about how the Kerberos protocol can be
extended. As the deployed base of Kerberos grows, the ability to
extend the Kerberos protocol becomes more important. In order to
ensure that vendors and the IETF can extend the protocol while
maintaining backwards compatibility, this document outlines a
framework for extending Kerberos.
Kerberos provides two general mechanisms for protocol extensibility.
Many protocol messages, including some defined in RFC 1510, contain
typed holes--sub-messages containing an octet string along with an
integer that identifies how to interpret the octet string. The
integer identifiers are registered centrally, but can be used both
for vendor extensions and for extensions standardized in the IETF.
This document adds typed holes to a number of messages which
previously lacked typed holes.
Many new messages defined in this document also contain ASN.1
extension markers. These markers allow future revisions of this
document to add additional elements to messages, for cases where
typed holes are inadequate for some reason. Because tag numbers and
position in a sequence need to be coordinated in order to maintain
interoperability, implementations MUST NOT include ASN.1 extensions
except when those extensions are specified by IETF standards-track
documents.
2.2. Compatibility with RFC 1510
Implementations of RFC 1510 did not use extensible ASN.1 types.
Sending additional fields not in RFC 1510 to these implementations
results in undefined behavior. Examples of this behavior are known
to include discarding messages with no error indications.
Where messages have been changed since RFC 1510, ASN.1 CHOICE types
are used; one alternative of the CHOICE provides a message which is
wire-encoding compatible with RFC 1510, and the other alternative
provides the new, extensible message.
Implementations sending new messages MUST ensure that the recipient
supports these new messages. Along with each extensible message is a
guideline for when that message MAY be used. IF that guideline is
followed, then the recipient is guaranteed to understand the message.
2.3. Backwards Compatibility
This document describes two sets (for the most part) of ASN.1 types.
The first set of types is wire-encoding compatible with RFC 1510 and
Yu Expires: Jul 2005 [Page 7]
Internet-Draft rfc1510ter-00 21 Jan 2005
[KCLAR]. The second set of types is the set of types enabling
extensibility. This second set may be referred to as
"extensibility-enabled types". [ need to make this consistent
throughout? ]
A major difference between the new extensibility-enabled types and
[5649 lines skipped]