home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1900s / rfc1968.txt < prev    next >
Text File  |  1996-06-17  |  21KB  |  620 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           G. Meyer
  8. Request for Comments: 1968                                Spider Systems
  9. Category: Standards Track                                      June 1996
  10.  
  11.  
  12.                The PPP Encryption Control Protocol (ECP)
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of 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.  PPP
  26.    also defines an extensible Link Control Protocol.
  27.  
  28.    This document defines a method for negotiating data encryption over
  29.    PPP links.
  30.  
  31. Conventions
  32.  
  33.    The following language conventions are used in the items of
  34.    specification in this document:
  35.  
  36.    o  MUST -- the item is an absolute requirement of the specification.
  37.       MUST is only used where it is actually required for interopera-
  38.       tion, not to try to impose a particular method on implementors
  39.       where not required for interoperability.
  40.  
  41.    o  SHOULD -- the item should be followed for all but exceptional cir-
  42.       cumstances.
  43.  
  44.    o  MAY or optional -- the item is truly optional and may be followed
  45.       or ignored according to the needs of the implementor.
  46.  
  47.       The words "should" and "may" are also used, in lower case, in
  48.       their more ordinary senses.
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Meyer                       Standards Track                     [Page 1]
  59.  
  60. RFC 1968                     PPP Encryption                    June 1996
  61.  
  62.  
  63. Table of Contents
  64.  
  65.       1. Introduction ...........................................  2
  66.       2. Encryption Control Protocol (ECP) ......................  2
  67.           2.1 Sending Encrypted Datagrams .......................  3
  68.       3. Additional Packets .....................................  4
  69.           3.1 Reset-Request and Reset-Ack .......................  5
  70.       4. ECP Configuration Options ..............................  6
  71.           4.1 Proprietary Encryption OUI ........................  7
  72.           4.2 Publicly Available Encryption Types ...............  8
  73.           4.3 Negotiating an Encryption Algorithm ...............  9
  74.       5. Security Considerations ................................ 10
  75.  
  76. 1. Introduction
  77.  
  78.    In order to establish communications over a PPP link, each end of the
  79.    link must first send LCP packets to configure and test the data link
  80.    during Link Establishment phase.  After the link has been
  81.    established, optional facilities may be negotiated as needed.
  82.  
  83.    One such facility is data encryption.  A wide variety of encryption
  84.    methods may be negotiated, although typically only one method is used
  85.    in each direction of the link.
  86.  
  87.    A different encryption algorithm may be negotiated in each direction,
  88.    for speed, cost, memory or other considerations.
  89.  
  90. 2. Encryption Control Protocol (ECP)
  91.  
  92.    The Encryption Control Protocol (ECP) is responsible for configuring
  93.    and enabling data encryption algorithms on both ends of the point-
  94.    to-point link.
  95.  
  96.    ECP uses the same packet exchange mechanism as the Link Control
  97.    Protocol (LCP).  ECP packets may not be exchanged until PPP has
  98.    reached the Network-Layer Protocol phase.  ECP packets received
  99.    before this phase is reached should be silently discarded.
  100.  
  101.    The Encryption Control Protocol is exactly the same as LCP [1] with
  102.    the following exceptions:
  103.  
  104.       Frame Modifications
  105.  
  106.          The packet may utilise any modifications to the basic frame
  107.          format which have been negotiated during the Link Establishment
  108.          phase.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Meyer                       Standards Track                     [Page 2]
  115.  
  116. RFC 1968                     PPP Encryption                    June 1996
  117.  
  118.  
  119.       Data Link Layer Protocol Field
  120.  
  121.          Exactly one ECP packet is encapsulated in the PPP Information
  122.          field, where the PPP Protocol field indicates type hex 8053
  123.          (Encryption Control Protocol).
  124.  
  125.          When individual link data encryption is used in a multiple link
  126.          connection to a single destination [2], the PPP Protocol field
  127.          indicates type hex 8055 (Individual link Encryption Control
  128.          Protocol).
  129.  
  130.       Code field
  131.  
  132.          ECP uses (decimal) codes 1 through 7 (Configure-Request,
  133.          Configure-Ack, Configure-Nak, Configure-Reject, Terminate-
  134.          Request, Terminate-Ack and Code-Reject); And may also use code
  135.          14 (Reset-Request) and code 15 (Reset-Ack).  Other codes should
  136.          be treated as unrecognised and should result in Code-Rejects.
  137.  
  138.       Negotiation
  139.  
  140.          ECP packets may not be exchanged until PPP has reached the
  141.          Network-Layer Protocol phase.  An implementation should be
  142.          prepared to wait for Authentication and Link Quality
  143.          Determination to finish before timing out waiting for a
  144.          Configure-Ack or other response.
  145.  
  146.          An implementation MUST NOT transmit data until ECP negotiation
  147.          has completed successfully.  If ECP negotiation is not
  148.          successful the link SHOULD be brought down.
  149.  
  150.       Configuration Option Types
  151.  
  152.          ECP has a distinct set of Configuration Options.
  153.  
  154. 2.1 Sending Encrypted Datagrams
  155.  
  156.    Before any encrypted packets may be communicated, PPP must reach the
  157.    Network-Layer Protocol phase, and the Encryption Control Protocol
  158.    must reach the Opened state.
  159.  
  160.    An encrypted packet is encapsulated in the PPP Information field,
  161.    where the PPP Protocol field indicates type hex 0053 (Encrypted
  162.    datagram).
  163.  
  164.    When using multiple PPP links to a single destination [2], there are
  165.    two methods of employing data encryption:
  166.  
  167.  
  168.  
  169.  
  170. Meyer                       Standards Track                     [Page 3]
  171.  
  172. RFC 1968                     PPP Encryption                    June 1996
  173.  
  174.  
  175.    o  The first method is to encrypt the data prior to sending it out
  176.       through the multiple links.
  177.  
  178.       The PPP Protocol field MUST indicate type hex 0053.
  179.  
  180.    o  The second is to treat each link as a separate connection, that
  181.       may or may not have encryption enabled.
  182.  
  183.       On links which have negotiated encryption, the PPP Protocol field
  184.       MUST be type hex 0055 (Individual link encrypted datagram).
  185.  
  186.    Only one encryption algorithm in each direction is in use at a time,
  187.    and that is negotiated prior to sending the first encrypted frame.
  188.    The PPP Protocol field of the encrypted datagram indicates that the
  189.    frame is encrypted, but not the algorithm with which it was
  190.    encrypted.
  191.  
  192.    The maximum length of an encrypted packet transmitted over a PPP link
  193.    is the same as the maximum length of the Information field of a PPP
  194.    encapsulated packet.  If the encryption algorithm is likely to
  195.    increase the size of the message beyond that, multilink should also
  196.    be negotiated to allow fragmentation of the frames (even if only
  197.    using a single link).
  198.  
  199.    If the encryption algorithm carries history between frames, the
  200.    encryption algorithm must supply a way of determining if it is
  201.    passing data reliably, or it must require the use of a reliable
  202.    transport such as LAPB [3].
  203.  
  204.    Compression may also be negotiated using the Compression Control
  205.    Protocol [5].  To ensure interoperability, plain text MUST be:
  206.  
  207.    o  First compressed.
  208.  
  209.    o  Then encrypted.
  210.  
  211.    This order has been chosen since it should result in smaller output
  212.    and more secure encryption.
  213.  
  214. 3. Additional Packets
  215.  
  216.    The Packet format and basic facilities are already defined for LCP
  217.    [1].
  218.  
  219.    Up-to-date values of the ECP Code field are specified in the most
  220.    recent "Assigned Numbers" RFC [4].  This specification concerns the
  221.    following values:
  222.  
  223.  
  224.  
  225.  
  226. Meyer                       Standards Track                     [Page 4]
  227.  
  228. RFC 1968                     PPP Encryption                    June 1996
  229.  
  230.  
  231.          14      Reset-Request
  232.          15      Reset-Ack
  233.  
  234. 3.1 Reset-Request and Reset-Ack
  235.  
  236.    Description
  237.  
  238.       ECP includes Reset-Request and Reset-Ack Codes in order to provide
  239.       a mechanism for indicating a decryption failure in one direction
  240.       of a decrypted link without affecting traffic in the other
  241.       direction.  Some encryption algorithms may not require this
  242.       mechanism.
  243.  
  244.       Individual algorithms need to specify a mechanism for determining
  245.       how to detect a decryption failure.  On initial detection of a
  246.       decryption failure, an ECP implementation SHOULD transmit an ECP
  247.       packet with the Code field set to 14 (Reset-Request).  The Data
  248.       field may be filled with any desired data.
  249.  
  250.       Once a Reset-Request has been sent, any encrypted packets received
  251.       are discarded.  Further Reset-Requests MAY be sent with the same
  252.       Identifier, until a valid Reset-Ack is received.
  253.  
  254.       When the link is busy, one decryption error is usually followed by
  255.       several more before the Reset-Ack can be received.  It is
  256.       undesirable to transmit Reset-Requests more frequently than the
  257.       round-trip-time of the link, since this will result in redundant
  258.       Reset-Requests and Reset-Acks being transmitted and processed.
  259.       The receiver MAY elect to limit transmission of Reset-Requests (to
  260.       say one per second) while a Reset-Ack is outstanding.
  261.  
  262.       Upon reception of a Reset-Request, the transmitting encrypter is
  263.       reset to an initial state.  An ECP packet MUST be transmitted with
  264.       the Code field set to 15 (Reset-Ack), the Identifier field copied
  265.       from the Reset-Request packet, and the Data field filled with any
  266.       desired data.
  267.  
  268.       On receipt of a Reset-Ack, the receiving decrypter is reset to an
  269.       initial state.  Since there may be several Reset-Acks in the pipe,
  270.       the decrypter MUST be reset for each Reset-Ack which matches the
  271.       currently expected identifier.
  272.  
  273.       A summary of the Reset-Request and Reset-Ack packet formats is
  274.       shown below.  The fields are transmitted from left to right.
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Meyer                       Standards Track                     [Page 5]
  283.  
  284. RFC 1968                     PPP Encryption                    June 1996
  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.        |     Code      |  Identifier   |            Length             |
  291.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  292.        |    Data ...
  293.        +-+-+-+-+
  294.  
  295.  
  296.    Code
  297.  
  298.       14 for Reset-Request;
  299.  
  300.       15 for Reset-Ack.
  301.  
  302.    Identifier
  303.  
  304.       On transmission, the Identifier field MUST be changed whenever the
  305.       content of the Data field changes, and whenever a valid reply has
  306.       been received for a previous request.  For retransmissions, the
  307.       Identifier SHOULD remain unchanged.
  308.  
  309.       On reception, the Identifier field of the Reset-Request is copied
  310.       into the Identifier field of the Reset-Ack packet.
  311.  
  312.    Data
  313.  
  314.       The Data field is zero or more octets and contains uninterpreted
  315.       data for use by the sender.  The data may consist of any binary
  316.       value and may be of any length from zero to the peer's established
  317.       MRU minus four.
  318.  
  319. 4. ECP Configuration Options
  320.  
  321.    ECP Configuration Options allow negotiation of encryption algorithms
  322.    and their parameters.  ECP uses the same Configuration Option format
  323.    defined for LCP [1], with a separate set of Options.
  324.  
  325.    Configuration Options, in this protocol, indicate algorithms that the
  326.    receiver is willing or able to use to decrypt data sent by the
  327.    sender.  Systems may offer to accept several algorithms, and
  328.    negotiate a single one that will be used.
  329.  
  330.    Up-to-date values of the ECP Option Type field are specified in the
  331.    most recent "Assigned Numbers" RFC [4].  Current values are assigned
  332.    as follows:
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Meyer                       Standards Track                     [Page 6]
  339.  
  340. RFC 1968                     PPP Encryption                    June 1996
  341.  
  342.  
  343.          ECP Option      Encryption type
  344.  
  345.          0               OUI
  346.          1               DESE
  347.  
  348.  
  349.    All compliant ECP implementations SHOULD implement ECP option 1 - the
  350.    PPP DES Encryption Protocol (DESE) [6].
  351.  
  352.    Vendors who want to use proprietary encryption MAY use the OUI
  353.    mechanism to negotiate these without recourse to requesting an
  354.    assigned option number from the Internet Assigned Numbers Authority.
  355.    All other encryption options are registered by IANA.  At the time of
  356.    writing only DESE (option 1) is registered.  Other registered options
  357.    may be found by referring to future versions of the Assigned Numbers
  358.    RFC.
  359.  
  360. 4.1 Proprietary Encryption OUI
  361.  
  362.    Description
  363.  
  364.       This Configuration Option provides a way to negotiate the use of a
  365.       proprietary encryption protocol.
  366.  
  367.       Vendor's encryption protocols are distinguished from each other by
  368.       means of an Organisationally Unique Identifier (OUI), namely the
  369.       first three octets of a Vendor's Ethernet address assigned by IEEE
  370.       802.
  371.  
  372.       Since the first matching encryption will be used, it is
  373.       recommended that any known OUI encryption options be transmitted
  374.       first, before the common options are used.
  375.  
  376.       Before accepting this option, the implementation must verify that
  377.       the OUI identifies a proprietary algorithm that the implementation
  378.       can decrypt, and that any vendor specific negotiation values are
  379.       fully understood.
  380.  
  381.       A summary of the Proprietary Encryption OUI Configuration Option
  382.       format is shown below.  The fields are transmitted from left to
  383.       right.
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Meyer                       Standards Track                     [Page 7]
  395.  
  396. RFC 1968                     PPP Encryption                    June 1996
  397.  
  398.  
  399.        0                   1                   2                   3
  400.        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
  401.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  402.       |     Type      |    Length     |       OUI ...
  403.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  404.             OUI       |    Subtype    |  Values...
  405.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  406.  
  407.  
  408.    Type
  409.  
  410.        0
  411.  
  412.    Length
  413.  
  414.       >= 6
  415.  
  416.    IEEE OUI
  417.  
  418.       The IEEE OUI is the most significant three octets of an Ethernet
  419.       Physical Address, assigned to the vendor by IEEE 802.  This
  420.       identifies the option as being proprietary to the indicated
  421.       vendor.  The bits within the octet are in canonical order, and the
  422.       most significant octet is transmitted first.
  423.  
  424.    Subtype
  425.  
  426.       This field is specific to each OUI, and indicates an encryption
  427.       type for that OUI.  There is no standardisation for this field.
  428.       Each OUI implements its own values.
  429.  
  430.    Values
  431.  
  432.       This field is zero or more octets, and contains additional data as
  433.       determined by the vendor's encryption protocol.
  434.  
  435. 4.2 Publicly Available Encryption Types
  436.  
  437.    Description
  438.  
  439.       These Configuration Options provide a way to negotiate the use of
  440.       a publicly defined encryption algorithm.
  441.  
  442.       These protocols should be made available to interested parties,
  443.       but may have certain licencing or export restrictions associated
  444.       with them.  For additional information, refer to the encryption
  445.       protocol documents that define each of the encryption types.
  446.  
  447.  
  448.  
  449.  
  450. Meyer                       Standards Track                     [Page 8]
  451.  
  452. RFC 1968                     PPP Encryption                    June 1996
  453.  
  454.  
  455.       A summary of the Encryption Type Configuration Option format is
  456.       shown below.  The fields are transmitted from left to right.
  457.  
  458.        0                   1                   2                   3
  459.        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
  460.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  461.       |     Type      |    Length     |  Values...
  462.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  463.  
  464.  
  465.     Type
  466.  
  467.        1 to 254, indicating the encryption protocol option
  468.        being negotiated.  DESE [6] is option type 1.  Refer to the
  469.        latest Assigned Numbers RFC for other encryption protocols.
  470.  
  471.     Length
  472.  
  473.        >= 2
  474.  
  475.    Values
  476.  
  477.       This field is zero or more octets, and contains additional data as
  478.       determined by the encryption protocol.
  479.  
  480. 4.3 Negotiating an Encryption Algorithm
  481.  
  482.    ECP uses LCP option negotiation techniques to negotiate encryption
  483.    algorithms.  In contrast with most other LCP or NCP negotiation of
  484.    multiple options, ECP negotiation is expected to converge on a single
  485.    mutually agreeable option (encryption algorithm) - or none.
  486.    Encryption SHOULD be negotiated in both directions, but the
  487.    algorithms MAY be different.
  488.  
  489.    An implementation willing to decrypt using a particular encryption
  490.    algorithm (or one of a set of algorithms) offers the algorithm(s) as
  491.    an option (or options) in an ECP Configure-Request - call this end
  492.    the Decrypter; call the peer the Encrypter.
  493.  
  494.    A Decrypter supporting more than one encryption algorithm may send a
  495.    Configure-Request containing either:
  496.  
  497.    o  an ordered list of options, with the most-preferred encryption
  498.       algorithm coming first.
  499.  
  500.    o  Or may just offer its preferred (not already Rejected) option.
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Meyer                       Standards Track                     [Page 9]
  507.  
  508. RFC 1968                     PPP Encryption                    June 1996
  509.  
  510.  
  511.    An Encrypter wishing to accept the first option (of several) MAY
  512.    Configure-Ack ALL Options to indicate complete acceptance of the
  513.    first-listed, preferred, algorithm.
  514.  
  515.    Otherwise, if the Encrypter does not recognise - or is unwilling to
  516.    support - an option it MUST send a Configure-Reject for that option.
  517.    Where more than one option is offered, the Encrypter SHOULD
  518.    Configure-Reject all but a single preferred option.
  519.  
  520.    If the Encrypter Configure-Rejects all offered ECP options - and the
  521.    Decrypter has no further (non-rejected) options it can offer in a
  522.    Configure-Request - the Encrypter SHOULD take the link down.
  523.  
  524.    If the Encrypter recognises an option, but it is not acceptable due
  525.    to values in the request (or optional parameters not in the request),
  526.    it MUST send a Configure-Nak with the option modified appropriately.
  527.    The Configure-Nak MUST contain only those options that will be
  528.    acceptable.  The Decrypter SHOULD send a new Configure-Request with
  529.    only the single preferred option, adjusted as specified in the
  530.    Configure-Nak.
  531.  
  532. 5. Security Considerations
  533.  
  534.    Negotiation of encryption using PPP is designed to provide protection
  535.    against eavesdropping on that link.  The strength of the protection
  536.    is dependent on the encryption algorithm used and the care with which
  537.    any 'secret' used by the encryption algorithm is protected.
  538.  
  539.    It must be recognised that complete security can only be obtained
  540.    through end-to-end security between hosts.
  541.  
  542. References
  543.  
  544.    [1]  Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", STD
  545.         51, RFC 1661, Daydreamer, July 1994.
  546.  
  547.    [2]  Sklower, K., Lloyd, B., McGregor, G. and and D. Carr, "The PPP
  548.         Multilink Protocol (MP)", RFC 1717, University of California,
  549.         Berkeley, November 1994.
  550.  
  551.    [3]  Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July
  552.         1994.
  553.  
  554.    [4]  Reynolds, J., and Postel, J.; "ASSIGNED NUMBERS", STD 2,
  555.         RFC 1700, USC/Information Sciences Institute, October 1994.
  556.  
  557.    [5]  Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
  558.         1962, Novell, June 1996.
  559.  
  560.  
  561.  
  562. Meyer                       Standards Track                    [Page 10]
  563.  
  564. RFC 1968                     PPP Encryption                    June 1996
  565.  
  566.  
  567.    [6]  Sklower, K., and G. Meyer, "The PPP DES Encryption Protocol
  568.         (DESE)", RFC 1969, University of California, Berkeley, June
  569.         1996.
  570.  
  571. Acknowledgements
  572.  
  573.    The style and approach of this proposal owes much to the work on the
  574.    Compression CP [5].
  575.  
  576. Chair's Address
  577.  
  578.    The working group can be contacted via the current chair:
  579.  
  580.    Karl Fox
  581.    Ascend Communications
  582.    3518 Riverside Drive, Suite 101
  583.    Columbus, Ohio 43221
  584.  
  585.    EMail: karl@ascend.com
  586.  
  587. Author's Address
  588.  
  589.    Gerry Meyer
  590.    Spider Systems
  591.    Stanwell Street
  592.    Edinburgh EH6 5NG
  593.    Scotland, UK
  594.  
  595.    Phone: (UK) 131 554 9424
  596.    Fax:   (UK) 131 554 0649
  597.    EMail: gerry@spider.co.uk
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Meyer                       Standards Track                    [Page 11]
  619.  
  620.