`Request for Comments: 1334 L&A
` W. Simpson
` Daydreamer
` October 1992
`
` PPP Authentication Protocols
`
`Status of this Memo
`
` This RFC specifies an IAB standards track protocol for the Internet
` community, and requests discussion and suggestions for improvements.
` Please refer to the current edition of the "IAB Official Protocol
` Standards" 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 of
` encapsulating Network Layer protocol information over point-to-point
` links. PPP also defines an extensible Link Control Protocol, which
` allows negotiation of an Authentication Protocol for authenticating
` its peer before allowing Network Layer protocols to transmit over the
` link.
`
` This document defines two protocols for Authentication: the Password
` Authentication Protocol and the Challenge-Handshake Authentication
` Protocol. This memo is the product of the Point-to-Point Protocol
` Working Group of the Internet Engineering Task Force (IETF).
` Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu
` mailing list.
`
`Table of Contents
`
` 1. Introduction ............................................... 2
` 1.1 Specification Requirements ................................. 2
` 1.2 Terminology ................................................ 3
` 2. Password Authentication Protocol ............................ 3
` 2.1 Configuration Option Format ................................ 4
` 2.2 Packet Format .............................................. 5
` 2.2.1 Authenticate-Request ..................................... 5
` 2.2.2 Authenticate-Ack and Authenticate-Nak .................... 7
` 3. Challenge-Handshake Authentication Protocol.................. 8
` 3.1 Configuration Option Format ................................ 9
` 3.2 Packet Format .............................................. 10
` 3.2.1 Challenge and Response ................................... 11
` 3.2.2 Success and Failure ...................................... 13
`
`Lloyd & Simpson [Page 1]
`
`Petitioner Apple Inc. - Exhibit 1050, p. 1
`
`
`
`RFC 1334 PPP Authentication October 1992
`
` SECURITY CONSIDERATIONS ........................................ 14
` REFERENCES ..................................................... 15
` ACKNOWLEDGEMENTS ............................................... 16
` CHAIR’S ADDRESS ................................................ 16
` AUTHOR’S ADDRESS ............................................... 16
`
`1. Introduction
`
` PPP has three main components:
`
` 1. A method for encapsulating datagrams over serial links.
`
` 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.
`
` In order to establish communications over a point-to-point link, each
` end of the PPP link must first send LCP packets to configure the data
` link during Link Establishment phase. After the link has been
` established, PPP provides for an optional Authentication phase before
` proceeding to the Network-Layer Protocol phase.
`
` By default, authentication is not mandatory. If authentication of
` the link is desired, an implementation MUST specify the
` Authentication-Protocol Configuration Option during Link
` Establishment phase.
`
` These authentication protocols are intended for use primarily by
` hosts and routers that connect to a PPP network server via switched
` circuits or dial-up lines, but might be applied to dedicated links as
` well. The server can use the identification of the connecting host
` or router in the selection of options for network layer negotiations.
`
` This document defines the PPP authentication protocols. The Link
` Establishment and Authentication phases, and the Authentication-
` Protocol Configuration Option, are defined in The Point-to-Point
` Protocol (PPP) [1].
`
`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.
`
`Lloyd & Simpson [Page 2]
`
`Petitioner Apple Inc. - Exhibit 1050, p. 2
`
`
`
`RFC 1334 PPP Authentication October 1992
`
` 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 should 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.
`
`1.2. Terminology
`
` This document frequently uses the following terms:
`
` authenticator
` The end of the link requiring the authentication. The
` authenticator specifies the authentication protocol to be used in
` the Configure-Request during Link Establishment phase.
`
` peer
` The other end of the point-to-point link; the end which is being
` authenticated by the authenticator.
`
` silently discard
` This means 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. Password Authentication Protocol
`
` The Password Authentication Protocol (PAP) provides a simple method
` for the peer to establish its identity using a 2-way handshake. This
` is done only upon initial link establishment.
`
` After the Link Establishment phase is complete, an Id/Password pair
` is repeatedly sent by the peer to the authenticator until
` authentication is acknowledged or the connection is terminated.
`
` PAP is not a strong authentication method. Passwords are sent over
` the circuit "in the clear", and there is no protection from playback
`
`Lloyd & Simpson [Page 3]
`
`Petitioner Apple Inc. - Exhibit 1050, p. 3
`
`
`
`RFC 1334 PPP Authentication October 1992
`
` or repeated trial and error attacks. The peer is in control of the
` frequency and timing of the attempts.
`
` Any implementations which include a stronger authentication method
` (such as CHAP, described below) MUST offer to negotiate that method
` prior to PAP.
`
` This authentication method is most appropriately used where a
` plaintext password must be available to simulate a login at a remote
` host. In such use, this method provides a similar level of security
` to the usual user login at the remote host.
`
` Implementation Note: It is possible to limit the exposure of the
` plaintext password to transmission over the PPP link, and avoid
` sending the plaintext password over the entire network. When the
` remote host password is kept as a one-way transformed value, and
` the algorithm for the transform function is implemented in the
` local server, the plaintext password SHOULD be locally transformed
` before comparison with the transformed password from the remote
` host.
`
`2.1. Configuration Option Format
`
` A summary of the Authentication-Protocol Configuration Option format
` to negotiate the Password Authentication Protocol 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 | Authentication-Protocol |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` Type
`
` 3
`
` Length
`
` 4
`
` Authentication-Protocol
`
` c023 (hex) for Password Authentication Protocol.
`
` Data
`
` There is no Data field.
`
`Lloyd & Simpson [Page 4]
`
`Petitioner Apple Inc. - Exhibit 1050, p. 4
`
`
`
`RFC 1334 PPP Authentication October 1992
`
`2.2. Packet Format
`
` Exactly one Password Authentication Protocol packet is encapsulated
` in the Information field of a PPP Data Link Layer frame where the
` protocol field indicates type hex c023 (Password Authentication
` Protocol). A summary of the PAP packet 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
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Code | Identifier | Length |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Data ...
` +-+-+-+-+
`
` Code
`
` The Code field is one octet and identifies the type of PAP packet.
` PAP Codes are assigned as follows:
`
` 1 Authenticate-Request
` 2 Authenticate-Ack
` 3 Authenticate-Nak
`
` Identifier
`
` The Identifier field is one octet and aids in matching requests
` and replies.
`
` Length
`
` The Length field is two octets and indicates the length of the PAP
` packet including the Code, Identifier, Length and Data fields.
` Octets outside the range of the Length field should be treated as
` Data Link Layer padding and should be ignored on reception.
`
` Data
`
` The Data field is zero or more octets. The format of the Data
` field is determined by the Code field.
`
`2.2.1. Authenticate-Request
`
` Description
`
` The Authenticate-Request packet is used to begin the Password
` Authentication Protocol. The link peer MUST transmit a PAP packet
`
`Lloyd & Simpson [Page 5]
`
`Petitioner Apple Inc. - Exhibit 1050, p. 5
`
`
`
`RFC 1334 PPP Authentication October 1992
`
` with the Code field set to 1 (Authenticate-Request) during the
` Authentication phase. The Authenticate-Request packet MUST be
` repeated until a valid reply packet is received, or an optional
` retry counter expires.
`
` The authenticator SHOULD expect the peer to send an Authenticate-
` Request packet. Upon reception of an Authenticate-Request packet,
` some type of Authenticate reply (described below) MUST be
` returned.
`
` Implementation Note: Because the Authenticate-Ack might be
` lost, the authenticator MUST allow repeated Authenticate-
` Request packets after completing the Authentication phase.
` Protocol phase MUST return the same reply Code returned when
` the Authentication phase completed (the message portion MAY be
` different). Any Authenticate-Request packets received during
` any other phase MUST be silently discarded.
`
` When the Authenticate-Nak is lost, and the authenticator
` terminates the link, the LCP Terminate-Request and Terminate-
` Ack provide an alternative indication that authentication
` failed.
`
` A summary of the Authenticate-Request packet 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
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Code | Identifier | Length |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Peer-ID Length| Peer-Id ...
` +-+-+-+-+-+-+-+-+-+-+-+-+
` | Passwd-Length | Password ...
` +-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` Code
`
` 1 for Authenticate-Request.
`
` Identifier
`
` The Identifier field is one octet and aids in matching requests
` and replies. The Identifier field MUST be changed each time an
` Authenticate-Request packet is issued.
`
`Lloyd & Simpson [Page 6]
`
`Petitioner Apple Inc. - Exhibit 1050, p. 6
`
`
`
`RFC 1334 PPP Authentication October 1992
`
` Peer-ID-Length
`
` The Peer-ID-Length field is one octet and indicates the length of
` the Peer-ID field.
`
` Peer-ID
`
` The Peer-ID field is zero or more octets and indicates the name of
` the peer to be authenticated.
`
` Passwd-Length
`
` The Passwd-Length field is one octet and indicates the length of
` the Password field.
`
` Password
`
` The Password field is zero or more octets and indicates the
` password to be used for authentication.
`
`2.2.2. Authenticate-Ack and Authenticate-Nak
`
` Description
`
` If the Peer-ID/Password pair received in an Authenticate-Request
` is both recognizable and acceptable, then the authenticator MUST
` transmit a PAP packet with the Code field set to 2 (Authenticate-
` Ack).
`
` If the Peer-ID/Password pair received in a Authenticate-Request is
` not recognizable or acceptable, then the authenticator MUST
` transmit a PAP packet with the Code field set to 3 (Authenticate-
` Nak), and SHOULD take action to terminate the link.
`
` A summary of the Authenticate-Ack and Authenticate-Nak packet 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
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Code | Identifier | Length |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Msg-Length | Message ...
` +-+-+-+-+-+-+-+-+-+-+-+-+-
`
` Code
`
` 2 for Authenticate-Ack;
`
`Lloyd & Simpson [Page 7]
`
`Petitioner Apple Inc. - Exhibit 1050, p. 7
`
`
`
`RFC 1334 PPP Authentication October 1992
`
` 3 for Authenticate-Nak.
`
` Identifier
`
` The Identifier field is one octet and aids in matching requests
` and replies. The Identifier field MUST be copied from the
` Identifier field of the Authenticate-Request which caused this
` reply.
`
` Msg-Length
`
` The Msg-Length field is one octet and indicates the length of the
` Message field.
`
` Message
`
` The Message field is zero or more octets, and its contents are
` implementation dependent. It is intended to be human readable,
` and MUST NOT affect operation of the protocol. It is recommended
` that the message contain displayable ASCII characters 32 through
` 126 decimal. Mechanisms for extension to other character sets are
` the topic of future research.
`
`3. Challenge-Handshake Authentication Protocol
`
` The Challenge-Handshake Authentication Protocol (CHAP) is used to
` periodically verify the identity of the peer using a 3-way handshake.
` This is done upon initial link establishment, and MAY be repeated
` anytime after the link has been established.
`
` After the Link Establishment phase is complete, the authenticator
` sends a "challenge" message to the peer. The peer responds with a
` value calculated using a "one-way hash" function. The authenticator
` checks the response against its own calculation of the expected hash
` value. If the values match, the authentication is acknowledged;
` otherwise the connection SHOULD be terminated.
`
` CHAP provides protection against playback attack through the use of
` an incrementally changing identifier and a variable challenge value.
` The use of repeated challenges is intended to limit the time of
` exposure to any single attack. The authenticator is in control of
` the frequency and timing of the challenges.
`
` This authentication method depends upon a "secret" known only to the
` authenticator and that peer. The secret is not sent over the link.
` This method is most likely used where the same secret is easily
` accessed from both ends of the link.
`
`Lloyd & Simpson [Page 8]
`
`Petitioner Apple Inc. - Exhibit 1050, p. 8
`
`
`
`RFC 1334 PPP Authentication October 1992
`
` Implementation Note: CHAP requires that the secret be available in
` plaintext form. To avoid sending the secret over other links in
` the network, it is recommended that the challenge and response
` values be examined at a central server, rather than each network
` access server. Otherwise, the secret SHOULD be sent to such
` servers in a reversably encrypted form.
`
` The CHAP algorithm requires that the length of the secret MUST be at
` least 1 octet. The secret SHOULD be at least as large and
` unguessable as a well-chosen password. It is preferred that the
` secret be at least the length of the hash value for the hashing
` algorithm chosen (16 octets for MD5). This is to ensure a
` sufficiently large range for the secret to provide protection against
` exhaustive search attacks.
`
` The one-way hash algorithm is chosen such that it is computationally
` infeasible to determine the secret from the known challenge and
` response values.
`
` The challenge value SHOULD satisfy two criteria: uniqueness and
` unpredictability. Each challenge value SHOULD be unique, since
` repetition of a challenge value in conjunction with the same secret
` would permit an attacker to reply with a previously intercepted
` response. Since it is expected that the same secret MAY be used to
` authenticate with servers in disparate geographic regions, the
` challenge SHOULD exhibit global and temporal uniqueness. Each
` challenge value SHOULD also be unpredictable, least an attacker trick
` a peer into responding to a predicted future challenge, and then use
` the response to masquerade as that peer to an authenticator.
` Although protocols such as CHAP are incapable of protecting against
` realtime active wiretapping attacks, generation of unique
` unpredictable challenges can protect against a wide range of active
` attacks.
`
` A discussion of sources of uniqueness and probability of divergence
` is included in the Magic-Number Configuration Option [1].
`
`3.1. Configuration Option Format
`
` A summary of the Authentication-Protocol Configuration Option format
` to negotiate the Challenge-Handshake Authentication Protocol is shown
` below. The fields are transmitted from left to right.
`
`Lloyd & Simpson [Page 9]
`
`Petitioner Apple Inc. - Exhibit 1050, p. 9
`
`
`
`RFC 1334 PPP Authentication October 1992
`
` 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 | Authentication-Protocol |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Algorithm |
` +-+-+-+-+-+-+-+-+
`
` Type
`
` 3
`
` Length
`
` 5
`
` Authentication-Protocol
`
` c223 (hex) for Challenge-Handshake Authentication Protocol.
`
` Algorithm
`
` The Algorithm field is one octet and indicates the one-way hash
` method to be used. The most up-to-date values of the CHAP
` Algorithm field are specified in the most recent "Assigned
` Numbers" RFC [2]. Current values are assigned as follows:
`
` 0-4 unused (reserved)
` 5 MD5 [3]
`
`3.2. Packet Format
`
` Exactly one Challenge-Handshake Authentication Protocol packet is
` encapsulated in the Information field of a PPP Data Link Layer frame
` where the protocol field indicates type hex c223 (Challenge-Handshake
` Authentication Protocol). A summary of the CHAP packet 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
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Code | Identifier | Length |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Data ...
` +-+-+-+-+
`
`Lloyd & Simpson [Page 10]
`
`Petitioner Apple Inc. - Exhibit 1050, p. 10
`
`
`
`RFC 1334 PPP Authentication October 1992
`
` Code
`
` The Code field is one octet and identifies the type of CHAP
` packet. CHAP Codes are assigned as follows:
`
` 1 Challenge
` 2 Response
` 3 Success
` 4 Failure
`
` Identifier
`
` The Identifier field is one octet and aids in matching challenges,
` responses and replies.
`
` Length
`
` The Length field is two octets and indicates the length of the
` CHAP packet including the Code, Identifier, Length and Data
` fields. Octets outside the range of the Length field should be
` treated as Data Link Layer padding and should be ignored on
` reception.
`
` Data
`
` The Data field is zero or more octets. The format of the Data
` field is determined by the Code field.
`
`3.2.1. Challenge and Response
`
` Description
`
` The Challenge packet is used to begin the Challenge-Handshake
` Authentication Protocol. The authenticator MUST transmit a CHAP
` packet with the Code field set to 1 (Challenge). Additional
` Challenge packets MUST be sent until a valid Response packet is
` received, or an optional retry counter expires.
`
` A Challenge packet MAY also be transmitted at any time during the
` Network-Layer Protocol phase to ensure that the connection has not
` been altered.
`
` The peer SHOULD expect Challenge packets during the Authentication
` phase and the Network-Layer Protocol phase. Whenever a Challenge
` packet is received, the peer MUST transmit a CHAP packet with the
` Code field set to 2 (Response).
`
` Whenever a Response packet is received, the authenticator compares
`
`Lloyd & Simpson [Page 11]
`
`Petitioner Apple Inc. - Exhibit 1050, p. 11
`
`
`
`RFC 1334 PPP Authentication October 1992
`
` the Response Value with its own calculation of the expected value.
` Based on this comparison, the authenticator MUST send a Success or
` Failure packet (described below).
`
` Implementation Note: Because the Success might be lost, the
` authenticator MUST allow repeated Response packets after
` completing the Authentication phase. To prevent discovery of
` alternative Names and Secrets, any Response packets received
` having the current Challenge Identifier MUST return the same
` reply Code returned when the Authentication phase completed
` (the message portion MAY be different). Any Response packets
` received during any other phase MUST be silently discarded.
`
` When the Failure is lost, and the authenticator terminates the
` link, the LCP Terminate-Request and Terminate-Ack provide an
` alternative indication that authentication failed.
`
` A summary of the Challenge and Response packet 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
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Code | Identifier | Length |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Value-Size | Value ...
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Name ...
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` Code
`
` 1 for Challenge;
`
` 2 for Response.
`
` Identifier
`
` The Identifier field is one octet. The Identifier field MUST be
` changed each time a Challenge is sent.
`
` The Response Identifier MUST be copied from the Identifier field
` of the Challenge which caused the Response.
`
` Value-Size
`
` This field is one octet and indicates the length of the Value
` field.
`
`Lloyd & Simpson [Page 12]
`
`Petitioner Apple Inc. - Exhibit 1050, p. 12
`
`
`
`RFC 1334 PPP Authentication October 1992
`
` Value
`
` The Value field is one or more octets. The most significant octet
` is transmitted first.
`
` The Challenge Value is a variable stream of octets. The
` importance of the uniqueness of the Challenge Value and its
` relationship to the secret is described above. The Challenge
` Value MUST be changed each time a Challenge is sent. The length
` of the Challenge Value depends upon the method used to generate
` the octets, and is independent of the hash algorithm used.
`
` The Response Value is the one-way hash calculated over a stream of
` octets consisting of the Identifier, followed by (concatenated
` with) the "secret", followed by (concatenated with) the Challenge
` Value. The length of the Response Value depends upon the hash
` algorithm used (16 octets for MD5).
`
` Name
`
` The Name field is one or more octets representing the
` identification of the system transmitting the packet. There are
` no limitations on the content of this field. For example, it MAY
` contain ASCII character strings or globally unique identifiers in
` ASN.1 syntax. The Name should not be NUL or CR/LF terminated.
` The size is determined from the Length field.
`
` Since CHAP may be used to authenticate many different systems, the
` content of the name field(s) may be used as a key to locate the
` proper secret in a database of secrets. This also makes it
` possible to support more than one name/secret pair per system.
`
`3.2.2. Success and Failure
`
` Description
`
` If the Value received in a Response is equal to the expected
` value, then the implementation MUST transmit a CHAP packet with
` the Code field set to 3 (Success).
`
` If the Value received in a Response is not equal to the expected
` value, then the implementation MUST transmit a CHAP packet with
` the Code field set to 4 (Failure), and SHOULD take action to
` terminate the link.
`
` A summary of the Success and Failure packet format is shown below.
` The fields are transmitted from left to right.
`
`Lloyd & Simpson [Page 13]
`
`Petitioner Apple Inc. - Exhibit 1050, p. 13
`
`
`
`RFC 1334 PPP Authentication October 1992
`
` 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 |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Message ...
` +-+-+-+-+-+-+-+-+-+-+-+-+-
`
` Code
`
` 3 for Success;
`
` 4 for Failure.
`
` Identifier
`
` The Identifier field is one octet and aids in matching requests
` and replies. The Identifier field MUST be copied from the
` Identifier field of the Response which caused this reply.
`
` Message
`
` The Message field is zero or more octets, and its contents are
` implementation dependent. It is intended to be human readable,
` and MUST NOT affect operation of the protocol. It is recommended
` that the message contain displayable ASCII characters 32 through
` 126 decimal. Mechanisms for extension to other character sets are
` the topic of future research. The size is determined from the
` Length field.
`
`Security Considerations
`
` Security issues are the primary topic of this RFC.
`
` The interaction of the authentication protocols within PPP are
` highly implementation dependent. This is indicated by the use of
` SHOULD throughout the document.
`
` For example, upon failure of authentication, some implementations
` do not terminate the link. Instead, the implementation limits the
` kind of traffic in the Network-Layer Protocols to a filtered
` subset, which in turn allows the user opportunity to update
` secrets or send mail to the network administrator indicating a
` problem.
`
` There is no provision for re-tries of failed authentication.
` However, the LCP state machine can renegotiate the authentication
` protocol at any time, thus allowing a new attempt. It is
`
`Lloyd & Simpson [Page 14]
`
`Petitioner Apple Inc. - Exhibit 1050, p. 14
`
`
`
`RFC 1334 PPP Authentication October 1992
`
` recommended that any counters used for authentication failure not
` be reset until after successful authentication, or subsequent
` termination of the failed link.
`
` There is no requirement that authentication be full duplex or that
` the same protocol be used in both directions. It is perfectly
` acceptable for different protocols to be used in each direction.
` This will, of course, depend on the specific protocols negotiated.
`
` In practice, within or associated with each PPP server, there is a
` database which associates "user" names with authentication
` information ("secrets"). It is not anticipated that a particular
` named user would be authenticated by multiple methods. This would
` make the user vulnerable to attacks which negotiate the least
` secure method from among a set (such as PAP rather than CHAP).
` Instead, for each named user there should be an indication of
` exactly one method used to authenticate that user name. If a user
` needs to make use of different authentication method under
` different circumstances, then distinct user names SHOULD be
` employed, each of which identifies exactly one authentication
` method.
`
` Passwords and other secrets should be stored at the respective
` ends such that access to them is as limited as possible. Ideally,
` the secrets should only be accessible to the process requiring
` access in order to perform the authentication.
`
` The secrets should be distributed with a mechanism that limits the
` number of entities that handle (and thus gain knowledge of) the
` secret. Ideally, no unauthorized person should ever gain
` knowledge of the secrets. It is possible to achieve this with
` SNMP Security Protocols [4], but such a mechanism is outside the
` scope of this specification.
`
` Other distribution methods are currently undergoing research and
` experimentation. The SNMP Security document also has an excellent
` overview of threats to network protocols.
`
`References
`
` [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
` Daydreamer, May 1992.
`
` [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1340,
` USC/Information Sciences Institute, July 1992.
`
`Lloyd & Simpson [Page 15]
`
`Petitioner Apple Inc. - Exhibit 1050, p. 15
`
`
`
`RFC 1334 PPP Authentication October 1992
`
` [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", MIT
` Laboratory for Computer Science and RSA Data Security, Inc. RFC
` 1321, April 1992.
`
` [4] Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security
` Protocols"