INTERNET DRAFT EXPIRES FEB 1999 INTERNET DRAFT
Key Recovery Alliance TMarkham
INTERNET DRAFT Secure Computing Corporation
Catagory: Experimental August 1998
ISAKMP Key Recovery Extensions
<draft-rfced-exp-markham-01.txt>
Status of This Memo
This document is an Internet-Draft. 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."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Distribution of this document is unlimited.
This contribution has been prepared to assist the Key Recovery Alliance.
This proposal is made by the authors as a basis of discussion. This
contribution should not be construed as a binding proposal on the
authors or their companies. Specifically, the authors and their
companies reserve the right to amend or modify the statements contained
herein.
Comments on this document should be sent to key-recovery@raleigh.ibm.com.
Table of Contents
1. Introduction
2. Requirements, Goals And Issues
3. Typical Use
4. Acknowledgments
5. References
6. Security Considerations
7. Author Information
8. Appendix - Proposed DOI Values
9. Full Copyright Statement
1. INTRODUCTION
ABSTRACT
This document describes the proposed approach for negotiating and
exchanging key recovery information within the Internet Security
Association Key Management Protocol (ISAKMP).
This document describes the method for transmitting the Common Key
Recovery Block (CKRB) when two entities establish a security association
using ISAKMP [DM97]. ISAKMP is used to negotiate the mechanism to carry
key recovery information carried within the CKRB as specified in [SG98].
Section 2, Requirements, Goals And Issues, provides background
information on the technical approach and rational.
Section 3, Typical Use provides information on the Key Recovery
Mechanism (KRM) negotiation and use of the ISAKMP notify to carry the
CKRB.
Section 4, Acknowledgments
Section 5, References
Section 6, Author information
2. REQUIREMENTS, GOALS AND ISSUES
This section explains the proposed approach and rational for inserting
key recovery into ISAKMP.
2.1 Requirements and Goals
The following have been identified as requirements or goals for key
recovery within the context of ISAKMP.
o Interoperability: The key recovery mechanisms must allow
interoperability to the greatest extent allowed by the applicable
security policies. Key recovery aware implementations MUST be able to
interoperate with other key recovery aware implementations. Non-key
recovery aware implementations SHOULD be able to interoperate with key
recovery aware implementations.
o Business requirements: The key recovery mechanism must allow
organizations to comply with government regulations with respect to
the use of encryption. The mechanism must also allow an organization
to defend its business practices by monitoring intra- and
inter-organization communications within legal limits. This requires
that the organization must be able to intercept the CKRB at the time of
key establishment or periodically while the security association
remains active. This requires that the key recovery enabled entity
transmit the CKRB during the key establishment protocol and every N
hours during the security association.
o Government Requirements: Governments must be able to intercept the
CKRB at the time of key establishment or periodically while the
security association remains active. This requires that the key
recovery enabled entity transmit the CKRB during the key establishment
protocol and every N hours during the security association.
o ISAKMP compatibility: The key recovery approach must maintain
compatibility with ISAKMP.
o Security: The key recovery mechanisms must negligibly reduce the
strength of the cryptographic system.
2.2 Issues
o Subvertability: The key recovery information SHOULD be bound to the
ISAKMP negotiation in a way which makes it difficult to subvert the
key recovery function. However, the binding mechanism used SHOULD be
no stronger than necessary to meet the reasonable business and
Government evaluation criteria. Mechanisms which increase complexity
and cost beyond what is required to meet these requirements SHOULD be
avoided.
o Changing IETF ISAKMP: The IETF ISAKMP is not an RFC yet.
The key recovery mechanism must be reviewed as ISAKMP evolves.
2.3 Requirements Terminology
In this document, the words that are used to define the significance
of each particular requirement are usually capitalized. These words
are:
- MUST
This word or the adjective "REQUIRED" means that the item is an
absolute requirement of the specification.
- SHOULD
This word or the adjective "RECOMMENDED" means that there might
exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the case
carefully weighed before taking a different course.
- MAY
This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor might choose to include the item
because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit the
same item.
3. KEY RECOVERY WITHIN ISAKMP
3.1 Overview
The CKRB [SG98] may be passed across the network using two methods in
the ISAKMP/IPSEC environment. When key recovery is required and ISAKMP
is used, the CKRB MAY be transmitted in the ISAKMP notify message.
When key recovery is required and ISAKMP is not used, the CKRB MUST be
transmitted in the IPSEC Key Recovery Header (KRH).
ISAKMP will be used to negotiate the use of the KRM in much the same
way that the use of AH and ESP are negotiated. Two entities will
negotiate and pick a proposal which may include AH, ESP and the KRM.
The peer ISAKMP MUST always be notified when key recovery will be
applied to the IPSEC security association. Key recovery is not applied
to the ISAKMP Phase I security association. Some policies may allow ISAKMP to
negotiate the use of weaker cryptography (e.g., 40 bit) if the peer
device rejects the proposal(s) to do key recovery.
The values for the KRMs are defined in the IPSEC key recovery DOI. (A
draft version of the proposed DOI values are included as an appendix
to this document.) The KR negotiation addresses the following
parameters independently for initiator and responder;
- Key Recovery Mechanism: This is a security association
attribute. Example KRMs include IBM, Cylink, TIS, Any (key
recovery is required but any mechanism recognized by policy is
accepted), or none (no key recovery).
- KRH Interval: The KRH protocol is a header similar in concept to
AH. The KRH protocol is described in [CW98]. The
negotiation includes the interval, in seconds, at which the KRH
will be sent. A value of zero indicates that the KRH will never be
sent.
This negotiation and transmission of the CKRB only occurs within the
context of an ISAKMP phase 2 exchange. Key recovery is not applied to
ISAKMP phase 1 exchanges.
3.2 Exchange of CKRBs in ISAKMP
The ISAKMP proposal negotiation process allows the initiator to create
an ordered set of proposals. The responder is required to pick from
one of these proposals or send a message indicating that all proposals
were rejected. There are many permutations of sender and receiver
policies/implementations which affect interoperability. The key
recovery negotiation is actually a pair of negotiations due to the
asymmetric nature of key recovery. The initiator sends the responder
two sets of proposals. One proposal addresses what key recovery, if
any, the initiator will do. The other addresses what key recovery, if
any, the responder will do.
This subsection outlines multiple cases of exchanging the byte
oriented CKRB within the ISAKMP phase 2 exchange. Please see the ISAKMP
specification [DM99] for complete information on the negotiation
process. The integrity mechanisms to protect the CKRB are negotiated as
part of the negotiation to determine the KRM to be used.
The exchanges of interest are:
- Initiator does key recovery but responder does not
- Initiator does not do key recovery but responder does
- Initiator and responder do key recovery
Two entities which MUST perform key recovery could fail to negotiate
a security exchange if the KRM negotiation fails. A device which is
key recovery unaware cannot prevent the peer device from sending a
CKRB. The examples below provide an overview of the exchange
process. Detailed protocol information is contained in subsection
3.2.4 - Security Association and Attributes 3.2.5 - Security Protocol.
3.2.1 Initiator does key recovery but responder does not
In this example assume the initiator MUST do key recovery and the
responder will not issue a CKRB but will communicate with initiators
which issue CKRBs.
1. The initiator creates two ordered sets of proposals. The initiator
must do key recovery so all of the proposals which apply to the
initiator contain the KRM(s) as part of the proposed suite(s). The set
of proposals which apply to the responder contain key recovery and
non-key recovery options. These proposals are sent to the responder.
2. The responder picks one proposal to be applied to the initiator and
one proposal to be applied to the responder. If none of the initiator
proposals are accepted or none of the responder proposals are
accepted, the responder sends the initiator an error message
indicating the reason for the rejection.
The responder may not understand the proposals because of the KRM. If
this occurs, the initiator MAY omit the KRM from the proposals and
simply exchange the CKRB within the ISAKMP notify message. The
initiator is responsible for ensuring the lifetime of the security
association conforms to local policy.
NOTE: This could lead to situations in which key recovery is
supported without the explicit consent of the responder.
Implementations which MUST NOT support key recovery MUST terminate
the security association when a CKRB is received.
3. The initiator completes the ISAKMP exchange and sets the commit bit
within the ISAKMP header. This informs the responder that it must not
use the newly created security association until the initiator sends
an informational exchange carrying the notify payload indicating the
security association may be used.
4. The responder completes the ISAKMP exchange and waits for the
notify from the initiator.
5. The initiator prepares the notify payload containing the CKRBs. One
CKRB contains the initiator to responder key and the other CKRB contains
the responder to initiator key. The notify message value indicates
that the security association may now be used. The initiator sets the
encryption bit/flag to 0, indicating that the payload is not
encrypted, and sends this notify payload to the responder. The message
will be protected by the ISAKMP authentication mechanism but it will
not be encrypted. The authentication prevents undetected tampering
with the contents of the CKRBs yet allows the CKRBs to be intercepted.
This notify message SHOULD NOT contain payloads which require
confidentiality protection.
6. Both initiator and responder may use the security association when
the responder receives and processes the notify message. If the notify
message has been corrupted, the responder performs the standard ISAKMP
processing.
The setting and resetting of the commit bit by multiple protocols
within a single device is the local responsibility of that device.
For example, if both key recovery and ESP within the initiating device
set the commit bit, the logic within the initiating device determines
when the notify message may be sent to clear the commit bit.
3.2.2 Initiator does not do key recovery but responder does
In this example assume the initiator is not key recovery aware but the
responder must issue a CKRB. The responder is allowed to communicate
with initiators which do not issue CKRBs.
1. The initiator creates an ordered set of proposals. The initiator is
not key recovery aware so none of the proposals contain the KRM as
part of the proposed suite. These proposals are sent to the responder.
2. The responder picks one of the proposals and informs the initiator
which proposal was accepted. If none of the proposals are accepted,
the responder sends the initiator an error message indicating the
reason for the rejection.
The responder sets the commit bit within the ISAKMP header sent to the
initiator. This prevents use of the security association until after
the responder has transmitted the CKRB. The responder is responsible for
ensuring the lifetime of the security association conforms to local
policy.
3. The initiator completes the ISAKMP exchange and waits for the
notify payload from the responder.
4. The responder completes the ISAKMP exchange and sends the notify
payload containing the CKRBs. One CKRB contains the initiator to
responder key and the other CKRB contains the responder to initiator
key. The notify message value indicates that the security association
may now be used. The responder sets the encryption bit/flag to 0,
indicating that the payload is not encrypted, and sends this notify
payload to the initiator. The message will be protected by the ISAKMP
authentication mechanism but it will not be encrypted. The
authentication prevents undetected tampering with the contents of the
CKRBs yet allows the CKRBs to be intercepted. This notify message SHOULD
NOT contain payloads which require confidentiality protection.
NOTE: This could lead to situations in which key recovery is
supported without the explicit consent of the initiator.
Implementations which MUST NOT support key recovery MUST terminate
the security association when a CKRB is received.
5. Both initiator and responder may use the security association when
the initiator receives and processes the notify message.
3.2.3 Initiator and responder do key recovery
In this example assume both the initiator and responder do key
recovery.
1. The initiator creates two ordered sets of proposals. The initiator
must do key recovery so all of the proposals which apply to the
initiator contain the KRM as part of the proposed suite. The proposals
which apply to the responder allow the responder the option of doing
key recovery or not. These proposals are sent to the responder.
2. The responder picks one of the initiator proposals and one of the
responder proposals and informs the initiator which proposals were
accepted. If none of the initiator proposals or none of the responder
proposals are accepted, the responder sends the initiator an error
message indicating the reason for the rejection.
3. The initiator completes the ISAKMP exchange and sets the commit bit
within the ISAKMP header. This informs the responder that it must not
use the newly created security association until the initiator sends
an informational exchange carrying the notify payload indicating the
security association may be used.
4. The responder completes the ISAKMP exchange and also sets the
commit bit within the ISAKMP header sent to the initiator. This
prevents use of the security association until after the responder has
transmitted the CKRB.
5. The initiator prepares the notify payload containing the CKRBs. One
CKRB contains the initiator to responder key and the other CKRB contains
the responder to initiator key. The initiator sends both CKRBs even if
the responder is also performing key recovery. The notify message
value indicates that the initiator is ready to use the security
association.
The initiator sets the encryption bit/flag to 0, indicating that the
payload is not encrypted, and sends this notify payload to the
responder. The message will be protected by the ISAKMP authentication
mechanism but it will not be encrypted.
6. The responder sends the notify payload containing the CKRBs. One
CKRB contains the initiator to responder key and the other CKRB contains
the responder to initiator key. The responder sets the encryption
bit/flag to 0, indicating that the payload is not encrypted, and sends
this notify payload to the initiator. The message will be protected by
the ISAKMP authentication mechanism but it will not be encrypted.
The notify message value indicates that the security association is
cleared for use by the responder. Both initiator and responder are
able to use the security association when the initiator receives and
processes the notify message.
3.2.4 - Security Association Attributes
The key recovery mechanism to be used by each party is negotiated using
the Security Association payload, Proposal payload, Transform payload,
Security Association attribute field. The example in Figure 1 below shows
a proposal for a combined protection suite with two different protocols.
The first protocol is presented with two transforms supported by the
proposer. The second protocol is presented with a single transform. An
example for this proposal might be: Protocol 1 is ESP with Transform 1 as
3DES using key recovery as defined in the SA Attributes and Transform 2 as
40 bit RC4 with no key recovery AND Protocol 2 is AH with Transform 1 as
SHA.
Figure 1 shows the example values for the transform ID and key recovery
related fields. The attribute flag and attribute type consume 16
bits. The DOI value for the KRM uses basic encoding so it fits in 16
bits. In this example, there is no key recovery attribute associated
with the 40 bit RC4 transform.
The responder MUST select from the two transforms proposed for ESP. The
resulting protection suite will be either (1) 3DES (with key recovery) AND
SHA OR (2) 40 bit RC4 (no key recovery) AND SHA, depending on which ESP
transform was selected by the responder. Note this example is shown using
the Base Exchange.
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
/+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Nonce ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SA Pay ! Domain of Interpretation (DOI) !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! Situation !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans =2 !
\ ! ! ESP ! ! !
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Transform! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ ! ! 3DES ! !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ! SA Attributes !
| !A! Attribute Type ! AF=1 Attribute Value !
| !F! Initiator Key Recovery ! DOI value of KRM !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ !A! Attribute Type ! AF=1 Attribute Value !
\!F! Responder Key Recovery ! DOI value of KRM !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 !
\ ! ! RC4 40 ! !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
\+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Example payload containing key recovery attributes.
The protocol allows key recovery attributes to be associated with AH
(proposal 1, protocol 2 in the example above). This could be used to allow
an intermediate device such as a firewall to authenticate packets without
decrypting them. If an organization uses this feature, the CKRB intended
for the firewall SHOULD be protected using a mechanism which prevents
unwanted access by entities outside the organization.
3.2.5 - Security Protocol.
The use of the Key Recovery Header (KRH) protocol is negotiated in the
same manner as other protocols (e.g., AH and ESP). Figure 2 below shows a
proposal for a combined protection suite with 3 different protocols. The
third protocol, KRH, uses a transform ID which reflects the key recovery
mechanism as defined in the DOI. The KRH attributes (e.g., the interval
between KRH transmissions) are contained within the SA attributes for the KRH
protocol. It is not necessary (or desirable) to send the KRH on each IPSEC
packet. The intervals at which the initiator and responder send KRH
headers is established independently. A value of 0 indicates the
associated entity will never send the KRH. Thus, an initiator could send
the KRH every hour while the responder never sends the KRH.
An example for this proposal might be: Protocol 1 is ESP with Transform 1
as 3DES, AND Protocol 2 is AH with Transform 1 as SHA AND Protocol 3 is
KRH with Transform 1 as Cylink and Transform 2 as Any.
In this example, the responder MUST accept KRH and select from the two
transforms proposed for KRH. The resulting protection suite will be either
3DES (with key recovery) AND AH SHA AND KRH with (1) the Cylink mechanism OR
(2) Any CKRB mechanism authorized by the policy, depending on which KRH
transform was selected by the responder.
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
/+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Nonce ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SA Pay ! Domain of Interpretation (DOI) !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! Situation !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans =2 !
\ ! ! ESP ! ! !
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Transform! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ ! ! 3DES ! !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Transform! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans =2 !
\ ! ! ESP ! ! !
Prot 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Transform! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ ! ! Cylink ! !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ! SA Attributes !
| !A! Attribute Type ! AF=1 Attribute value !
| !F! Initiator KRH Interval ! Seconds !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ !A! Attribute Type ! AF=1 Attribute value !
\!F! Responder KRH Interval ! Seconds !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Transform! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 !
\ ! ! Any ! !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ! SA Attributes !
| !A! Attribute Type ! AF=1 Attribute value !
| !F! Initiator KRH Interval ! Seconds !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ !A! Attribute Type ! AF=1 Attribute value !
\!F! Responder KRH Interval ! Seconds !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Example payload containing a key recovery header proposal.
3.2.6 Transmission of the CKRBs
The CKRBs are transmitted in the notify payload. Each CKRB contains 1 key
so 2 CKRBs are transmitted. The first contains the initiator to responder
key and the second contains the responder to initiator key.
The key recovery mechanism uses the Commit Bit to prevent encrypted IPSEC
traffic until the CKRB pair has been transmitted. The Commit Bit is set
by either party intending to send a CKRB pair via the notify message
within an Informational Exchange. If the Commit Bit is set(1), the entity
which did not set MUST wait for an Informational Exchange containing a
Notify payload (with the CONNECTED Notify Message) from the entity which
set the Commit Bit. This indicates that the SA establishment was
successful and the receiving entity can now proceed with encrypted traffic
communication.
The CKRBs MUST be sent within the Informational Exchange and not as part
of a payload which is encrypted. The information exchange is normally
encrypted using the ISAKMP SA. The Authentication Only Bit is used to
send the informational exchange using authentication but not
encryption. This protects the CKRBs from unauthorized modification while
allowing the CKRBs to be observed.
Figure 3 shows the format of the Notification Payload containing CKRBs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Notification Data !
! Connected ! !
! Type = CKRB ! length of CKRB !
! CKRB ~
! Type = CKRB ! length of CKRB !
! CKRB ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Notification Payload Format with CKRBs
3.3 Discussion
When one of the communicating ISAKMP entities does not accept any
proposals containing the KRM, the entity performing key recovery is
responsible for ensuring that the CKRBs are transmitted at intervals
required by the situation.
Manually keyed IPSEC security associations MUST use the Key Recovery
Header to pass the CKRBs.
Some situations may require the CKRB to be retransmitted periodically.
This MAY be done via the KRH or via the ISAKMP notify message. A
second ISAKMP phase 2 exchange MUST be performed when a notify message
is used to retransmit the CKRB.
ISAKMP is defined to be key recovery tolerant. If an ISAKMP
implementation receives a well formed notify containing an unknown
CKRB, then the receiver gracefully discards the CKRB and continues the
security association. This allows key recovery enabled devices to
interoperate with legacy devices which are key recovery unaware.
4. ACKNOWLEDGMENTS
This document was produced based on the combined efforts of the
protocol subcommittee of the Key Recovery Alliance. Comments on this
document should be sent to key-recovery@raleigh.ibm.com.
5. REFERENCES
[Atk95a] Atkinson, R., "IP Authentication Header", RFC 1826, NRL,
August 1995.
[Atk95b] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
NRL, August 1995.
[CW98] Charles Williams, Tom Markham, Key Recovery Header for IPSEC,
DRAFT Key Recovery Alliance Recommendation 2, April 1998
[DoD85] US National Computer Security Center, "Department of Defense
Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US
Department of Defense, Ft. Meade, MD., December 1985.
[DM97] Internet Security Association and Key Management Protocol
(ISAKMP), Douglas Maughan, Mark Schertler, Mark Schneider, Jeff
Turner, INTERNET-DRAFT draft-ietf-ipsec-isakmp-08.txt, .ps, July 26,
1997
[DP98] The Internet IP Security Domain of Interpretation for ISAKMP
[DP98], Derrell Piper, Network Alchemy, May 12, 1998
[RA95] Security Architecture for the Internet Protocol,
R. Atkinson, Naval Research Laboratory, Request for Comments: 1825,
Category: Standards Track, August 1995
[SG98] A Common Key Recovery Block Format: promoting Interoperability
between dissimilar key recovery schemes, Sarbari Gupta, Key Recovery
Alliance Recommendation 1, April 1998
6. SECURITY CONSIDERATIONS
This entire document discusses a means to disclose cryptographic keys in
a controlled manner. The session keying material is contained in a
common key recovery block [SG98] which itself is cryptographically
protected.
Implementors must apply good coding practices to prevent the
introduction of vulnerabilities into the common key recovery block
processing.
A second security concern is the potential for unauthorized access to
the session key after the common key recovery block has been decrypted.
This protection is provided by the key recovery agent which is outside
the scope of this protocol.
The security issues associated with key recovery may be explored using
this experimental protocol in the context of a larger key recovery
system.
7. AUTHOR INFORMATION
Tom Markham
Secure Computing Corp
2675 Long Lake Road
Roseville, MN 55113 USA
Phone: 651.628.2754, Fax: 651.628.2701
EMail: tom_markham@securecomputing.com
8. APPENDIX A: Proposed DOI Values
This appendix is temporary. It will be removed and placed in a separate
DOI document if/when the key recovery documents progress through the
standards process.
The addition of key recovery to ISAKMP requires the extension of the
existing Internet IP Security Domain of Interpretation for ISAKMP
[DP98]. The following types of extensions are required.
- Protocol ID
- SA Attributes
- Transforms
An identifiers for the Type = CKRB used within the Notify must also be
defined.
A1. Protocol ID - IPSEC Security Protocol Identifier
The following table lists the values for the Security Protocol
Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC
DOI.
Protocol ID Value
----------- -----
RESERVED 0
PROTO_ISAKMP 1
PROTO_IPSEC_AH 2
PROTO_IPSEC_ESP 3
PROTO_IPCOMP 4
PROTO_KRH 5
PROTO_IPSEC_KRH
The PROTO_IPSEC_KRH type specifies IP Key Recovery Header containing a
pair of CKRBs.
A2. SA Attributes
The SA Attributes will be extended to include the following.
Attribute Types
class value type
-------------------------------------------------
SA Initiator Key Recovery TBD B
SA Responder Key Recovery TBD B
SA Initiator KRH Interval TBD B
SA Responder KRH Interval TBD B
Initiator Key Recovery indicates that the initiator will perform key
recovery. The value associated with this attribute specifies the CKRB
Transform Identifier which applies to the CKRB to be transmitted by the
initiator.
Responder Key Recovery indicates that the responder will perform key
recovery. The value associated with this attribute specifies the CKRB
Transform Identifier which applies to the CKRB to be transmitted by the
responder.
Initiator KRH Interval indicates the maximum interval between KRHs sent by
the initiator.
Responder KRH Interval indicates the maximum interval between KRHs sent by
the responder.
A3. Transforms - IPSEC CKRB Transform Identifier
The CKRB specification specifies a common wrapper for multiple key
recovery technologies each using unique transforms.
Transform ID Value
----------- -----
None 0
Any 1
Bull-P 2
Bull-G 3
Cylink 4
IBM 5
NETA 6
Novell 7
None: No key recovery is to be performed.
Any: Any key recovery mechanism recognized by the applicable policy is
acceptable.
Bull-P: The Bull transform using the ISAKMP protocol integrity mechanism.
Bull-G: The Bull transform using the split key generation mechanism.
Cylink: The Cylink CyKey mechanism together with the ISAKMP protocol
integrity mechanism.
IBM: The IBM mechanism together with the ISAKMP protocol
integrity mechanism.
NETA: The Network Associates (formerly TIS) mechanism together with the ISAKMP protocol
integrity mechanism.
Novell: The Novell mechanism together with the ISAKMP protocol
integrity mechanism.
9. FULL COPYRIGHT STATEMENT
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implmentation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
INTERNET DRAFT EXPIRES FEB 1999 INTERNET DRAFT