IPSEC Working Group Ashar Aziz
INTERNET-DRAFT Tom Markson
Hemma Prafullchandra
Sun Microsystems, Inc.
Expires in six months December 21, 1995
SKIP Algorithm Discovery Protocol
<draft-ietf-ipsec-skip-adp-00.txt>
Status of this Memo
This document is a submission to the IETF Internet Protocol Security
(IPSEC) Working Group. Comments are solicited and should be addressed to
to the working group mailing list (ipsec@ans.net) or to the authors.
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 draft documents are 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 learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). Distribution of this memo is unlimited.
draft-ietf-ipsec-skip-adp-00.txt [Page 1]
INTERNET-DRAFT SKIP-ADP December 21, 1995
Abstract
SKIP [1] provides privacy and authentication with Internet Protocols. It
does not define a method by which two entities may mutually agree on
encryption, authentication and compression algorithms. We describe a
protocol which will allow one SKIP entity to inform another entity of
the capabilities it supports.
draft-ietf-ipsec-skip-adp-00.txt [Page 2]
CONTENTS
Status of this Memo.................................. 1
Abstract............................................. 2
1. SKIP Algorithm Discovery............................. 3
2. Assigned Numbers..................................... 5
2.1 SKIP ICMP message (SKIP_ICMP)................... 5
3. Security Considerations.............................. 6
Acknowledgements..................................... 6
References........................................... 6
Author's Address(es)................................. 7
- i -
INTERNET-DRAFT SKIP-ADP December 21, 1995
1. SKIP Algorithm Discovery
SKIP [1] allows two entities to communicate securely with no bilateral
state other than the other party's public key. However, different
entities may have different encryption, authentication or compression
capabilities. The SKIP protocol does not define a method for
discovering the algorithms that another entity supports. SKIP Algorithm
Discovery enables one entity to inform another of the capabilities it
supports.
SKIP Algorithm Discovery is in many ways analogous to algorithm
negotiation in conventional session oriented key management schemes.
However, "negotiation" is a misnomer as applied to most existing
protocols that accommodate this feature. This is because in essence
there is no negotiation, simply a statement of capabilities on both
sides. The sides agree to pick a common subset of their capabilities.
SKIP Algorithm Discovery allows the same statement of capabilities to
occur in a stateless manner, entirely analogous to how the IP protocol
performs path MTU discovery. A SKIP implementation is free to choose a
set of algorithms with a particular node. If it chooses incorrectly, it
will discover this through an authenticated ICMP message, which is in
effect a statement of capabilities and preferences for that node.
For instance, host A attempts to talk to host B with an encryption
algorithm. Host B, however, does not support this algorithm. Host B
will send an ICMP message indicating it does not support this algorithm
and include the algorithms it does support.
RFC 1825 defines Keyed MD5 as mandatory to implement for Authentication.
The SKIP Algorithm Discovery ICMP message MUST be authenticated using
SKIP [1], AH [3] and Keyed-MD5 [5], which MUST be supported by all SKIP
nodes that support this ICMP protocol.
If a node (or communications end point) receives a SKIP packet which
specifies algorithms it does not support (or prefer), it SHOULD send an
authenticated ICMP message indicating this failure and specifying which
algorithms it supports. The ICMP Packet MUST be encapsulated using SKIP
and AH with keyed MD5 used as the authentication algorithm. Any received
algorithm discovery ICMP message that is not authenticated MUST be
ignored and SHOULD be recorded in the system log or audit log.
The ICMP message SHOULD always specify the complete set of Kij, Crypt,
MAC and compression algorithms the host supports.
draft-ietf-ipsec-skip-adp-00.txt [Page 3]
INTERNET-DRAFT SKIP-ADP December 21, 1995
The SKIP Algorithm discovery ICMP message:
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE=SKIP_ICMP| CODE | CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VER | RESRVD| Protocol | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nKij | Kij Algorithms (0-255), 1 byte each ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nCrypt | Crypt Algorithms (0-255), 1 byte each ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nmac | MAC Algorithms (0-255), 1 byte each ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ncomp | Compression Algorithms (0-255), 1 byte each ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CODE should be interpreted as a bit field in the following way:
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|I|P|M|C|R| | | |
+-+-+-+-+-+-+-+-+
I is set if the Kij algorithm in the SKIP packet is unsupported.
P is set if the Crypt algorithm in the SKIP packet is unsupported.
M is set if the MAC algorithm in the SKIP packet is unsupported.
C is set if the compression algorithm in the SKIP packet is
unsupported.
R is set if replay protection is required but was not used
in the SKIP packet. In case a replay protection mechanism
is defined, this bit MAY be used to request replay protection.
bits 0-2 are reserved and MUST be set to 0 by the sender and ignored
by the receiver.
The ICMP type field SKIP_ICMP is specified later in this document.
The first field "VER" specifies the version of the ICMP message. The
Version of the protocol described here is 1.
RESRVD specifies a reserved field. This field MUST be set to zero (0)
by the sender and ignored by the receiver.
draft-ietf-ipsec-skip-adp-00.txt [Page 4]
INTERNET-DRAFT SKIP-ADP December 21, 1995
The next two fields "Protocol" and "Port Number", indicate if this
algorithm discovery is to be applied only for a particular protocol/port
# pair. This allows different communication end-points on an IP node to
use different algorithms. An example of the protocol field could be the
TCP protocol, followed by the port # which would identify a TCP end-
point. If the Protocol field is non-zero, then the algorithm discovery
packet MUST be applied ONLY for the specified communications end-point,
as identified by the (Protocol, Port Number) fields.
If the algorithms are to be used on a per Master Key-ID, rather than a
per communications end-point basis, then the "Protocol" field MUST be
zero. If the "Protocol" field is zero, the Port Number field MUST be
ignored. In this case, the algorithms SHOULD be used on a per Master
Key-ID basis, where the Master Key-ID is the Source Master Key-ID in the
SKIP_ICMP SKIP header. If the source Master Key-ID is absent from the
SKIP header, then the algorithms SHOULD be used on a per node basis,
using the source IP address of SKIP_ICMP message as the node identifier.
The nKij, ncrypt, nmac and ncomp fields should be filled in with the
number of Kij, Crypt, MAC and Compression algorithms the system
supports, respectively. If the system does not support a particular
class of algorithms, the field should be set to 0. For example, if a
system does not support compression, it would set ncomp to 0.
The Kij, Crypt, MAC and Compression algorithms fields should be filled
in sequentially with the one byte identifiers for each of the algorithms
that the system supports. The algorithms should be an ordered list with
the most desirable algorithms first and the least desirable last.
For example, if the system supports 5 Kij algorithms, nKij would be set
to 5 and the Kij Algorithms field would be 5 bytes long (one byte for
each algorithm supported).
A host may elicit a SKIP_ICMP message by sending a SKIP packet to the
remote host with Kij Alg set to zero.
2. Assigned Numbers
2.1 SKIP ICMP message (SKIP_ICMP)
The SKIP algorithm discovery ICMP message has been assigned the type 39
(SKIP_ICMP) by the Internet Assigned Numbers Authority (IANA).
draft-ietf-ipsec-skip-adp-00.txt [Page 5]
INTERNET-DRAFT SKIP-ADP December 21, 1995
3. Security Considerations
Security issues are the primary topic of this memo.
Unauthenticated SKIP Algorithm Discovery messages or messages which fail
authentication MUST be discarded.
Acknowledgements
We would like to thank all of the people who helped make this draft
possible.
Martin Patterson and Joseph Reveane for their help in the design of this
protocol.
Germano Caronni for his help in reviewing this protocol.
Ran Atkinson for suggesting this protocol be independent of the primary
SKIP document.
Bill Danielson, Marc Dye, Colin Plumb, Rich Skrenta and Ben Stoltz for
reviewing this draft and providing constructive suggestions.
References
[1] Aziz, A., Markson, T., Prafullchandra, H., "Simple Key Management
for Internet Protocols", (I-D draft-ietf-ipsec-skip-06.txt), Work In
Progress
[2] Atkinson, R., "Security Architecture for the Internet Protocol", RFC
1825, August 1995
[3] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995
[4] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April 1992
[5] Metzger, P., Simpson, W., "IP Authentication using Keyed MD5", RFC
1828, August 1995
draft-ietf-ipsec-skip-adp-00.txt [Page 6]
INTERNET-DRAFT SKIP-ADP December 21, 1995
Author's Address(es)
Ashar Aziz
Sun Microsystems, Inc.
M/S PAL1-550
2550 Garcia Avenue
Mountain View, CA 94043
Email: ashar.aziz@eng.sun.com
Alternate email address: ashar@incog.com
Tom Markson
Sun Microsystems, Inc.
M/S PAL1-550
2550 Garcia Avenue
Mountain View, CA 94043
Email: markson@incog.com
Alternate email address: markson@eng.sun.com
Hemma Prafullchandra
Sun Microsystems, Inc.
M/S PAL1-550
2550 Garcia Avenue
Mountain View, CA 94043
Email: hemma@eng.sun.com
Alternate email address: hemma@incog.com
draft-ietf-ipsec-skip-adp-00.txt [Page 7]
