XXX (KINK) T. Kivinen
INTERNET-DRAFT SSH Communications Security
draft-kivinen-ike-over-kkmp-00.txt 10 August 2000
Expires: 10 February 2001
Running IKE Phase 2 over Artificial Kerberos IKE SA
Status of This Memo
This document is a submission to the IETF XXX
(KINK) Working Group. Comments are solicited and should be
addressed to the working group mailing list (ietf-kink@vpnc.org)
or to the editor.
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.
Abstract
This document defines how to create artificial IKE SA using kerberos.
It defines how to calculate SKEYID, cookies and IV needed by the IKE SA
from the Kerberos session key. After the artificial IKE SA is created,
it can be used to run normal IKE [RFC-2409] phase 2 negotiations. Those
negotiations include quick Mode (creating IPsec SA), new group mode,
delete notifications, and error notifications.
T. Kivinen [page 1]
INTERNET-DRAFT 10 August 2000
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . . 3
3. SKEYID material Calculation . . . . . . . . . . . . . . . . . . 3
4. IV and Cookie Calculation . . . . . . . . . . . . . . . . . . . 3
5. Transmitting the AP Messages Inside the IKE Payload . . . . . . 3
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
After the IKE [RFC-2409] phase 1 finishes it produces following
information that is used to create the IKE SA:
CKY-I and CKY-R
cookies used to identify the IKE SA.
SKEYID
a string derived from secret material known only to the active
players in the exchange.
SKEYID_e
keying material used by the IKE SA to protect its own messages.
SKEYID_a
keying material used by the IKE SA to authenticate its own
messages.
SKEYID_d
keying material used to derive keys for IPsec SAs.
IV
initialization vector used by the IKE SA for the phase 2 messages.
IKE SA algorithms
encryption, hash, and authentication algorithms.
The SKEYID material can easily be created from the kerberos session key
by just hashing it in the similar way they are created in the IKE
[RFC-2409]. Cookies are just random numbers, but as they should remain
constant over the negotiation between two parties, it would be desirable
to derive them from the session key so they remain constant as long as
the kerberos ticket is valid. Encryption, hash and authentication
algorithms can be fixed to be 3DES, SHA-1 and HMAC-SHA1.
The IKE SA is authenticated using the normal kerberos AP request added
to first packet in each phase 2 negotiations. The mutual authentication
is done only if the phase 2 negotiation includes multiple packets, in
which case the second packet encrypted using session key authenticates
T. Kivinen [page 2]
INTERNET-DRAFT 10 August 2000
the responder.
Before this exchange can happen the initiator must first do normal
kerberos authentication to KDC and receive valid kerberos ticket for the
responder.
2. Specification of Requirements
This document shall use the keywords "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and
"OPTIONAL" to describe requirements. They are to be interpreted as
described in [RFC-2119] document.
3. SKEYID material Calculation
>From the kerberos ticket we have the session key, which is just a shared
secret with the other host. We use that session key instead of the
Diffie-Hellman shared secret in the SKEYID calculation. Also there is no
point of including the cookies in the SKEYID calculation, as they are
generated from the session key. The SKEYID is calculated as follows:
SKEYID = kerberos_session_key
SKEYID_d = prf(SKEYID, kerberos_session_key | 0)
SKEYID_a = prf(SKEYID, SKEYID_d | kerberos_session_key | 1)
SKEYID_e = prf(SKEYID, SKEYID_a | kerberos_session_key | 2)
4. IV and Cookie Calculation
To encrypt the Phase 2 messages the IKE SA needs a "last phase 1 CBC
output block" to used to calculate the IV for the Phase 2 messages.
Because we do not have it we take the material used for the IV from the
kerberos AP message included in the phase 2. The IV then used for the
first encrypted block in the phase 2 message is derived from a hash of a
concatenation of the kerberos AP message and the phase 2 message id
using the fixed SHA-1 hash algorithm.
Cookies for the IKE SA are generated similarly from the AP message, i.e
it is taken as the 16 first bytes of the SHA-1 hash of the AP message.
Note, that this means that there will be two possible IKE SAs, one for
each direction.
5. Transmitting the AP Messages Inside the IKE Payload
The kerberos AP request and reply must be delivered from client to
server and back inside the IKE payloads, and they cannot be encrypted,
as the receiver of the packet does not yet know how to create the
encryption key because it has not yet seen the AP message. Because of
this we need to add a new payload to the beginning of each phase 2
payload and that must be transmitted without encryption. This means that
we need to define new payload type for that kerberos AP message and if
the next payload field in the generic header is that then the first
payload is in clear, and encryption starts only after that payload. The
whole packet is still authenticated as defined in [REVISED-HASH].
T. Kivinen [page 3]
INTERNET-DRAFT 10 August 2000
The final payload will look like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initiator !
! Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Responder !
! Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! NP = XXX ! MjVer ! MnVer ! Exchange Type ! Flags !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Message ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Kerberos AP message !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted phase 2 payload starts here |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Kerberos AP payload is only added to first phase 2 payload sent out
in one negotiation, i.e it is always in the first quick mode packet
going out, and it is always in all notifications and delete
notifications.
The initiator can authenticate the responder by verifying the hash
payload in the second quick mode packet. Only the responder can create
it because it knows the session key used to create authentication MAC.
Note, that when the other end responds to quick mode it will use the
same cookies that was inside the quick mode packet it received, but if
it rekeys, i.e initiates itself, then it uses cookies and IV created
from its own AP payload and adds the AP payload in the beginning of the
packet.
Also because this quick mode is normally used without PFS the responder
can immediately after receiving first packet instantiate inbound SA and
then send reply back to initiator. This means that when the initiator
receives the reply from responder it can also immediately start using
the SA without need to wait for the third message to reach the
responder. The third message only gives protection against replay
attacks and because ipsec keys are derived also from the nonces inside
the first and second packet any valid IPsec packet will also give proof
of liveliness. Thus responder can instantiate outbound SA immediately
when it receives the third quick mode message, or when it receives valid
authenticated IPsec packet for the inbound SA. This removes need for
commit bit and reduces number of round trips from 1.5 to 1 (the last
half round trip is already interleaved with the normal IPsec traffic).
This optimization should NOT be used if PFS is used, because in that
T. Kivinen [page 4]
INTERNET-DRAFT 10 August 2000
case instantiating the IPsec SA requires costly Diffie-Hellman
operation, which should be postponed to the point where replay attacks
are not possible.
6. Security Considerations
This document assumes that the session key generated by the kerberos is
safe and the whole security of the IKE SA is derived from that. The
IPsec SAs created using the Quick Mode negotiation over that IKE SA
derive entrypy also from the nonces passed in the negotiation, and also
from the Diffie-Hellman if PFS is used in the quick mode.
7. References
[REVISED-HASH] Kivinen T., "Fixing IKE Phase 1 Authentication HASH",
draft-ietf-ipsec-ike-hash-revised-01.txt (WORK IN PROGRESS)
[RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)",
November 1998
[RFC-2119] Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", March 1997
8. Authors' Addresses
Tero Kivinen
SSH Communications Security Corp
Fredrikinkatu 42
FIN-00100 HELSINKI
Finland
E-mail: kivinen@ssh.fi
T. Kivinen [page 5]