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]
