[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
My current thoughts on IPSEC
See below
---------------------------------------------------------------------------
Donald E. Eastlake, III DTN: 226-6577(w) dee@lkg.dec.com
550 King St, LKG2-1/BB3 1-508-486-6577(w) dee@ranger.enet.dec.com
Littleton, MA 01460 USA 1-508-486-7417(fax) 1-508-287-4877(h)
INTERNET-DRAFT PIPS: Practical IP Security
31 March 1994
Expires 30 September 1994
PIPS: Practical IP Security
----- --------- -- --------
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-ipsec-pips-00.txt, is intended to be
become a standards track RFC. Distribution of this document is
unlimited. Comments should be sent to the IP Security Working Group
mailing list <ipsec@ans.net> or to the author.
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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``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 ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au.
Abstract
[to be written]
Donald E. Eastlake 3rd [Page 1]
INTERNET-DRAFT PIPS
Table of Contents
[Table of Contents gets moved here from the end]
Donald E. Eastlake 3rd [Page 2]
INTERNET-DRAFT PIPS
1. Introduction
[To be written]
2. Overview of the Protocol
PIPS provides a wide variety of security services for datagram,
multicast, and connection oriented traffic.
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT PIPS
3. Packet Format
Below is a simplified diagram of the PIPS packet format with optional
fields omitted. After a brief description and discussion of this
simplified format, the full diagram is given followed by detailed
specifications.
SIMPLIFIED DIAGRAM
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP packet header with PIPS protocol specified |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Black Flags | Security Association ID /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* | Red Flags | Orig. Proto. | /
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
* / data part of original IP Packet /
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Authentication Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* = portion optionally encrypted
PIPS works by replacing the protocol field in the header of the IP
packet to be secured with the PIPS protocol number and then
encapsulating the replaced original protocol number and the data
portion of the original IP packet in a security envelope.
The value of the PIPS protocol type is xxx.
The original data is optionally compressed and prefixed by the
original protocol and some flags (which include a flag indicating
whether compression is in effect) and the resulting byte sequence is
optionally encrypted.
This possibly encrypted byte sequence is then prefixed by a 24 bit
Security Association ID (SAID) and some additional flags (which
include an indication of whether encryption is in effect). The final
packet is produced by calculating a digital signature across the PIPS
packet data portion thus far and selected fields from the new IP
packet header and appending this digital signature (authentication
tail) to the packet.
Authentication is applied last, as opposed to inside the encryption,
(1) to minimize the effort required by software implementations of
PIPS to reject bogus packets, and (2) to allow the creation of
"filter walls" that can screen packets enterning a nework area to
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT PIPS
allow only certain types of authorized packets without giving filter
wall computers access to the encrypted message body.
[The SAID field could be made variable length despite the additional
complexity this entails to accommodate the seeming irreconcilable
requirements by different populations of PIPS users. Those using
slower radio or serial links have argued for a one byte SAID. Others
who want to use cryptographic hardware and have the SAID be the
session key encyrpted under a host key need 64 bits or more. See the
receiver specified opaque quantity option as another way to meet this
later requirement.]
A flag indicating whether or not encryption is in effect in included
in the Black Flags field so that in cases where only authentication
is in effect routers, statistics gathering software, etc., can look
inside the PIPS packet and use the original protocol or things like
TCP header fields.
DETAILED DIAGRAM
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP packet header with PIPS protocol specified |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Black Flags | Security Association ID /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Time Stamp) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (Black Options) /
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* | Red Flags | Orig. Proto. | (true src &/or dst address(s))/
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* / (Red Options) /
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* / data part of original IP Packet /
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Authentication Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* = optionally encrypted portion
Most fields in this detailed diagram are described below.
3.1 Black Flag Bits
Bit 0 is the control bit. If it is clear, this is a data
packet. If it is set, this is a control or error packet and the
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT PIPS
"original protocol" field is actually an operation or error code.
Bit 1 is the error bit. It is meaningless if bit zero is zero.
If bit zero is a one, it indicates the packet is an error packet
instead of a control packet.
Bit 2 indicates that a 32 bit time stamp is present after the
SAID.
Bit 3 is the encryption bit. If it is on, the area marked by
asterisks at the right edge in the above diagram is encrypted.
Bit 4 is the black options bit. If on, the black options area
is non-null.
Bit 5 is reserved and must be zero.
Bits 6-7 are a two bit field which indicates the SAID type. 00
indicates a global SAID, 01 indicates a dictated SAID, 10 indicates a
negotiated SAID, and 11 is reserved.
3.2 Security Association IDentifiers
Security Association IDentifiers come in three varieties: global,
dictated, and negotiated. In all cases, an SAID can be used by a
recipient to tell what cryptographic algorithms are in use and what
the keys are or how to find this information, as well as what
compression algorithms are available.
3.2.1 Global Security Association IDentifiers
Global SAIDs are used for the most simple and fundamental case of
secure datagrams without explicit call setup. Such datagrams can be
either multicast or unicast. The Global SAIDs are defined by a
standards action and must mean the same thing to all recipients.
Global SAID zero is illegal. Global SAIDs 1 and 2 are defined below.
3.2.1.1 Global SAID One
This SAID permits an authenticated and optionally confidential packet
to be sent across the Internet with no explicit set up. The
encryption and authentication algorithms are the default RSA datagram
algorithms as described in section 4. The compression algorithm, if
used, is the default. The keys used are the private key for the
Donald E. Eastlake 3rd [Page 6]
INTERNET-DRAFT PIPS
source id and the public key for the destination id. Low level
implementations of PIPS (see Section 9) can use only the default IP
address source and destination identities (see Section 3.5.2).
3.2.1.2 Global SAID Two
Global SAID 2 is used when there is complete prior arrangement
between the parties requiring no parameters or negotiation. The
encryption, authentication, and compression algorithms are as so
arranged. The keying material must be pre-configured at both
machines or could have been arrived at in some way outside of PIPS.
3.2.2 Dictated Security Association IDentifiers
A dictated SAID is established by a transmitting entity. The SAID is
relative to the originating IP address, ie, the SAID number is
allocated by the transmitting host. This is typically used for
transmission to a multicast group where the class of receivers is
dynamic. See section 6 on control messages in relation to this type
of SAID.
3.2.3 Negotiated Security Association IDentifiers
Negotiated SAIDs can be used only in the special case of secure
unicast connections. The exchanged SAID is relative to the
destination IP address, ie, the SAID is allocated by the receiving
host. Thus this type of SAID can not be used if the destination is a
multicast group.
Such connections are set up and torn down via PIPS control messages.
They are called negotiated because the source and destination
generally have to agree on the algorithms and keys involved. See
Section 6 on PIPS control message in connection with this tpe of
SAID.
Such connections are two way and the SAID in each PIPS packet is one
assigned by and meaningful to the recipient of the packet,
3.3 Time Stamp
Optionally a 32 bit plain text time stamp can be included in the PIPS
packet. Its presence is indicated by a black flag bit. The quantity
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT PIPS
is the number of second since the beginning of 1994 until the time
the packet was assembled. The time stamp is not encrypted because
there isn't anything secret about it (it's the "current" time) and so
that it can be used in authenticating packets without/before looking
inside the encyption. The Time Stamp is included in the
authentication calculation.
3.4 Red Flag Bits
The bits in the red flags byte are defined as follows:
Bits 0-3 are reserved for future use and must be zero.
Bit 4 indicates that data compression is in effect. See section
5.
Bit 5 indicates that the source IP address is not the true
origin of the packet (eg, the original packet was encapsulated in
PIPS along the way, possibly at a firewall router). If it is on, the
red flags and original protocol bytes are immediately followed by the
true four byte source IP address.
Bit 6 indicates that the destination IP address is not the true
destination of the encapsulated packet (ie, the original packet was
encapsulated in PIPS and then address to some intermediate machine,
possibly a firewall router, before the true destination). If it is a
one, the true four byte destination IP address appears either
immediately after the red flags and original protocol bytes or after
the true source address if bit 5 is also a one.
Bit 7 indicates that the red options area is non-null.
3.5 Black / Red Options
Options can appear at two places in the PIPS format: the black
options area and the red options area. The only difference in the
two areas is that red options will be encrypted if encryption is
used. In the absence of encryption, it is better to combine the
options in one area to decrease bytes wasted on area formating
overhead. The presence of either options area is indicated by a bit
in the black and red flags bytes respectively so that no bytes need
be used up if either or both areas is unnecessary.
Although there are a wide variety of options to handle various
complexities, a Level One or Level Two implementation (see section 9)
of PIPS need not implement options at all and can respond to any PIPS
Donald E. Eastlake 3rd [Page 8]
INTERNET-DRAFT PIPS
packet having any options with an "unimplemented" error.
Each options is indicated by a one byte code followed by a length
(except for the two special codes 80 and 81 which are not followed by
any length field or data) and then zero or more bytes of data. The
option codes are the same for the black and red options areas. As
shown below, the most significant bit of the option code indicates
that understanding of the option is mandatory. As soon as an option
of this type is encountered which the receiver does not understand,
option processing may halt and an error packet must be sent back
unless the packet being received is itself an error packet.
0 1 2 3 4 5 6 7 8 ... 15/23
+---+---+---+---+---+---+---+---+-+-+-+-/-+-+-+-+
| M - option code | length |
+---+---+---+---+---+---+---+---+-+-+-+-/-+-+-+-+
M = comprehension mandatory
The length has the following format:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 - 127 | or
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 1 | 0 - 32767 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
3.5.1 Option Codes
The following subsections define the assigned option codes and list
the reserved and illegal option codes.
3.5.1.1 Mandatory Comprehension Option Codes
The current options for which comprehension is mandatory are
described below. Each paragraph begins with the option code in
hexadecimal.
80 - End of options. This code indicates the end of the
particular options area. It is NOT followed by a length code.
81 - No-op. This code is followed by no additional associated
Donald E. Eastlake 3rd [Page 9]
INTERNET-DRAFT PIPS
bytes and does nothing. It can be used as a one byte pad for
alignment or other purposes. It is NOT followed by a length code.
(Option code 01 can be used for variable length padding.)
82 - Mandatory labels. Data sensitivity and handling labels.
See section 3.5.4.
83 - Authentication algorithms list. See section 3.5.3.
84 - Encryption algorithms list. See section 3.5.3.
85 - Source identity. See section 3.5.2.
86 - Destination identity. See section 3.5.2.
87 - Receiver specified opaque quatity.
3.5.1.2 Permissive Comprehension Option Codes
The current options for which comprehension is optional are described
below. Each paragraph begins with the option code in hexadecimal.
01 - Padding. This code provides a variable length (minimum
size 2 bytes (0x0100), maximum size 32,770 bytes (0x01FFFF...))
padding field. Use option code 81 for a single byte pad.
02 - Permissive labels. Data sensitivity and handling labels.
See section 3.5.4.
03 - Compression algorithms list. See section 7.
3.5.1.3 Illegal Option Codes
The option codes consisting of all zero and all one bits (hex 00 and
FF) are illegal and will not be assigned.
3.5.1.4 Reserved Option Codes
The following ranges of option codes are reserved for future
allocation by the IANA:
[everything that's left]
Donald E. Eastlake 3rd [Page 10]
INTERNET-DRAFT PIPS
3.5.2 Source and Destination Identities
The source identity option indicates the authenticated entity
originating the encapsulated packet. The destination identity option
indicates the entity for which the packet is destined and optionally
encrypted. These options may occur only once in a PIPS packet.
There are several types of identities described below.
In the absence of source or destination identity options, the source
or destination identities are the DNS names corresponding to the
source and destination IP addresses. Thus if the PIPS packet has a
source address of x.y.z.w and there is no source identity option, the
packet is treated as if there were a DNS host name source identity of
w.z.y.x.in-addr.arpa. Note that the destination IP address may be a
multicast address.
While there are a variety of identity types, not all need be
implemented, depending of the level of implementation desired (see
section 9). Furthermore, depending on security policy, the
identities need be processed only enough to extract or retrieve and,
in some cases, authenticate the relevant public key.
00 - Illegal.
01 - DNS entity. Followed by one or more zone signed DNS
Resource Records. [See draft-ietf-dnssec-secext-*.txt] The owner
name of the first RR present is the DNS name of the source /
destination identity. The RRs present must include a signed key for
that entity. Additional signed RSA RRs are allowed to provide a
certificate chain to a zone more likely to be known to the recipient
of the PIPS packet; however, size constraints may limit how may RRs
can be included. Usual DNS name abbreviation by pointer may be done
inside the data area of this option.
02 - DNS host name. Followed by a fully qualified DNS name.
The identity is that corresponding to the IP host having that name.
For example nic.ddn.mil. In general, this type makes it necessary to
retrieve the identity's public key from the DNS. It may be
preferable to use the DNS entity type above.
03 - DNS account name. Followed by a fully qualified DNS name.
The identity is that corresponding to the account named by the first
part of the DNS name at the host corresponding to the remainder of
the DNS name. For example dee.skidrow.lkg.dec.com which corresponds
to the user dee@skidrow.lkg.dec.com. In general, this type makes it
necessary to retrieve the identity's public key from the DNS. It may
be preferable to use the DNS entity type above.
04 - RSA key owner. Followed by three bytes of unsigned
exponent and then an unsigned count byte and the count byte number of
Donald E. Eastlake 3rd [Page 11]
INTERNET-DRAFT PIPS
bytes of modulus. This data is the public version of an RSA key and
asserts only that the source/destination identity is whatever
posesses the corresponding private key. This type is included
specifically to provide for anonymous identities that are not part of
any hierarchy. In addition, the special case of a modulus length of
zero indicates the publicly anonymous and unconfirmable null
identity.
05 - OSI entity. Followed by the BER encoding of the ASN.1 for
either a DN or an X.509 certificate or a sequence of such
certificates. The DN or the DN in the first certificate is the name
of the source/destination entity. Multiple certificates are allowed
to provide a chain of authentication to a high level entity that may
be more easy to contact or confirm. However, space restrictions may
make it difficult to include more than one certificate. Provision of
just a DN will generally require retrieval of the public key from an
X.500 directory or other database containing X.509 certificates.
06 through FE - reserved for future allocation by the IANA.
FF - illegal.
3.5.3 Algorithm Lists
Algorithm list options consist of a sequence of OIDs preceeded by an
unsigned count byte giving the sequence length. Each of the three
types of option lists, encryption, authentication, and compression,
may occur only once in a PIPS packet.
During the set up of a negotiated SAID, the two parties must agree on
what encryption algorithm and authentication algorithm will be used
and what data compression algorithms will be available. The initial
Open control packet can contain a list of encryption and/or a list of
authentication algorithms that the opener would find acceptable. In
the Open acknowledge control packet, the other party must then
specify which single algorithm is to be used.
In the announcement of a dictated SAID with an Open control packet,
the sender may specify a non-default encryption and/or authentication
algorithm by including the appropriate list option with a single
algorithm secified.
Because compression is optional in each packet and can be selected
among the available algorithms on a per packet basis by the sender, a
set of compression algorithms can be established.
For a negotiated SAID, the sender of the initial Open control packet
may specify a list of compression algorithms they want to be able to
Donald E. Eastlake 3rd [Page 12]
INTERNET-DRAFT PIPS
use. The Open acknowledgement control packet then specifies the
subset of those algorithms that the receiver is also willing to use.
(This list in the open acknowledge can not be longer than that in the
original open which can be no longer than 255 algorithms.) It
defines the numbering of the available algorithms for use in the
compressed data prefix byte.
For a dictated SAID, the sender of the Open control packet may
dictate the set of compression algorithms it may use; however, it
must be certain any algorithm it uses is available to any receiver it
would like to understand compressed data.
In the absence of any algorithm list, the default algorithm is
presumed.
3.5.4 Labels
[this section needs work]
Donald E. Eastlake 3rd [Page 13]
INTERNET-DRAFT PIPS
4. Cryptographic Algorithms
The default datagram algorithms given in 4.1 below must be included
in all PIPS implementations. The default negotiated/dictated
algorithms in section 4.2 must be included in all level two or higher
PIPS implementations. The supplemental algorithms given in section
4.3 must be included in all Level Three or higher implementations.
There is no explicit provision in the PIPS formats for padding of
input to or IVP prefixing of output from encrytion algorithms. This
is all considered part of the encryption algorithm which may produce
a longer output than its input.
4.1 Default Datagram Algorithms
The default encryption algorithm is similar to PKCS#1 using the
public key of the destination identity. The data is divided into
byte sequences that are six or more bytes shorter than the public
key. Each such piece is then encoded as follows:
output = ( 02 | salt* | 00 | data ) ** e (mod n)
where "| is concatenation, 02 and 00 are bytes of that hex value, and
"salt" is at least 3 non-zero bytes of non-repeating data. (For
example, an implementation could maintain a 3 byte or larger counter
with values where any byte of the count was zero supressed and use
this as the salt. This counter would be incremented for each PIPS
packet sent. For additional padding, as might be required on the
last piece of the data, the counter bytes could be repeated as
necessary to make enough salt.)
The OID for the default datagram encrytion algorithm is xxx.
The default authentication algorithm is to calculate the MD5 hash of
the pseudo header defined above and the PIPS data area (including
possibly encrypted data) before the authentication tail and then to
digitally sign this value as per PKCS#1. That is
authentication tail = ( 01 | FF* | 00 | hash ) ** e (mod n)
The OID for the default datagram authentication algorithm is xxx.
4.2 Default Negotiated / Dictated Algorithms
The default encryption algorithm uses MD5 for key generation. MD5
produces a 128 bit block by hashing the bottom 128 bits of the shared
Donald E. Eastlake 3rd [Page 14]
INTERNET-DRAFT PIPS
key, the IP source and destination addresses, and IP packet ID, the
portion of the PIPS packet before the encrypted portion begins, and a
12 bit quantity which is a sequence count of the up to 4K 128 bit
blocks it would take to cover 64K bytes of data. As many such 128
bit blocks as necessary are computed and concatenated. The resulting
bit stream is masked to the exact length of the data to be encypted
and xor'ed with it.
Advantages of this type of encryption are that it does not expand the
data at all and that it may be possible to pre-calculate the
encryption for the next packet before the packet is available to
send. This results in better latency on packet transmission.
WARNING: It is essential that the hashed quantity be different for
every different packet sent. If the IP packet ID is used to obtain
this, there must be extremely high confidence that it will change for
each different packet and it will be necessary to re-key if more than
64K packets are sent. As an alternative, a black padding option can
be included that is a PIPS packet count. If two different messages
are ever sent with the same key generation, it may result in easy to
decode data.
The OID for this encryption algorithm is xxx.
The default authentication algorithm for negotiated / deictated SAIDs
is to calculate and MD5 message digest over a secret key and most of
the packet. The 128 bit of MD5 output are then appended to the
message as the authentication tail field.
The quantity hashed consists of the top 128 bits of the shared key,
the pseudo header defined above, and all of the PIPS packet before
the authentication tail including the possibly encrypted portion.
The OID for this authentication algorithm is xxx.
4.3 Supplemental Algorithms
[A few additional algorithms can be specified here. All Level three
or higher implementations will be required to include them. The only
things which seem like they might be worth while are DES, Triple DES,
and IDEA for encryption, and SHS for authentication.]
Donald E. Eastlake 3rd [Page 15]
INTERNET-DRAFT PIPS
5. Compression
Data compression is an important feature of the PIPS protocol.
5.1 Body Data Compression
Many encryption and essentially all digital signature techniques
increase the size of the data encrypted or authenticated. This can
lead to packet fragmentation and other significant inefficiencies
which can be partially avoided with compression.
Compression must be done before encryption because compression
depends on the redundancy in most data. After encryption, the data
appears to be random and is essentially incompressible. In some
cases, data can be very redundant with large areas of equal bytes or
the like. Without encryption, such data may be highly compressed by
low level end-to-end software, modem logic, or the like. Without a
means to compress before encryption, encryption leads to a massive
loss in efficiency.
Most popular compression algorithms are designed to compress long
sequences of bytes, such as large data files, or indefinitely long
data streams through a modem. For PIPS we need compression
algorithms that will help on a packet by packet basis. A basic
compression algorithm is decribed below. Facilities are provided to
use alternative algorithms between cooperating end points.
Compression algorithms are almost entirely orthogonal to encryption,
authentication, integrity, etc., algorithms. As a result, we
indicate the algorithm in use for a particular packet by the first
byte of data if the compression bit is on in the red flags.
5.2 Basic Compression Algorithm
The basic PIPS compression algorithm works as follows:
(1) Pick a flag byte to indicate the occurence of a compression
encoding. The should be a byte not used anywhere in the data of the
packet to be compressed or, if all 256 byte values are used, it
should be the value of one of the values used most rarely.
(2) Output a zero prefix byte to indicate that the basic compression
algorithm is in use followed by the flag byte determined in 1.
(3) Scan the input data where possible replacing sequences with the
form 1 or form 2 abbreviations shown below.
Donald E. Eastlake 3rd [Page 16]
INTERNET-DRAFT PIPS
(3.1) Form 1 is indicated by a zero most significant bit in the byte
following the flag byte as follows:
+-----------+----------+
| flag byte | 0xxyyyyy |
+-----------+----------+
xx and yyyyy are unsigned integer fields of 2 and 5 bits length. A
two byte Form 1 sequence indicates the repetition of the x+3 source
bytes starting y+x+2 bytes back in the source stream.
y=0 is special and indicates that the two byte sequence encodes a
literal occurence of the flag byte (in this case the value of x is
ignored).
(3.2) Form 2 is indicated by a most significant bit of one in the
byte following the flag byte as follows:
+-----------+----------+----------+
| flag byte | 1zzzwwww | wwwwwwww |
+-----------+----------+----------+
zzz and wwwwwwwwwwww are unsigned integer fields of 3 and 12 bits
length with the most significant part of w in the byte immediately
after the flag byte and the low order part in the next byte. A three
byte Form 2 sequence indicates the repetition of the z+4 source bytes
starting w+z+4 bytes back in the source stream.
Due to the requirement to include a two byte (zero and flag) prefix
and the encoding of a source occurence of the flag byte as two bytes
in the output, the basic compression algorithm will not compress some
input sequencess. In such cases, it should not be used and, unless
other compression is available, the source sequence should be sent as
is and the compression bit should be off in the red flags.
5.3 Header Compression
[There will be cases of host communication primarily via PIPS packets
over leased lines or the like where bandwidth or response time is at
a premium. To maximize performance under such circumstances, a
compression algorithm similar to the Van Jacobsen TCP/IP header
compression needs to be defined for PIPS.]
Donald E. Eastlake 3rd [Page 17]
INTERNET-DRAFT PIPS
6. PIPS Control/ Error Packets
PIPS control and error messages are indicated by the control bit in
the Black Flags being a one. The error bit in the Black Flags bit is
zero for control packets and a one for error packets. The normal
PIPS SAID value and type and the encrypted black flag refer to the
encryption / authentication of the control or error packet itself.
Control packets are generally used to set up and tear down negotiated
or dictated SAIDs.
Error packets are only issued in response to the receipt of an
apparently erroneous PIPS packet and include a possibly truncated and
decrypted copy of that packet. Other possible "error" conditions are
indicated by control messages.
6.1 Control Message Formats
For control packets, the "original protocol" byte is actually an
operation code.
If anything in the control packet itself is sensitive, it should be
sent encyrpted. If no appropriate connection (one with the
appropriate destination identity and destination IP address and
security) exists, sensitive control packets should be sent as Global
SAID 1 PIPS packets.
The format of the data portion of control packets is as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | Security Association IDentifier (SAID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| keying material length | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
/ keying material /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The control packet flags are defined as follows:
Bits 0-5 are reserved and must be zero.
Bits 6-7 are the SAID type. 00 indicates a global SAID which is
illegal because no operations are applicable to such SAIDs. 01
indicates a dictated SAID. 10 indicates a negotiated SAID. 11 is
reserved.
Donald E. Eastlake 3rd [Page 18]
INTERNET-DRAFT PIPS
6.2 Key Exchange
For a dictated SAID being established, the keying material is as sent
in the Open message. It must be long enough for the cryptographic
algorithms used and a minimum of 196 bits is recommended.
For a negotiated SAID being established, the ultimate keying material
is set via Diffie-Hellman key exchange. The Open contains the
quantities public-x, g, and n from the following equation:
public-x = g ** secret-x (mod n)
where n is a large prime (1000 or more bits is recommended), (n-1)/2
is also prime, and g is a primitive route of n. g, secret-x, and n
are all chosen by the party opening the negotiated connection and are
each represented as an unsigned once byte count of bytes followed by
the number. The corresponding Open Acknowledge will contain public-y
from the following equation:
public-y = g ** secret-y (mod n)
where g and n are as provided in the Open and secret y was chosen by
the party acknowledging the Open. The Opener then calculates
shared = public-y ** secret-x (mod n)
and the Acknowledger calculates
shared = public-x ** secret-y (mod n)
and the keying information used is the shared secret quantity
"shared" with its top 32 bits and bottom 32 bits discarded. The
resulting quantity must be lareg enough for the cryptographic
algorithms used. At least 196 bits is recommended.
6.3 Operation Codes
The valid PIPS operation codes which can occur in the "original
protocol" field are as follows:
[this section needs more work]
00 - Illegal.
01 - Open. This command attempts to establish a dictated or
negotiated SAID.
02 - Open Acknowledge.
Donald E. Eastlake 3rd [Page 19]
INTERNET-DRAFT PIPS
03 - Close.
04 - Close Acknowledge.
05 - Inquire. Used, for example, by someone entering a
multicast group as a receiver to inquire of a transmitter as to the
dicatated key and algorithms.
06 - Inquire Response.
07-FD - Reserved
FE - Private code. This code will never be defined by the PIPS
protocol. It is available for private use. Such use should be
avoided if there is any way to achieve the desired effect within the
defined PIPS control operations.
FF - Illegal.
[The above probably needs a simple state diagram or two.]
6.4 Error Packet Formats
Within an error packet, the "original protocol" byte is actually an
error code. The data portion of the packet is not an encapsulated IP
packet data area but rather is structured as shown below.
To avoid various possibilities of compromise, the error packet
resulting from an encrypted PIPS packet MUST always be encrypted. If
no other possibilities are available, it should be sent as a global
SAID 1 datagram. If an appropriate connection oriented SAID is
available (one with a destination ID the same as the apparent origin
ID of the erroneous packet at the same IP address as the IP source of
the erroenous packet and appropirate security and source ID), it can
be sent on that connection. (If the error concerns an SAID, that can
be extracted from the erroneous PIPS packet by tghe receiver from the
error packet.)
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-error code| starting bit | starting byte |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| error flags | ending bit | ending byte |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|length of erroneous packet data| /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
/ erroneous PIPS packet /
Donald E. Eastlake 3rd [Page 20]
INTERNET-DRAFT PIPS
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The erroneous PIPS packet is essentially as it was when the error was
detected.
The starting and ending byte and bit numbers specify a field within the
erroneous PIPS packet. If the field is actualy a field of one or more
whole bytes, the staring bit number will be 0 and the ending bit number
will be 7. Note: this may point to a location within the encrypted
portion of the original PIPS packet, such as a red option. It may also
be necessary to truncate the erroneous packet in which case bytes are
dropped from its end even if the error field was within them (almost
certainly a bad authentication tail).
The error flags are defined as follows:
Bit 0 - Encrypted. If the erroneous PIPS packet packet claims to
be encrypted and was not yet decrypted when the error was found, this
bit will be a one.
Bit 1 - Compressed. If it had been determined that the PIPS packet
claimed to be compressed and was not yet decompressed when the error was
found, this bit will be a one.
Bits 2-6 - Reserved.
Bit 7 - Truncated. Indicates that the erroneous PIPS packet had to
be truncated to fit into the error packet.
6.5 Error Codes
The valid PIPS error codes which can occur in the "original protocol"
field are as follows:
00 - Illegal code.
01 - Illegal field value.
02 - Bad Time. Time stamp field is bad. Sub-error 0 means packet
too old. Sub-error 1 means packet seems to be from the future.
03 - Unimplemented. Value specifies something that could be
implemented but is not in the implementation issuing the error packet.
04 - Unknown. Field value is something that could be bound in real
time like an SAID but appear not to be.
Donald E. Eastlake 3rd [Page 21]
INTERNET-DRAFT PIPS
05 - Duplicate. An option which is only permitted to appear once
in a packet appears twice. Field pointed to is any occurence of the
option code in the erroneous packet.
06 - Bogus. Sub-error 0 means authentication check failed. Sub-
error 1 means that decrypting failed due to apparent garbled data as
indicated by the decryption algorithm. Sub-error 2 means that
decompressing failed to to apparent garbled data as indicated by the
decompression algorithm.
07 - Insecure. Indicates a packet which violates any reasonable
security policy.
08-FE - Reserved.
FF - Illegal code.
Donald E. Eastlake 3rd [Page 22]
INTERNET-DRAFT PIPS
7. Initial Communications and New ICMP Error Code
There are several strategies that can be adopted by a host source entity
that desires security when starting to communicate with a remote entity.
Basicly you can start by sending PIPS packets, by sending non-PIPS
packets, or both. Sending both and changing to just using PIPS if you
get PIPS responses is a possible strategy, though somewhat wasteful.
A problem with simply sending PIPS and seeing if it is rejected is that
many implementations of IP erroneously fail to return a protocol-
unreachable ICMP error on receiving a packet or a protocol they do not
implement. Thus the packets may fall into a black hole and the sending
host will have to have an arbitrarily time out.
If the desired secure communications are based on DNS keys, as will most
commonly be the case, and the DNS entries show that security for the
destination entity is "mandatory", just sending PIPS packets is
reasonable.
If you just send unsecured packets and the destination has a policy of
only engaging in secure communications, some means is necessary to
indicate this. A new type of "unreachable" ICMP error code needs to be
assigned to indicate that the packet was rejected because it was not
secured with the PIPS protocol and the recipient will only communicate
with the sender using PIPS. Once the use of PIPS is established by
receipt of this ICMP, much more detailed PIPS negotiation and errors can
be used to settle security details.
Donald E. Eastlake 3rd [Page 23]
INTERNET-DRAFT PIPS
8. Decoding a PIPS Packet
This section describes, step by step, the decoding of an incoming packet
by PIPS.
NOTE: in all cases where these instructions say to return an error
control message, you should NOT do this if the erroneous packet is
itself an error. This can easily be determined by checking if both the
control and error bits are on in the Black Flags byte. You should also
NOT do this if the destination address that delivered it to you is a
multicast or broadcast address.
(1) Look at the Black Flags. If any must-be-zero bits are non-zero,
return an Illegal error packet.
(2) If the time stamp flag is on and you have a policy with respect to
stale packets, check the time. If it's bad, drop the packet and send a
Bad Time error packet back.
(3) If the black options flag is on and options are not implemented,
return an Unimplemented error packet. If the flag is on and options are
implemented, parse the black options returning an Illegal or
Unimplemented error if any illegal or unimplemented non-permissive
options are found or a Duplicate error if any options that may only
occur once are found more than once. Record the values for valid
implemented options.
(4) If this is a data packet, go to 5. If it is a control packet, go to
6. If it is an error packet, go to 7.
(5) DATA Packet
Check the SAID type and value. If the value is zero, return an
Illegal error. If the type is global and the value is greater than two
or is equal to two with no prior arrangement with the source, return an
Unimplemented error. If the type is negotiated and the SAID is unknown
to you, return an Unknown error. If the type is dictated and the SAID
is unknown then you can return an Unknown error (only if unicast) or
unicast an Inquire control message to the source (even if the
destination was multicast) to try to learn about the SAID. If the SAID
type is reserved, return an Unimplemented error.
(5.1) At this point you have a superficially valid data packet and
enought information to check the authentication tail. If authentication
fails, return a Bogus error.
(5.2) If the encryption flag is on, decrypt the data portion of the
packet using the algorithm and key you have. If the decryption
algorithm indicates the data is garbled, return an Bogus error.
(5.3) Look at the Red Flags. If any must-be-zero bits are non-zero,
Donald E. Eastlake 3rd [Page 24]
INTERNET-DRAFT PIPS
return an Illegal error packet.
(5.4) If the red options flag is on and options are not implemented,
return an Unimplemented error packet. If the flag is on and options are
implemented, parse the red options returning an Illegal or Unimplemented
error if any illegal or unimplemented non-permissive options are found
or a Duplicate error if any options that may only occur once are found
more than once (including duplication in the black options). Record the
values for valid implemented options.
(5.5) If the data is compressed, either de-compress it or return an
appropriate Illegal or Unimplemented error. If the decompression
algorithm indicates that the data is garbled, return a Bogus error.
(5.6) At this point, you are essentially done. Depending on local
implementation, you should be able to fully recontruct the encapsulated
IP packet by taking the incoming packet header, replacing the PIPS
protocol number with the original protocol, replacing the source and
destination IP addresses with the true source and destination IP
addressee if necessary, and affixing the plain text data.
(6) CONTROL Packet
xxx
(7) ERROR Packet
If the error is Illegal, Duplicate, Bogus, or Unsecure, it
indicates a real error condition, although this could be due to packet
corruption on the network or a bug in the source of the error PIPS
packet as well as a bug in the recipient of the error packet. Within
reason, such errors should be logged.
If the error is Bad Time, you may be out of synchronization with
the other end or it may just have very tight timing requirmeents. This
is likely to be a persistent error.
An Unimplemented error may indicated the need, if permitted by your
security poicy, to fall back to a a lower level of PIPS capabilities.
... Unknown
Donald E. Eastlake 3rd [Page 25]
INTERNET-DRAFT PIPS
9. Levels of Implementation
PIPS is a rich protocol containing many features and options. But it is
only necessary to implement a limited subset to get many of its
advantages. Four levels of implementation are defined below but even
the minimum level provides substantial authentication and
confidentiality.
Note that the descriptions below give only the minimum necessary to
qualify for each level. Most real implementations will include
additional features beyond the level they qualify at.
In addition, it should be noted that the requirement for certain
capabilities does not imply any obligation on any party to adopt
security policies which would actualy make use of such capabilities.
9.1 Level One Implementation
A level one implementation (PIPS-1) must include global SAID 1, the
default (IP address) source and destination identities, the default
datagram encryption and authentication algorithms, and the default
compression algorithm. It must also allow the time stamp option but
need not do anything with received time stamps. It must implement the
true source and true destination red flags. The implementation must have
access to or include a resolver that can securely retrieve keys from the
DNS. However, a PIPS-1 implementation need not include any key exchange
or connection oriented logic and need not understand or even be able to
parse options.
WARNING: Level one implementations are impractical under most
circumstances without special cryptographic hardware. Without such
hardware, the default encryption and authentication algorithms impose an
excessive computational burden. Nevertheless, there may be special
circumstances where software implementations of PIPS-1 may be useful
such as authentication of router ICMP re-direct datagrams.
Even a lowly level one implementation provides (1) authentication that
the source of an encapsulated IP packet is someone currently authorized
to speak for the source IP address, (2) assurance that the packet has
not been tampered with in transit, and (3) optional protection against
observation of the packet content by anyone not currently authorized to
hear for the destination IP address (which may be a multicast address).
However, PIPS-1 provides no inherent protection against replay attacks.
Unless the packet being encapsulated contains time stamp information or
is replay insensitive, the PIPS time stamp field should be included and
checked.
Donald E. Eastlake 3rd [Page 26]
INTERNET-DRAFT PIPS
9.2 Level Two Implementation
A level two implemetation augments PIPS-1 by adding dictated and
negotiated SAIDs and the default connection oriented encryption and
authentication algorithms. There is still no need to understand or
parse options or implement any but the default algorithms.
The connection oriented cryptographic algorithms are much less
computation intensive than the datagram cryptographic algorithms making
software implementation more practical.
PIPS-2, through the authenticated cryptographic establishment of a
random shared key, provides the additional security that even later
compromise of both hosts involved will not compromise the messages sent
over the connection as long as the shared key has been purged.
Furthermore, the existence of a uniquely keyed temporary connection
reduces the risk of replay attacks, in the absence of time stamps, to
the duration of the connection.
A PIPS-2 implementation should provide the capability, when appropriate,
to fall back to pure datagram mode when speaking securely with a PIPS-1
implementation.
9.3 Level Three Implementation
Level three implementation adds the ability to parse options and
requires the implementation of (1) the DNS oriented source/destination
identity options, (2) the key owner source/destination identity options,
and (3) the encryption and authentication algorithm list options and
recognition in these lists and implementation of all the default and
supplemental encryption and authentication algorithms defined in this
document. For example, this permits connection oriented secure traffic
using the RSA/MD5 authentication algorithm so that each packet could be
independently authenticated without looking inside any encyrption.
A PIPS-3 implementation should provide the capability, when appropriate,
to fall back to level two or level one capabilities when speaking
securely with lower level implementations.
9.4 Level Four Implementation
Level four implementation adds the high level OSI oriented source and
destination identity options. This permits a wider range of source and
destination identities and better integration with X.500 directories.
A PIPS-4 implementation should provide the capability, when appropriate,
Donald E. Eastlake 3rd [Page 27]
INTERNET-DRAFT PIPS
to fall back to lower level capabilities when speaking securely with
lower level implementations.
Donald E. Eastlake 3rd [Page 28]
INTERNET-DRAFT PIPS
10. Abbreviations
ASN.1 - OSI Abstract Syntax Notation.
BER - OSI Basic Encoding Rules.
DN - OSI Distinguished Name.
DNS - Internet Domain Name System.
IANA - Internet Assigned Numbers Authority.
IP - Internet Protocol.
OID - OSI Object IDentifier.
PIPS - Practical IP Security protocol.
RR - DNS Resource Record.
SAID - Security Association IDentifier.
X.500 - An OSI Directory System.
11. Security Considerations
The entirety of this document concerns a network level protocol to
provide packet integrity, authentication, and confidentiality for IP
protocol verison 4.
References
[PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 3
June 1991, Version 1.4.
[RFC1305] - Network Time Protocol (v3), D. Mills, April 9 1992
[SHS] - NIST FIPS PUB 180, Secure Hash Standard, National Institute of
Science and Technology, U.S. Department of Commerce, April 1993.
Donald E. Eastlake 3rd [Page 29]
INTERNET-DRAFT PIPS
Author's Address
Donald E. Eastlake 3rd
Digital Equipment Corporation
550 King Street, LKG2-1/BB3
Littleton, MA 01460
Telephone: +1 508 486 6577(w) +1 508 287 4877(h)
EMail: dee@lkg.dec.com
Expiration and File Name
This draft expires 30 September 1994.
Its file name is draft-ietf-ipsec-pips-00.txt.
Donald E. Eastlake 3rd [Page 30]
INTERNET-DRAFT PIPS
Status of This Document....................................1
Abstract...................................................1
Acknowledgements...........................................1
Table of Contents..........................................2
1. Introduction............................................3
2. Overview of the Protocol...............................3
3. Packet Format...........................................4
3.1 Black Flag Bits........................................5
3.2 Security Association IDentifiers.......................6
3.2.1 Global Security Association IDentifiers..............6
3.2.1.1 Global SAID One....................................6
3.2.1.2 Global SAID Two....................................7
3.2.2 Dictated Security Association IDentifiers............7
3.2.3 Negotiated Security Association IDentifiers..........7
3.3 Time Stamp.............................................7
3.4 Red Flag Bits..........................................8
3.5 Black / Red Options....................................8
3.5.1 Option Codes.........................................9
3.5.1.1 Mandatory Comprehension Option Codes...............9
3.5.1.2 Permissive Comprehension Option Codes.............10
3.5.1.3 Illegal Option Codes..............................10
3.5.1.4 Reserved Option Codes.............................10
3.5.2 Source and Destination Identities...................11
3.5.3 Algorithm Lists.....................................12
3.5.4 Labels..............................................13
4. Cryptographic Algorithms...............................14
4.1 Default Datagram Algorithms...........................14
4.2 Default Negotiated / Dictated Algorithms..............14
4.3 Supplemental Algorithms...............................15
5. Compression............................................16
5.1 Body Data Compression.................................16
5.2 Basic Compression Algorithm...........................16
5.3 Header Compression....................................17
6. PIPS Control/ Error Packets............................18
6.1 Control Message Formats...............................18
6.2 Key Exchange..........................................19
6.3 Operation Codes.......................................19
6.4 Error Packet Formats..................................20
6.5 Error Codes...........................................21
7. Initial Communications and New ICMP Error Code.........23
8. Decoding a PIPS Packet.................................24
Donald E. Eastlake 3rd [Page 31]
INTERNET-DRAFT PIPS
9. Levels of Implementation...............................26
9.1 Level One Implementation..............................26
9.2 Level Two Implementation..............................27
9.3 Level Three Implementation............................27
9.4 Level Four Implementation.............................27
10. Abbreviations.........................................29
11. Security Considerations...............................29
References................................................29
Author's Address..........................................30
Expiration and File Name..................................30
Donald E. Eastlake 3rd [Page 32]