idnits 2.17.1 draft-ietf-pppext-link-negot-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 73: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 76: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 79: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 85: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 87: '...h does not include this option MUST be...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 18, 1996) is 10082 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1548 (ref. '1') (Obsoleted by RFC 1661) ** Obsolete normative reference: RFC 1340 (ref. '2') (Obsoleted by RFC 1700) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1334 (ref. '5') (Obsoleted by RFC 1994) Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Culbert 2 Internet Draft Funk Software 3 expires in six months September 18, 1996 5 Proposal for LCP Authentication Option 6 draft-ietf-pppext-link-negot-00.txt 8 Status of this Memo 10 This document is a submission of the Point-to-Point Protocol Working 11 Group of the Internet Engineering Task Force (IETF). Comments should 12 be submitted to the ietf-ppp@merit.edu mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a 25 `working draft' or `work in progress.' 27 Please check the 1id-abstracts.txt listing contained in the 28 internet-drafts Shadow Directories on nic.ddn.mil, ds.internic.net, 29 venera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the current 30 status of any Internet Draft. 32 Abstract 34 The Point-to-Point Protocol (PPP) [1] provides a standard method for 35 transporting multi-protocol datagrams over point-to-point links. PPP 36 is comprised of three main components: 38 1. A method for encapsulating multi-protocol datagrams. 40 2. A Link Control Protocol (LCP) for establishing, configuring, 41 and testing the data-link connection. 43 3. A family of Network Control Protocols (NCPs) for establishing 44 and configuring different network-layer protocols. 46 This document defines an interoperable method for the authentication 47 of peers during the Link negotiation phase. 49 1. Introduction 51 Up-to-date values of the LCP Option Type field are specified in the 52 most recent "Assigned Numbers" RFC [2]. This document concerns the 53 following values: 55 In "The Point-to-Point Protocol [1], the use of an authentication 56 protocol may be negotiated as part of the LCP negotiation phase. 57 The actual process of authentication is then performed in a 58 subsequent authentication phase. 60 This scheme may be unsatisfactory in situations, such as in the 61 negotiation of Callback [3] or Layer 2 Tunneling [4], where the 62 identity and authenticity of the peer is required during the LCP 63 phase. 65 It is proposed that a new LCP Authentication Option be defined as a 66 extension to the Link Control Protocol. 68 1.1. Specification Requirements 70 In this document, several words are used to signify the requirements 71 of the specification. These words are often capitalized. 73 MUST This word, or the adjective "required", means that the 74 definition is an absolute requirement of the specification. 76 MUST NOT This phrase means that the definition is an absolute 77 prohibition of the specification. 79 SHOULD This word, or the adjective "recommended", means that there 80 may exist valid reasons in particular circumstances to 81 ignore this item, but the full implications must be 82 understood and carefully weighed before choosing a 83 different course. 85 MAY This word, or the adjective "optional", means that this 86 item is one of an allowed set of alternatives. An 87 implementation which does not include this option MUST be 88 prepared to interoperate with another implementation which 89 does include the option. 91 1.2 Terminology 93 This document frequently uses the following terms: 95 peer An end-point of a point-to-point link. 97 authenticator The end-point that verifies the authenticity of 98 its peer. 100 authenticatee The end-point that is requesting authentication. 102 silently discard 103 The implementation discards the packet without 104 further processing. The implementation SHOULD 105 provide the capability of logging the error, 106 including the contents of the silently discarded 107 packet, and SHOULD record the event in a statistics 108 counter. 110 2.0 Overview 112 In the current scheme, authentication is negotiated as part of the 113 LCP phase, while authentication is actually carried out in a 114 subsequent authentication phase. This document extends this scheme 115 by adding a new option to the Link Control Protocol (LCP) which 116 enables authentication to be carried out during the LCP 117 negotiation phase. 119 The LCP-Authentication option works differently than the current 120 Authentication option in that the authenticatee includes the option 121 in its Configuration-Request, and the authenticator indicates the 122 success or failure of authentication in its response (Config-Ack 123 or Config-Rej). 125 Rejection of the LCP-Authentication option does not preclude 126 negotiation of an authentication protocol using the current 127 Authentication option. 129 An authenticatee MAY offer the LCP-Authentication option in an 130 initial Configure-Request or may wait for an authenticator to 131 request its use by including it in a Config-Nak. An authenticator 132 MAY include it in a Config-Nak in order to request its use by its 133 peer; a peer which does not support the option MAY then send a 134 Config-Nak including the current Authentication option or may simply 135 wait for the authenticator to include the current Authentication 136 option in a Config-Request. 138 2.1 Description 140 A maximum of one LCP-Authentication option MAY be included in an LCP 141 frame. 143 The LCP-Authentication option may be initiated by either the 144 authenticator or authenticatee. Here is an example of such a dialog: 146 Authenticator Authenticatee 147 ------------- ------------- 149 Config-Request 150 <-------------------------------------------------- 151 authentication type / authenticatee id 153 Config-Nak 154 --------------------------------------------------> 155 authentication type / authenticator id / challenge 157 Config-Request 158 <-------------------------------------------------- 159 authentication type / authenticatee id / response 161 Config Ack or Config-Rej 162 --------------------------------------------------> 163 authentication type / authenticator id / message 165 Each end-point includes its identity (username) in every packet; an 166 advantage of so doing is that both peers can then access their 167 databases to determine which LCP options may be appropriate for 168 its peer, such as Callback. Therefore, this option could be used 169 merely to provide identity, leaving authentication to be carried out 170 using the current scheme. 172 If an authenticatee fails authentication based on the 173 LCP-Authentication option, the authenticator MAY terminate the 174 connection with a Terminate-Request. If an authenticatee does not 175 negotiate any authentication scheme, the authenticator MAY terminate 176 the connection. 178 An implementation MAY choose to not implement any or all 179 authentication types. 181 The LCP Authentication option employs a challenge-handshake 182 technique, similar to CHAP [5]. The authenticator includes a 183 Challenge value in the Value field of the LCP-Authentication option 184 included in a Configuration-Nak. The authenticator then performs an 185 MD5 hash over a stream of octets consisting of the concatentation of 186 the Configuration-Request identifier, the "secret" (password), and 187 the challenge value. The length of the Value field for the LCP 188 Authentication option in both Configuration-Naks and 189 Configuration-Acks is 16. 191 The challenge value SHOULD change if the LCP Authentication option 192 is sent in a Configuration-Nak with a different Identifier. 194 If the authenticatee fails authentication, the authenticator MUST 195 send a Configuration-Rej, and MAY terminate the link by issuing a 196 Terminate-Request. 198 If the authenticatee succeeds, the authenticator MUST send a 199 Configuration-Ack. 201 A summary of the LCP-Authentication option format is shown below. 202 The fields are transmitted from left to right. 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 207 | Type | Length | Id-Length |Identification... 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 209 | Value ... 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 212 Type 214 to be determined 216 Length 218 >= 3 220 Id-Length 222 The Id-Length field is one octet and indicates the length of the 223 Identification field. 225 Identification 227 The Identification field is zero or more octets and indicates the 228 identity of the sending peer. 230 Value 232 The Value field is zero or more octets and MAY contain a Challenge 233 value in the case of a Configuration-Request, a Response value in 234 the case of a Configuration-Response, or a message in the case of 235 a Configuration-Ack or Configuration-Rej. 237 3.0 Security Considerations 239 Security issues are the primary topic of this draft. 241 4.0 References 243 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC 244 1548, Daydreamer, December 1993. 246 [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 247 RFC 1340, USC/Information Sciences Institute, July 1992. 249 [3] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, 250 Daydreamer, January 1994. 252 [4] Valencia, A. J., and G. S. Pall, "Layer Two Tunneling 253 Protocol "L2TP"", work in progress, Cisco Systems, August 254 1996. 256 [5] Lloyd, B., and W. Simpson, "PPP Authentication", RFC 1334, 257 L & A, October 1992. 259 Acknowledgments 261 Thanks to Vernon Schryver for his assistance in developing this draft. 263 Chair's Address 265 The working group can be contacted via the current chair: 267 Karl F. Fox 268 Ascend Communications 269 3518 Riverside Dr., Suite 101 270 Columbus, OH 43221 272 EMail: karl@ascend.com 274 Author's Address 276 Questions about this memo can also be directed to: 278 Ken Culbert 279 Funk Software, Inc. 280 222 Third Street 281 Cambridge, MA 02142 283 +1 617 497-6339 284 EMail: ken@funk.com