GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1969

Network Working Group K. Sklower Request for Comments: 1969 University of California, Berkeley Category: Informational G. Meyer

                                                        Spider Systems
                                                             June 1996
               The PPP DES Encryption Protocol (DESE)

Status of This Memo

 This memo provides information for the Internet community.  This memo
 does not specify an Internet standard of any kind.  Distribution of
 this memo is unlimited.

Abstract

 The Point-to-Point Protocol (PPP) [1] provides a standard method for
 transporting multi-protocol datagrams over point-to-point links.
 The PPP Encryption Control Protocol (ECP) [2] provides a method to
 negotiate and utilize encryption protocols over PPP encapsulated
 links.
 This document provides specific details for the use of the DES
 standard [5, 6] for encrypting PPP encapsulated packets.

Acknowledgements

 The authors extend hearty thanks to Fred Baker of Cisco for helpful
 improvements to the clarity of the document.

Table of Contents

 1. Introduction ................................................    2
 1.1. Motivation ................................................    2
 1.2. Conventions ...............................................    2
 2. General Overview ............................................    2
 3. Structure of This Specification .............................    3
 4. DESE Configuration Option for ECP ...........................    4
 5. Packet Format for DESE ......................................    5
 6. Encryption ..................................................    6
 6.1. Padding Considerations ....................................    6
 6.2. Generation of the Ciphertext ..............................    7
 6.3. Retrieval of the Plaintext ................................    8
 6.4. Recovery after Packet Loss ................................    8
 7. MRU Considerations ..........................................    8
 8. Security Considerations .....................................    9

Sklower & Meyer Informational [Page 1] RFC 1969 PPP DES Encryption June 1996

 9. References ..................................................    9
 10. Authors' Addresses .........................................   10
 11. Expiration Date of this Draft ..............................   10

1. Introduction

1.1. Motivation

 The purpose of this memo is two-fold: to show how one specifies the
 necessary details of a "data" or "bearer" protocol given the context
 of the generic PPP Encryption Control Protocol, and also to provide
 at least one commonly-understood means of secure data transmission
 between PPP implementations.
 The DES encryption algorithm is a well studied, understood and widely
 implemented encryption algorithm.  The DES cipher was designed for
 efficient implementation in hardware, and consequently may be
 relatively expensive to implement in software.  However, its
 pervasiveness makes it seem like a reasonable choice for a "model"
 encryption protocol.
 Source code implementing DES in the "Electronic Code Book Mode" can
 be found in [7].  US export laws forbid the inclusion of
 compilation-ready source code in this document.

1.2. Conventions

 The following language conventions are used in the items of
 specification in this document:
 o    MUST, SHALL or MANDATORY -- the item is an absolute requirement
      of the specification.
 o    SHOULD or RECOMMENDED -- the item should generally be followed
      for all but exceptional circumstances.
 o    MAY or OPTIONAL -- the item is truly optional and may be
      followed or ignored according to the needs of the implementor.

2. General Overview

 The purpose of encrypting packets exchanged between two PPP
 implementations is to attempt to insure the privacy of communication
 conducted via the two implementations.  The encryption process
 depends on the specification of an encryption algorithm and a shared
 secret (usually involving at least a key) between the sender and
 receiver.

Sklower & Meyer Informational [Page 2] RFC 1969 PPP DES Encryption June 1996

 Generally, the encryptor 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
 resulting plain text as if it were a PPP packet which had arrived
 directly on the interface.
 The means by which the secret becomes known to both communicating
 elements is beyond the scope of this document; usually some form of
 manual configuration is involved.  Implementations might make use of
 PPP authentication, or the EndPoint Identifier Option described in
 PPP Multilink [3], as factors in selecting the shared secret.  If the
 secret can be deduced by analysis of the communication between the
 two parties, then no privacy is guaranteed.
 While the US Data Encryption Standard (DES) algorithm [5, 6] provides
 multiple modes of use, this specification selects the use of only one
 mode in conjunction with the PPP Encryption Control Protol (ECP): the
 Cipher Block Chaining (CBC) mode.  In addition to the US Government
 publications cited above, the CBC mode is also discussed in [7],
 although no C source code is provided for it per se.
 The initialization vector for this mode is deduced from an explicit
 64-bit nonce, which is exchanged in the clear during the negotiation
 phase.  The 56-bit key required by all DES modes is established as a
 shared secret between the implementations.
 One reason for choosing the chaining mode is that it is generally
 thought to require more computation resources to deduce a 64 bit key
 used for DES encryption by analysis of the encrypted communication
 stream when chaining mode is used, compared with the situation where
 each block is encrypted separately with no chaining.  Further, if
 chaining is not used, even if the key is never deduced, the
 communication may be subject to replay attacks.
 However, if chaining is to extend beyond packet boundaries, both the
 sender and receiver must agree on the order the packets were
 encrypted.  Thus, this specification provides for an explicit 16 bit
 sequence number to sequence decryption of the packets.  This mode of
 operation even allows recovery from occasional packet loss; details
 are also given below.

