One document matched: draft-ietf-pppext-eaprsa-01.txt
Differences from draft-ietf-pppext-eaprsa-00.txt
Network Working Group William T. Whelan
Internet Draft Network Express, Inc.
expires in six months February 16, 1996
PPP EAP RSA Public Key Authentication Protocol
<draft-ietf-pppext-eaprsa-01.txt>
Status of this Memo
This document is a submission to 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.
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 and 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 'work in
progress.'
To learn the current status of any Internet-Draft,
please check the '1id-abstracts.txt' listing contained
in the Internet-Drafts Shadow Directories on
ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au
(Pacific Rim).
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 Link Control Protocol,
which allows negotiation of an Authentication Protocol
for authentication its peer before allowing Network
Layer protocols to transmit over the link.
PPP Extensible Authentication Protocol (EAP) [2]
provides for a number of authentication mechanisms.
One of these is RSA Public Key Authentication. This
document defines RSA Public Key Authentication Protocol
within PPP EAP.
Whelan Expires in six months [Page 1]
DRAFT PPP EAP RSA Public Key Authentication Protocol February 1996
1. Introduction
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.
PPP Extensible Authentication Protocol (EAP) [2] allows
for a number of authentication protocols including RSA
Public Key Authentication Protocol.
This document defines the PPP EAP RSA Public Key
Authentication Protocol. The Link Establishment and
Authentication phases, and the Authentication-Protocol
Configuration Option are defined in The Point-to-Point
Protocol (PPP) [1]. The Extensible Authentication
protocol is defined in PPP Extensible Authentication
Protocol (EAP) [2].
1.1 Specification of 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
Whelan Expires in six months [Page 2]
DRAFT PPP EAP RSA Public Key Authentication Protocol February 1996
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 use of RSA Public Key
Authentication in the EAP-Request
during Authentication phase.
peer The other end of the point-to-point
link; the end which is being
authenticated by the authenticator.
RSA key pair A pair of keys, each of which can be
used to encode data or to reverse the
encoding performed by the other. The
two keys in the pair are known as the
public and private keys.
public key That key of a users key pair which is
publicly known [3].
private key (secret key) That key of a users key
pair which is known only by that user
[3].
digital signature Encipherment, by the originator's
secret key, of a compressed string of
the relevant data to be transferred.
The digital signature together with
the plain data is sent to the
recipient. This message is processed
by the recipient to prove integrity.
The digital signature mechanism also
proves the authenticity of the
originator and the unambiguous
relationship between the originator
and the data that was transferred [3].
A unique digital pattern produced by
encoding a message digest of digital
document using the signatory's private
key. The signature can be produced
only by someone holding the private
key and cannot be applied to any but
Whelan Expires in six months [Page 3]
DRAFT PPP EAP RSA Public Key Authentication Protocol February 1996
the intended digital document. The
signature can be verified by anyone
who has the signatory's public key.
certificate The public keys of a user, together
with some other information, rendered
unforgeable by encipherment with the
secret key of the certification
authority which issued it [3].
certification authority (CA) An authority trusted by
one or more users to create and assign
certificates. Optionally the
certification authority may create the
users' keys [3].
Whelan Expires in six months [Page 4]
DRAFT PPP EAP RSA Public Key Authentication Protocol February 1996
2. PPP EAP RSA Public Key Authentication
The PPP Extensible Authentication Protocol is a general
protocol for PPP authentication which supports multiple
authentication mechanisms. EAP MAY be negotiated at
Link Control Phase. EAP MAY then be used to select RSA
Public Key Authentication at Authentication Phase.
RSA Public Key Authentication Protocol is a challenge-
response protocol based on unilateral two pass
authentication as described in ISO/IEC 9798-3 [4]. The
authenticator issues a challenge in the form of a
Request packet. The peer MUST formulate a Response
packet based on information in the Request packet as
well as information only the peer knows (the peer's
private key). The peer MUST also provide in its
response its own public key as well as proof that it
knows the corresponding private key. The Response MUST
also contain the peer's certificate produced by a
trusted Certification Authority.
1. After the Link Establishment phase is complete and
Extensible Authentication Protocol is negotiated,
the authenticator sends a Request packet to
authenticate the peer. The Request packet has a
type field specifying RSA Public Key
Authentication plus some random data produced by
the authenticator.
2. The peer sends a Response packet in reply to the
Request. The exact contents of the Response is
partially dependent upon the random data sent by
the authenticator and partially dependent upon
random data produced by the peer itself.
Based on information contained in the Response packet,
the authenticator ends the authentication phase with
either a Success packet or a Failure packet. These
packets are defined in PPP Extensible Authentication
Protocol (EAP) [2].
Whelan Expires in six months [Page 5]
DRAFT PPP EAP RSA Public Key Authentication Protocol February 1996
3 PPP EAP RSA Public Key Authentication Packet Format
A summary of the PPP EAP RSA Public Key Authentication
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 | 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
9 - RSA Public Key Authentication
Data
The format of the Data field is determined by the
Code field.
Whelan Expires in six months [Page 6]
DRAFT PPP EAP RSA Public Key Authentication Protocol February 1996
3.1 RSA Public Key Request Packet
A summary of the PPP EAP RSA Public Key Authentication
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | ChallengeVal... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...ChallengeVal... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...ChallengeVal... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...ChallengeVal... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|...ChallengeVal|
+-+-+-+-+-+-+-+-+
Code
1
Identifier
The identifier field is one octet and aids in
matching responses with requests. The identifier
field MUST be changed on each Request packet
containing a different ChallengeVal.
Length
21
Type
9
ChallengeVal
The ChallengeVal is sixteen octets of data. It
SHOULD be generated by the authenticator in such a
way as to assure that it cannot be predicted by an
attacker using a playback attack. The
ChallengeVal will affect the Response packet sent
by the peer. The ChallengeVal SHOULD be changed
each time a Request is sent. This includes
retransmitted Requests in instances where a
previously transmitted Request or corresponding
Response is lost. Changing the ChallengeVal on
retransmissions is recommended so as to make a
replay attack more difficult.
Whelan Expires in six months [Page 7]
DRAFT PPP EAP RSA Public Key Authentication Protocol February 1996
3.2 RSA Public Key Response Packet
A summary of the PPP EAP RSA Public Key Authentication
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 | Cert Type | Certificate...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ResponseVal... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...ResponseVal... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...ResponseVal... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...ResponseVal... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChallengeVal... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...ChallengeVal... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...ChallengeVal... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...ChallengeVal |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Len | Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
2
Identifier
The identifier field is one octet and MUST match
the Identifier field from the corresponding
request.
Length
The Length field is two octets and indicates the
length of the EAP packet including the Code,
Identifier, Length, Type, Certificate, Random
Data, Echo Value, Signature Len, and Signature
fields.
Type
9
Whelan Expires in six months [Page 8]
DRAFT PPP EAP RSA Public Key Authentication Protocol February 1996
Cert Type
This field identifies the type of certificate the
peer is presenting. This is further defined in
the following section.
Certificate
The peers certificate. This is further defined
in the following section.
ResponseVal
The ResponseVal is a sixteen octet field. It
SHOULD be generated by the peer in such a way as
to assure that it cannot be predicted by an
attacker.
ChallengeVal
The ChallengeVal is a sixteen octet field which
MUST match the ChallengeVal which appeared in the
corresponding Request packet.
Signature Len
The length in octets of the following signature.
Signature
The signature of the peer applied to the
combination of ChallengeVal and ResponseVal. The
peer MUST take the thirty-two octets formed by
the ChallengeVal followed by the ResponseVal and
produce an MD5 message digest. The 128 bit
message digest MUST then be encrypted by the peer
using the peer's private key.
To verify this signature, the authenticator
MUST decrypt the peer's signature using the peer's
public key. The authenticator MUST also produce
an MD5 message digest using the ChallengeVal
followed by the ResponseVal. The two results
MUST then be compared for equality.
Whelan Expires in six months [Page 9]
DRAFT PPP EAP RSA Public Key Authentication Protocol February 1996
4 Certificates
PPP EAP RSA Public Key Authentication allows for the use
of different certificate formats. The Certificate Type
field in the Response packet identifies the certificate
format which follows. Two certificate formats and
corresponding Certificate Types are currently defined
for RSA public Key Authentication.
A certificate MUST provide the RSA public key of the
owner as well as some identification of the certificate
owner. These information must be signed by a mutually
trusted certifying authority.
Certificate Type = 1 - BER encoded ISO-509 certificate.
Certificate ::= SIGNED { SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version must be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version must be v2 or v3
extensions [3] Extensions OPTIONAL
-- If present, version must be v3 } }
Version ::= INTEGER { v1(0), v2 (1), v3(2) }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
notBefore UTCTime,
notAfter UTCTime
}
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectKey BIT STRING
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
}
Whelan Expires in six months [Page 10]
DRAFT PPP EAP RSA Public Key Authentication Protocol February 1996
UniqueIdentifier ::= BIT STRING
Extension ::= SEQUENCE {
extnId EXTENSION.&id ({ExtensionSet}),
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
-- contains a DER encoding of a value of type &ExtnType
-- for the extensin object identified by extnId
}
Certificate Type = 255 - Simple Certificate.
Simple Certificate Format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate Length |Identifier Len |Identifier Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Key Exp Length | Public Key Exponent...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Key Mod Length | Public Key Modulus...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Len | Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Certificate Length
The length in octets of the entire certificate
including all contiguous fields from the
Certificate Length through the Signature fields.
Identifier Len
The total length in octets of the Identifier Type
and Identification fields.
Identifier Type
This refers to the type of identification provided
by the Identification field.
1 - Identification field contains a name.
Whelan Expires in six months [Page 11]
DRAFT PPP EAP RSA Public Key Authentication Protocol February 1996
Identification
Format depends upon the value in the Identifier
Type. For Identifier Type = 1, this will be a
name. The length of the name will depend upon the
Identifier Len. The name will not be null
terminated.
Key Exp Len
Length in octets of the Public Key Exponent field.
Public Key Exponent
The value of the RSA public key exponent in
network byte order.
Key Mod Len
Length in octets of the Public Key Modulus field.
Public Key Modulus
The value of the RSA public key modulus in network
byte order.
Signature Len
Length in octets of the Signature field.
Signature
This field contains the signature of a certifying
authority applied to all contiguous fields within
the certificate from the Identifier Len through
the Public Key Modulus. To produce this
signature, the certifying authority will produce
an MD5 message digest of these fields then encrypt
the result using its RSA private key.
Whelan Expires in six months [Page 12]
DRAFT PPP EAP RSA Public Key Authentication Protocol February 1996
Security Considerations
RSA Public Key Authentication is designed to allow an
authenticator to obtain the public key from a peer and
to authenticate the peer by requiring the peer to
corroborate its identity by demonstrating its knowledge
of its private key. The process is based on the
unilateral two pass authentication described in ISO/IEC
9798-3 [4].
The use of random data fields within this protocol is
necessary to prevent replay or interleaving attacks.
Each entity (authenticator and peer) MUST provide
unpredictable random data so as to assure an adequate
level of security. Some techniques and considerations
for generating suitably unpredictable random data are
described in 'Randomness Recommendations for Security' [6].
RSA Public Key Authentication MUST provide for the
following requirements:
1. The peer MUST possess a valid certificate signed by
a mutually recognized certifying authority.
2. The peer MUST possess a valid private key corresponding
to the public key in the peer's certificate.
To assure these requirements are met, upon receipt of
the EAP Response packet, the authenticator MUST
verify the certification authority's signature within
the certificate by decrypting using the certification
authority's public key and compare the resulting
information to the rest of the certificate. The
authenticator MUST then obtain the peer's public key
from the peer's certificate and use it to decrypt the
peer's signature to verify it matches the MD5 digest
of the two sets of random data.
The set of recognized certifying authorities is
implementation dependent. As a minimum, an
authenticator MUST recognize any certifying authority
which signed the authenticators certificate.
Implementations MAY recognize certifying authorities
from a hierarchical chain.
If the peer's EAP Response satisfies all requirements,
the authenticator MUST send an EAP Success packet. If
the peer's EAP Response does not satisfy all
requirements, the authenticator MUST send an EAP
Failure packet and MAY take down the link.
Whelan Expires in six months [Page 13]
DRAFT PPP EAP RSA Public Key Authentication Protocol February 1996
References
[1] Simpson, W. A., 'The Point to Point Protocol
(PPP)', July 1994, RFC 1661.
[2] Blunk, L. J. & Vollbrecht, J. R., 'PPP Extensible
Authentication Protocol (EAP)', July 1995, work in
progress.
[3] CCITT Recommendation X.509, 'The Directory -
Authentication Framework', 1988.
[4] International Organization for Standardization and
the International Electrotechnical Commission,
ISO/IEC 9798-3, 'Information technology - Security
techniques - Entity Authentication - mechanisms -
Part 3: Entity authentication using a public key
algorithm'.
[5] Rivest, R., 'The MD5 Message Digest Algorithm',
April 1992, RFC 1321.
[6] Eastlake, D. E., Crocker, S. D., & Schiller, J. I.,
'Randomness Recommendations for Security', December
1994, RFC 1750.
Acknowledgments
Dave Carrell, Jeff Schiller, and Fred Baker provided
valuable feedback on earlier versions of this draft.
Chair's Address
The working group can be contacted via the current
chair:
Fred Baker
Cisco Systems, Inc.
Email: fbaker@cisco.com
Author's Address
Questions about this memo can also be directed to:
William T. Whelan
bwhelan@nei.com
Whelan Expires in six months [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-22 22:28:58 |