Network Working Group William A. Nace(NSA)
Internet Draft James E. Zmuda(SPYRUS)
expires in six months November 21st, 1997
PPP Fortezza Encryption Encapsulation Protocol
<draft-ietf-pppext-feep-01.txt>
Status of this Memo
This document is a submission to the Point-to-Point Protocol
Extensions Working Group of the Internet Engineering Task Force
(IETF). Comments should be submitted to the ietf-ppp@merit.edu
mailing list.
Distribution of this memo is unlimited.
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 not appropriate 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 ds.internic.net (US East Coast),
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim).
Abstract
The Point-to-Point Protocol (PPP) [1] provides a standard method
for transporting multi-protocol datagrams over point-to-point
links
PPP also defines an extensible Link Control Protocol, which
allows negotiation of an Authentication Protocol for
authentication of its peer before allowing Network Layer
protocols to transmit over the link.
One of the Authentication protocols that can be negotiated is
Nace & Zmuda Expires in six months [Page 1]
DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997
the EAP. The EAP can be used in any of a number of variants.
When the EAP is used in it's KEA variant, this results in mutual
authentication and key generation. This key is available for
use during the PPP data transfer phase by an encryption
encapsulation. The encryption encapsulation that is described
in this memo is one possible encapsulation that can use the
keying material generated by the EAP KEA protocol.
1. Introduction
The PPP encryption encapsulation will take a PPP packet including the
protocol field, apply the chosen encryption algorithm, place the
resulting cipher text (and in this specification, an explicit
sequence number) in the information field of another PPP packet. The
decryptor will apply the inverse algorithm and interpret the result-
ing plain text as if it were a PPP packet which had arrived directly
on the interface.
1.1. Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
MUST This word, or the adjective required, means that the
definition is an absolute requirement of the specifi-
cation.
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
SHOULD This word, or the adjective recommended, means that
there may exist valid reasons in particular cir-
cumstances to ignore this item, but the full implica-
tions must be understood and carefully weighed before
choosing a different course.
MAY This word, or the adjective optional, means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST
be prepared to interoperate with another implementa-
tion which does include the option.
1.2. Terminology
This document frequently uses the following terms:
Nace & Zmuda Expires in six months [Page 2]
DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997
Cryptographic Algorithm
The algorithm used to encrypt data. In the Fortezza
Encryption Encapsulation Protocol, the Cryptographic
Algorithm is Skipjack.
Cryptographic mode
Block ciphers may be used in several different
manners, known as modes. The basic mode of operation
of a block cipher is called Electronic Code Book
(ECB). This mode always produces the same block of
ciphertext as output for the same block of ciphertext
as input. In the interest of increasing the random
character of the outputs of encipherment other modes
were introduced. One such mode is called Cipher Block
Chaining (CBC).
Cipher Block Chaining (CBC)
The CBC mode of operation for Block Ciphers was intro-
duced to further obscure the relationship between the
ciphertext blocks and the actual input data blocks by
manipulating the input data block before encipherment.
Block ciphers in CBC mode exhibit the property that
the result of an encryption or decryption is deter-
mined by not only the value of this particular block
of data, but also the value of the ciphertext from the
previous block. Hence the term "Chaining" in the name.
Cryptographic Synchronization
For Block ciphers in CBC mode the loss of a block of
data will result in not only failing to decrypt that
block, but may also result in failure to decrypt the
immediately succeeding block. This condition is known
as a loss of "cryptographic synchronization." Note
that for block mode algorithms in CBC mode, the loss
of cryptographic synchronization only persists for one
block after the missing block in the case of decryp-
tion. On the other hand, any error during the encryp-
tion process will propagate through all subsequent
blocks. This is not however, strictly speaking, a loss
of cryptographic synchronization. This phenomenon is
known as "error-propagation." Therefore, the CBC mode
of a block cipher may be said to exhibit "error-
propagation" during encryption and be subject to the
loss of "cryptographic synchronization" during
decrypt.
encapsulation The term used to describe the technique of burying one
completely formed Protocol Data Unit (PDU), or packet,
Nace & Zmuda Expires in six months [Page 3]
DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997
in another PDU. The advantages of using this method
for providing encryption services is that it can be
provided without impacting the operation of protocols
above the encapsulation protocol.
encipherment Synonym for encryption.
Initialization Vector (IV)
For a block cipher algorithm in CBC mode, the IV is
input into the encryption of the first block in order
to further obscure the relationship between the
ciphertext and the actual input data by manipulating
the input data block before encipherment. For non-
streaming protocols, it is required to provide an IV
for each individual packet, since the order of
delivery of packets may vary in such protocols, and an
attempt to decrypt out of order would result in a
"loss of cryptographic synchronization." For stream-
ing protocols (like PPP) it is not necessary to pro-
vide an IV for each individual packet, as the in-order
nature of deliver in a streaming protocol means that
the "IV" needed to perform a decryption can be
obtained from the preceding block of ciphertext.
(Note: although not necessary, an IV MAY still be pro-
vided for each protected PPP packet. In fact, for a
number of reasons, this is the approach suggested
here.)
Integrity Check Value (ICV)
An Integrity Check Value is a value that is computed
by the originator over the
entire data value that is to be protected. This ICV
value is then sent with the data value
being protected. Using the same algorithm an ICV
value is computed by the recipient over the received
data value. The receiver compares the received ICV
with the ICV he has computed. If they match, it is
probable that the protected data value has not been
modified.
padding For a block mode algorithm, the data that is encrypted
must consist of a whole number of "blocks", where the
"block" size is determined by the algorithm (often
being 8 bytes in length). If the input data does not
contain a whole number of crypto block sized units, it
will need to be padded until it reaches that length.
Padding can be supplied in two forms: 1) with an
explicit length field, or 2) as self-describing
Nace & Zmuda Expires in six months [Page 4]
DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997
padding. Self-describing padding is the type of pad-
ding used in the FEEP encapsulation.
peer The other end of the point-to-point link.
2. PPP Fortezza Encryption Encapsulation Format
The PPP Fortezza Encryption Encapsulation Protocol packet has the
following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | Control | 0000 | Protocol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ciphertext ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2.0-1 - The Fortezza Encryption Encapsulation protocol
Address and Control
These fields MUST be present unless the PPP Address and
Control Field Compression option (ACFC) has been nego-
tiated.
Protocol ID
The value of this field is 0x53 or 0x55; the latter indi-
cates that ciphertext includes headers for the Multilink
Protocol, and REQUIRES that the Individual Link Encryp-
tion Control Protocol has reached the Opened state. The
leading zero MAY be absent if the PPP Protocol Field
Compression option (PFC) has been negotiated.
Ciphertext
The ciphertext is arrived at as described in the follow-
ing section.
3. PPP Fortezza Encryption Encapsulation Protocol processing
The following sections define the procedures associated with process-
ing the PPP Fortezza Encryption Encapsulation.
These procedures are threefold: First, a pad is appended to the
Nace & Zmuda Expires in six months [Page 5]
DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997
protocol and information fields of a PPP packet in order to produce a
data block that is a multiple of 8 bytes. Second, an Integrity Check
Value (ICV) is computed over the result, and this ICV is appended to
the packet. Third, and finally, the SKIPJACK Algorithm in CBC mode is
applied over this entire packet, including the pad and ICV value.
The following diagram depicts what the ciphertext field in the For-
tezza Encryption Encapsulation looks like in detail.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Initialization Vector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original PPP Packet... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Original PPP Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Self Describing Padding... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Self Describing Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Integrity Check Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3.0-1 - The format of the Ciphertext field of the Fortezza
Encryption Encapsulation protocol
Initialization Vector
This 8 byte field holds the IV. These are carried on a
per PPP packet basis even though PPP is a stream-
oriented, or in-order delivery protocol. This is in
order to simplify loss-of-sync recovery.
Original PPP packet
This arbitrary sized field holds the original PPP packet.
Nace & Zmuda Expires in six months [Page 6]
DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997
Self-describing Padding
This field contains the self-describing padding required
to produce an 8-byte aligned packet. It is 1 to 8 bytes
in length.
Integrity Check Value
This field contains the Integrity Check value computed
over everything above. It is 8 bytes in length. The
first four bytes are the ICV value itself, as a 4 byte
big-endian integer. The second four bytes are all
zeroes.
3.1. Padding
Since the SKIPJACK algorithm operates on blocks of 8 octets (and,
indeed, so does the ICV algorithm), packets which are of a length
which is not a multiple of 8 octets must be padded. This can be
injurious to the interpretation of client network-layer protocols
being carried over the PPP link, particularly those protocols which
do not contain an explicit length field in their protocol headers.
In order to avoid this problem the use of self-describing padding is
mandated for use with the PPP encapsulation using SKIPJACK. Self-
describing padding is defined in RFC1570. Simply put, self-
describing padding works like this:
1. On the generation side, you always place at least one pad
byte, and up to eight - in the case where the packet is already
block-aligned. Each pad byte placed has a value equal to its index,
from 1 to 8. Once padded the PPP packet is integrity-checked and
encrypted and placed in a PPP encryption encapsulation frame, as
described in the subsequent sections.
2. On the reception side, after the ciphertext is decrypted,
and the 8 byte Integrity Check Value field is removed, one looks at
the last byte in the remaining data. This is the last byte of the
self describing pad field. (The last byte of the self describing pad
can be determined by looking for the byte immediately preceding the 8
byte ICV, which in turn is the field immediately preceding the HDLC
FCS.) This byte indicates the number of bytes of padding to be dis-
carded.
Nace & Zmuda Expires in six months [Page 7]
DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997
3.2. Integrity Check Value calculation
The Integrity Check Value is computed in the following manner:
The originator computes the 32-bit 1's complement sum of the data
field, after it has been padded out to 64-bit block boundaries. The
1's complement sum is computed by viewing the data as a series of
32-bit big-endian words. The ICV value itself is a 64-bit field. The
ones complement sum computed above is placed in the first four bytes
and the second four bytes are all zeroes. This ICV value is then
appended to the data packet.
On the receiving side, after decryption processing, the recipient
computes, using the very same algorithm, the entire 64-bit ICV value
and then compares it with what has been received. The two values
should match.
3.3. Encryption
The ciphertext is obtained from the plaintext in the following
manner:
Generally, the SKIPJACK encryption algorithm, being a block cipher,
works on packets composed of a multiple of 8 byte blocks. The above
padding and Integrity Check Value calculation steps will have pro-
duced a data packet that is a multiple of 8 byte blocks. The For-
tezza Encryption Encapsulation thus consists of two steps: first,
the pre-pending of a per-packet IV value and secondly, the applica-
tion of the SKIPJACK algorithm in CBC mode with 64 bit blocks.
On the transmit side, the FEEP encryption encapsulation is performed
after the Integrity Check Value processing has appended an ICV and
before the HDLC or A-HDLC data link protocol processing. Because
FEEP utilizes the PPP HDLC or A-HDLC link protocol it is provided
with a sequential and mostly reliable link - e.g. HDLC FCS will
detect and eliminate corrupted frames.. For this reason we could
utilize chaining across multiple packets. I.E., we could obtain the
IV value to be used for encrypting the first block of this packet
from the ciphertext resulting from the encryption of the last block
of the previous packet.
However, in the interest of simplifying the processing needed to han-
dle a loss of cryptographic synchronization we have elected to
include an 8 byte IV value (or "Crypto Synchronization Header" if you
will) as the first 8 bytes of the field titled "Ciphertext" in figure
2.0-1 above.
Nace & Zmuda Expires in six months [Page 8]
DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997
What this means is that with this field each packet will automati-
cally resync itself. Therefore the loss of one packet due to a com-
munications failure will result only in the loss of one packet.
Without the Crypto Synchronization Header, the loss of one packet due
to communications failure would result in the loss of two packets as
the immediately following packet would fail to decrypt properly. The
ECP protocol can be utilized to provide crypto resynchronization, but
we believe the use of a per packet Crypto Synchronization Header to
be the simpler approach.
If the async control character map option has been negotiated on the
link, the sender applies mapping after the encryption algorithm has
been run.
There are a lot of details concerning what constitutes the Protocol
and Information fields, in the presence or non-presence of Multilink,
and whether the ACFC and PFC options have been negotiated, and the
type of padding to perform.
Regardless of whether ACFC has been negotiated on the link, the
sender applies the encryption procedure to only that portion of the
packet excluding the address and control field.
The plaintext is obtained from the ciphertext in the following
manner:
The information field of the encapsulating packet is obtained and
decrypted using SKIPJACK in CBC mode. Because we are assuming the
first 8 bytes constitutes an IV value for the purposes of the CBC
mode, we load the first eight bytes in the PPP packets data field
into the Skipjack algorithm as IV, and the second 8 bytes as the
first data packet. The resulting decrypted PPP packet is handed to
Integrity Check Value receive processing.
The key to use for these encryption/decryption operations is the one
developed during the KEA authentication accomplished during the
authentication phase [2].
3.4. MRU considerations and Padding
Because of the padding described above, and the additional protocol
field and the two bytes of sequence number, it can be seen that the
size of the resulting PPP encryption encapsulated frame may be as
much as 27 bytes larger than the original, unencapsulated PPP frame.
Depending upon the MRU size established during the Link establishment
Nace & Zmuda Expires in six months [Page 9]
DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997
phase, this expansion could result in the need for fragmentation of a
single, original PPP packet into two encryption encapsulated frames.
A number of different solutions are available for dealing with this.
The simplest solution is to be aware of this problem during Link
establishment phase and simply to adjust the value of the MRU that is
negotiated with the peer PPP entity to be 27 greater than that being
requested by the original PPP link without encryption. That, coupled
with the step of reporting the original MRU value to the upper layers
as the MTU.
Another solution is to make use of the PPP Multi-link procedures
which add the overhead of another PPP packet header with additional
sequence numbers and "Begin" and "End" bits to signal fragment boun-
daries. Given the fact that we only produce, at most, two
fragments...as the extra 27 bytes will surely fit in any MRU value
negotiated....the Multilink procedure will not actually be that
onerous in terms of buffer overhead.
For the purposes of this initial recommendation, the former procedure
is to be utilized.
3.5. Cryptographic synchronization handling
We avoid the problem that the loss of a packet due to communications
failure will cause the loss of a second packet due to loss of crypto-
graphic synchronization through the use of an explicit IV, or "Crypto
Synchronization Header" at the beginning of each PPP packet. This
approach costs 8 bytes per packet for a savings that is dependent on
link quality and is thus hard to quantify.
3.6. SKIPJACK mode
As PPP is a packet oriented protocol the cryptographic mode selected
for SKIPJACK operations is Cipher Block Chaining mode on 64 bits of
data.
Security Considerations
This memo defines a method for securing the exchanging of data frames
over a PPP link.
Nace & Zmuda Expires in six months [Page 10]
DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997
References:
[1] Simpson, W. A., 'The Point to Point Protocol
(PPP)', July 1994, RFC 1661.
[2] Nace, W. A., and Zmuda, J. E. 'PPP EAP KEA Public Key
Authentication Protocol', November 21st,
1997, draft-ietf-pppext-eapkea-00.txt, work
in progress.
Acknowledgements:
Thanks to Peter Yee and Russ Housley who provided helpful comments on
earlier versions of this Memo. Thanks are due to Gerry Meyer for
helping me understand his ECP Internet Draft. Thanks also are due to
Keith Sklower and Gerry Meyer for their DESE RFC. And thanks to Bill
Simpson for the standard PPP spec boilerplate from which I have bor-
rowed heavily.
Chair's Address:
The working group can be contacted via the current
chair:
Karl Fox
Ascend Communications, Inc.
Email: karl@ascend.com
Author's Address:
Questions about this memo can also be directed to:
DIRNSA
Attn: X22 (W. Nace)
9800 Savage Road
Fort Meade, MD 20755-6000
USA
Phone: +1 410 859-4464
Email: WANace@missi.ncsc.mil
James E. Zmuda
SPYRUS
2460 N. First Street
Suite 100
San Jose, CA 95131-1023
USA
Nace & Zmuda Expires in six months [Page 11]
DRAFT PPP Fortezza Encryption Encapsulation ProtocolNovember 1997
Phone: +1 408 432-8180
Email: jzmuda@spyrus.com
Nace & Zmuda Expires in six months [Page 12]