3. Structure of This Specification

 The PPP Encryption Control Protocol (ECP), provides a framework for
 negotiating parameters associated with encryption, such as choosing
 the algorithm.  It specifies the assigned numbers to be used as PPP

Sklower & Meyer Informational [Page 3] RFC 1969 PPP DES Encryption June 1996

 protocol numbers for the "data packets" to be carried as the
 associated "data protocol", and describes the state machine.
 Thus, a specification for use in that matrix need only describe any
 additional configuration options required to specify a particular
 algorithm, and the process by which one encrypts/decrypts the
 information once the Opened state has been achieved.

4. DESE Configuration Option for ECP

 Description
      The ECP DESE Configuration Option indicates that the issuing
      implementation is offering to employ this specification for
      decrypting communications on the link, and may be thought of as
      a request for its peer to encrypt packets in this manner.
      The ECP DESE Configuration Option has the following fields,
      which are transmitted from left to right:
                  Figure 1:  ECP DESE Configuration Option
      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      |    Length     |         Initial Nonce ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Type
           1, to indicate the DESE protocol.
      Length
           10
      Initial Nonce
           This field is an 8 byte quantity which is used by the peer
           implementation to encrypt the first packet transmitted
           after the sender reaches the opened state.
           To guard against replay attacks, the implementation SHOULD
           offer a different value during each ECP negotiation.  An

Sklower & Meyer Informational [Page 4] RFC 1969 PPP DES Encryption June 1996

           example might be to use the number of seconds since Jan
           1st, 1970 (GMT/UT) in the upper 32 bits, and the current
           number of nanoseconds relative to the last second mark in
           the lower 32 bits.
           Its formulaic role is described in the Encryption section
           below.

