From b6a1268714671904e96a49b88680dc3ff07aaa1c Mon Sep 17 00:00:00 2001 From: Kozlov Dmitry Date: Wed, 6 Oct 2010 16:43:14 +0400 Subject: project cleanup and prepare to release --- doc/rfc1334.txt | 899 -------------------------------------------------------- 1 file changed, 899 deletions(-) delete mode 100644 doc/rfc1334.txt (limited to 'doc/rfc1334.txt') diff --git a/doc/rfc1334.txt b/doc/rfc1334.txt deleted file mode 100644 index 6051f480..00000000 --- a/doc/rfc1334.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -Network Working Group B. Lloyd -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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", Trusted Information Systems, Inc., Hughes LAN - Systems, Inc., MIT Laboratory for Computer Science, RFC 1352, - July 1992. - -Acknowledgments - - Some of the text in this document is taken from RFC 1172, by Drew - Perkins of Carnegie Mellon University, and by Russ Hobby of the - University of California at Davis. - - Special thanks to Dave Balenson, Steve Crocker, James Galvin, and - Steve Kent, for their extensive explanations and suggestions. Now, - if only we could get them to agree with each other. - -Chair's Address - - The working group can be contacted via the current chair: - - Brian Lloyd - Lloyd & Associates - 3420 Sudbury Road - Cameron Park, California 95682 - - Phone: (916) 676-1147 - - EMail: brian@lloyd.com - -Author's Address - - Questions about this memo can also be directed to: - - William Allen Simpson - Daydreamer - Computer Systems Consulting Services - P O Box 6205 - East Lansing, MI 48826-6205 - - EMail: Bill.Simpson@um.cc.umich.edu - - - - - - - - -Lloyd & Simpson [Page 16] - \ No newline at end of file -- cgit v1.2.3