doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc1968.txt b/doc/rfc/rfc1968.txt
new file mode 100644
index 0000000..5916a31
--- /dev/null
+++ b/doc/rfc/rfc1968.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                           G. Meyer
+Request for Comments: 1968                                Spider Systems
+Category: Standards Track                                      June 1996
+
+
+               The PPP Encryption Control Protocol (ECP)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   The Point-to-Point Protocol (PPP) [1] provides a standard method for
+   transporting multi-protocol datagrams over point-to-point links.  PPP
+   also defines an extensible Link Control Protocol.
+
+   This document defines a method for negotiating data encryption over
+   PPP links.
+
+Conventions
+
+   The following language conventions are used in the items of
+   specification in this document:
+
+   o  MUST -- the item is an absolute requirement of the specification.
+      MUST is only used where it is actually required for interopera-
+      tion, not to try to impose a particular method on implementors
+      where not required for interoperability.
+
+   o  SHOULD -- the item should be followed for all but exceptional cir-
+      cumstances.
+
+   o  MAY or optional -- the item is truly optional and may be followed
+      or ignored according to the needs of the implementor.
+
+      The words "should" and "may" are also used, in lower case, in
+      their more ordinary senses.
+
+
+
+
+
+
+
+
+
+Meyer                       Standards Track                     [Page 1]
+
+RFC 1968                     PPP Encryption                    June 1996
+
+
+Table of Contents
+
+      1. Introduction ...........................................  2
+      2. Encryption Control Protocol (ECP) ......................  2
+          2.1 Sending Encrypted Datagrams .......................  3
+      3. Additional Packets .....................................  4
+          3.1 Reset-Request and Reset-Ack .......................  5
+      4. ECP Configuration Options ..............................  6
+          4.1 Proprietary Encryption OUI ........................  7
+          4.2 Publicly Available Encryption Types ...............  8
+          4.3 Negotiating an Encryption Algorithm ...............  9
+      5. Security Considerations ................................ 10
+
+1. Introduction
+
+   In order to establish communications over a PPP link, each end of the
+   link must first send LCP packets to configure and test the data link
+   during Link Establishment phase.  After the link has been
+   established, optional facilities may be negotiated as needed.
+
+   One such facility is data encryption.  A wide variety of encryption
+   methods may be negotiated, although typically only one method is used
+   in each direction of the link.
+
+   A different encryption algorithm may be negotiated in each direction,
+   for speed, cost, memory or other considerations.
+
+2. Encryption Control Protocol (ECP)
+
+   The Encryption Control Protocol (ECP) is responsible for configuring
+   and enabling data encryption algorithms on both ends of the point-
+   to-point link.
+
+   ECP uses the same packet exchange mechanism as the Link Control
+   Protocol (LCP).  ECP packets may not be exchanged until PPP has
+   reached the Network-Layer Protocol phase.  ECP packets received
+   before this phase is reached should be silently discarded.
+
+   The Encryption Control Protocol is exactly the same as LCP [1] with
+   the following exceptions:
+
+      Frame Modifications
+
+         The packet may utilise any modifications to the basic frame
+         format which have been negotiated during the Link Establishment
+         phase.
+
+
+
+
+
+Meyer                       Standards Track                     [Page 2]
+
+RFC 1968                     PPP Encryption                    June 1996
+
+
+      Data Link Layer Protocol Field
+
+         Exactly one ECP packet is encapsulated in the PPP Information
+         field, where the PPP Protocol field indicates type hex 8053
+         (Encryption Control Protocol).
+
+         When individual link data encryption is used in a multiple link
+         connection to a single destination [2], the PPP Protocol field
+         indicates type hex 8055 (Individual link Encryption Control
+         Protocol).
+
+      Code field
+
+         ECP uses (decimal) codes 1 through 7 (Configure-Request,
+         Configure-Ack, Configure-Nak, Configure-Reject, Terminate-
+         Request, Terminate-Ack and Code-Reject); And may also use code
+         14 (Reset-Request) and code 15 (Reset-Ack).  Other codes should
+         be treated as unrecognised and should result in Code-Rejects.
+
+      Negotiation
+
+         ECP packets may not be exchanged until PPP has reached the
+         Network-Layer Protocol phase.  An implementation should be
+         prepared to wait for Authentication and Link Quality
+         Determination to finish before timing out waiting for a
+         Configure-Ack or other response.
+
+         An implementation MUST NOT transmit data until ECP negotiation
+         has completed successfully.  If ECP negotiation is not
+         successful the link SHOULD be brought down.
+
+      Configuration Option Types
+
+         ECP has a distinct set of Configuration Options.
+
+2.1 Sending Encrypted Datagrams
+
+   Before any encrypted packets may be communicated, PPP must reach the
+   Network-Layer Protocol phase, and the Encryption Control Protocol
+   must reach the Opened state.
+
+   An encrypted packet is encapsulated in the PPP Information field,
+   where the PPP Protocol field indicates type hex 0053 (Encrypted
+   datagram).
+
+   When using multiple PPP links to a single destination [2], there are
+   two methods of employing data encryption:
+
+
+
+
+Meyer                       Standards Track                     [Page 3]
+
+RFC 1968                     PPP Encryption                    June 1996
+
+
+   o  The first method is to encrypt the data prior to sending it out
+      through the multiple links.
+
+      The PPP Protocol field MUST indicate type hex 0053.
+
+   o  The second is to treat each link as a separate connection, that
+      may or may not have encryption enabled.
+
+      On links which have negotiated encryption, the PPP Protocol field
+      MUST be type hex 0055 (Individual link encrypted datagram).
+
+   Only one encryption algorithm in each direction is in use at a time,
+   and that is negotiated prior to sending the first encrypted frame.
+   The PPP Protocol field of the encrypted datagram indicates that the
+   frame is encrypted, but not the algorithm with which it was
+   encrypted.
+
+   The maximum length of an encrypted packet transmitted over a PPP link
+   is the same as the maximum length of the Information field of a PPP
+   encapsulated packet.  If the encryption algorithm is likely to
+   increase the size of the message beyond that, multilink should also
+   be negotiated to allow fragmentation of the frames (even if only
+   using a single link).
+
+   If the encryption algorithm carries history between frames, the
+   encryption algorithm must supply a way of determining if it is
+   passing data reliably, or it must require the use of a reliable
+   transport such as LAPB [3].
+
+   Compression may also be negotiated using the Compression Control
+   Protocol [5].  To ensure interoperability, plain text MUST be:
+
+   o  First compressed.
+
+   o  Then encrypted.
+
+   This order has been chosen since it should result in smaller output
+   and more secure encryption.
+
+3. Additional Packets
+
+   The Packet format and basic facilities are already defined for LCP
+   [1].
+
+   Up-to-date values of the ECP Code field are specified in the most
+   recent "Assigned Numbers" RFC [4].  This specification concerns the
+   following values:
+
+
+
+
+Meyer                       Standards Track                     [Page 4]
+
+RFC 1968                     PPP Encryption                    June 1996
+
+
+         14      Reset-Request
+         15      Reset-Ack
+
+3.1 Reset-Request and Reset-Ack
+
+   Description
+
+      ECP includes Reset-Request and Reset-Ack Codes in order to provide
+      a mechanism for indicating a decryption failure in one direction
+      of a decrypted link without affecting traffic in the other
+      direction.  Some encryption algorithms may not require this
+      mechanism.
+
+      Individual algorithms need to specify a mechanism for determining
+      how to detect a decryption failure.  On initial detection of a
+      decryption failure, an ECP implementation SHOULD transmit an ECP
+      packet with the Code field set to 14 (Reset-Request).  The Data
+      field may be filled with any desired data.
+
+      Once a Reset-Request has been sent, any encrypted packets received
+      are discarded.  Further Reset-Requests MAY be sent with the same
+      Identifier, until a valid Reset-Ack is received.
+
+      When the link is busy, one decryption error is usually followed by
+      several more before the Reset-Ack can be received.  It is
+      undesirable to transmit Reset-Requests more frequently than the
+      round-trip-time of the link, since this will result in redundant
+      Reset-Requests and Reset-Acks being transmitted and processed.
+      The receiver MAY elect to limit transmission of Reset-Requests (to
+      say one per second) while a Reset-Ack is outstanding.
+
+      Upon reception of a Reset-Request, the transmitting encrypter is
+      reset to an initial state.  An ECP packet MUST be transmitted with
+      the Code field set to 15 (Reset-Ack), the Identifier field copied
+      from the Reset-Request packet, and the Data field filled with any
+      desired data.
+
+      On receipt of a Reset-Ack, the receiving decrypter is reset to an
+      initial state.  Since there may be several Reset-Acks in the pipe,
+      the decrypter MUST be reset for each Reset-Ack which matches the
+      currently expected identifier.
+
+      A summary of the Reset-Request and Reset-Ack packet formats is
+      shown below.  The fields are transmitted from left to right.
+
+
+
+
+
+
+
+Meyer                       Standards Track                     [Page 5]
+
+RFC 1968                     PPP Encryption                    June 1996
+
+
+        0                   1                   2                   3
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |     Code      |  Identifier   |            Length             |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |    Data ...
+       +-+-+-+-+
+
+
+   Code
+
+      14 for Reset-Request;
+
+      15 for Reset-Ack.
+
+   Identifier
+
+      On transmission, the Identifier field MUST be changed whenever the
+      content of the Data field changes, and whenever a valid reply has
+      been received for a previous request.  For retransmissions, the
+      Identifier SHOULD remain unchanged.
+
+      On reception, the Identifier field of the Reset-Request is copied
+      into the Identifier field of the Reset-Ack packet.
+
+   Data
+
+      The Data field is zero or more octets and contains uninterpreted
+      data for use by the sender.  The data may consist of any binary
+      value and may be of any length from zero to the peer's established
+      MRU minus four.
+
+4. ECP Configuration Options
+
+   ECP Configuration Options allow negotiation of encryption algorithms
+   and their parameters.  ECP uses the same Configuration Option format
+   defined for LCP [1], with a separate set of Options.
+
+   Configuration Options, in this protocol, indicate algorithms that the
+   receiver is willing or able to use to decrypt data sent by the
+   sender.  Systems may offer to accept several algorithms, and
+   negotiate a single one that will be used.
+
+   Up-to-date values of the ECP Option Type field are specified in the
+   most recent "Assigned Numbers" RFC [4].  Current values are assigned
+   as follows:
+
+
+
+
+
+Meyer                       Standards Track                     [Page 6]
+
+RFC 1968                     PPP Encryption                    June 1996
+
+
+         ECP Option      Encryption type
+
+         0               OUI
+         1               DESE
+
+
+   All compliant ECP implementations SHOULD implement ECP option 1 - the
+   PPP DES Encryption Protocol (DESE) [6].
+
+   Vendors who want to use proprietary encryption MAY use the OUI
+   mechanism to negotiate these without recourse to requesting an
+   assigned option number from the Internet Assigned Numbers Authority.
+   All other encryption options are registered by IANA.  At the time of
+   writing only DESE (option 1) is registered.  Other registered options
+   may be found by referring to future versions of the Assigned Numbers
+   RFC.
+
+4.1 Proprietary Encryption OUI
+
+   Description
+
+      This Configuration Option provides a way to negotiate the use of a
+      proprietary encryption protocol.
+
+      Vendor's encryption protocols are distinguished from each other by
+      means of an Organisationally Unique Identifier (OUI), namely the
+      first three octets of a Vendor's Ethernet address assigned by IEEE
+      802.
+
+      Since the first matching encryption will be used, it is
+      recommended that any known OUI encryption options be transmitted
+      first, before the common options are used.
+
+      Before accepting this option, the implementation must verify that
+      the OUI identifies a proprietary algorithm that the implementation
+      can decrypt, and that any vendor specific negotiation values are
+      fully understood.
+
+      A summary of the Proprietary Encryption OUI Configuration Option
+      format is shown below.  The fields are transmitted from left to
+      right.
+
+
+
+
+
+
+
+
+
+
+Meyer                       Standards Track                     [Page 7]
+
+RFC 1968                     PPP Encryption                    June 1996
+
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |    Length     |       OUI ...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+            OUI       |    Subtype    |  Values...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+   Type
+
+       0
+
+   Length
+
+      >= 6
+
+   IEEE OUI
+
+      The IEEE OUI is the most significant three octets of an Ethernet
+      Physical Address, assigned to the vendor by IEEE 802.  This
+      identifies the option as being proprietary to the indicated
+      vendor.  The bits within the octet are in canonical order, and the
+      most significant octet is transmitted first.
+
+   Subtype
+
+      This field is specific to each OUI, and indicates an encryption
+      type for that OUI.  There is no standardisation for this field.
+      Each OUI implements its own values.
+
+   Values
+
+      This field is zero or more octets, and contains additional data as
+      determined by the vendor's encryption protocol.
+
+4.2 Publicly Available Encryption Types
+
+   Description
+
+      These Configuration Options provide a way to negotiate the use of
+      a publicly defined encryption algorithm.
+
+      These protocols should be made available to interested parties,
+      but may have certain licencing or export restrictions associated
+      with them.  For additional information, refer to the encryption
+      protocol documents that define each of the encryption types.
+
+
+
+
+Meyer                       Standards Track                     [Page 8]
+
+RFC 1968                     PPP Encryption                    June 1996
+
+
+      A summary of the Encryption Type Configuration Option format is
+      shown below.  The fields are transmitted from left to right.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |    Length     |  Values...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+    Type
+
+       1 to 254, indicating the encryption protocol option
+       being negotiated.  DESE [6] is option type 1.  Refer to the
+       latest Assigned Numbers RFC for other encryption protocols.
+
+    Length
+
+       >= 2
+
+   Values
+
+      This field is zero or more octets, and contains additional data as
+      determined by the encryption protocol.
+
+4.3 Negotiating an Encryption Algorithm
+
+   ECP uses LCP option negotiation techniques to negotiate encryption
+   algorithms.  In contrast with most other LCP or NCP negotiation of
+   multiple options, ECP negotiation is expected to converge on a single
+   mutually agreeable option (encryption algorithm) - or none.
+   Encryption SHOULD be negotiated in both directions, but the
+   algorithms MAY be different.
+
+   An implementation willing to decrypt using a particular encryption
+   algorithm (or one of a set of algorithms) offers the algorithm(s) as
+   an option (or options) in an ECP Configure-Request - call this end
+   the Decrypter; call the peer the Encrypter.
+
+   A Decrypter supporting more than one encryption algorithm may send a
+   Configure-Request containing either:
+
+   o  an ordered list of options, with the most-preferred encryption
+      algorithm coming first.
+
+   o  Or may just offer its preferred (not already Rejected) option.
+
+
+
+
+
+Meyer                       Standards Track                     [Page 9]
+
+RFC 1968                     PPP Encryption                    June 1996
+
+
+   An Encrypter wishing to accept the first option (of several) MAY
+   Configure-Ack ALL Options to indicate complete acceptance of the
+   first-listed, preferred, algorithm.
+
+   Otherwise, if the Encrypter does not recognise - or is unwilling to
+   support - an option it MUST send a Configure-Reject for that option.
+   Where more than one option is offered, the Encrypter SHOULD
+   Configure-Reject all but a single preferred option.
+
+   If the Encrypter Configure-Rejects all offered ECP options - and the
+   Decrypter has no further (non-rejected) options it can offer in a
+   Configure-Request - the Encrypter SHOULD take the link down.
+
+   If the Encrypter recognises an option, but it is not acceptable due
+   to values in the request (or optional parameters not in the request),
+   it MUST send a Configure-Nak with the option modified appropriately.
+   The Configure-Nak MUST contain only those options that will be
+   acceptable.  The Decrypter SHOULD send a new Configure-Request with
+   only the single preferred option, adjusted as specified in the
+   Configure-Nak.
+
+5. Security Considerations
+
+   Negotiation of encryption using PPP is designed to provide protection
+   against eavesdropping on that link.  The strength of the protection
+   is dependent on the encryption algorithm used and the care with which
+   any 'secret' used by the encryption algorithm is protected.
+
+   It must be recognised that complete security can only be obtained
+   through end-to-end security between hosts.
+
+References
+
+   [1]  Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", STD
+        51, RFC 1661, Daydreamer, July 1994.
+
+   [2]  Sklower, K., Lloyd, B., McGregor, G. and and D. Carr, "The PPP
+        Multilink Protocol (MP)", RFC 1717, University of California,
+        Berkeley, November 1994.
+
+   [3]  Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July
+        1994.
+
+   [4]  Reynolds, J., and Postel, J.; "ASSIGNED NUMBERS", STD 2,
+        RFC 1700, USC/Information Sciences Institute, October 1994.
+
+   [5]  Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
+        1962, Novell, June 1996.
+
+
+
+Meyer                       Standards Track                    [Page 10]
+
+RFC 1968                     PPP Encryption                    June 1996
+
+
+   [6]  Sklower, K., and G. Meyer, "The PPP DES Encryption Protocol
+        (DESE)", RFC 1969, University of California, Berkeley, June
+        1996.
+
+Acknowledgements
+
+   The style and approach of this proposal owes much to the work on the
+   Compression CP [5].
+
+Chair's Address
+
+   The working group can be contacted via the current chair:
+
+   Karl Fox
+   Ascend Communications
+   3518 Riverside Drive, Suite 101
+   Columbus, Ohio 43221
+
+   EMail: karl@ascend.com
+
+Author's Address
+
+   Gerry Meyer
+   Spider Systems
+   Stanwell Street
+   Edinburgh EH6 5NG
+   Scotland, UK
+
+   Phone: (UK) 131 554 9424
+   Fax:   (UK) 131 554 0649
+   EMail: gerry@spider.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Meyer                       Standards Track                    [Page 11]
+