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