Network Working Group K. Culbert Internet Draft Funk Software expires in six months September 18, 1996 Proposal for LCP Authentication Option draft-ietf-pppext-link-negot-00.txt Status of this Memo This document is a submission of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a `working draft' or `work in progress.' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, ds.internic.net, venera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the current status of any Internet Draft. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components: 1. A method for encapsulating multi-protocol datagrams. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines an interoperable method for the authentication of peers during the Link negotiation phase. Culbert expires in six months [Page 1] DRAFT PPP LCP Authentication Option September 1996 1. Introduction Up-to-date values of the LCP Option Type field are specified in the most recent "Assigned Numbers" RFC [2]. This document concerns the following values: In "The Point-to-Point Protocol [1], the use of an authentication protocol may be negotiated as part of the LCP negotiation phase. The actual process of authentication is then performed in a subsequent authentication phase. This scheme may be unsatisfactory in situations, such as in the negotiation of Callback [3] or Layer 2 Tunneling [4], where the identity and authenticity of the peer is required during the LCP phase. It is proposed that a new LCP Authentication Option be defined as a extension to the Link Control Protocol. 1.1. Specification Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. Culbert expires in six months [Page 2] DRAFT PPP LCP Authentication Option September 1996 1.2 Terminology This document frequently uses the following terms: peer An end-point of a point-to-point link. authenticator The end-point that verifies the authenticity of its peer. authenticatee The end-point that is requesting authentication. silently discard The implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. 2.0 Overview In the current scheme, authentication is negotiated as part of the LCP phase, while authentication is actually carried out in a subsequent authentication phase. This document extends this scheme by adding a new option to the Link Control Protocol (LCP) which enables authentication to be carried out during the LCP negotiation phase. The LCP-Authentication option works differently than the current Authentication option in that the authenticatee includes the option in its Configuration-Request, and the authenticator indicates the success or failure of authentication in its response (Config-Ack or Config-Rej). Rejection of the LCP-Authentication option does not preclude negotiation of an authentication protocol using the current Authentication option. An authenticatee MAY offer the LCP-Authentication option in an initial Configure-Request or may wait for an authenticator to request its use by including it in a Config-Nak. An authenticator MAY include it in a Config-Nak in order to request its use by its peer; a peer which does not support the option MAY then send a Config-Nak including the current Authentication option or may simply wait for the authenticator to include the current Authentication option in a Config-Request. Culbert expires in six months [Page 3] DRAFT PPP LCP Authentication Option September 1996 2.1 Description A maximum of one LCP-Authentication option MAY be included in an LCP frame. The LCP-Authentication option may be initiated by either the authenticator or authenticatee. Here is an example of such a dialog: Authenticator Authenticatee ------------- ------------- Config-Request <-------------------------------------------------- authentication type / authenticatee id Config-Nak --------------------------------------------------> authentication type / authenticator id / challenge Config-Request <-------------------------------------------------- authentication type / authenticatee id / response Config Ack or Config-Rej --------------------------------------------------> authentication type / authenticator id / message Each end-point includes its identity (username) in every packet; an advantage of so doing is that both peers can then access their databases to determine which LCP options may be appropriate for its peer, such as Callback. Therefore, this option could be used merely to provide identity, leaving authentication to be carried out using the current scheme. If an authenticatee fails authentication based on the LCP-Authentication option, the authenticator MAY terminate the connection with a Terminate-Request. If an authenticatee does not negotiate any authentication scheme, the authenticator MAY terminate the connection. An implementation MAY choose to not implement any or all authentication types. Culbert expires in six months [Page 4] DRAFT PPP LCP Authentication Option September 1996 The LCP Authentication option employs a challenge-handshake technique, similar to CHAP [5]. The authenticator includes a Challenge value in the Value field of the LCP-Authentication option included in a Configuration-Nak. The authenticator then performs an MD5 hash over a stream of octets consisting of the concatentation of the Configuration-Request identifier, the "secret" (password), and the challenge value. The length of the Value field for the LCP Authentication option in both Configuration-Naks and Configuration-Acks is 16. The challenge value SHOULD change if the LCP Authentication option is sent in a Configuration-Nak with a different Identifier. If the authenticatee fails authentication, the authenticator MUST send a Configuration-Rej, and MAY terminate the link by issuing a Terminate-Request. If the authenticatee succeeds, the authenticator MUST send a Configuration-Ack. A summary of the LCP-Authentication 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 | Id-Length |Identification... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type to be determined Length >= 3 Id-Length The Id-Length field is one octet and indicates the length of the Identification field. Identification The Identification field is zero or more octets and indicates the identity of the sending peer. Culbert expires in six months [Page 5] DRAFT PPP LCP Authentication Option September 1996 Value The Value field is zero or more octets and MAY contain a Challenge value in the case of a Configuration-Request, a Response value in the case of a Configuration-Response, or a message in the case of a Configuration-Ack or Configuration-Rej. 3.0 Security Considerations Security issues are the primary topic of this draft. 4.0 References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC 1548, Daydreamer, December 1993. [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. [3] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer, January 1994. [4] Valencia, A. J., and G. S. Pall, "Layer Two Tunneling Protocol "L2TP"", work in progress, Cisco Systems, August 1996. [5] Lloyd, B., and W. Simpson, "PPP Authentication", RFC 1334, L & A, October 1992. Culbert expires in six months [Page 6] DRAFT PPP LCP Authentication Option September 1996 Acknowledgments Thanks to Vernon Schryver for his assistance in developing this draft. Chair's Address The working group can be contacted via the current chair: Karl F. Fox Ascend Communications 3518 Riverside Dr., Suite 101 Columbus, OH 43221 EMail: karl@ascend.com Author's Address Questions about this memo can also be directed to: Ken Culbert Funk Software, Inc. 222 Third Street Cambridge, MA 02142 +1 617 497-6339 EMail: ken@funk.com Culbert expires in six months [Page 7]