[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, 19 Oct 2005 22:00:23 +0200 |
Update of /home/cvs/shishi/doc/specifications
In directory dopio:/tmp/cvs-serv24600
Added Files:
draft-ietf-krb-wg-kerberos-set-passwd-04.txt
Log Message:
Add.
---
/home/cvs/shishi/doc/specifications/draft-ietf-krb-wg-kerberos-set-passwd-04.txt
2005/10/19 20:00:23 NONE
+++
/home/cvs/shishi/doc/specifications/draft-ietf-krb-wg-kerberos-set-passwd-04.txt
2005/10/19 20:00:23 1.1
Kerberos Working Group Nicolas Williams
INTERNET-DRAFT Sun Microsystems
Expires: August 22, 2005 October 2005
Kerberos Set/Change Password: Version 2
<draft-ietf-krb-wg-kerberos-set-passwd-04.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on April 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document specifies an extensible protocol for setting keys and
changing the passwords of Kerberos V principals.
Table of Contents
1 Introduction
2 The Protocol
2.1 Transports
2.2 Protocol Framing
2.3 Protocol version negotiation
2.3.1 Protocol Major Version Negotiation
2.3.2 Protocol Minor Version Negotiation
2.4 Use of Kerberos V
N. Williams [Page 1]
DRAFT Kerberos Set/Change Password v2 Expires April 2006
2.5 Use of ASN.1
2.6 Internationalization
2.6.1 Normalization Forms for UTF-8 Strings
2.6.2 Language Negotiation
2.7 Protocol Extensibility
2.8 Protocol Subsets
3 Protocol Elements
3.1 PDUs
3.2 Operations
3.2.1 Null
3.2.2 Change Kerberos Password
3.2.3 Set Kerberos Password
3.2.4 Set Kerberos Keys
3.2.5 Generate Kerberos Keys
3.2.6 Get New Keys
3.2.7 Commit New Keys
3.2.8 Get Password Quality Policy
3.2.9 Get Principal Aliases
3.2.10 Get Realm's Supported Kerberos V Version and Features
4 ASN.1 Module
6 IANA Considerations
7 Security Considerations
8 Acknowledgements
9 References
9.1 Normative References
9.2 Informative References
10 Authors' Addresses
11 Notes to the RFC Editor
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 [RFC2119].
1 Introduction
Up to this point Kerberos V has lacked a single, standard protocol
for changing passwords and keys. While several vendor-specific
protocols exist for changing Kerberos passwords/keys, none are
properly internationalized and all are incomplete in one respect or
another and none are sufficiently extensible to cope with new
features that may be added to Kerberos V at some future time.
This document defines a protocol that is somewhat backward-compatible
with the "kpasswd" protocol defined in [RFC3244] that uses more or
less the same protocol framing.
This new protocol is designed to be extensible and properly
internationalized.
2 The Protocol
N. Williams [Page 2]
DRAFT Kerberos Set/Change Password v2 Expires April 2006
The structure of the protocol is quite similar to that of typical RPC
protocols. Each transaction consists of a data structure specific to
an operation which is then wrapped in a data structure which is
general to all operations of the protocol. These data structures are
defined with the Abstract Syntax Notation 1 (ASN.1) [X680] and they
are encoded using the Distinguished Encoding Rules (DER) [X690].
All protocol data is wrapped KRB-PRIV messages, or, in some cases, a
KRB-ERROR, and framed in a header that is backwards compatible with
[RFC3244].
2.1 Transports
The service supports only connection-oriented transports,
specifically TCP, and MUST accept requests on TCP port 464, the same
as in [RFC3244].
2.2 Protocol Framing
Requests and responses are exchanged using the same framing as in
[RFC3244], but with the following differences:
- the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1)
- the 'AP-REQ length' field of the request can be set to 0x0, in
which case the 'AP-REQ' field of the request is excluded
- the 'KRB-PRIV' field of the request and reply is mutually
exclusive with the 'AP-REQ' field of the request
- the 'AP-REP length' field of the reply can be set to 0x0, in
which case the 'AP-REP' field of the reply is excluded
- all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can
be or has been accepted by the server
- any KRB-ERROR messages are framed and sent in the 'AP-REP' field
of the reply
The initial message from the client MUST carry an AP-REQ and the
response to any request bearing an AP-REQ MUST carry an AP-REP or
MUST be a KRB-ERROR.
Subsequent messages exchanged on the same TCP connection MAY involve
Kerberos V AP exchanges, but generally the client SHOULD NOT initiate
a new AP exchange except when it desires to authenticate as a
different principal, when the ticket last used for authentication
expires or when the server responds with an error indicating that the
client must re-authenticate.
2.3 Protocol Version Negotiation
There are several major versions of this protocol. Version 2 also
N. Williams [Page 3]
DRAFT Kerberos Set/Change Password v2 Expires April 2006
introduces a notion of protocol minor versions for use in negotiating
protocol extensions. As of this time only one minor version is
defined for major version 2: minor version 0, defined herein.
2.3.1 Protocol Major Version Negotiation
Version 2 clients that also support other versions, such as 0xff80,
as in [RFC3244], SHOULD attempt to use version 2 of the protocol
first.
Servers which do not support version 2 of this protocol typically
include their preferred version number in the reply and/or may
include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a
status code of KRB5_KPASSWD_MALFORMED.
Note that some [RFC3244] server implementations close the TCP
connection without returning any other response. Note also that
there is no integrity protection for the major version number in the
protocol framing or for any data in a KRB-ERROR.
As a result change password protocol major version negotiation is
subject to downgrade attacks. Therefore major version negotiation is
NOT RECOMMENDED.
Where the server indicates that it does not support version 2, the
client MAY, but SHOULD NOT, unless configured to do so, fall back on
another major version of this protocol.
Version 2 servers MAY respond to non-v2 requests using whatever
response is appropriate for the versions used by the clients, but if
a server does not do this or know how to do this then it MUST respond
with an error framed as in section 2.2, using an AP-REP and KRB-PRIV
if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and
using a ProtocolErrorCode value of unsupported-major-version.
It is expected that implementations of as yet unspecified future
major versions of this protocol will be required to support version 2
integrity protected error replies for properly indicating no support
for version 2 of the protocl. We also hope that no further major
versions of this protocol will be needed.
2.3.2 Protocol Minor Version Negotiation
Version 2 clients are free to use whatever protocol minor version and
message extensions are available to them in their initial messages to
version 2 servers, provided that the minor versions (other than 0)
have been defined through IETF documents.
Version 2 servers MUST answer with the highest protocol minor version
number supported by the server and the client.
Version 2 clients MUST use the protocol minor version used in a
server's reply for any subsequent messages in the same TCP session.
N. Williams [Page 4]
DRAFT Kerberos Set/Change Password v2 Expires April 2006
See section 2.7 for further description of the protocol's
extensibility and its relation to protocol minor versions and the
negotiation thereof.
2.4 Use of Kerberos V and Key Exchange
This protocol makes use of messages defined in [RFC1510] and
[clarifications]. Specifically, AP-REQ, AP-REP, KRB-ERROR and
KRB-PRIV.
All operations are to be performed by the server on behalf of the
client principal.
Clients SHOULD use "kadmin/setpw" as the principal name of the server
for all requests except when changing the client principal's own
expired password, for which they should use "kadmin/changepw". The
"kadmin/changepw" service exists to allow KDCs to limit principals
with expired passwords to getting initial tickets to the password
changing service only and only for changing expired passwords.
Servers MUST limit clients that used the "kadmin/changepw" service
principal name to changing the password of the client principal.
The client MUST request mutual authentication and the client MUST
MUST request the use of sequence numbers.
Clients SHOULD use INITIAL tickets for requests whose target
principal is the client's principal. Servers SHOULD force the use of
INITIAL tickets for such requests and MAY force the use of INITIAL
for all others - see section 3.2.
Servers MUST specify a sub-session key.
The encrypted part of KRB-PRIVs MUST be encrypted with the server's
sub-session key and key usage 20 (client->server) or 21
(server->client).
After each new AP exchange the client and server MUST destroy the
session keys, if any, resulting from the previous AP exchange.
2.5 Use of ASN.1
This protocol's messages are defined in ASN.1, using only features
from [X680]. All ASN.1 types defined herein are to be encoded in
DER [X690]. A complete ASN.1 module is given in section 4.
The DER encoding of the ASN.1 PDUs are exchanged wrapped in a
KRB-PRIV as described above and/or as e-data in KRB-ERROR messages.
2.6 Internationalization
This protocol's request PDU carries an optional field indicating the
N. Williams [Page 5]
DRAFT Kerberos Set/Change Password v2 Expires April 2006
languages spoken by the client user; the client SHOULD send its list
of spoken languages to the server (once per-TCP session).
The server SHOULD localize all strings intended for display to users
to a language in common with the languages spoken by the client user.
Strings for Kerberos principal and realm names used in this protocol
are be constrained as per [clarifications].
2.6.1 Normalization Forms for UTF-8 Strings
Because Kerberos V [clarifications] restricts principal names, realm
names and passwords to IA5String, this protocol uses UTF8String with
an extensible constraint to IA5String.
Future versions of Kerberos may relax this constraint; if so then a
minor version of this protocol should relax this constraint
accordingly.
2.6.2 Language Negotiation
The server MUST pick a language from the client's input list or
the default language tag (see [RFC3066]) for text in its responses
which is meant for the user to read.
The server SHOULD use a language selection algorithm such that
consideration is first given to exact matches between the client's
spoken languages and the server's available locales, followed by
"fuzzy" matches where only the first sub-tags of the client's
language tag list are used for matching against the servers available
locales.
Servers MUST cache the optional language tag lists from prior
requests for use with subsequent requests that exclude the language
tag list. Clients MAY expect such server behaviour and send the
language tag lists only once per-TCP session. Clients SHOULD send
the server the language tag list at least once.
When the server has a message catalog for one of the client's spoken
languages the server SHOULD localize any text strings intended for
display to users.
2.7 Protocol Extensibility
The protocol is defined in ASN.1 and uses extensibility markers
throughout. As such, the module presented herein can be extended
within the framework of [X680].
Typed holes are not used in this protocol as it is very simple and
does not require the ability to deal with abstract data types defined
in different layers. For this reason, the only way to extend this
protocol is by extending the ASN.1 module within the framework of the
IETF; all future extensions to this protocol have to be defined in
N. Williams [Page 6]
DRAFT Kerberos Set/Change Password v2 Expires April 2006
IETF documents unless otherwise specified in a future IETF revision
of this protocol.
A protocol minor version number is used to negotiate use of
extensions. See section 2.3.2 for the minor version negotiation.
Servers SHOULD ignore unknown additions to the ASN.1 types, in
initial requests, where the syntax allows them, except for extensions
to the "Op-req" type, which MUST result in an error.
Servers MUST respond with an error (ProtocolErrorCode value of
unsupported-minor-version) to clients that use operations unknown to
the server.
2.8 Protocol Subsets
The structure of the protocol is such that the ASN.1 syntaxes for the
various operations supported by the protocol are independent of the
each other. Client and server implementations MAY implement subsets
of the overall protocol by removing some alternatives to the Op-req,
Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4.
For example, it should be possible to have a password-change only
client that cannot set principal's keys - and vice versa.
3 Protocol Elements
The protocol as defined herein supports the following operations
relating to the management of Kerberos principal's passwords or keys:
[NOTE: New since last version of this I-D.]
- get principal's current and preferred string-to-key parameters
- change password (or enctypes and string-to-key parameters)
- set password (administrative)
- set new keys
- generate new keys
- get new, un-committed keys
- commit new keys
- get password policy name and/or description of principal
- list aliases of a principal
- list enctypes and version of Kerberos V supported by realm
The operation for retrieving a list of aliases of a principal is
needed where KDCs implement aliasing of principal names and allows
clients to properly setup their key databases when principal aliasing
is in use.
Operations such as creation or deletion of principals are outside the
scope of this document, and should be performed via other means, such
[1387 lines skipped]