[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: |
Fri, 27 May 2005 21:55:16 +0200 |
Update of /home/cvs/shishi/doc/specifications
In directory dopio:/tmp/cvs-serv2996
Added Files:
draft-ietf-kink-kink-07.txt
Log Message:
Add.
--- /home/cvs/shishi/doc/specifications/draft-ietf-kink-kink-07.txt
2005/05/27 19:55:16 NONE
+++ /home/cvs/shishi/doc/specifications/draft-ietf-kink-kink-07.txt
2005/05/27 19:55:16 1.1
INTERNET-DRAFT Shoichi Sakane
KINK Working Group Ken'ichi Kamada
Yokogawa Electric Corp.
M. Thomas
J. Vilhuber
Cisco Systems
Expires: November 28, 2005 May 27, 2005
Kerberized Internet Negotiation of Keys (KINK)
draft-ietf-kink-kink-07.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 document is a submission by the KINK Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the KINK mailing list (address@hidden). You can subscribe by
sending mail to address@hidden with a line in the body of
the mail with the word SUBSCRIBE in it.
Distribution of this memo is unlimited.
This Internet-Draft expires in November 28, 2005.
Thomas, Vilhuber [Page 1]
^L
Internet-Draft KINK May 2005
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document describes the Kerberized Internet Negotiation of Keys
protocol (KINK) and the domain of interpretation (DOI). KINK defines
a low-latency, computationally inexpensive, easily managed, and
cryptographically protocol to establish and maintain IPsec security
associations (SAs) using the Kerberos authentication system. KINK
reuses the payloads of Quick Mode of the Internet Key Exchange (IKE),
which should lead to substantial reuse of existing IKE
implementations.
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.
It is assumed that the reader is familiar with the terms and concepts
described in the Kerberos version 5 [KERBEROS], IPsec [IPSEC] and IKE
[IKE].
Thomas, Vilhuber [Page 2]
^L
Internet-Draft KINK May 2005
Table of Contents
1. Introduction ................................................. 5
2. Terminology .................................................. 5
3. Protocol Overview ............................................ 6
4. Message Flows ................................................ 6
4.1. Standard KINK Message Flow .............................. 6
4.2. GETTGT Message Flow ..................................... 7
4.3. CREATE Security Association ............................. 7
4.3.1. CREATE Key Derivation Considerations ............. 8
4.4. DELETE Security Association ............................. 9
4.4.1. Rekeying Security Associations ................... 10
4.4.2. Dead Peer Detection .............................. 11
4.5. STATUS Message Flow ..................................... 12
5. KINK Message Format .......................................... 12
5.1. KINK Payloads ........................................... 15
5.1.1. KINK Padding Rules ............................... 16
5.1.2. KINK_AP_REQ Payload .............................. 16
5.1.3. KINK_AP_REP Payload .............................. 17
5.1.4. KINK_KRB_ERROR Payload ........................... 18
5.1.5. KINK_TGT_REQ Payload ............................. 19
5.1.6. KINK_TGT_REP Payload ............................. 20
5.1.7. KINK_ISAKMP Payload .............................. 21
5.1.8. KINK_ENCRYPT Payload ............................. 22
5.1.9. KINK_ERROR Payload ............................... 23
6. KINK Quick Mode Payload Profile .............................. 23
6.1. General Quick Mode Differences .......................... 24
6.2. Security Association Payloads ........................... 24
6.3. Proposal and Transform Payloads ......................... 25
6.4. Identification Payloads ................................. 25
6.5. Nonce Payloads .......................................... 25
6.6. Notify Payloads ......................................... 25
6.7. Delete Payloads ......................................... 26
6.8. KE Payloads ............................................. 26
7. IPsec DOI Message Formats .................................... 27
7.1. REPLY Message Considerations ............................ 27
7.2. ACK Message Considerations .............................. 27
7.3. CREATE Message .......................................... 28
7.4. DELETE Message .......................................... 29
7.5. STATUS Message .......................................... 30
8. Key Derivation ............................................... 31
9. Transport Considerations ..................................... 32
10. Security Considerations ...................................... 32
10.1. Security Policy Database Considerations ................ 33
11. IANA Considerations .......................................... 34
12. Forward Compatibility Considerations ......................... 34
12.1. New Versions of Quick Mode ............................. 34
12.2. New DOI ................................................ 35
Thomas, Vilhuber [Page 3]
^L
Internet-Draft KINK May 2005
13. Related Work ................................................. 35
14. Acknowledgments .............................................. 36
15. References ................................................... 36
15.1. Normative References ................................... 36
15.2. Informative References ................................. 37
Authors' Addresses ............................................... 37
Change History (To be removed from RFC) .......................... 38
Full Copyright Statement ......................................... 38
Intellectual Property Statement .................................. 38
Thomas, Vilhuber [Page 4]
^L
Internet-Draft KINK May 2005
1. Introduction
KINK is designed to provide a secure, scalable mechanism for
establishing keys between communicating entities within a centrally
managed environment in which it is important to maintain consistent
security policy. The security goals of KINK are to provide privacy,
authentication, and replay protection of key management messages, and
to avoid denial of service vulnerabilities whenever possible. The
performance goals of the protocol are to incur a low computational
cost, to have low latency, to have a small footprint, and to avoid or
minimize the use of public key operations. In particular, the
protocol provides the capability to establish IPsec security
associations in two messages with minimal computational effort.
Kerberos [KERB] and [KERBEROS] provides an efficient authentication
mechanism for clients and servers using trusted third-party model.
(Kerberos also provides an mechanisms for inter-realm authentication
natively.) A client obtains a ticket from an online authentication
server (the Key Distribution Center or KDC). The ticket is then used
to construct a credential for authenticating the client to the
server. As a result of this authentication operation, the client and
the server will also share a secret key. KINK uses this property as
the basis of distributing keys for IPsec.
The central key management provided by Kerberos is efficient because
it limits computational cost and limits complexity versus IKE's [IKE]
necessity of using public key cryptography. Initial authentication
to the KDC may be performed using either symmetric keys or asymmetric
keys using [PKINIT]; however, subsequent requests for tickets, as
well as authenticated exchanges between client and server always
utilize symmetric cryptography. Therefore, public key operations (if
any) are limited and are amortized over the lifetime of the initial
authentication operation to the Kerberos KDC. For example, a client
may use a single public key exchange with the KDC to efficiently
establish multiple security associations with many other servers in
the extended realm of the KDC. Kerberos also scales better than
direct peer to peer keying when symmetric keys are used. The reason
is that since the keys are stored in the KDC, the number of principal
keys is O(n) rather than O(n*m), where "n" is the number of clients
and "m" is the number of servers. Kerberos, like any internet
protocol, does have its own security considerations. You can find
them discussed in [KERBEROS] and [KERB].
2. Terminology
Editor's comment: remain it for the order of sections referred from
Thomas, Vilhuber [Page 5]
^L
Internet-Draft KINK May 2005
the issue list.
3. Protocol Overview
KINK is a command/response protocol which can create, delete, and
maintain IPsec security associations. Each command or response
contains a common header along with a set of type-length-value
payloads which are constrained according to the type of command or
response. KINK itself is a stateless protocol in that each command
or response does not require storage of hard state for KINK. This is
in contrast to IKE's use of Main Mode to first establish an ISAKMP
security association followed by subsequent Quick Mode exchanges.
KINK uses Kerberos mechanisms to provide mutual authentication and
replay protection. For security association establishment, KINK
provides privacy of the payloads which follow the Kerberos
authenticator. KINK's design mitigates denial of service attacks by
requiring authenticated exchanges before the use of any public key
operations and the installation of any state. KINK also provides the
means of using Kerberos User-to-User mechanisms when there isn't a
key shared between the server and the KDC. This is typically, but
not limited to, the case with IPsec peers using [PKINIT] for initial
authentication.
KINK directly reuses Quick Mode payloads defined in section 5.5 of
[IKE], with some minor changes and omissions. In most cases, KINK
exchanges are a single command and its response. The exception is
that the CREATE command may have a third message. When the responder
disagrees with the optimistic proposal, it requests the third
message, an acknowledgement, to the initiator in order to complete a
non-optimistic keying. KINK also provides rekeying and dead peer
detection.
4. Message Flows
KINK message flows all follow the same pattern between the two peers:
a command, a response, and a possible acknowledgment with CREATE's.
The actual Kerberos KDC traffic here is for illustrative purposes
only. In practice, when a principal obtains various tickets is a
subject of Kerberos and local policy consideration. In these flows,
we assume that A and B both have TGT's from their KDC.
4.1. Standard KINK Message Flow
Thomas, Vilhuber [Page 6]
^L
Internet-Draft KINK May 2005
A B KDC
------ ------ ---
1 COMMAND------------------->
2 <------------------REPLY
3 [ ACK---------------------> ]
Figure 1: KINK Message Flow
4.2. GETTGT Message Flow
If the initiator determines that it will not be able to get a normal
service ticket for the responder (e.g., B is a client principal), it
MUST first fetch the TGT from the responder in order to get a User-
to-User service ticket:
A B KDC
------ ------ ---
1 GETTGT+KRB_TGT_REQ------->
2 <-------REPLY+KRB_TGT_REP
3 TGS-REQ+TGT(B)------------------------------------->
4 <--------------------------------------------TGS-REP
Figure 2: GETTGT Message Flow
4.3. CREATE Security Association
This flow instantiates a security association. The CREATE command
takes an "optimistic" approach where security associations are
initially created on the expectation that the responder will choose
the initial proposed payload. The optimistic proposal is defined as
the first transform of the first proposal of the first conjugate.
The initiator MUST check to see if the optimistic proposal was
selected by comparing all transforms and attributes which MUST be
identical from those in the initiator's optimistic proposal with the
exceptions of LIFE_KILOBYTES and LIFE_SECONDS. Each of these
attributes MAY be set to a lower value by the responder and still
expect optimistic keying, but MUST NOT be set to a higher value which
MUST generate an error.
CREATE'ing a security association on an existing SPI is an error in
KINK and MUST be rejected with an ISAKMP notification of INVALID-SPI.
Thomas, Vilhuber [Page 7]
^L
Internet-Draft KINK May 2005
A B KDC
------ ------ ---
[1731 lines skipped]