blank.gif (43 bytes)

Church Of The
Swimming Elephant

Search:
6.2. Authentication-Protocol Connected: An Internet Encyclopedia
6.2. Authentication-Protocol

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1661
Up: 6. LCP Configuration Options
Prev: 6.1. Maximum-Receive-Unit (MRU)
Next: 6.3. Quality-Protocol

6.2. Authentication-Protocol

6.2. Authentication-Protocol

Description

On some links it may be desirable to require a peer to authenticate itself before allowing network-layer protocol packets to be exchanged.

This Configuration Option provides a method to negotiate the use of a specific protocol for authentication. By default, authentication is not required.

An implementation MUST NOT include multiple Authentication- Protocol Configuration Options in its Configure-Request packets. Instead, it SHOULD attempt to configure the most desirable protocol first. If that protocol is Configure-Nak'd, then the implementation SHOULD attempt the next most desirable protocol in the next Configure-Request.

The implementation sending the Configure-Request is indicating that it expects authentication from its peer. If an implementation sends a Configure-Ack, then it is agreeing to authenticate with the specified protocol. An implementation receiving a Configure-Ack SHOULD expect the peer to authenticate with the acknowledged protocol.

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.

A summary of the Authentication-Protocol Configuration 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     |     Authentication-Protocol   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+

Type

3

Length

>= 4

Authentication-Protocol

The Authentication-Protocol field is two octets, and indicates the authentication protocol desired. Values for this field are always the same as the PPP Protocol field values for that same authentication protocol.

Up-to-date values of the Authentication-Protocol field are specified in the most recent "Assigned Numbers" RFC [2]. Current values are assigned as follows:

   Value (in hex)  Protocol

   c023            Password Authentication Protocol
   c223            Challenge Handshake Authentication Protocol

Data

The Data field is zero or more octets, and contains additional data as determined by the particular protocol.


Next: 6.3. Quality-Protocol

Connected: An Internet Encyclopedia
6.2. Authentication-Protocol

Cotse.Net

Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

 
.
www.cotse.com
Have you gone to church today?
.
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 Cotse.com.
Cotse.com is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609