5. Packet Format for DESE

 Description
      The DESE packets themselves have the following fields:
              Figure 2:  DES Encryption Protocol Packet 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  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Seq. No. High | Seq. No. Low  |        Ciphertext ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Address and Control
           These fields MUST be present unless the PPP Address and
           Control Field Compression option (ACFC) has been
           negotiated.
      Protocol ID
           The value of this field is 0x53 or 0x55; the latter
           indicates that ciphertext includes headers for the
           Multilink Protocol, and REQUIRES that the Individual Link
           Encryption Control Protocol has reached the opened state.
           The leading zero MAY be absent if the PPP Protocol Field
           Compression option (PFC) has been negotiated.
      Sequence Number
           These 16-bit numbers are assigned by the encryptor
           sequentially starting with 0 (for the first packet
           transmitted once ECP has reached the opened state.

Sklower & Meyer Informational [Page 5] RFC 1969 PPP DES Encryption June 1996

      Ciphertext
           The generation of this data is described in the next
           section.

6. Encryption

 Once the ECP has reached the Opened state, the sender MUST NOT apply
 the encryption procedure to LCP packets nor ECP packets.
 If the async control character map option has been negotiated on the
 link, the sender applies mapping after the encryption algorithm has
 been run.
 The encryption algorithm is generally to pad the Protocol and
 Information fields of a PPP packet to some multiple of 8 bytes, and
 apply DES in Chaining Block Cipher mode with a 56-bit key K.
 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
 sort of padding chosen.
 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.
 If the Multilink Protocol has been negotiated and encryption is to be
 construed as being applied to each link separately, then the
 encryption procedure is to be applied to the (possibly extended)
 protocol and information fields of the packet in the Multilink
 Protocol.
 If the Multilink Protocol has been negotiated and encryption is to be
 construed as being applied to the bundle, then the multilink
 procedure is to be applied to the resulting DESE packets.

6.1. Padding Considerations

 Since the DES algorithm operates on blocks of 8 octets, packets which
 are of length not a multiple of 8 octets must be padded.  This can be
 injurious to the interpretation of some protocols which do not
 contain an explicit length field in their protocol headers.
 (Additional padding of the ciphered packet for the purposes of
 transmission by HDLC hardware which requires an even number of bytes
 should not be necessary since the information field will now be of
 length a multiple of 8, and whether or not the packet is of even
 length can be forced by use or absence of a leading zero in the

Sklower & Meyer Informational [Page 6] RFC 1969 PPP DES Encryption June 1996

 protocol field).
 For protocols which do have an explicit length field, such as IP,
 IPX, XNS, and CLNP, then padding may be accomplished by adding random
 trailing garbage.  Even when performing the Multilink protocol, if it
 is only being applied to packets with explicit length fields, and if
 care is taken so that all non-terminating fragments (i.e., those not
 bearing the (E)nd bit) are of lengths divisible by 8; then no ill
 effects will happen if garbage padding is applied only to terminating
 fragments.
 For certain cases, such as the PPP bridging protocol when the
 trailing CRC is forwarded or when any bridging is being applied to
 protocols not having explicit length fields, adding garbage changes
 the interpretation of the packet.  The self-describing padding option
 [4] permits unambiguous removal of padded bytes; although it should
 only be used when absolutely necessary as it may inadvertently
 require adding as many as 8 octets to packets that could otherwise be
 left unaltered.
    Consider a packet, which by unlucky circumstance is already a
    multiple of 8 octets, but terminates in the sequence 0x1, 0x2.
    Self-describing padding would otherwise remove the trailing two
    bytes.  For purposes of coexistence with archaic HDLC chips where
    it is necessary to transmit packets of even length, one would
    normally only have to add an additional two octets (0x1, 0x2),
    which could then be removed.  However, since the packet was
    initially a multiple of 8 bytes, an additional 8 bytes would need
    to be added.

6.2. Generation of the Ciphertext

 In this discussion, E[k] will denote the basic DES cipher determined
 by a 56-bit key k acting on 64 bit blocks. and D[k] will denote the
 corresponding decryption mechanism.  The padded plaintext described
 in the previous section then becomes a sequence of 64 bit blocks P[i]
 (where i ranges from 1 to n).  The circumflex character (^)
 represents the bit-wise exclusive-or operation applied to 64-bit
 blocks.
 When encrypting the first packet to be transmitted in the opened
 state let C[0] be the result of applying E[k] to the Initial Nonce
 received in the peer's ECP DESE option; otherwise let C[0] be the
 final block of the previously transmitted packet.

Sklower & Meyer Informational [Page 7] RFC 1969 PPP DES Encryption June 1996

 The ciphertext for the packet is generated by the iterative process
                      C[i] = E[k](P[i] ^ C[i-1])
 for i running between 1 and n.

6.3. Retrieval of the Plaintext

 When decrypting the first packet received in the opened state, let
 C[0] be the result of applying E[k] to the Initial Nonce transmitted
 in the ECP DESE option.  The first packet will have sequence number
 zero.  For subsequent packets, let C[0] be the final block of the
 previous packet in sequence space.  Decryption is then accomplished
 by
                      P[i] = C[i-1] ^ D[k](C[i]),
 for i running between 1 and n.

6.4. Recovery after Packet Loss

 Packet loss is detected when there is a discontinuity in the sequence
 numbers of consecutive packets.  Suppose packet number N - 1 has an
 unrecoverable error or is otherwise lost, but packets N and N + 1 are
 received correctly.
 Since the algorithm in the previous section requires C[0] for packet
 N to be C[last] for packet N - 1, it will be impossible to decode
 packet N.  However, all packets N + 1 and following can be decoded in
 the usual way, since all that is required is the last block of
 ciphertext of the previous packet (in this case packet N, which WAS
 received).

7. MRU Considerations

 Because padding can occur, and because there is an additional
 protocol field in effect, implementations should take into account
 the growth of the packets.  As an example, if PFC had been
 negotiated, and if the MRU before had been exactly a multiple of 8,
 then the plaintext resulting combining a full sized data packets with
 a one byte protocol field would require an additional 7 bytes of
 padding, and the sequence number would be an additional 2 bytes so
 that the information field in the DESE protocol is now 10 bytes
 larger than that in the original packet.  Because the convention is
 that PPP options are independent of each other, negotiation of DESE
 does not, by itself, automatically increase the MRU value.

Sklower & Meyer Informational [Page 8] RFC 1969 PPP DES Encryption June 1996

8. Security Considerations

 Security issues are the primary subject of this memo.  This proposal
 relies on exterior and unspecified methods for authentication and
 retrieval of shared secrets.
 It proposes no new technology for privacy, but merely describes a
 convention for the application of the DES cipher to data transmission
 between PPP implementation.
 Any methodology for the protection and retrieval of shared secrets,
 and any limitations of the DES cipher are relevant to the use
 described here.

9. References

 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
     RFC 1661, Daydreamer, July 1994.
 [2] Meyer, G., "The PPP Encryption Protocol", RFC 1968, Spider
     Systems, June 1996.
 [3] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The PPP
     Multilink Protocol (MP)", RFC 1717, UC Berkeley, November 1994.
 [4] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer,
     January 1994.
 [5] National Bureau of Standards, "Data Encryption Standard", FIPS
     PUB 46 (January 1977).
 [6] National Bureau of Standards, "DES Modes of Operation", FIPS PUB
     81 (December 1980).
 [7] Schneier, B., "Applied Cryptography - Protocols Algorithms, and
     source code in C", John Wiley & Sons, Inc. 1994.  There is an
     errata associated with the book, and people can get a copy by
     sending e-mail to schneier@counterpane.com.

Sklower & Meyer Informational [Page 9] RFC 1969 PPP DES Encryption June 1996

10. Authors' Addresses

 Keith Sklower
 Computer Science Department
 384 Soda Hall, Mail Stop 1776
 University of California
 Berkeley, CA 94720-1776
 Phone:  (510) 642-9587
 EMail:  sklower@CS.Berkeley.EDU
 Gerry M. Meyer
 Spider Systems
 Stanwell Street
 Edinburgh EH6 5NG
 Scotland, UK
 Phone: (UK) 131 554 9424
 Fax:   (UK) 131 554 0649
 EMail: gerry@spider.co.uk

Sklower & Meyer Informational [Page 10]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1969.txt · Last modified: 1996/06/18 22:01 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki