One document matched: draft-ietf-pppext-eap-srp-01.txt
Differences from draft-ietf-pppext-eap-srp-00.txt
Network Working Group J. Carlson
INTERNET-DRAFT Sun Microsystems
Expires September 2001 March 2001
PPP EAP SRP-SHA1 Authentication Protocol
<draft-ietf-pppext-eap-srp-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document is the product of the Point-to-Point Protocol
Extensions 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.
Abstract
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
also defines an Extensible Authentication Protocol (EAP) [2]
framework to allow the use of multiple authentication mechanisms
without fixing the mechanism to be used during initial link
negotiation. This document defines an authentication mechanism for
EAP called SRP-SHA1, and allows the use of the Secure Remote Password
(SRP) [3] protocol as a PPP link authentication method.
Carlson expires September 2001 [Page 1]
INTERNET-DRAFT PPP EAP SRP-SHA1 Authentication Protocol March 2001
Table of Contents
1. Introduction ........................................... 2
2. Detailed Description of EAP SRP-SHA1 Authentication .... 3
2.1. EAP SRP-SHA1 Packet Formats ............................ 4
2.2. EAP SRP-SHA1 Part 1 Request Packet ..................... 5
2.3. EAP SRP-SHA1 Part 1 Response Packet .................... 6
2.4. EAP SRP-SHA1 Part 2 Request Packet ..................... 7
2.5. EAP SRP-SHA1 Part 2 Response Packet .................... 8
2.6. EAP SRP-SHA1 Success Packet ............................ 9
3. Use with EAP ........................................... 11
3.1. One-Way Versus Bidirectional Encryption ................ 11
3.2. One-Way Versus Mutual Authentication ................... 11
3.3. DESEbis Versus 3DES .................................... 12
4. Security Considerations ................................ 12
5. Intellectual Property Rights Notices ................... 12
5.1. Patent Issues .......................................... 12
5.2. Full Copyright Statement ............................... 13
6. References ............................................. 14
7. Author's Address ....................................... 15
8. Appendix A - Well-Known Prime Modulus .................. 15
1. Introduction
PPP-EAP allows the use of multiple authentication mechanisms within a
single negotiation framework. This design overcomes the chief design
limitation of the original PPP authentication mechanisms, PAP [4] and
CHAP [5], which require that the protocol to be used for authentica-
tion be chosen before the user's identity is known. EAP also simpli-
fies the process of adding authentication mechanisms to PPP.
SRP is an open source protocol that provides strong, password-based
authentication based on cryptographic hashing that is resistant to
eavesdropping and active attacks. Unlike PAP, the password never
appears on the wire. Unlike CHAP (and variants MS-CHAPv1 [6] and
MS-CHAPv2 [7]), access to the cleartext password is not required for
the authenticator. Unlike all of these protocols, SRP is resistant
to man-in-the-middle attacks. As a side-effect, SRP also creates a
session key that can be used for data encryption.
SHA-1 [8] is a message digest algorithm that can be used as a hashing
mechanism for SRP, producing an SRP variant known as SRP-SHA1. For
calculation of the shared key in SRP, SHA-1 is used in an interleaved
form to produce 40 octet hashes. See [3] for details.
This document describes the message exchanges REQUIRED for one PPP
peer to authenticate the other using EAP and SRP-SHA1. As with all
Carlson expires September 2001 [Page 2]
INTERNET-DRAFT PPP EAP SRP-SHA1 Authentication Protocol March 2001
PPP authentication mechanisms, the peers are independent and equal,
and either or both may demand authentication from the other, and dif-
ferent protocols may be used independently in each direction.
When the PPP Encryption Control Protocol (ECP) [9] is used along with
EAP SRP-SHA1, this document describes methods that SHOULD be used to
generate the necessary shared keys from the SRP-SHA1 session key.
Because authentication necessarily requires prior arrangement between
the peers, pre-configured keys MAY be used in place of the SRP-SHA1
session key, and any such selection is outside the scope of this
document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [10].
2. Detailed Description of EAP SRP-SHA1 Authentication
Unlike CHAP, SRP-SHA1 requires more than one exchange to authenticate
the peer. For this reason, the usual EAP Request/Response is insuf-
ficient, and two separate Request/Response messages are defined.
With SRP, the authenticator must communicate at least three values to
the authenticatee, referred to as 's' (the password salt), 'B' (an
ephemeral public key), and 'M2' (a hash value). The authenticatee
must communicate at least three values to the authenticator, referred
to as 'C' (the client name), 'A' (an ephemeral public key), and 'M1'
(a hash value).
(The value 'u' passed from authenticator to authenticatee in the gen-
eral SRP algorithm is derived from the first 32 bits of a SHA-1 hash
of the 'B' value itself in the SRP-SHA1 algorithm. Thus, it does not
need to be sent explicitly.)
In order to send its last value (M1), the authenticatee needs A, B,
and u. However, in order to guarantee that the authenticatee's value
chosen for A isn't a rogue value (see section 3.2.4 of the SRP
description [11]), the value of u must not be sent until the authen-
ticatee reveals A. This implies that there are at least three steps
-- authenticatee sends A, authenticator sends B, authenticatee sends
M1.
The adaptation described in this document uses the EAP Identity
Request/Response mechanism to obtain C from the peer. It then uses
two new message types -- EAP SRP-SHA1 Parts 1 and 2 -- to handle the
SRP authentication. The Part 1 Request message contains s, g, and N.
The Part 1 Response contains A. The Part 2 Request continues with B
Carlson expires September 2001 [Page 3]
INTERNET-DRAFT PPP EAP SRP-SHA1 Authentication Protocol March 2001
and the Part 2 Response contains M1. Finally, the M2 value is
returned in a modified EAP Success message.
2.1. EAP SRP-SHA1 Packet Formats
A summary of the PPP EAP SRP-SHA1 Request/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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
1 - Request
2 - Response
Identifier
The identifier field is one octet and aids in matching responses
with requests.
Length
The Length field is two octets and indicates the length of the
EAP packet including the Code, Identifier, Length, Type, 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.
Type
19 - EAP SRP-SHA1 Part 1
20 - EAP SRP-SHA1 Part 2
Type-Data
The format of the Type-Data field is determined by the Code
field. The formats associated with EAP SRP-SHA1 are described in
the sections below.
Carlson expires September 2001 [Page 4]
INTERNET-DRAFT PPP EAP SRP-SHA1 Authentication Protocol March 2001
2.2. EAP SRP-SHA1 Part 1 Request Packet
The PPP EAP SRP-SHA1 Part 1 Request packet is SHOULD be sent after
the peer's identity has been obtained using the EAP Identity
Request/Response packets described in [2]. Using the peer's unau-
thenticated identity, the authenticator SHOULD look up the password
salt, verifier ('v'), prime modulus, and generator values in an
implementation-dependent manner. Use of EAP Identity is not required
by this specification, and determination of salt, verifier, prime
modulus, and generator may be done in any convenient manner.
A summary of the PPP EAP SRP-SHA1 Part 1 Request packet format is
shown below. Length and Type fields are as described above. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Salt Length | Prime Modulus Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prime Modulus ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
1 - Request
Identifier
The Identifier field is one octet and aids in matching responses
with requests. The Identifier field SHOULD be changed on each
Request packet sent, but MAY be kept the same on retransmit.
Type
19 - EAP SRP-SHA1 Part 1
Salt Length
Length of the Salt field in octets. This MUST be at least 4
octets and MAY be any length up to 255 octets. This field is not
padded.
Carlson expires September 2001 [Page 5]
INTERNET-DRAFT PPP EAP SRP-SHA1 Authentication Protocol March 2001
Prime Modulus Length
Length of the Prime Modulus field in octets. This value MAY be
zero to select the 2048 bit value for N listed in Appendix A and
select g=2. In this case, neither the Prime Modulus nor the
Generator field is present in the message.
If the Prime Modulus Length field is non-zero, then it SHOULD be
at least 64 octets (512 bits). Longer values are RECOMMENDED.
Salt
Password salt string; may contain any values and be of any
length, subject to link MTU restrictions.
Prime Modulus
Prime Modulus value. This value (called 'N' in the SRP
documentation) is in network byte order and has a length equal to
the Prime Modulus Length field.
Generator
The Generator value. This value (called 'g' in the SRP
documentation) is in network byte order and fills the rest of the
message without padding. If the Prime Modulus Length field is
omitted, then g is set to 2.
2.3. EAP SRP-SHA1 Part 1 Response Packet
The PPP EAP SRP-SHA1 Part 1 Response message MUST be sent in reply to
an EAP SRP-SHA1 Part 1 Request message and MUST NOT be retransmitted
on a time-out. Duplicate and invalid Response messages MUST be
ignored by the authenticator and SHOULD be logged. Invalid Request
messages MUST be acknowledged by the authenticatee with the EAP Nak
message; this includes Request messages with an unacceptable modulus
or generator value.
A summary of the PPP EAP SRP-SHA1 Part 1 Response packet format is
shown following. Length and Type fields are as described above. The
fields are transmitted from left to right.
Carlson expires September 2001 [Page 6]
INTERNET-DRAFT PPP EAP SRP-SHA1 Authentication Protocol March 2001
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value A ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
2 - Response
Identifier
The Identifier field is one octet and MUST match the Identifier
from the most recently received Part 1 Request.
Type
19 - EAP SRP-SHA1 Part 1
Value A
The result of (g**a) mod N, where 'a' is a randomly chosen number
in the range 1 .. N (exclusive). The randomly chosen number is
the authenticatee's private key, and the Value A field is the
corresponding public key. This field is not padded.
The A value MUST NOT be zero. If the authenticator receives zero
for this field, it SHOULD take action to disconnect the link.
2.4. EAP SRP-SHA1 Part 2 Request Packet
The PPP EAP SRP-SHA1 Part 2 Request message MUST NOT be sent until a
valid Part 1 Response message has be received. The Part 2 Request
message may be retransmitted on time-out. Once a valid Part 1
Response message has been received, it is not necessary to send
another Part 1 Request unless re-authentication is desired.
A summary of the PPP EAP SRP-SHA1 Part 2 Request packet format is
shown following. Length and Type fields are as described above. The
fields are transmitted from left to right.
Carlson expires September 2001 [Page 7]
INTERNET-DRAFT PPP EAP SRP-SHA1 Authentication Protocol March 2001
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value B ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
1 - Request
Identifier
The Identifier field is one octet and aids in matching responses
with requests. The Identifier field MUST be changed on each
Request packet sent.
Type
20 - EAP SRP-SHA1 Part 2
Value B
The result of (v + g**b) mod N, where 'b' is a randomly chosen
number in the range 1 .. N (exclusive), and v is the stored
verifier from the authentication database. The randomly chosen
number is the authenticator's private key, and the Value B field
is the corresponding public key. This field is not padded.
The B value MUST NOT be zero. If the authenticatee receives zero
for this field, it SHOULD take action to disconnect the link.
2.5. EAP SRP-SHA1 Part 2 Response Packet
The PPP EAP SRP-SHA1 Part 2 Response message MUST be sent by the
authenticatee in response to a valid EAP SRP-SHA1 Part 2 Request.
The authenticator validates this message by calculating the M1 value
from its own copies of A, B, and K, and compares the result. If the
values match, then the authentication is successful, and EAP Success
SHOULD be returned. If the values do not match, then EAP Failure
SHOULD be returned and the link terminated.
As described in SRP, the authenticatee computes x = SHA1(s,
passphrase), and then computes K = SHA_Interleave((B - g^x)^(a + u*x)
mod N). The authenticator computes K = SHA1_Interleave((A * v^u)^b
mod N). M1 may then be computed as SHA1(A, B, K).
Carlson expires September 2001 [Page 8]
INTERNET-DRAFT PPP EAP SRP-SHA1 Authentication Protocol March 2001
A summary of the PPP EAP SRP-SHA1 Part 2 Response packet format is
shown below. Length and Type fields are as described above. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value M1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M1 (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M1 (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M1 (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M1 (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M1 |
+-+-+-+-+-+-+-+-+
Code
2 - Response
Identifier
The Identifier field is one octet and MUST match the Identifier
from the most recently received Part 2 Request.
Length
25
Type
20 - EAP SRP-SHA1 Part 2
Value M1
The 20 octet result of SHA1(A, B, K).
2.6. EAP SRP-SHA1 Success Packet
The PPP EAP SRP-SHA1 Success message MUST be sent by the authentica-
tor in response to a valid EAP SRP-SHA1 Part 2 Response packet, and
Carlson expires September 2001 [Page 9]
INTERNET-DRAFT PPP EAP SRP-SHA1 Authentication Protocol March 2001
MUST NOT be retransmitted on an authenticator time-out. The SRP-SHA1
Success message MUST NOT be sent if a valid Part 2 Response has not
been received. If the authenticatee receives a Success message with
invalid contents, it SHOULD terminate the link to avoid man-in-the-
middle attacks. An authenticatee SHOULD retransmit its Part 2
Response message if a time-out occurs waiting for the Success mes-
sage, and an authenticator MUST retransmit the Success message if a
duplicate Part 2 Response is received.
A summary of the PPP EAP Success packet format is shown below.
Length and Type fields are as described above. 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 M2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M2 (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M2 (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M2 (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M2 (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
3 - Success
Identifier
The Identifier field is one octet and MUST match the Identifier
from the most recently transmitted Part 2 Request and received
Part 2 Response.
Length
24
Value M2
The 20 octet result of SHA1(A, B, K).
Carlson expires September 2001 [Page 10]
INTERNET-DRAFT PPP EAP SRP-SHA1 Authentication Protocol March 2001
3. Use with ECP
The 40 octet value K calculated by the SRP-SHA1 authentication pro-
cedure SHOULD be used to form encryption keys if PPP encryption is in
use. For the DESEbis [12] algorithm, a shared 56 bit key is neces-
sary, and for the 3DES [13] algorithm, a shared 168 bit key is
required. Complicating this, ECP may be negotiated in only one
direction or both. In addition, PPP authentication may be performed
one-way (the most common case) or mutually, and when mutual authenti-
cation is chosen, different authentication schemes may be used to
authenticate each peer. The effects of these details are described
below.
The "decryptor" is the peer that sends ECP Configure-Request suggest-
ing an algorithm and receives a corresponding ECP Configure-Ack. The
"encryptor" is the sender of the ECP Configure-Ack, and will transmit
the encrypted data.
3.1. One-Way Versus Bidirectional Encryption
When encryption is employed in only one direction, then the K value
that is chosen for the shared key is the value associated with the
EAP SRP-SHA1 authentication in which the decryptor is the authentica-
tor. If the decryptor did not authenticate its peer with EAP SRP-
SHA1, then the K value associated with the other authentication ses-
sion is used instead.
3.2. One-Way Versus Mutual Authentication
If only one peer authenticates the other using SRP-SHA1, and the
other either does not authenticate its peer at all or uses a method
that does not result in encryption keys, then the one K value associ-
ated with this authentication SHOULD be used for both encryption ses-
sions. The first 20 octets of K are used for the encryption of data
sent by the authenticatee to the authenticator, and the second 20
octets of K are used for encryption of data in the opposite direc-
tion.
If mutual authentication with algorithms that produce encryption keys
is done, such as SRP-SHA1, then two K values are produced. The K
values are used so that the encryptor is the authenticatee for the
corresponding authentication session, and the decryptor is the
authenticator.
Carlson expires September 2001 [Page 11]
INTERNET-DRAFT PPP EAP SRP-SHA1 Authentication Protocol March 2001
3.3. DESEbis Versus 3DES
For DESEbis, the first 8 octets of the key value are used. DES keys
are constructed such that the most significant bit (MSB) of each
octet is reserved for parity.
For 3DES, 24 octets of key value are used by most implementations.
As for DESEbis, the MSBs are discarded. If the 40 octet K value has
been split into two 20 octet values because one-way authentication is
in use, then an extra 4 octets are needed for each key. The SHA-1
algorithm is run again over the 40 octet K value to produce a 20
octet hash. This hash is split into two 10 octet values that are
then appended to the two 20 octet values from the split K value. The
first 24 octets of each 30 octet value is used as the 3DES key.
4. Security Considerations
The security of SRP relies on having a prime modulus that is large
enough to make brute force attack of the key exchange infeasible. A
length of at least 1024 bits is recommended. In addition, the SRP
document [3] describes tests that MUST be performed on the chosen
modulus and generator values and random numbers.
The hash values stored in the authenticator's database SHOULD be pro-
tected against disclosure and the user's choice password SHOULD be
restricted to limit the effectiveness of dictionary attacks.
5. Intellectual Property Rights Notices
5.1. Patent Issues
The SRP key-exchange protocol described in this document is available
worldwide on a royalty-free basis for commercial and non-commercial
uses.
"The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication and any assurances of licenses to
Carlson expires September 2001 [Page 12]
INTERNET-DRAFT PPP EAP SRP-SHA1 Authentication Protocol March 2001
be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat."
"The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director."
5.2. Full Copyright Statement
"Copyright (C) The Internet Society 2001. All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
Carlson expires September 2001 [Page 13]
INTERNET-DRAFT PPP EAP SRP-SHA1 Authentication Protocol March 2001
6. References
[1] W. Simpson, "The Point-to-Point Protocol (PPP)," RFC 1661,
07/1994
[2] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)," RFC 2284, 03/1998
[3] T. Wu, "The SRP Authentication and Key Exchange System,"
RFC 2945, 09/2000
[4] B. Lloyd, W. Simpson, "PPP Authentication Protocols," RFC
1334, 10/1992
[5] W. Simpson, "PPP Challenge Handshake Authentication Protocol
(CHAP)," RFC 1994, 08/1996
[6] G. Zorn, S. Cobb, "Microsoft PPP CHAP Extensions," RFC 2433,
10/1998
[7] G. Zorn, "Microsoft PPP CHAP Extensions, Version 2," RFC 2759,
01/2000
[8] National Institute of Standards and Technology (NIST),
"Announcing the Secure Hash Standard," FIPS 180-1, U.S.
Department of Commerce, 04/1995
[9] G. Meyer, "The PPP Encryption Control Protocol (ECP)," RFC 1968,
06/1996
[10] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels," BCP 14 and RFC 2119, 03/1997
[11] T. Wu, "The Secure Remote Password Protocol", in
Proceedings of the 1998 Internet Society Symposium on
Network and Distributed Systems Security, San Diego, CA,
pp. 97-111
[12] K. Sklower, G. Meyer, "The PPP DES Encryption Protocol, Version
2 (DESE-bis)," RFC 2419, September 1998.
[13] H. Kummert, "The PPP Triple-DES Encryption Protocol (3DESE),"
RFC 2420, September 1998.
Carlson expires September 2001 [Page 14]
INTERNET-DRAFT PPP EAP SRP-SHA1 Authentication Protocol March 2001
7. Author's Address
James Carlson
Sun Microsystems
1 Network Drive MS UBUR02-212
Burlington MA 01803-2757
Phone: +1 781 442 2084 Email: james.d.carlson@sun.com
Fax: +1 781 442 1677
8. Appendix A - Well-Known Prime Modulus
This 2048 bit prime modulus (and corresponding generator value 2) are
borrowed from the SRP GSS-API mechanism, an IETF work in progress.
0xAC, 0x6B, 0xDB, 0x41, 0x32, 0x4A, 0x9A, 0x9B,
0xF1, 0x66, 0xDE, 0x5E, 0x13, 0x89, 0x58, 0x2F,
0xAF, 0x72, 0xB6, 0x65, 0x19, 0x87, 0xEE, 0x07,
0xFC, 0x31, 0x92, 0x94, 0x3D, 0xB5, 0x60, 0x50,
0xA3, 0x73, 0x29, 0xCB, 0xB4, 0xA0, 0x99, 0xED,
0x81, 0x93, 0xE0, 0x75, 0x77, 0x67, 0xA1, 0x3D,
0xD5, 0x23, 0x12, 0xAB, 0x4B, 0x03, 0x31, 0x0D,
0xCD, 0x7F, 0x48, 0xA9, 0xDA, 0x04, 0xFD, 0x50,
0xE8, 0x08, 0x39, 0x69, 0xED, 0xB7, 0x67, 0xB0,
0xCF, 0x60, 0x95, 0x17, 0x9A, 0x16, 0x3A, 0xB3,
0x66, 0x1A, 0x05, 0xFB, 0xD5, 0xFA, 0xAA, 0xE8,
0x29, 0x18, 0xA9, 0x96, 0x2F, 0x0B, 0x93, 0xB8,
0x55, 0xF9, 0x79, 0x93, 0xEC, 0x97, 0x5E, 0xEA,
0xA8, 0x0D, 0x74, 0x0A, 0xDB, 0xF4, 0xFF, 0x74,
0x73, 0x59, 0xD0, 0x41, 0xD5, 0xC3, 0x3E, 0xA7,
0x1D, 0x28, 0x1E, 0x44, 0x6B, 0x14, 0x77, 0x3B,
0xCA, 0x97, 0xB4, 0x3A, 0x23, 0xFB, 0x80, 0x16,
0x76, 0xBD, 0x20, 0x7A, 0x43, 0x6C, 0x64, 0x81,
0xF1, 0xD2, 0xB9, 0x07, 0x87, 0x17, 0x46, 0x1A,
0x5B, 0x9D, 0x32, 0xE6, 0x88, 0xF8, 0x77, 0x48,
0x54, 0x45, 0x23, 0xB5, 0x24, 0xB0, 0xD5, 0x7D,
0x5E, 0xA7, 0x7A, 0x27, 0x75, 0xD2, 0xEC, 0xFA,
0x03, 0x2C, 0xFB, 0xDB, 0xF5, 0x2F, 0xB3, 0x78,
0x61, 0x60, 0x27, 0x90, 0x04, 0xE5, 0x7A, 0xE6,
0xAF, 0x87, 0x4E, 0x73, 0x03, 0xCE, 0x53, 0x29,
0x9C, 0xCC, 0x04, 0x1C, 0x7B, 0xC3, 0x08, 0xD8,
0x2A, 0x56, 0x98, 0xF3, 0xA8, 0xD0, 0xC3, 0x82,
0x71, 0xAE, 0x35, 0xF8, 0xE9, 0xDB, 0xFB, 0xB6,
0x94, 0xB5, 0xC8, 0x03, 0xD8, 0x9F, 0x7A, 0xE4,
0x35, 0xDE, 0x23, 0x6D, 0x52, 0x5F, 0x54, 0x75,
0x9B, 0x65, 0xE3, 0x72, 0xFC, 0xD6, 0x8E, 0xF2,
0x0F, 0xA7, 0x11, 0x1F, 0x9E, 0x4A, 0xFF, 0x73
Carlson expires September 2001 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 05:19:02 |