[ietf-enroll] PEAPOD I-D on imprinting/enrollment
Lord, Chris
chris.lord at intel.com
Wed Dec 17 18:47:07 EST 2003
Dear enroll mailing list members:
While researching protocols to enroll a device into secure network we
have come to believe that an enrollment protocol must balance mutual
authentication, implementation issues, and the user's experience. There
are real-world common usage models where mutual authentication is
required for enrollment. (This is especially true in environments with
overlapping wireless networks.) This mutual authentication must be
simple enough to be usable by the average person, must not be too
complex to implement or too slow to execute, and must maintain adequate
security.
Secure network credentials are based on cryptographic material which is
complex for an end user to evaluate - we want to make such evaluations
as easy as possible. Due to security reasons, the user must make
decisions based on the cryptographic information in the credentials as
opposed to non-cryptographic information in the credentials (i.e.,
present a hash of a key as opposed to a user name). The goal, then, is
to provide a flexible solution that enables users to deal with complex
information and come to the access control decisions they actually
desire.
The attached protocol (called PEAPOD) is an attempt to devise a protocol
that enables user-friendly representations of information to be used for
enrollment decisions. A suitable user interface is necessary to
complete the user experience, but the protocol establishes the elements
that need to be shown to the user.
The PEAPOD model assumes that each enrollment entity has a
public/private key pair. When a network authenticator receives a
connection request from an unknown device (public key not recognized),
it communicates with a user to determine whether the device should be
allowed access. Similarly, when a device finds a network authenticator
it doesn't recognize, the device takes steps (either through the PEAPOD
protocol or through a device-side user) to confirm that the network
authenticator is a trusted entity. PEAPOD assumes the existence an
out-of-band channel between the user controlling the network
authenticator and the device/device user. PEAPOD does not force these
authentication decisions, but it enables them to be made.
We are interested in sharing PEAPOD as input and in any feedback from
list members. Note that this draft has NOT been presented to the PPPEXT
working group.
Thanks in advance.
Dave Bowler
Chris Lord
PPPEXT Working Group Christopher Lord
Internet Draft David Bowler
Document: draft-peapod-00-06.txt Intel
Expires: April 2004 October 2003
Protected EAP for Ordinary Devices (PEAPOD)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This draft specifies a mutual authentication protocol based in the
Extensible Authentication Protocol (EAP) framework. This protocol
makes use of ancillary protocols and standards for the validation of
client device and authentication server credentials. The protocol is
based on public/private key pairs but does not require use of a
traditional certificate authority. PEAPOD is largely based on the
Internet-Draft Protected EAP, see [PEAP] for details. This
specification will highlight where PEAPOD deviates from PEAP. This
protocol was designed based on the requirements for securely
introducing client devices into an unmanaged 802.1x [IEEE8021X] based
network.
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 RFC-2119.
Lord, Bowler Standards Track [Page 1]
INTERNET DRAFT PEAPOD October 2003
Table of Contents
1. Introduction...................................................2
EAP/PEAP Issues................................................3
Terminology....................................................4
2. Protocol overview..............................................5
PEAPOD Part 1..................................................5
PEAPOD Part 2..................................................8
Version negotiation...........................................10
Error handling................................................10
Retry behavior................................................10
Session resumption............................................10
Fragmentation.................................................11
Key derivation................................................11
3. Detailed description of the PEAPOD protocol...................12
PEAPOD Outer Packet Format....................................12
PEAPOD Outer Request Packet...................................14
PEAPOD Outer Response Packet..................................16
PEAPOD Query Request Packet...................................18
PEAPOD Query Response Packet..................................19
PEAPOD Peer Secret Request Packet.............................20
PEAPOD Peer Secret Response Packet............................21
PEAPOD Display Request Packet.................................22
PEAPOD Display Response Packet................................23
4. Security considerations.......................................24
Method negotiation............................................24
TLS session cache handling....................................24
Self-signed certificates vs. certificate chains...............24
Certificate revocation........................................25
5. References....................................................26
Appendix A - Examples............................................27
Acknowledgments..................................................31
Author Addresses.................................................31
Intellectual Property Statement..................................31
Full Copyright Statement.........................................32
1. Introduction
The Extensible Authentication Protocol (EAP) provides a standard
protocol that extensibly supports multiple authentication schemes.
The Protected EAP (PEAP) protocol was developed to extend EAP in a
way that allows for encrypted and integrity-protected mutual
authentication. For this to work, it has generally been envisioned
that the Network Access Server (NAS) or an associated backend
authentication server will have knowledge of at least one traditional
certificate authority (CA) and will have access to applicable
certificate revocations lists.
Lord, Bowler Standards Track [Page 2]
INTERNET DRAFT PEAPOD October 2003
The PEAPOD protocol also extends EAP with the goal of establishing
secure mutual authentication. However, PEAPOD is designed to avoid
the use of traditional CAs, certificate revocation lists, etc. This
is of greater help when dealing with simple wireless devices and
environments in which use of commercial CAs are problematic.
The PEAPOD protocol, similar to the PEAP protocol, makes use of
Transport Layer Security (TLS) [RFC2246] to establish an encrypted
tunnel and exchange certificates between entities.
EAP/PEAP Issues
As EAP becomes increasingly popular, a number of weaknesses have
become apparent. Since EAP method negotiation is unprotected over a
medium to which an attacker has easy access, it is possible for an
attacker to inject and/or modify packets in order to cause "less
secure" methods of authentication to be negotiated. An attacker can
also collect information snooped during the authentication for
possible future attacks. PEAP addresses these issues by using TLS to
establish an encrypted channel between the peer and the
authentication server.
PEAP assumes that the peer in this connection has, or will have soon
after a connection is established, access to a CA with which to
validate the identity of the authentication server. No method other
than walking a certificate chain back to a trusted root is given for
a peer to make a decision to trust the authentication.
This is problematic for three reasons.
First, in the past, certificates have been issued by CAs to entities
other than the logical entity with which a peer believes it is
communicating. In some cases this has been accomplished by attackers
supplying the CA with incorrect information, while other times the
information is correct but confusing to a human who may be making a
trust decision based on it. (Example: A group administrator is
assigning rights based on a certificate from John Smith, but
incorrectly assumes that this is from the senior VP John Smith when
it is actually from the new contractor John Smith.)
Second, there have been cases where an attacker generates a root
certificate which looks very similar to the root certificate of a
trusted CA. While common certificate chain code will determine that
the root certificate is not trusted, it is a fairly common practice
to let an end-user make a decision about whether this new certificate
should be added to the list of trusted CAs.
Third, there are the issues of complexity and cost in accurately
deploying a public key infrastructure based on a CA. A large
Lord, Bowler Standards Track [Page 3]
INTERNET DRAFT PEAPOD October 2003
corporate entity may have sufficient IT support to run an internal CA
and do so effectively, but this is not likely to be the case for the
home user or smaller business. Also, some devices may lack
sufficient computing resources to be storing large sets of
authentication information. The decision may be made to install one
root certificate and trust all certificates off that root, but this
is likely to result in trusting a larger group than actually desired.
PEAPOD addresses these issues by eliminating the required use of CA
information. Instead, certificates communicated over TLS are
potentially self-signed, letting authentication entities know that
the peer is the one represented by the key in the certificate but
nothing else. In all cases, it is recommended that the trust
decision be based on the certificate in the certificate chain that is
at the lowest reasonable level (a root certificate being highest, a
leaf certificate being lowest). This solution can be problematic for
some peers with no way to receive trusted user interaction, so PEAPOD
has a method for communicating a shared secret from the
authentication server as a secondary means for authentication of the
server.
Terminology
Authenticator
The end of the link requiring the authentication.
Authentication Server
An Authentication Server is an entity that provides an
Authentication Service to an NAS. This service verifies the
credentials provided by the peer, and provides server
authentication credentials for the peer to validate.
NAS Short for "Network Access Server".
Peer
The other end of the point-to-point link (PPP), point-to-point
LAN segment (IEEE 802.1X) or 802.11 wireless link, which is being
authenticated by the NAS. In IEEE 802.1X, this end is known as
the Supplicant.
TLS Ciphersuite
The ciphersuite negotiated for protection of the PEAPOD Part 2
conversation.
Lord, Bowler Standards Track [Page 4]
INTERNET DRAFT PEAPOD October 2003
2. Protocol overview
PEAPOD is comprised of a two-part conversation, with most of the
second part being optional at the discretion of the peer.
[1] In Part 1, a TLS session is established with the server and
client mutually authenticating by certificate exchange. The
negotiated TLS key is then used to encrypt the conversation in
Part 2.
[2] In Part 2, the authentication server asks the peer if it requires
a shared secret be sent to provide additional authentication. If
the peer does require this, the server computes the shared secret
and communicates it over the TLS session.
The next two sections provide a more detailed overview of the two
parts of the PEAPOD conversation.
PEAPOD Part 1
The PEAPOD conversation MAY begin with the authenticator and the peer
negotiating EAP. The authenticator will typically send an EAP-
Request/Identity packet to the peer, and the peer will respond with
an EAP-Response/Identity packet to the authenticator, containing an
identifier (possibly a userId) for the peer.
Once the optional initial Identity Request/Response exchange is
completed, while nominally the EAP conversation occurs between the
authenticator and the peer, the authenticator MAY act as a pass-
through device, with the EAP packets received from the peer being
encapsulated for transmission to a backend authentication server. If
a backend authentication server is involved, the channel between the
authentication server and the authenticator SHOULD be secured. In
the discussion that follows, the term "EAP server" will be used to
denote the ultimate endpoint conversing with the peer.
Once it has determined that PEAPOD authentication is to occur, the
EAP server MUST respond with a PEAPOD/Start packet, which is an EAP-
Request packet with EAP-Type=PEAPOD, the Start (S) bit set, and no
data. Assuming that the peer supports PEAPOD, the PEAPOD conversation
will then begin, with the peer sending an EAP-Response packet with
EAP-Type=PEAPOD.
The data field of this EAP-Response packet will encapsulate a TLS
record in TLS record layer format, containing a TLS client_hello
handshake message. The current cipher spec for the TLS records will
be TLS_NULL_WITH_NULL_NULL and null compression. This current cipher
Lord, Bowler Standards Track [Page 5]
INTERNET DRAFT PEAPOD October 2003
spec remains in use until the change_cipher_spec message signals that
subsequent records will have the negotiated attributes for the
remainder of the handshake.
The client_hello message contains the client's TLS version number, a
sessionId, a random number, and a set of TLS ciphersuites supported
by the client. The version offered by the client MUST correspond to
TLS v1.0 or later.
The EAP server will then respond with an EAP-Request packet with EAP-
Type=PEAPOD. The data field of this packet will encapsulate one or
more TLS records. If a previous session is not being resumed, and no
errors have occurred, this packet MUST encapsulate the server_hello,
certificate, certificate_request, and server_hello_done messages; it
MAY include a server_key_exchange message. If a previous session is
being resumed, this packet MUST encapsulate the server_hello,
change_cipher_spec, and finished handshake messages.
The server_hello handshake message contains a TLS version number,
another random number, a sessionId, and a TLS ciphersuite. The
version offered by the server MUST correspond to TLS v1.0 or later.
In order to provide confidentiality, integrity and replay protection,
and authentication, the negotiated TLS ciphersuite MUST provide all
of these security services.
If the client's sessionId is null, unrecognized by the server, or is
relating to a session the server does not desire to resume, the
server MUST either choose a new sessionId to establish a new session
or choose to send an empty sessionId to indicate that the new session
will not be resumable. If the server recognizes the client's
sessionId and desires to resume the previous session, the server's
sessionId will match the one sent by the client. The server will
also choose a TLS ciphersuite from those offered by the client; if
the session matches the client's, then the TLS ciphersuite MUST match
the one negotiated during the handshake protocol execution that
established the session. If a session is being resumed, the peer
MUST NOT require that PEAPOD Part 2 be executed, though an
authentication server MAY elect to perform the PEAPOD Part 2
conversation.
PEAPOD implementations do not need to support all TLS ciphersuites
listed in [RFC2246]. Not all TLS ciphersuites are supported by
available TLS tool kits, and licenses may be required to support some
TLS ciphersuites (e.g. TLS ciphersuites utilizing the IDEA encryption
algorithm). To ensure interoperability, PEAPOD peers and
Authenticators MUST be able to negotiate the following TLS
ciphersuite:
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Lord, Bowler Standards Track [Page 6]
INTERNET DRAFT PEAPOD October 2003
Additionally, it is RECOMMENDED that PEAPOD peers and Authenticators
be able to negotiate the following TLS ciphersuites:
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS supports compression as well as ciphersuite negotiation.
Therefore, during the PEAPOD Part 1 conversation the EAP endpoints
MAY request or negotiate TLS compression.
The certificate message contains a certificate chain ending in a
public key certificate for either a key exchange public key (such as
an RSA or Diffie-Hellman key exchange public key) or a signature
public key (such as an RSA or DSS signature public key). In the
latter case, a TLS server_key_exchange handshake message MUST also be
included to allow the key exchange to take place. The certificate
chain MAY consist of only a self-signed certificate. See the section
?Self-signed certificates vs. certificate chains? for a discussion on
the security ramifications. Note that server authentication may
actually be performed in PEAPOD Part 2 based on the client?s response
to a PEAPOD Query Request.
The peer MUST respond to the EAP-Request with an EAP-Response packet
of EAP-Type=PEAPOD. The data field of this packet will encapsulate
one or more TLS records containing a TLS change_cipher_spec message
and finished handshake message. If a previous session is not being
resumed, this packet MUST also include certificate and
client_key_exchange messages and MAY include a certificate_verify
message. The certificate message will be used to authenticate the
peer to the server. The client_key_exchange completes the exchange
of a shared master secret between the peer and the EAP server. If
the preceding server_hello message sent by the EAP server in the
preceding EAP-Request packet indicated the resumption of a previous
session, then the peer MUST send only the change_cipher_spec and
finished handshake messages. The finished message contains the peer's
authentication response to the EAP server.
After the TLS session is established, there is no further PEAPOD
authentication of the peer. This lack of secondary authentication is
why the peer is required to send a certificate if one is requested by
the server. (Note: This is unlike PEAP where in PEAP Part 2 the
client sends its certificate to the server inside of the TLS tunnel
setup based on the server's certificate.) In PEAPOD the TLS client
certificates are sent in the clear; if identity protection is
required, the certificate SHOULD NOT contain any identifying
information other than the public key.
The EAP server MUST then respond with an EAP-Request packet with EAP-
Type=PEAPOD, which includes, in the case of a new TLS session, one or
more TLS records containing TLS change_cipher_spec and finished
Lord, Bowler Standards Track [Page 7]
INTERNET DRAFT PEAPOD October 2003
handshake messages. The latter contains the EAP server's
authentication response to the peer. The peer will then verify the
finished handshake hash in order to authenticate the EAP server.
If the EAP server authenticates unsuccessfully, the peer MAY send an
EAP-Response packet of EAP-Type=PEAPOD containing a TLS Alert message
identifying the reason for the failed authentication. The peer MAY
send a TLS alert message rather than immediately terminating the
conversation so as to allow the EAP server to log the cause of the
error for examination by the system administrator.
To ensure that the EAP Server receives the TLS alert message, the
peer MUST wait for the EAP Server to reply before terminating the
conversation. The EAP Server MUST reply with an EAP-Failure packet
since server authentication failure is a terminal condition.
If the EAP server authenticates successfully, the peer MUST send an
EAP-Response packet of EAP-Type=PEAPOD, with no data. If a previous
TLS session was not resumed, the EAP-Server then continues with Part
2 of the PEAPOD conversation. If a previous TLS session was resumed,
it is RECOMMENDED that the EAP-Server not continue with Part 2 of the
PEAPOD conversation, since Part 2 SHOULD be considered redundant with
the session resumption.
2.1.1.Forging of Success and Failure packets
Within EAP, Success and Failure packets may be trivially forged since
they are not authenticated in any way. Forging packets can results
in either failing a connection that should not have been failed or
accepting a connection that should not have been accepted.
By requiring mutual authentication, and securing EAP communication
inside a TLS tunnel, PEAPOD provides protection against forging
attacks. Since the PEAPOD Authenticator and peer MUST both
authenticate themselves during PEAPOD Part 1, once the TLS tunnel is
established all Success/Failure packets SHOULD be sent within the TLS
tunnel. Once PEAPOD has been selected as the authentication method
and the PEAPOD conversation has begun, a peer receiving
Success/Failure packets in the clear (outside the TLS tunnel) MUST
silently discard the packets.
PEAPOD Part 2
The second portion of the PEAPOD conversation consists of an optional
secondary authentication of the server to the peer. This part is
included to allow the peer a method of authenticating the server in
the case that the peer does not have the ability to validate the
Lord, Bowler Standards Track [Page 8]
INTERNET DRAFT PEAPOD October 2003
server based on the server's certificate. The PEAPOD Part 2
conversation will occur only if establishment of the TLS session in
Part 1 is successful. It MUST NOT occur if the EAP Server or the
peer authenticates unsuccessfully or if an EAP-Failure has been sent
by the EAP Server to the peer, terminating the conversation. Since
all packets sent within the PEAPOD Part 2 conversation occur after
TLS session establishment, they are protected using the negotiated
TLS ciphersuite.
Part 2 of the PEAPOD conversation begins with the Authenticator
sending an EAP-Request/Query Request packet to the peer, protected by
the TLS ciphersuite negotiated in PEAPOD Part 1. The peer responds
with an EAP-Response/Query Response packet to the authenticator,
containing information as to whether the peer requires a Peer Secret
be sent and whether the peer has user display capabilities.
At this point the authenticator MAY send an EAP-Request/Display
Request packet to the peer. This message SHOULD NOT be sent if the
EAP-Response/Query Response packet sent by the peer does not indicate
that the peer has the ability to display authentication credentials
to a user. The peer responds with an EAP-Response/Display Response
packet indicating whether or not it displayed credentials to the
user. The conversation MAY proceed whether or not the peer displayed
credentials. There is no PEAPOD message by which the authenticator
can instruct the peer to turn off its display. When to turn off the
display is an implementation choice of the peer.
If the peer does not require that a Peer Secret be communicated (the
Part 1 conversation was sufficient for authentication), the PEAPOD
Part 2 conversation ends. If the peer does require that a Peer
Secret be communicated, the server computes and transmits a Peer
Secret.
The Peer Secret is of the form:
H = HMAC-SHA1 (Secret, (Pd | Pa | TLS created random #))
HMAC-SHA1 is the keyed hash function described in RFC2104.
Secret is a value communicated to the authentication server via
an ancillary protocol (and known by the peer).
Pd and Pa are string representations of the peer's and
authenticator's public keys respectively.
TLS created random # is a SHA1 hash of the pre-master secret
used in establishing the TLS session.
Therefore, H is a HMAC-SHA1 of the public keys and a nonce value
using the secret string as an input key value to HMAC-SHA1. H is
then communicated over the TLS session. Upon receiving the
authenticator's H value, the peer computes its own H value using the
same algorithm. The peer compares it to H from the authenticator.
Lord, Bowler Standards Track [Page 9]
INTERNET DRAFT PEAPOD October 2003
Upon successful match, the peer returns a success code over the EAP
protocol to the authenticator.
Upon an unsuccessful match, the peer returns an error code over the
EAP protocol to the authenticator. At the peer?s discretion, this
may be considered a terminal error, in which case the peer also
includes a TLS alert in the EAP Response packet. If the peer does
not consider this to be a terminal error, the server may resend the
Peer Secret packet until either the H value matches or the peer
considers the number of failures to constitute a terminal error.
Version negotiation
PEAPOD packets contain a three-bit version field, which allows for
the possibility of PEAPOD implementations being backward compatible
with previous versions of the protocol. The version negotiation
protocol for PEAPOD is the same as is found in [PEAP] section 2.3.
For the version of PEAPOD described in this document, the version
number is 1.
Error handling
Error handling for PEAPOD is largely the same as is found in [PEAP]
section 2.5. The exceptions to this are when errors for Part 2
Requests for Display and Peer Secret are communicated. The Response
packets for these messages have success flags. In the event of an
error, these flags will be set to 0. After the response with the 0
flags, a TLS alert MAY be sent if the peer implementation considers
this to be a terminal error.
Retry behavior
The retry behavior for PEAPOD is the same as is found in [PEAP]
section 2.6.
Session resumption
Session resumption is based on the same as is found in [PEAP];
however, due to the differences in PEAPOD this section is self-
contained.
The purpose of the sessionId within the TLS protocol is to allow for
improved efficiency in the case where a client repeatedly attempts to
authenticate to an EAP server within a short period of time. This
Lord, Bowler Standards Track [Page 10]
INTERNET DRAFT PEAPOD October 2003
capability is particularly useful in environments in which multiple
reconnects are likely (wireless roaming, etc.).
It is left up to the peer whether to attempt to continue a previous
session. If a peer chooses to attempt to continue a previous
session, it is implicitly agreeing that the server sufficiently
authenticated during the previous session, and the peer does not
require that the server further authenticate itself. Resuming a
session shortens the PEAPOD Part 1 conversation and, at the
discretion of the server, eliminates the Part 2 conversation
(including the PEAPOD Query Peer Authentication Request packet).
Based on the sessionId chosen by the peer, the time elapsed since the
previous authentication, and whether the peer sufficiently
authenticated itself in the previous session, the EAP server will
decide whether to allow the continuation, or whether to choose a new
session. The EAP server MUST NOT allow the continuation of the
previous session if the peer did not sufficiently authenticate itself
during the previous session.
A client will only be able to resume a session when communicating
with the same authentication server it communicated with in the
previous session. As a result, the likelihood of successful
resumption increases when the authentication is handled by a backend
authentication server, since multiple NAS devices and servers will
remote their EAP authentications to the same backend authentication
server.
Fragmentation
The fragmentation for PEAPOD is the same as is found in [PEAP]
section 2.8.
Key derivation
The key derivation for PEAPOD is the same as is found in [PEAP]
section 2.9.
Lord, Bowler Standards Track [Page 11]
INTERNET DRAFT PEAPOD October 2003
3. Detailed description of the PEAPOD protocol
PEAPOD Outer Packet Format
A summary of the PEAPOD Outer 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 | Flags | Ver | 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
TBD - PEAPOD
Flags
0 1 2 3 4
+-+-+-+-+-+
|L M S R R|
+-+-+-+-+-+
L = Length included
M = More fragments
S = PEAPOD start
Lord, Bowler Standards Track [Page 12]
INTERNET DRAFT PEAPOD October 2003
R = Reserved (must be zero)
The L bit (length included) is set to indicate the presence of
the four-octet TLS Message Length field, and MUST be set for the
first fragment of a fragmented TLS message or set of messages.
The M bit (more fragments) is set on all but the last
fragment. The S bit (PEAPOD start) is set in a PEAPOD Start
message. This differentiates the PEAPOD Start message from a
fragment acknowledgment.
Version
0 1 2
+-+-+-+
|R R 1|
+-+-+-+
R = Reserved (must be zero)
Data
The format of the Data field is determined by the Code field.
Lord, Bowler Standards Track [Page 13]
INTERNET DRAFT PEAPOD October 2003
PEAPOD Outer Request Packet
A summary of the PEAPOD Outer 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 | Flags | Ver | TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS Message Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Length
The Length field is two octets and indicates the length of the
EAP packet including the Code, Identifier, Length, Type, and TLS
Response fields.
Type
TBD - PEAPOD
Flags
0 1 2 3 4
+-+-+-+-+-+
|L M S R R|
+-+-+-+-+-+
L = Length included
M = More fragments
S = PEAPOD start
R = Reserved (must be zero)
The L bit (length included) is set to indicate the presence of
Lord, Bowler Standards Track [Page 14]
INTERNET DRAFT PEAPOD October 2003
the four-octet TLS Message Length field, and MUST be set for the
first fragment of a fragmented TLS message or set of messages.
The M bit (more fragments) is set on all but the last fragment.
The S bit (PEAPOD start) is set in a PEAPOD Start message. This
differentiates the PEAPOD Start message from a fragment
acknowledgment.
Version
0 1 2
+-+-+-+
|R R 1|
+-+-+-+
R = Reserved (must be zero)
TLS Message Length
The TLS Message Length field is four octets, and is present only
if the L bit is set. This field provides the total length of the
TLS message or set of messages that is being fragmented.
TLS data
The TLS data consists of the encapsulated packet in TLS record
format. If the record layer indicates that the record carries
application data, that data will consist of packets for either
the PEAPOD Query Request or the PEAPOD Peer Secret Request. The
formats of these packets are described below. If the record
layer does not indicate that the record carries application data,
the record carries standard TLS data, and will be treated as
such.
Lord, Bowler Standards Track [Page 15]
INTERNET DRAFT PEAPOD October 2003
PEAPOD Outer Response Packet
A summary of the PEAPOD Outer 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 | Flags | Ver | TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS Message Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
2 - Response
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, and TLS
data fields.
Type
TBD - PEAPOD
Flags
0 1 2 3 4
+-+-+-+-+-+
|L M S R R|
+-+-+-+-+-+
L = Length included
M = More fragments
S = PEAPOD start
R = Reserved (must be zero)
The L bit (length included) is set to indicate the presence of
the four-octet TLS Message Length field, and MUST be set for the
Lord, Bowler Standards Track [Page 16]
INTERNET DRAFT PEAPOD October 2003
first fragment of a fragmented TLS message or set of messages.
The M bit (more fragments) is set on all but the last fragment.
The S bit (PEAPOD start) is set in a PEAPOD Start message. This
differentiates the PEAPOD Start message from a fragment
acknowledgment.
Version
0 1 2
+-+-+-+
|R R 1|
+-+-+-+
R = Reserved (must be zero)
TLS Message Length
The TLS Message Length field is four octets, and is present only
if the L bit is set. This field provides the total length of the
TLS message or set of messages that is being fragmented.
TLS data
The TLS data consists of the encapsulated TLS packet in TLS
record format. If the record layer indicates that the record
carries application data, that data will consist of packets for
either the PEAPOD Query Response or the PEAPOD Peer Secret
Response. The formats of these packets are described below. If
the record layer does not indicate that the record carries
application data, the record carries standard TLS data, and will
be treated as such.
Lord, Bowler Standards Track [Page 17]
INTERNET DRAFT PEAPOD October 2003
PEAPOD Query Request Packet
A summary of the PEAPOD Query 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 | Opcode | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
1 - Request
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
packet including the Code, Identifier, Length, Type, Opcode, and
Flags.
Type
TBD - PEAPOD
Opcode
1 - Query peer
Flags
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|A D R R R R R R|
+-+-+-+-+-+-+-+-+
A - The peer should indicate if it requires a peer secret
D - The peer should indicate if it can display authentication
information to the peer's user
R - Reserved (must be zero)
Lord, Bowler Standards Track [Page 18]
INTERNET DRAFT PEAPOD October 2003
PEAPOD Query Response Packet
A summary of the PEAPOD Query 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 | Opcode | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
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
packet including the Code, Identifier, Length, Type, Opcode, and
Flags.
Type
TBD - PEAPOD
Opcode
1 - Query peer
Flags
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|A D R R R R R R|
+-+-+-+-+-+-+-+-+
A - The peer requires a peer secret to be sent
D - The peer can show authentication information to its user
R - Reserved (must be zero)
Lord, Bowler Standards Track [Page 19]
INTERNET DRAFT PEAPOD October 2003
PEAPOD Peer Secret Request Packet
A summary of the PEAPOD Peer Secret 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 | Opcode | Flags | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
1 - Request
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
packet including the Code, Identifier, Length, Type, Opcode,
Flags, and Data.
Type
TBD - PEAPOD
Opcode
2 - Peer secret
Flags
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R R R R R R R R|
+-+-+-+-+-+-+-+-+
R - Reserved (must be zero)
All flag bits will be set to 0 on this request.
Data
The binary representation of H as calculated above. The value is
160 bits in length.
Lord, Bowler Standards Track [Page 20]
INTERNET DRAFT PEAPOD October 2003
PEAPOD Peer Secret Response Packet
A summary of the PEAPOD Peer Secret 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 | Opcode | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
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
packet including the Code, Identifier, Length, Type, Opcode, and
Flags.
Type
TBD - PEAPOD
Opcode
2 - Peer secret
Flags
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S R R R R R R R|
+-+-+-+-+-+-+-+-+
S - Success in matching secret
R - Reserved (must be zero)
Lord, Bowler Standards Track [Page 21]
INTERNET DRAFT PEAPOD October 2003
PEAPOD Display Request Packet
A summary of the PEAPOD Display 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 | Opcode | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
1 - Request
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
packet including the Code, Identifier, Length, Type, Opcode, and
Flags.
Type
TBD - PEAPOD
Opcode
3 - Display
Flags
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R R R R R R R R|
+-+-+-+-+-+-+-+-+
R - Reserved (must be zero)
All flag bits will be set to 0 on this request.
Lord, Bowler Standards Track [Page 22]
INTERNET DRAFT PEAPOD October 2003
PEAPOD Display Response Packet
A summary of the PEAPOD Display 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 | Opcode | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
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
packet including the Code, Identifier, Length, Type, Opcode, and
Flags.
Type
TBD - PEAPOD
Opcode
3 - Display
Flags
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S R R R R R R R|
+-+-+-+-+-+-+-+-+
S - Success in displaying information
R - Reserved (must be zero)
Lord, Bowler Standards Track [Page 23]
INTERNET DRAFT PEAPOD October 2003
4. Security considerations
Method negotiation
If the peer does not support PEAPOD, or does not wish to use PEAPOD
for this authentication, it MUST respond to the initial request to
start PEAPOD with a NAK and suggest an alternate authentication
method. The server SHALL determine if the suggested method is
acceptable. If not, the server MUST respond to a NAK with an EAP-
Failure, terminating the conversation.
TLS session cache handling
A client is allowed to attempt reconnection of a TLS session. If a
client attempts to resume a TLS session, and the server accepts the
request to resume the session, the client MUST NOT require the server
to do PEAPOD Part 2. A successfully resumed TLS session SHALL be
sufficient to complete the PEAPOD protocol.
If, after having established an initial TLS session with a client,
the authentication server determines that it should not communicate
with the client in the future, the authentication server SHOULD clear
the session cache of all related sessions, and MUST NOT resume a
session with the client.
In effect, resuming a TLS session is an implicit statement by both
authenticating entities that they are sufficiently satisfied by the
credentials of the prior session that they are willing to skip
another round of authentication.
Self-signed certificates vs. certificate chains
PEAPOD is designed around the idea that certificates are simply
objects that transport public keys. As such, ?identifying?
information is irrelevant and should not be relied upon for trust
decisions. The idea is that public key information is communicated
over an ancillary channel and then, when proof that an end entity is
the one represented by a given public key, trust decisions are made
on that public key.
In this model, self-signed certificates are preferred since they
present only the information being used in a given trust decision.
However, it does make sense to use certificate chains in environments
in which an issuer is perceived as granting rights (as opposed to
certifying identity). For instance, a corporate IT department may
have a root certificate and configure authentication servers to trust
Lord, Bowler Standards Track [Page 24]
INTERNET DRAFT PEAPOD October 2003
that any entity with an IT-issued certificate is trustworthy of
access to the corporate intranet.
For simpler networks and/or simpler devices, self-signed certificates
should be used as a means of preventing unintended trust decisions.
For networks in which a certificate chain makes sense, the root
certificate should be owned by the network owner and what trust
decisions are made based on that certificate should be fully
understood.
Certificate revocation
For TLS certificates that are self-signed, there is no certificate
revocation list with which a validating entity can check. Instead, a
certificate begins to be rejected when either it expires, or one of
the validating entities begins to reject the certificate based on
some local policy. An example of setting such a policy would be an
end-user setting options to no longer allow connections with the
holder of a given certificate.
For TLS certificates that are part of a certificate chain, the
validity of certificates should be checked against certificate
revocation lists from the level of the certificate being used in a
trust decision (possibly the root certificate) down to the leaf
certificate. The solution for certificate revocation with use of
certificate chains is similar to the method presented in PEAP.
Lord, Bowler Standards Track [Page 25]
INTERNET DRAFT PEAPOD October 2003
5. References
[PEAP] Josefsson et.al, "Protected EAP Protocol", Internet draft
(work in progress),
draft-josefsson-pppext-eap-tls-eap-06.txt, March 2003
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and
T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
August 1996.
[RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0",
RFC 2246, November 1998.
[RFC3268] Chown, P., ?Advanced Encryption Standard (AES) Ciphersuites
for Transport Layer Security (TLS)?, RFC 3268, June 2002.
[RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[TLSEXT] Blake-Wilson, S., et al. "TLS Extensions", Internet draft
(work in progress), draft-ietf-tls-extensions-02.txt,
December 2001.
[IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1X-2001,
June 2001.
Lord, Bowler Standards Track [Page 26]
INTERNET DRAFT PEAPOD October 2003
Appendix A - Examples
In the case where the identity exchange occurs within PEAPOD Part 1,
and PEAPOD Part 2 is used to exchange a secret, the conversation will
appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/ ->
Identity (MyID)
<- EAP-Request/
EAP-Type=PEAPOD
(PEAPOD Start, S bit set)
EAP-Response/ ->
EAP-Type=PEAPOD
(TLS client_hello)
<- EAP-Request/
EAP-Type=PEAPOD
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/ ->
EAP-Type=PEAPOD
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished)
<- EAP-Request/
EAP-Type=PEAPOD
(TLS change_cipher_spec,
TLS finished)
TLS channel established
(messages sent within the TLS channel)
<- EAP-Request/
EAP-Type=PEAPOD
(Query Request,
Peer Authentication requirements)
EAP-Response/ ->
EAP-Type=PEAPOD
(Query Response,
Lord, Bowler Standards Track [Page 27]
INTERNET DRAFT PEAPOD October 2003
Flags=A)
<- EAP-Request/
EAP-Type=PEAPOD
(Secret Request Packet,
Secret data)
EAP-Response/ ->
EAP-Type=PEAPOD
(Secret Response Packet,
Flags=S)
<- EAP-Success
TLS channel torn down
(messages sent in cleartext)
Lord, Bowler Standards Track [Page 28]
INTERNET DRAFT PEAPOD October 2003
Where all peers are known to support PEAPOD, and the PEAPOD Part 2
secret exchange is not needed, the conversation appears as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
EAP-Type=PEAPOD
(PEAPOD Start, S bit set)
EAP-Response/ ->
EAP-Type=PEAPOD
(TLS client_hello)
<- EAP-Request/
EAP-Type=PEAPOD
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/ ->
EAP-Type=PEAPOD
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished)
<- EAP-Request/
EAP-Type=PEAPOD
(TLS change_cipher_spec,
TLS finished)
TLS channel established
(messages sent within the TLS channel)
<- EAP-Request/
EAP-Type=PEAPOD
(Query Request,
Peer Authentication requirements)
EAP-Response/ ->
EAP-Type=PEAPOD
(Query Response,
Flags= (all zeroes) )
<- EAP-Success
TLS channel torn down
(messages sent in cleartext)
Lord, Bowler Standards Track [Page 29]
INTERNET DRAFT PEAPOD October 2003
In the case where the identity exchange occurs within PEAPOD Part 1,
and a previous session is resumed, the conversation will appear as
follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/ ->
Identity (MyID)
<- EAP-Request/
EAP-Type=PEAPOD
(PEAPOD Start, S bit set)
EAP-Response/ ->
EAP-Type=PEAPOD
(TLS client_hello)
<- EAP-Request/
EAP-Type=PEAPOD
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
EAP-Response/ ->
EAP-Type=PEAPOD
(TLS change_cipher_spec,
TLS finished)
TLS channel established
TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
<TBD> - need examples of failure cases, etc.
Lord, Bowler Standards Track [Page 30]
INTERNET DRAFT PEAPOD October 2003
Acknowledgments
<TBD>
Author Addresses
Christopher Lord
Intel Corporation
2111 NE 25th Ave M/S: JF3-232
Hillsboro, OR 97124-5961 USA
Phone: +1-503-264-0152
Fax: +1-503-264-0170
Email: chris.lord at intel.com
David Bowler
Intel Corporation
2111 NE 25th Ave M/S: JF3-232
Hillsboro, OR 97124-5961 USA
Phone: +1-503-264-9292
Fax: +1-503-264-0170
Email: david.bowler at intel.com
Intellectual Property Statement
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 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.
Lord, Bowler Standards Track [Page 31]
INTERNET DRAFT PEAPOD October 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 DISCLAIMS 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.
Lord, Bowler Standards Track [Page 32]
More information about the ietf-enroll
mailing list