draft-ietf-radext-fixes-05.txt   draft-ietf-radext-fixes-06.txt 
Network Working Group David Nelson Network Working Group David Nelson
INTERNET-DRAFT Elbrys Networks, Inc INTERNET-DRAFT Elbrys Networks, Inc
Updates: 2865, 2866, 2869, 3579 Alan DeKok Updates: 2865, 2866, 2869, 3579 Alan DeKok
Category: Proposed Standard FreeRADIUS Category: Proposed Standard FreeRADIUS
<draft-ietf-radext-fixes-05.txt> <draft-ietf-radext-fixes-06.txt>
Expires: January 02, 2007 Expires: February 27, 2007
27 August 2007
Common Remote Authentication Dial In User Service (RADIUS) Common Remote Authentication Dial In User Service (RADIUS)
Implementation Issues and Suggested Fixes Implementation Issues and Suggested Fixes
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 13 skipping to change at page 2, line 13
previous RADIUS specifications are clarified. previous RADIUS specifications are clarified.
Table of Contents Table of Contents
1. Introduction ............................................. 3 1. Introduction ............................................. 3
1.1. Terminology ......................................... 3 1.1. Terminology ......................................... 3
1.2. Requirements Language ............................... 3 1.2. Requirements Language ............................... 3
2. Issues ................................................... 4 2. Issues ................................................... 4
2.1. Session Definition .................................. 4 2.1. Session Definition .................................. 4
2.1.1. State Attribute ................................ 4 2.1.1. State Attribute ................................ 4
2.1.2. Request-ID Supplementation ..................... 5 2.1.2. Request-ID Supplementation ..................... 6
2.2. Overload Conditions ................................. 6 2.2. Overload Conditions ................................. 7
2.2.1. Retransmission Behavior ........................ 6 2.2.1. Retransmission Behavior ........................ 7
2.2.2. Duplicate detection and orderly delivery. ...... 8 2.2.2. Duplicate detection and orderly delivery. ...... 9
2.2.3. Server Response to Overload .................... 9 2.2.3. Server Response to Overload .................... 11
2.3. Accounting Issues ................................... 10 2.3. Accounting Issues ................................... 12
2.3.1. Attributes allowed in an Interim Update ........ 10 2.3.1. Attributes allowed in an Interim Update ........ 12
2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ...... 10 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ...... 12
2.3.3. Request Authenticator .......................... 11 2.3.3. Request Authenticator .......................... 13
2.3.4. Interim-Accounting-Interval .................... 11 2.3.4. Interim-Accounting-Interval .................... 13
2.3.5. Counter values in the RADIUS Management Informat 12 2.3.5. Counter values in the RADIUS Management Informat 14
2.4. Multiple Filter-ID Attributes ....................... 13 2.4. Multiple Filter-ID Attributes ....................... 15
2.5. Mandatory and Optional Attributes ................... 14 2.5. Mandatory and Optional Attributes ................... 16
2.6. Interpretation of Access-Reject ..................... 15 2.6. Interpretation of Access-Reject ..................... 17
2.6.1. Improper Use of Access-Reject .................. 15 2.6.1. Improper Use of Access-Reject .................. 17
2.6.2. Service Request Denial ......................... 17 2.6.2. Service Request Denial ......................... 19
2.7. Addressing .......................................... 18 2.7. Addressing .......................................... 19
2.7.1. Link-Local Addresses ........................... 18 2.7.1. Link-Local Addresses ........................... 20
2.7.2. Multiple Addresses ............................. 18 2.7.2. Multiple Addresses ............................. 20
2.8. Idle-Timeout ........................................ 18 2.8. Idle-Timeout ........................................ 20
2.9. Unknown Identity .................................... 19 2.9. Unknown Identity .................................... 21
2.10. Responses after retransmissions .................... 20 2.10. Responses after retransmissions .................... 22
2.11. Framed-IPv6-Prefix ................................. 21 2.11. Framed-IPv6-Prefix ................................. 23
3. IANA Considerations ...................................... 22 3. IANA Considerations ...................................... 24
4. Security Considerations .................................. 22 4. Security Considerations .................................. 24
5. References ............................................... 22 5. References ............................................... 24
5.1. Normative references ................................ 22 5.1. Normative references ................................ 24
5.2. Informative references .............................. 23 5.2. Informative references .............................. 25
Intellectual Property Statement .............................. 24 Intellectual Property Statement .............................. 26
Disclaimer of Validity ....................................... 26 Disclaimer of Validity ....................................... 28
Full Copyright Statement ..................................... 26 Full Copyright Statement ..................................... 28
1. Introduction 1. Introduction
The last few years have seen an increase in the deployment of RADIUS The last few years have seen an increase in the deployment of RADIUS
clients and servers. This document describes common issues seen in clients and servers. This document describes common issues seen in
RADIUS implementations and suggests some fixes. Where applicable, RADIUS implementations and suggests some fixes. Where applicable,
ambiguities and errors in previous RADIUS specifications are ambiguities and errors in previous RADIUS specifications are
clarified. clarified.
1.1. Terminology 1.1. Terminology
skipping to change at page 4, line 28 skipping to change at page 4, line 28
This Attribute is available to be sent by the server to the client This Attribute is available to be sent by the server to the client
in an Access-Accept that also includes a Termination-Action in an Access-Accept that also includes a Termination-Action
Attribute with the value of RADIUS-Request. If the NAS performs Attribute with the value of RADIUS-Request. If the NAS performs
the Termination-Action by sending a new Access-Request upon the Termination-Action by sending a new Access-Request upon
termination of the current session, it MUST include the State termination of the current session, it MUST include the State
attribute unchanged in that Access-Request. attribute unchanged in that Access-Request.
Some RADIUS client implementations do not properly use the State Some RADIUS client implementations do not properly use the State
attribute in order to distinguish a restarted EAP authentication attribute in order to distinguish a restarted EAP authentication
process from the continuation of an ongoing process (by the same user process from the continuation of an ongoing process (by the same user
on the same NAS and port). on the same NAS and port). Where an EAP-Message attribute is
included in an Access-Challenge or Access-Accept attribute, RADIUS
servers SHOULD also include a State attribute. See Section 2.1.2 on
Request ID supplementation for additional benefits to using the State
attribute in this fashion.
Where an EAP-Message attribute is included in an Access-Challenge or As defined in [RFC2865] Table 5.44, Access-Request packets may
Access-Accept attribute, RADIUS servers SHOULD also include a State contain a State attribute. The table does not qualify this
attribute. See Section 2.1.3 on Request ID supplementation for statement, while the text in Section 5.24 quoted above adds other
additional benefits to using the State attribute in this fashion. requirements not specified in that table.
An Access-Request sent as a result of a new or restarted We extend the requirements of [RFC2865] to say that Access-Requests
authentication run MUST NOT include the State attribute, even if the which are part of an ongoing Access-Request / Access-Challenge
State attribute has previously been received in an Access-Challenge authentication process SHOULD contain a State attribute. It is the
for the same user and port. responsibility of the server to send a State attribute in an Access-
Challenge packet, if that server needs a State attribute in a
subsequent Access-Request to tie multiple Access-Requests togther
into one authentication session. As defined in [RFC2865] Section
5.24, the State MUST be sent unmodified from the client to the server
in the new Access-Request reply to that challenge, if any.
Since a State attribute is always initially provided by the server in While most server implementations require the presence of a State
an Access-Accept, Access-Challenge, CoA-Request or Disconnect- attribute in an Access-Challenge packet, some challenge-response
Request, a RADIUS client MUST NOT insert a State attribute that it systems can distinguish the initial request from the response to the
has not previously received from the server. challenge without using a State attribute to track an authentication
session. The Access-Challenge and subsequent Access-Request packets
for those systems do not need to contain a State attribute.
As defined in [RFC 2865] Table 5.44, Access-Request packets MAY Other authentication mechanisms need to tie a sequence of Access-
contain a State attribute. We extend that definition here, to say Request / Access-Challenge packets together into one ongoing
that Access-Request packets that contain an authentication attribute authentication session. Servers implementing those authentication
or a Service-Type attribute with the value Call Check (10) MAY mechanisms SHOULD include a State attribute in Access-Challenge
contain a State attribute. Access-Request packets not matching the packets.
above description MUST contain a State attribute.
In general, if the authentication process involves one or more
Access-Request / Access-Challenge sequences, the State attribute
SHOULD be sent by the server in the Access-Challenge packets. Using
the State attribute to create a multi-packet session is the simplest
method available in RADIUS today. While other methods of creating
multi-packet sessions are possible (e.g. [RFC3579] Section 2.6.1),
those methods are NOT RECOMMENDED.
The only permissible values for a State attribute are values provided
in an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
Request packet. A RADIUS client MUST use only those values for the
State attribute that it has previously received from a server. An
Access-Request sent as a result of a new or restarted authentication
run MUST NOT include the State attribute, even if a State attribute
has previously been received in an Access-Challenge for the same user
and port.
In contrast, Access-Requests which are intended to perform
authorization checks MUST contain a State attribute in order to tie
the authorization check to a previous authentication session. This
last requirement often means that an Access-Accept needs to contain a
State attribute, which is then used in a later Access-Request that
performs authorization checks.
Access-Request packets that contain a Service-Type attribute with
value Authorize Only (17) MUST contain a State attribute. Access-
Request packets that contain a Service-Type attribute with value Call
Check (10) SHOULD NOT contain a State attribute. Any other Access-
Request packet that performs authorization checks MUST contain a
State attribute.
The standard use case for Call-Check is pre-screening authentication
based solely on the end-point identifier information, such as phone
number or MAC address in Calling-Station-ID and optionally Called-
Station-ID. In that use case there is no source of the State
attribute in the NAS. Other, non-standard, uses of Call-Check may
require or permit the use of a State Attribute, but are beyond the
scope of this document.
Implementing Call Check functionality via requests where the User-
Name and User-Password contain the same information (e.g. MAC
address) is NOT RECOMMENDED. This practice gives an attacker both
the clear-text and cipher-text of the User-Password field, which
permits many additional attacks on the security of the RADIUS
protocol. For example, if the Request Authenticator does not satisfy
the [RFC2865] requirements on global and temporal uniqueness, the
practice described above may lead to the compromise of the User-
Password attribute in other Access-Requests for unrelated users.
Access to the cipher-text also greatly simplifies offline dictionary
attacks, potentially exposing the shared secret, and compromising the
entire RADIUS protocol.
Any Access-Request packet that performs authorization checks,
including Call Check, MUST contain a Message-Authenticator attribute.
Any response to an Access-Request performing an authorization check
MUST NOT contain confidential information about any user (such as
Tunnel-Password), unless that Access-Request contains a State
attribute. The use of State here permits the authorization check to
be tied to an earlier user authentication. In that case, the server
MAY respond to the NAS with confidential information about that user.
The server MUST NOT respond to that authorization check with
confidential information about any other user.
2.1.2. Request-ID Supplementation 2.1.2. Request-ID Supplementation
[RFC3579] Section 2.6.1 states: [RFC3579] Section 2.6.1 states:
In EAP, each session has its own unique Identifier space. RADIUS In EAP, each session has its own unique Identifier space. RADIUS
server implementations MUST be able to distinguish between EAP server implementations MUST be able to distinguish between EAP
packets with the same Identifier existing within distinct packets with the same Identifier existing within distinct
sessions, originating on the same NAS. For this purpose, sessions sessions, originating on the same NAS. For this purpose, sessions
can be distinguished based on NAS and session identification can be distinguished based on NAS and session identification
skipping to change at page 6, line 46 skipping to change at page 8, line 20
specified below. specified below.
[b] Congestive backoff. While it is not necessary for RADIUS client [b] Congestive backoff. While it is not necessary for RADIUS client
implementations to implement complex retransmission algorithms, implementations to implement complex retransmission algorithms,
implementations SHOULD support congestive backoff within the limits implementations SHOULD support congestive backoff within the limits
suggested by [RFC2865] Section 2.4. suggested by [RFC2865] Section 2.4.
RADIUS retransmission timers are based on the model used in DHCPv6 RADIUS retransmission timers are based on the model used in DHCPv6
[RFC3315]. Variables used here are also borrowed from this [RFC3315]. Variables used here are also borrowed from this
specification. RADIUS is a request/response-based protocol. The specification. RADIUS is a request/response-based protocol. The
message exchange terminates when the requester successfully message exchange terminates when the requester successfully receives
receives the answer or the message exchange is considered to have the answer or the message exchange is considered to have failed
failed according to the retransmission mechanism described below. according to the RECOMMENDED retransmission mechanism described
below. Other retransmission mechanisms are possible, so long as they
satisfy the requirements on jitter and congestive backoff.
The following algorithms apply to any client that originates RADIUS
packets, including but not limited to Access-Request, Accounting-
Request, Disconnect-Request, and CoA-Request [RFC3576].
The retransmission behavior is controlled and described by the The retransmission behavior is controlled and described by the
following variables: following variables:
RT Retransmission timeout RT Retransmission timeout
IRT Initial retransmission time (default 2 seconds) IRT Initial retransmission time (default 2 seconds)
MRC Maximum retransmission count (default 10 attempts) MRC Maximum retransmission count (default 10 attempts)
MRT Maximum retransmission time (default 16 seconds) MRT Maximum retransmission time (default 16 seconds)
MRD Maximum retransmission duration (default 30 seconds) MRD Maximum retransmission duration (default 30 seconds)
RAND Randomization factor RAND Randomization factor
With each message transmission or retransmission, the sender sets With each message transmission or retransmission, the sender sets RT
RT according to the rules given below. If RT expires before the according to the rules given below. If RT expires before the message
message exchange terminates, the sender recomputes RT and exchange terminates, the sender recomputes RT and retransmits the
retransmits the message. message.
Each of the computations of a new RT include a randomization factor Each of the computations of a new RT include a randomization factor
(RAND), which is a random number chosen with a uniform distribution (RAND), which is a random number chosen with a uniform distribution
between -0.1 and +0.1. The randomization factor is included to between -0.1 and +0.1. The randomization factor is included to
minimize synchronization of messages. minimize synchronization of messages.
The algorithm for choosing a random number does not need to be The algorithm for choosing a random number does not need to be
cryptographically sound. The algorithm SHOULD produce a different cryptographically sound. The algorithm SHOULD produce a different
sequence of random numbers from each invocation. sequence of random numbers from each invocation.
skipping to change at page 7, line 50 skipping to change at page 9, line 30
MRT specifies an upper bound on the value of RT (disregarding the MRT specifies an upper bound on the value of RT (disregarding the
randomization added by the use of RAND). If MRT has a value of 0, randomization added by the use of RAND). If MRT has a value of 0,
there is no upper limit on the value of RT. Otherwise: there is no upper limit on the value of RT. Otherwise:
if (RT > MRT) if (RT > MRT)
RT = MRT + RAND*MRT RT = MRT + RAND*MRT
MRD specifies an upper bound on the length of time a sender may MRD specifies an upper bound on the length of time a sender may
retransmit a message. The message exchange fails once MRD seconds retransmit a message. The message exchange fails once MRD seconds
have elapsed since the client first transmitted the message. MRD have elapsed since the client first transmitted the message. MRD
MUST be set, and SHOULD have a value between 5 and 30 seconds. MUST be set, and SHOULD have a value between 5 and 30 seconds. These
These values mirror the values for a servers duplicate detection values mirror the values for a servers duplicate detection cache, as
cache, as described in the next section. described in the next section.
MRC specifies an upper bound on the number of times a sender may MRC specifies an upper bound on the number of times a sender may
retransmit a message. if MRC is zero, the message exchange fails retransmit a message. if MRC is zero, the message exchange fails
once MRD seconds have elapsed since the client first transmitted once MRD seconds have elapsed since the client first transmitted the
the message. If MRC is non-zero, the message exchange fails when message. If MRC is non-zero, the message exchange fails when the
the either the sender has transmitted the message MRC times, or either the sender has transmitted the message MRC times, or when MRD
when MRD seconds have elapsed since the client first transmitted seconds have elapsed since the client first transmitted the message.
the message.
For Accounting-Request packets, the default values for MRC, MRD, and
MRT SHOULD be zero. These settings will enable a RADIUS client to
continue sending accounting requests to a RADIUS server until the
request is acknowledged. If any of MRC, MRD, or MRT are non-zero,
then the accounting information could potentially be discarded
without being recorded.
2.2.2. Duplicate detection and orderly delivery. 2.2.2. Duplicate detection and orderly delivery.
When packets are retransmitted by a client, the server may receive When packets are retransmitted by a client, the server may receive
duplicate requests. The limitations of the transport protocol used duplicate requests. The limitations of the transport protocol used
by RADIUS, the User Datagram Protocol (UDP), means that the Access- by RADIUS, the User Datagram Protocol (UDP), means that the Access-
Request packets may be received, and potentially processed, in an Request packets may be received, and potentially processed, in an
order different from the order in which the packets were sent. order different from the order in which the packets were sent.
However, the discussion of the Identifier field in Section 3 of However, the discussion of the Identifier field in Section 3 of
[RFC2865] says: [RFC2865] says:
skipping to change at page 14, line 52 skipping to change at page 16, line 46
With respect to Vendor-Specific Attributes (VSAs), [RFC2865] Section With respect to Vendor-Specific Attributes (VSAs), [RFC2865] Section
5.26 states: 5.26 states:
Servers not equipped to interpret the vendor-specific information Servers not equipped to interpret the vendor-specific information
sent by a client MUST ignore it (although it may be reported). sent by a client MUST ignore it (although it may be reported).
Clients which do not receive desired vendor-specific information Clients which do not receive desired vendor-specific information
SHOULD make an attempt to operate without it, although they may do SHOULD make an attempt to operate without it, although they may do
so (and report they are doing so) in a degraded mode. so (and report they are doing so) in a degraded mode.
It is possible for either a standard attribute or VSA to represent a It is possible for either a standard attribute or VSA to represent a
request for an unavailable service. However, where the Type or request for an unavailable service. However, where the Type, Vendor-
Vendor-ID is unknown, a RADIUS client will not know whether the ID, or Vendor-Type is unknown, a RADIUS client will not know whether
attribute defines a service or not. the attribute defines a service or not.
In general, it is best for RADIUS clients to err on the side of In general, it is best for a RADIUS clients to err on the side of
caution. On receiving an Access-Accept including an attribute of caution. On receiving an Access-Accept including an attribute of
unknown Type, a RADIUS client SHOULD assume that it is a potential known Type for an unimplemented service, a RADIUS client MUST treat
service definition, and treat it as an Access-Reject. Unknown VSAs it as an Access-Reject, as directed in [RFC2865] Section 1.1. On
SHOULD be ignored by RADIUS clients. receiving an Access-Accept including an attribute of unknown Type, a
RADIUS client SHOULD assume that it is a potential service
definition, and treat it as an Access-Reject. Unknown VSAs SHOULD be
ignored by RADIUS clients.
As there may be interoperability issues with the above suggestion, In order to avoid introducing changes in default behavior, existing
client implementations SHOULD make the suggested behavior implementations that do not obey this recommendation should make the
configurable. A configuration flag such as "treat unknown attributes behavior configurable, with the legacy behavior being enabled by
as reject" can be exposed to the system administrator. If the flag default. A configuration flag such as "treat unknown attributes as
is set to true, then Access-Accepts containing unknown attributes are reject" can be exposed to the system administrator. If the flag is
set to true, then Access-Accepts containing unknown attributes are
treated as Access-Rejects. If the flag is set to false, then unknown treated as Access-Rejects. If the flag is set to false, then unknown
attributes in Access-Accepts are be silently ignored. The default attributes in Access-Accepts are be silently ignored.
value for the flag SHOULD be set to true.
On receiving a packet including an attribute of unknown type, RADIUS On receiving a packet including an attribute of unknown type, RADIUS
authentication server implementations SHOULD ignore such attributes. authentication server implementations SHOULD ignore such attributes.
However, RADIUS accounting server implementations typically do not However, RADIUS accounting server implementations typically do not
need to understand attributes in order to write them to stable need to understand attributes in order to write them to stable
storage or pass them to the billing engine. Therefore, accounting storage or pass them to the billing engine. Therefore, accounting
server implementations SHOULD be equipped to handle unknown server implementations SHOULD be equipped to handle unknown
attributes. attributes.
To avoid misinterpretation of service requests encoded within VSAs, To avoid misinterpretation of service requests encoded within VSAs,
skipping to change at page 22, line 34 skipping to change at page 24, line 33
disclose sensitive information to a RADIUS client or third parties disclose sensitive information to a RADIUS client or third parties
observing the RADIUS protocol. observing the RADIUS protocol.
The cache mechanism described in Section 2.2.2 is vulnerable to The cache mechanism described in Section 2.2.2 is vulnerable to
attacks when Access-Request packets do not contain a Message- attacks when Access-Request packets do not contain a Message-
Authenticator attribute. If the server accepts requests without a Authenticator attribute. If the server accepts requests without a
Message-Authenticator, then RADIUS packets can be trivially forged by Message-Authenticator, then RADIUS packets can be trivially forged by
an attacker. Cache entries can then be forcibly expired, negating an attacker. Cache entries can then be forcibly expired, negating
the utility of the cache. This attack can be mitigated by following the utility of the cache. This attack can be mitigated by following
the suggestions in [RFC3579] Section 4, or by requiring the presence the suggestions in [RFC3579] Section 4, or by requiring the presence
of Message-Authenticator, as described in Section 2.2.2. of Message-Authenticator, as described in Sections 2.1.1 and 2.2.2.
Since this document describes the use of RADIUS for purposes of Since this document describes the use of RADIUS for purposes of
authentication, authorization, and accounting in a wide variety of authentication, authorization, and accounting in a wide variety of
networks, applications using these specifications are vulnerable to networks, applications using these specifications are vulnerable to
all of the threats that are present in other RADIUS applications. all of the threats that are present in other RADIUS applications.
For a discussion of these threats, see [RFC2865], [RFC2607], For a discussion of these threats, see [RFC2865], [RFC2607],
[RFC3162], [RFC3579], and [RFC3580]. [RFC3162], [RFC3579], and [RFC3580].
5. References 5. References
skipping to change at page 23, line 35 skipping to change at page 25, line 32
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions",
RFC 2869, June 2000. RFC 2869, June 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
3162, August 2001. 3162, August 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba,
"Dynamic Authorization Extensions to Remote Authentication
Dial In User Service (RADIUS)", RFC 3576, July 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003. Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service "IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003. (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004. 3748, June 2004.
 End of changes. 18 change blocks. 
82 lines changed or deleted 175 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/