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-3des-encrypt-00.txt < prev    next >
Text File  |  1997-07-21  |  16KB  |  447 lines
  1.  
  2.  
  3. Network Working Group                                         H. Kummert
  4. Internet-draft                                               Nentec GmbH
  5. Expires: January 1998                                          July 1997
  6.  
  7.  
  8.              The PPP Triple-DES Encryption Protocol (3DESE)
  9.                  draft-ietf-pppext-3des-encrypt-00.txt
  10.  
  11.  
  12. Status of this Memo
  13.  
  14.    This document is a submission to the Point-to-Point Protocol Working
  15.    Group of the Internet Engineering Task Force (IETF).  Comments should
  16.    be submitted to the ietf-ppp@merit.edu mailing list.
  17.  
  18.    Distribution of this memo is unlimited.
  19.  
  20.    This document is an Internet-Draft.  Internet-Drafts are working
  21.    documents of the Internet Engineering Task Force (IETF), its areas,
  22.    and its working groups.  Note that other groups may also distribute
  23.    working documents as Internet-Drafts.
  24.  
  25.    Internet-Drafts are draft documents valid for a maximum of six months
  26.    and may be updated, replaced, or obsoleted by other documents at any
  27.    time.  It is inappropriate to use Internet- Drafts as reference
  28.    material or to cite them other than as ``work in progress.''
  29.  
  30.    To learn the current status of any Internet-Draft, please check the
  31.    ``1id-abstracts.txt'' listing contained in the Internet- Drafts
  32.    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  33.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  34.    ftp.isi.edu (US West Coast).
  35.  
  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 Triple-DES
  47.    standard (3DES) [6] for encrypting PPP encapsulated packets.
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Kummert                                                         [Page 1]
  55.  
  56. INTERNET DRAFT         PPP Triple-DES Encryption               July 1997
  57.  
  58.  
  59.    Table of contents
  60.  
  61.    1.   Introduction ..............................................    2
  62.    1.1  Algorithm .................................................    3
  63.    1.2  Keys ......................................................    3
  64.    2.   3DESE Configuration Option for ECP ........................    4
  65.    3.   Packet format for 3DESE ...................................    4
  66.    4.   Encryption ................................................    5
  67.    4.1  Padding ...................................................    6
  68.    4.2  Recovery after packet loss ................................    6
  69.    5.   Security considerations ...................................    7
  70.    6.   References ................................................    7
  71.    7.   Acknowledgements ..........................................    7
  72.    8.   Author's address ..........................................    8
  73.    9.   Expiration date of this draft .............................    8
  74.  
  75.  
  76.  
  77.  
  78. 1. Introduction
  79.  
  80.    The purpose of encrypting packets exchanged between two PPP implemen-
  81.    tations is to attempt to insure the privacy of communication con-
  82.    ducted via the two implementations. There exists a large variety of
  83.    encryption algorithms, where one is the DES algorithm. The DES
  84.    encryption algorithm is a well studied, understood and widely imple-
  85.    mented encryption algorithm.  Triple-DES means that this algorithm is
  86.    applied three times on the data to be encrypted before it is sent
  87.    over the line. The variant used is the DES-EDE3-CBC, which is
  88.    described in more detail in the text. It was also chosen to be
  89.    applied in the security section of IP [5].
  90.  
  91.    This document shows how to send via the Triple-DES algorithm
  92.    encrypted packets over a point-to-point-link. It lies in the context
  93.    of the generic PPP Encryption Control Protocol [2].
  94.  
  95.    Because of the use of the CBC-mode a sequence number is provided to
  96.    ensure the right order of transmitted packets. So lost packets can be
  97.    detected.
  98.  
  99.    The padding section reflects the result of the discussion on this
  100.    topic on the ppp mailing list.
  101.  
  102.    In this document, the key words "MUST", "SHOULD", and "recommended"
  103.    are to be interpreted as described in [3].
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110. Kummert                                                         [Page 2]
  111.  
  112. INTERNET DRAFT         PPP Triple-DES Encryption               July 1997
  113.  
  114.  
  115. 1.1  Algorithm
  116.  
  117.    The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC algo-
  118.    rithm.  In DES-EDE3-CBC, an Initialization Vector (IV) is XOR'd with
  119.    the first 64-bit (8 octet) plaintext block (P1).  The keyed DES func-
  120.    tion is iterated three times, an encryption (E) followed by a decryp-
  121.    tion (D) followed by an encryption (E), and generates the ciphertext
  122.    (C1) for the block. Each iteration uses an independent key: k1, k2
  123.    and k3.
  124.  
  125.    For successive blocks, the previous ciphertext block is XOR'd with
  126.    the current 8-octet plaintext block (Pi). The keyed DES-EDE3 encryp-
  127.    tion function generates the ciphertext (Ci) for that block.
  128.  
  129.                       P1             P2                 Pi
  130.                       |              |                  |
  131.                IV--->(X)    +------>(X)      +-------->(X)
  132.                       v     |        v       |          v
  133.                    +-----+  |     +-----+    |       +-----+
  134.                k1->|  E  |  | k1->|  E  |    :   k1->|  E  |
  135.                    +-----+  |     +-----+    :       +-----+
  136.                       |     |        |       :          |
  137.                       v     |        v       :          v
  138.                    +-----+  ^     +-----+    ^       +-----+
  139.                k2->|  D  |  | k2->|  D  |    |   k2->|  D  |
  140.                    +-----+  |     +-----+    |       +-----+
  141.                       |     |        |       |          |
  142.                       v     |        v       |          v
  143.                    +-----+  |     +-----+    |       +-----+
  144.                k3->|  E  |  | k3->|  E  |    |   k3->|  E  |
  145.                    +-----+  |     +-----+    |       +-----+
  146.                       |     |        |       |          |
  147.                       +---->+        +------>+          +---->
  148.                       |              |                  |
  149.                       C1             C2                 Ci
  150.  
  151.    To decrypt, the order of the functions is reversed: decrypt with k3,
  152.    encrypt with k2, decrypt with k1, and XOR with the previous cipher-
  153.    text block.
  154.  
  155.    When all three keys (k1, k2 and k3) are the same, DES-EDE3-CBC is
  156.    equivalent to DES-CBC.
  157.  
  158.  
  159. 1.2  Keys
  160.  
  161.    The secret DES-EDE3 key shared between the communicating parties is
  162.    effectively 168-bits long.  This key consists of three independent
  163.  
  164.  
  165.  
  166. Kummert                                                         [Page 3]
  167.  
  168. INTERNET DRAFT         PPP Triple-DES Encryption               July 1997
  169.  
  170.  
  171.    56-bit quantities used by the DES algorithm.  Each of the three 56-
  172.    bit subkeys is stored as a 64-bit (8 octet) quantity, with the least
  173.    significant bit of each octet used as a parity bit.
  174.  
  175.    When configuring keys for 3DESE those with incorrect parity or so-
  176.    called weak keys [6] SHOULD be rejected.
  177.  
  178.  
  179. 2.  3DESE Configuration Option for ECP
  180.  
  181.    Description
  182.  
  183.         The ECP 3DESE Configuration Option indicates that the issuing
  184.         implementation is offering to employ this specification for
  185.         decrypting communications on the link, and may be thought of as
  186.         a request for its peer to encrypt packets in this manner.  The
  187.         ECP 3DESE Configuration Option has the following fields, which
  188.         are transmitted from left to right:
  189.  
  190.                Figure 1:  ECP 3DESE Configuration Option
  191.  
  192.         0                   1                   2                   3
  193.         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
  194.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  195.         |     Type      |    Length     |         Initial Nonce ...
  196.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  197.  
  198.         Type
  199.  
  200.              tbd, to indicate the 3DESE protocol.
  201.  
  202.         Length
  203.  
  204.              10
  205.  
  206.         Initial Nonce
  207.  
  208.              This field is an 8 byte quantity which is used by the peer
  209.              implementation to encrypt the first packet transmitted
  210.              after the sender reaches the opened state. To guard against
  211.              replay attacks, the implementation SHOULD offer a different
  212.              value during each ECP negotiation.
  213.  
  214.  
  215.  
  216. 3.  Packet format for 3DESE
  217.  
  218.    Description
  219.  
  220.  
  221.  
  222. Kummert                                                         [Page 4]
  223.  
  224. INTERNET DRAFT         PPP Triple-DES Encryption               July 1997
  225.  
  226.  
  227.         The 3DESE packets that contain the encrypted payload have the
  228.         following fields:
  229.  
  230.                Figure 2:  3DESE Encryption Protocol Packet Format
  231.  
  232.         0                   1                   2                   3
  233.         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
  234.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  235.         |    Address    |    Control    |     0000      |  Protocol ID  |
  236.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  237.         | Seq. No. High | Seq. No. Low  |        Ciphertext ...
  238.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  239.  
  240.         Address and Control
  241.  
  242.              These fields MUST be present unless the PPP Address and
  243.              Control Field Compression option (ACFC) has been nego-
  244.              tiated.
  245.  
  246.         Protocol ID
  247.  
  248.              The value of this field is 0x53 or 0x55; the latter indi-
  249.              cates the use of the Individual Link Encryption Control
  250.              Protocol and that the ciphertext contains a Multilink frag-
  251.              ment.  Protocol Field Compression MAY be applied to the
  252.              leading zero if negotiated.
  253.  
  254.         Sequence Number
  255.  
  256.              These 16-bit numbers are assigned by the encryptor sequen-
  257.              tially starting with 0 (for the first packet transmitted
  258.              once ECP has reached the opened state).
  259.  
  260.         Ciphertext
  261.  
  262.              The generation of this data is described in the next sec-
  263.              tion.
  264.  
  265.  
  266. 4.  Encryption
  267.  
  268.    Once the ECP has reached the Opened state, the sender MUST NOT apply
  269.    the encryption procedure to LCP packets nor ECP packets.
  270.  
  271.    If the async control character map option has been negotiated on the
  272.    link, the sender applies mapping after the encryption algorithm has
  273.    been run.
  274.  
  275.  
  276.  
  277.  
  278. Kummert                                                         [Page 5]
  279.  
  280. INTERNET DRAFT         PPP Triple-DES Encryption               July 1997
  281.  
  282.  
  283.    The encryption algorithm is generally to pad the Protocol and Infor-
  284.    mation fields of a PPP packet to some multiple of 8 bytes, and apply
  285.    3DES as described in section 1.1 with the three 56-bit keys k1, k2
  286.    and k3.
  287.  
  288.    The encryption procedure is only applied to that portion of the
  289.    packet excluding the address and control field.
  290.  
  291.    When encrypting the first packet after ECP stepped into opened state
  292.    the Initial Nonce is encrypted via 3DES-algorithm before its use.
  293.  
  294.  
  295. 4.1  Padding
  296.  
  297.    Since the 3DES algorithm operates on blocks of 8 octets, plain text
  298.    packets which are of length not a multiple of 8 octets must be padded
  299.    prior to encrypting.  If this padding is not removed after decryption
  300.    this can be injurious to the interpretation of some protocols which
  301.    do not contain an explicit length field in their protocol headers.
  302.  
  303.    Therefore all packets not already a multiple of eight bytes in length
  304.    MUST be padded prior to encrypting using the unambiguous technique of
  305.    Self Describing Padding with a Maximum Pad Value (MPV) of 8. This
  306.    means that the plain text is padded with the sequence of octets 1, 2,
  307.    3, .. 7 since its length is a multiple of 8 octets. Negotiation of
  308.    SDP is not needed.  Negotiation of the LCP Self Describing Option may
  309.    be negotiated independently to solve an orthogonal problem.
  310.  
  311.    Plain text which length is already a multiple of 8 octets may require
  312.    padding with a further 8 octets (1, 2, 3 ... 8).  These additional
  313.    octets MUST only be appended, if the last octet of the plain text had
  314.    a value of 8 or less.
  315.  
  316.    When using Multilink and encrypting on individual links it is recom-
  317.    mended that all non-terminating fragments have a length divisible by
  318.    8. So no additional padding is needed on those fragments.
  319.  
  320.    After the peer has decrypted the ciphertext, it strips off the Self
  321.    Describing Padding octets to recreate the original plain text.  The
  322.    peer SHOULD discard the frame if the octets forming the padding do
  323.    not match the Self Describing Padding scheme just described.
  324.  
  325.    Note that after decrypting, only the content of the last byte needs
  326.    to be examined to determine the presence or absence of a Self
  327.    Described Pad.
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334. Kummert                                                         [Page 6]
  335.  
  336. INTERNET DRAFT         PPP Triple-DES Encryption               July 1997
  337.  
  338.  
  339. 4.2  Recovery after packet loss
  340.  
  341.    Packet loss is detected when there is a discontinuity in the sequence
  342.    numbers of consecutive packets.  Suppose packet number N - 1 has an
  343.    unrecoverable error or is otherwise lost, but packets N and N + 1 are
  344.    received correctly.
  345.  
  346.    Since the previously described algorithm requires the last Ci of
  347.    packet N - 1 to decrypt C1 of packet N, it will be impossible to
  348.    decrypt packet N.  However, all packets N + 1 and following can be
  349.    decrypted in the usual way, since all that is required is the last
  350.    block of ciphertext of the previous packet (in this case packet N,
  351.    which WAS received).
  352.  
  353.  
  354. 5.  Security considerations
  355.  
  356.    Security issues are the primary subject of this draft. This proposal
  357.    relies on exterior and unspecified methods for retrieval of shared
  358.    secrets.  It proposes no new technology for privacy, but merely
  359.    describes a convention for the application of the 3DES cipher to data
  360.    transmission between PPP implementations.  Any methodology for the
  361.    protection and retrieval of shared secrets, and any limitations of
  362.    the 3DES cipher are relevant to the use described here.
  363.  
  364.  
  365. 6.  References
  366.  
  367.    [1]  Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
  368.         51, RFC 1661, Daydreamer, July 1994.
  369.  
  370.    [2]  Meyer, G., "The PPP Encryption Protocol", RFC 1968, Spider Sys-
  371.         tems, June 1996.
  372.  
  373.    [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
  374.         Levels", RFC 2119, BCP 14, Harvard University, March 1997.
  375.  
  376.    [4]  Meyer, G., Sklower, K. "The PPP DES Encryption Protocol (DESE)",
  377.         RFC 1969, Spider Systems, June 1996.
  378.  
  379.    [5]  Doraswamy, N., Metzger, P., Simpson, W., "The ESP Triple DES
  380.         Transform", Work in progress, June 1997
  381.  
  382.    [6]  Schneier, B., "Applied Cryptography Second Edition", John Wiley
  383.         & Sons, New York, NY, 1995.  ISBN 0-471-12845-7.
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390. Kummert                                                         [Page 7]
  391.  
  392. INTERNET DRAFT         PPP Triple-DES Encryption               July 1997
  393.  
  394.  
  395. 7.  Acknowledgements
  396.  
  397.    Much portions of this document was taken from [4] and [5]. Bill Simp-
  398.    son gave useful hints on the initial revision.
  399.  
  400.  
  401. 8. Author's  Address:
  402.  
  403.    Holger Kummert
  404.    Nentec Gesellschaft fuer Netzwerktechnologie
  405.    76227 Karlsruhe, Killisfeldstr. 67, Germany
  406.  
  407.    Phone:  +49 721 9495 0
  408.    E-mail: kummert@nentec.de
  409.  
  410. 9. Expiration date of this draft
  411.  
  412.    January 23, 1998
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446. Kummert                                                         [Page 8]
  447.