home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1969.txt < prev    next >
Text File  |  1996-08-15  |  21KB  |  564 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         K. Sklower
  8. Request for Comments: 1969            University of California, Berkeley
  9. Category: Informational                                         G. Meyer
  10.                                                           Spider Systems
  11.                                                                June 1996
  12.  
  13.  
  14.                  The PPP DES Encryption Protocol (DESE)
  15.  
  16. Status of This Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  25.    transporting multi-protocol datagrams over point-to-point links.
  26.  
  27.    The PPP Encryption Control Protocol (ECP) [2] provides a method to
  28.    negotiate and utilize encryption protocols over PPP encapsulated
  29.    links.
  30.  
  31.    This document provides specific details for the use of the DES
  32.    standard [5, 6] for encrypting PPP encapsulated packets.
  33.  
  34. Acknowledgements
  35.  
  36.    The authors extend hearty thanks to Fred Baker of Cisco for helpful
  37.    improvements to the clarity of the document.
  38.  
  39. Table of Contents
  40.  
  41.    1. Introduction ................................................    2
  42.    1.1. Motivation ................................................    2
  43.    1.2. Conventions ...............................................    2
  44.    2. General Overview ............................................    2
  45.    3. Structure of This Specification .............................    3
  46.    4. DESE Configuration Option for ECP ...........................    4
  47.    5. Packet Format for DESE ......................................    5
  48.    6. Encryption ..................................................    6
  49.    6.1. Padding Considerations ....................................    6
  50.    6.2. Generation of the Ciphertext ..............................    7
  51.    6.3. Retrieval of the Plaintext ................................    8
  52.    6.4. Recovery after Packet Loss ................................    8
  53.    7. MRU Considerations ..........................................    8
  54.    8. Security Considerations .....................................    9
  55.  
  56.  
  57.  
  58. Sklower & Meyer              Informational                      [Page 1]
  59.  
  60. RFC 1969                  PPP DES Encryption                   June 1996
  61.  
  62.  
  63.    9. References ..................................................    9
  64.    10. Authors' Addresses .........................................   10
  65.    11. Expiration Date of this Draft ..............................   10
  66.  
  67. 1.  Introduction
  68.  
  69. 1.1.  Motivation
  70.  
  71.    The purpose of this memo is two-fold: to show how one specifies the
  72.    necessary details of a "data" or "bearer" protocol given the context
  73.    of the generic PPP Encryption Control Protocol, and also to provide
  74.    at least one commonly-understood means of secure data transmission
  75.    between PPP implementations.
  76.  
  77.    The DES encryption algorithm is a well studied, understood and widely
  78.    implemented encryption algorithm.  The DES cipher was designed for
  79.    efficient implementation in hardware, and consequently may be
  80.    relatively expensive to implement in software.  However, its
  81.    pervasiveness makes it seem like a reasonable choice for a "model"
  82.    encryption protocol.
  83.  
  84.    Source code implementing DES in the "Electronic Code Book Mode" can
  85.    be found in [7].  US export laws forbid the inclusion of
  86.    compilation-ready source code in this document.
  87.  
  88. 1.2.  Conventions
  89.  
  90.    The following language conventions are used in the items of
  91.    specification in this document:
  92.  
  93.    o    MUST, SHALL or MANDATORY -- the item is an absolute requirement
  94.         of the specification.
  95.  
  96.    o    SHOULD or RECOMMENDED -- the item should generally be followed
  97.         for all but exceptional circumstances.
  98.  
  99.    o    MAY or OPTIONAL -- the item is truly optional and may be
  100.         followed or ignored according to the needs of the implementor.
  101.  
  102. 2.  General Overview
  103.  
  104.    The purpose of encrypting packets exchanged between two PPP
  105.    implementations is to attempt to insure the privacy of communication
  106.    conducted via the two implementations.  The encryption process
  107.    depends on the specification of an encryption algorithm and a shared
  108.    secret (usually involving at least a key) between the sender and
  109.    receiver.
  110.  
  111.  
  112.  
  113.  
  114. Sklower & Meyer              Informational                      [Page 2]
  115.  
  116. RFC 1969                  PPP DES Encryption                   June 1996
  117.  
  118.  
  119.    Generally, the encryptor will take a PPP packet including the
  120.    protocol field, apply the chosen encryption algorithm, place the
  121.    resulting cipher text (and in this specification, an explicit
  122.    sequence number) in the information field of another PPP packet.  The
  123.    decryptor will apply the inverse algorithm and interpret the
  124.    resulting plain text as if it were a PPP packet which had arrived
  125.    directly on the interface.
  126.  
  127.    The means by which the secret becomes known to both communicating
  128.    elements is beyond the scope of this document; usually some form of
  129.    manual configuration is involved.  Implementations might make use of
  130.    PPP authentication, or the EndPoint Identifier Option described in
  131.    PPP Multilink [3], as factors in selecting the shared secret.  If the
  132.    secret can be deduced by analysis of the communication between the
  133.    two parties, then no privacy is guaranteed.
  134.  
  135.    While the US Data Encryption Standard (DES) algorithm [5, 6] provides
  136.    multiple modes of use, this specification selects the use of only one
  137.    mode in conjunction with the PPP Encryption Control Protol (ECP): the
  138.    Cipher Block Chaining (CBC) mode.  In addition to the US Government
  139.    publications cited above, the CBC mode is also discussed in [7],
  140.    although no C source code is provided for it per se.
  141.  
  142.    The initialization vector for this mode is deduced from an explicit
  143.    64-bit nonce, which is exchanged in the clear during the negotiation
  144.    phase.  The 56-bit key required by all DES modes is established as a
  145.    shared secret between the implementations.
  146.  
  147.    One reason for choosing the chaining mode is that it is generally
  148.    thought to require more computation resources to deduce a 64 bit key
  149.    used for DES encryption by analysis of the encrypted communication
  150.    stream when chaining mode is used, compared with the situation where
  151.    each block is encrypted separately with no chaining.  Further, if
  152.    chaining is not used, even if the key is never deduced, the
  153.    communication may be subject to replay attacks.
  154.  
  155.    However, if chaining is to extend beyond packet boundaries, both the
  156.    sender and receiver must agree on the order the packets were
  157.    encrypted.  Thus, this specification provides for an explicit 16 bit
  158.    sequence number to sequence decryption of the packets.  This mode of
  159.    operation even allows recovery from occasional packet loss; details
  160.    are also given below.
  161.  
  162. 3.  Structure of This Specification
  163.  
  164.    The PPP Encryption Control Protocol (ECP), provides a framework for
  165.    negotiating parameters associated with encryption, such as choosing
  166.    the algorithm.  It specifies the assigned numbers to be used as PPP
  167.  
  168.  
  169.  
  170. Sklower & Meyer              Informational                      [Page 3]
  171.  
  172. RFC 1969                  PPP DES Encryption                   June 1996
  173.  
  174.  
  175.    protocol numbers for the "data packets" to be carried as the
  176.    associated "data protocol", and describes the state machine.
  177.  
  178.    Thus, a specification for use in that matrix need only describe any
  179.    additional configuration options required to specify a particular
  180.    algorithm, and the process by which one encrypts/decrypts the
  181.    information once the Opened state has been achieved.
  182.  
  183. 4.  DESE Configuration Option for ECP
  184.  
  185.    Description
  186.  
  187.         The ECP DESE Configuration Option indicates that the issuing
  188.         implementation is offering to employ this specification for
  189.         decrypting communications on the link, and may be thought of as
  190.         a request for its peer to encrypt packets in this manner.
  191.  
  192.         The ECP DESE Configuration Option has the following fields,
  193.         which are transmitted from left to right:
  194.  
  195.  
  196.                     Figure 1:  ECP DESE Configuration Option
  197.  
  198.  
  199.         0                   1                   2                   3
  200.         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
  201.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  202.         |     Type      |    Length     |         Initial Nonce ...
  203.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  204.  
  205.         Type
  206.  
  207.              1, to indicate the DESE protocol.
  208.  
  209.  
  210.         Length
  211.  
  212.              10
  213.  
  214.  
  215.         Initial Nonce
  216.  
  217.              This field is an 8 byte quantity which is used by the peer
  218.              implementation to encrypt the first packet transmitted
  219.              after the sender reaches the opened state.
  220.  
  221.              To guard against replay attacks, the implementation SHOULD
  222.              offer a different value during each ECP negotiation.  An
  223.  
  224.  
  225.  
  226. Sklower & Meyer              Informational                      [Page 4]
  227.  
  228. RFC 1969                  PPP DES Encryption                   June 1996
  229.  
  230.  
  231.              example might be to use the number of seconds since Jan
  232.              1st, 1970 (GMT/UT) in the upper 32 bits, and the current
  233.              number of nanoseconds relative to the last second mark in
  234.              the lower 32 bits.
  235.  
  236.              Its formulaic role is described in the Encryption section
  237.              below.
  238.  
  239. 5.  Packet Format for DESE
  240.  
  241.    Description
  242.  
  243.         The DESE packets themselves have the following fields:
  244.  
  245.  
  246.                 Figure 2:  DES Encryption Protocol Packet Format
  247.  
  248.  
  249.         0                   1                   2                   3
  250.         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
  251.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  252.         |    Address    |    Control    |     0000      |  Protocol ID  |
  253.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  254.         | Seq. No. High | Seq. No. Low  |        Ciphertext ...
  255.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  256.  
  257.  
  258.         Address and Control
  259.  
  260.              These fields MUST be present unless the PPP Address and
  261.              Control Field Compression option (ACFC) has been
  262.              negotiated.
  263.  
  264.         Protocol ID
  265.  
  266.              The value of this field is 0x53 or 0x55; the latter
  267.              indicates that ciphertext includes headers for the
  268.              Multilink Protocol, and REQUIRES that the Individual Link
  269.              Encryption Control Protocol has reached the opened state.
  270.              The leading zero MAY be absent if the PPP Protocol Field
  271.              Compression option (PFC) has been negotiated.
  272.  
  273.         Sequence Number
  274.  
  275.              These 16-bit numbers are assigned by the encryptor
  276.              sequentially starting with 0 (for the first packet
  277.              transmitted once ECP has reached the opened state.
  278.  
  279.  
  280.  
  281.  
  282. Sklower & Meyer              Informational                      [Page 5]
  283.  
  284. RFC 1969                  PPP DES Encryption                   June 1996
  285.  
  286.  
  287.         Ciphertext
  288.  
  289.              The generation of this data is described in the next
  290.              section.
  291.  
  292. 6.  Encryption
  293.  
  294.    Once the ECP has reached the Opened state, the sender MUST NOT apply
  295.    the encryption procedure to LCP packets nor ECP packets.
  296.  
  297.    If the async control character map option has been negotiated on the
  298.    link, the sender applies mapping after the encryption algorithm has
  299.    been run.
  300.  
  301.    The encryption algorithm is generally to pad the Protocol and
  302.    Information fields of a PPP packet to some multiple of 8 bytes, and
  303.    apply DES in Chaining Block Cipher mode with a 56-bit key K.
  304.  
  305.    There are a lot of details concerning what constitutes the Protocol
  306.    and Information fields, in the presence or non-presence of Multilink,
  307.    and whether the ACFC and PFC options have been negotiated, and the
  308.    sort of padding chosen.
  309.  
  310.    Regardless of whether ACFC has been negotiated on the link, the
  311.    sender applies the encryption procedure to only that portion of the
  312.    packet excluding the address and control field.
  313.  
  314.    If the Multilink Protocol has been negotiated and encryption is to be
  315.    construed as being applied to each link separately, then the
  316.    encryption procedure is to be applied to the (possibly extended)
  317.    protocol and information fields of the packet in the Multilink
  318.    Protocol.
  319.  
  320.    If the Multilink Protocol has been negotiated and encryption is to be
  321.    construed as being applied to the bundle, then the multilink
  322.    procedure is to be applied to the resulting DESE packets.
  323.  
  324. 6.1.  Padding Considerations
  325.  
  326.    Since the DES algorithm operates on blocks of 8 octets, packets which
  327.    are of length not a multiple of 8 octets must be padded.  This can be
  328.    injurious to the interpretation of some protocols which do not
  329.    contain an explicit length field in their protocol headers.
  330.    (Additional padding of the ciphered packet for the purposes of
  331.    transmission by HDLC hardware which requires an even number of bytes
  332.    should not be necessary since the information field will now be of
  333.    length a multiple of 8, and whether or not the packet is of even
  334.    length can be forced by use or absence of a leading zero in the
  335.  
  336.  
  337.  
  338. Sklower & Meyer              Informational                      [Page 6]
  339.  
  340. RFC 1969                  PPP DES Encryption                   June 1996
  341.  
  342.  
  343.    protocol field).
  344.  
  345.    For protocols which do have an explicit length field, such as IP,
  346.    IPX, XNS, and CLNP, then padding may be accomplished by adding random
  347.    trailing garbage.  Even when performing the Multilink protocol, if it
  348.    is only being applied to packets with explicit length fields, and if
  349.    care is taken so that all non-terminating fragments (i.e., those not
  350.    bearing the (E)nd bit) are of lengths divisible by 8; then no ill
  351.    effects will happen if garbage padding is applied only to terminating
  352.    fragments.
  353.  
  354.    For certain cases, such as the PPP bridging protocol when the
  355.    trailing CRC is forwarded or when any bridging is being applied to
  356.    protocols not having explicit length fields, adding garbage changes
  357.    the interpretation of the packet.  The self-describing padding option
  358.    [4] permits unambiguous removal of padded bytes; although it should
  359.    only be used when absolutely necessary as it may inadvertently
  360.    require adding as many as 8 octets to packets that could otherwise be
  361.    left unaltered.
  362.  
  363.       Consider a packet, which by unlucky circumstance is already a
  364.       multiple of 8 octets, but terminates in the sequence 0x1, 0x2.
  365.       Self-describing padding would otherwise remove the trailing two
  366.       bytes.  For purposes of coexistence with archaic HDLC chips where
  367.       it is necessary to transmit packets of even length, one would
  368.       normally only have to add an additional two octets (0x1, 0x2),
  369.       which could then be removed.  However, since the packet was
  370.       initially a multiple of 8 bytes, an additional 8 bytes would need
  371.       to be added.
  372.  
  373. 6.2.  Generation of the Ciphertext
  374.  
  375.    In this discussion, E[k] will denote the basic DES cipher determined
  376.    by a 56-bit key k acting on 64 bit blocks. and D[k] will denote the
  377.    corresponding decryption mechanism.  The padded plaintext described
  378.    in the previous section then becomes a sequence of 64 bit blocks P[i]
  379.    (where i ranges from 1 to n).  The circumflex character (^)
  380.    represents the bit-wise exclusive-or operation applied to 64-bit
  381.    blocks.
  382.  
  383.    When encrypting the first packet to be transmitted in the opened
  384.    state let C[0] be the result of applying E[k] to the Initial Nonce
  385.    received in the peer's ECP DESE option; otherwise let C[0] be the
  386.    final block of the previously transmitted packet.
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Sklower & Meyer              Informational                      [Page 7]
  395.  
  396. RFC 1969                  PPP DES Encryption                   June 1996
  397.  
  398.  
  399.    The ciphertext for the packet is generated by the iterative process
  400.  
  401.                         C[i] = E[k](P[i] ^ C[i-1])
  402.  
  403.    for i running between 1 and n.
  404.  
  405. 6.3.  Retrieval of the Plaintext
  406.  
  407.    When decrypting the first packet received in the opened state, let
  408.    C[0] be the result of applying E[k] to the Initial Nonce transmitted
  409.    in the ECP DESE option.  The first packet will have sequence number
  410.    zero.  For subsequent packets, let C[0] be the final block of the
  411.    previous packet in sequence space.  Decryption is then accomplished
  412.    by
  413.  
  414.                         P[i] = C[i-1] ^ D[k](C[i]),
  415.  
  416.    for i running between 1 and n.
  417.  
  418. 6.4.  Recovery after Packet Loss
  419.  
  420.    Packet loss is detected when there is a discontinuity in the sequence
  421.    numbers of consecutive packets.  Suppose packet number N - 1 has an
  422.    unrecoverable error or is otherwise lost, but packets N and N + 1 are
  423.    received correctly.
  424.  
  425.    Since the algorithm in the previous section requires C[0] for packet
  426.    N to be C[last] for packet N - 1, it will be impossible to decode
  427.    packet N.  However, all packets N + 1 and following can be decoded in
  428.    the usual way, since all that is required is the last block of
  429.    ciphertext of the previous packet (in this case packet N, which WAS
  430.    received).
  431.  
  432. 7.  MRU Considerations
  433.  
  434.    Because padding can occur, and because there is an additional
  435.    protocol field in effect, implementations should take into account
  436.    the growth of the packets.  As an example, if PFC had been
  437.    negotiated, and if the MRU before had been exactly a multiple of 8,
  438.    then the plaintext resulting combining a full sized data packets with
  439.    a one byte protocol field would require an additional 7 bytes of
  440.    padding, and the sequence number would be an additional 2 bytes so
  441.    that the information field in the DESE protocol is now 10 bytes
  442.    larger than that in the original packet.  Because the convention is
  443.    that PPP options are independent of each other, negotiation of DESE
  444.    does not, by itself, automatically increase the MRU value.
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Sklower & Meyer              Informational                      [Page 8]
  451.  
  452. RFC 1969                  PPP DES Encryption                   June 1996
  453.  
  454.  
  455. 8.  Security Considerations
  456.  
  457.    Security issues are the primary subject of this memo.  This proposal
  458.    relies on exterior and unspecified methods for authentication and
  459.    retrieval of shared secrets.
  460.  
  461.    It proposes no new technology for privacy, but merely describes a
  462.    convention for the application of the DES cipher to data transmission
  463.    between PPP implementation.
  464.  
  465.    Any methodology for the protection and retrieval of shared secrets,
  466.    and any limitations of the DES cipher are relevant to the use
  467.    described here.
  468.  
  469. 9.  References
  470.  
  471.    [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
  472.        RFC 1661, Daydreamer, July 1994.
  473.  
  474.    [2] Meyer, G., "The PPP Encryption Protocol", RFC 1968, Spider
  475.        Systems, June 1996.
  476.  
  477.    [3] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The PPP
  478.        Multilink Protocol (MP)", RFC 1717, UC Berkeley, November 1994.
  479.  
  480.    [4] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer,
  481.        January 1994.
  482.  
  483.    [5] National Bureau of Standards, "Data Encryption Standard", FIPS
  484.        PUB 46 (January 1977).
  485.  
  486.    [6] National Bureau of Standards, "DES Modes of Operation", FIPS PUB
  487.        81 (December 1980).
  488.  
  489.    [7] Schneier, B., "Applied Cryptography - Protocols Algorithms, and
  490.        source code in C", John Wiley & Sons, Inc. 1994.  There is an
  491.        errata associated with the book, and people can get a copy by
  492.        sending e-mail to schneier@counterpane.com.
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Sklower & Meyer              Informational                      [Page 9]
  507.  
  508. RFC 1969                  PPP DES Encryption                   June 1996
  509.  
  510.  
  511. 10.  Authors' Addresses
  512.  
  513.    Keith Sklower
  514.    Computer Science Department
  515.    384 Soda Hall, Mail Stop 1776
  516.    University of California
  517.    Berkeley, CA 94720-1776
  518.  
  519.    Phone:  (510) 642-9587
  520.    EMail:  sklower@CS.Berkeley.EDU
  521.  
  522.  
  523.    Gerry M. Meyer
  524.    Spider Systems
  525.    Stanwell Street
  526.    Edinburgh EH6 5NG
  527.    Scotland, UK
  528.  
  529.    Phone: (UK) 131 554 9424
  530.    Fax:   (UK) 131 554 0649
  531.    EMail: gerry@spider.co.uk
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Sklower & Meyer              Informational                     [Page 10]
  563.  
  564.