draft-ietf-radext-radsec-06.txt   draft-ietf-radext-radsec-07.txt 
RADIUS Extensions Working Group S. Winter RADIUS Extensions Working Group S. Winter
Internet-Draft RESTENA Internet-Draft RESTENA
Intended status: Experimental M. McCauley Intended status: Experimental M. McCauley
Expires: September 6, 2010 OSC Expires: January 13, 2011 OSC
S. Venaas S. Venaas
UNINETT UNINETT
K. Wierenga K. Wierenga
Cisco Cisco
March 05, 2010 July 12, 2010
TLS encryption for RADIUS TLS encryption for RADIUS
draft-ietf-radext-radsec-06 draft-ietf-radext-radsec-07
Abstract Abstract
This document specifies security on the transport layer (TLS) for the This document specifies security on the transport layer (TLS) for the
RADIUS protocol when transmitted over TCP. This enables dynamic RADIUS protocol when transmitted over TCP. This enables dynamic
trust relationships between RADIUS servers. trust relationships between RADIUS servers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 13, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 27
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Normative: Transport Layer Security for RADIUS over TCP . . . 4 2. Normative: Transport Layer Security for RADIUS over TCP . . . 4
2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4 2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4
2.2. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4 2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 4
2.3. Connecting Client Identity . . . . . . . . . . . . . . . . 6 2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4
2.4. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7 2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6
2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7
3. Informative: Design Decisions . . . . . . . . . . . . . . . . 8 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 8
3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 8 3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 8
3.2. Ciphersuites and Compression Negotiation Considerations . 9 3.2. Ciphersuites and Compression Negotiation Considerations . 9
3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 9 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 9
4. Compatibility with other RADIUS transports . . . . . . . . . . 10 4. Compatibility with other RADIUS transports . . . . . . . . . . 10
5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 3, line 26 skipping to change at page 3, line 26
The main focus of RADIUS over TLS is to provide a means to secure the The main focus of RADIUS over TLS is to provide a means to secure the
communication between RADIUS/TCP peers on the transport layer. The communication between RADIUS/TCP peers on the transport layer. The
most important use of this specification lies in roaming environments most important use of this specification lies in roaming environments
where RADIUS packets need to be transferred through different where RADIUS packets need to be transferred through different
administrative domains and untrusted, potentially hostile networks. administrative domains and untrusted, potentially hostile networks.
An example for a world-wide roaming environment that uses RADIUS over An example for a world-wide roaming environment that uses RADIUS over
TLS to secure communication is "eduroam", see [eduroam]. TLS to secure communication is "eduroam", see [eduroam].
There are multiple known attacks on the MD5 algorithm which is used There are multiple known attacks on the MD5 algorithm which is used
in RADIUS to provide integrity protection and a limited in RADIUS to provide integrity protection and a limited
confidentiality protection. RADIUS over TLS wraps the entire RADIUS confidentiality protection (see [MD5-attacks]). RADIUS over TLS
packet payload into a TLS stream and thus mitigates the risk of wraps the entire RADIUS packet payload into a TLS stream and thus
attacks on MD5. mitigates the risk of attacks on MD5.
Because of the static trust establishment between RADIUS peers (IP Because of the static trust establishment between RADIUS peers (IP
address and shared secret) the only scalable way of creating a address and shared secret) the only scalable way of creating a
massive deployment of RADIUS-servers under control by different massive deployment of RADIUS-servers under control by different
administrative entities is to introduce some form of a proxy chain to administrative entities is to introduce some form of a proxy chain to
route the access requests to their home server. This creates a lot route the access requests to their home server. This creates a lot
of overhead in terms of possible points of failure, longer of overhead in terms of possible points of failure, longer
transmission times as well as middleboxes through which transmission times as well as middleboxes through which
authentication traffic flows. These middleboxes may learn privacy- authentication traffic flows. These middleboxes may learn privacy-
relevant data while forwarding requests. The new features in RADIUS relevant data while forwarding requests. The new features in RADIUS
over TLS obsolete the use of IP addresses and shared MD5 secrets to over TLS obsolete the use of IP addresses and shared MD5 secrets to
identify other peers and thus allow the dynamic establishment of identify other peers and thus allow the dynamic establishment of
connections to peers that are not previously configured, and thus connections to peers that are not previously configured, and thus
makes it possible to avoid intermediate aggregation proxies. One makes it possible to avoid aggregation-only RADIUS proxies and reduce
the number of middleboxes which can eavesdrop on traffic. One
mechanism to discover RADIUS over TLS peers with DNS is specified in mechanism to discover RADIUS over TLS peers with DNS is specified in
[I-D.winter-dynamic-discovery]. [I-D.winter-dynamic-discovery].
1.1. Requirements Language 1.1. Requirements Language
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in and "OPTIONAL" in this document are to be interpreted as described in
RFC 2119. [RFC2119] RFC 2119. [RFC2119]
skipping to change at page 4, line 25 skipping to change at page 4, line 26
RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865] RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865]
2. Normative: Transport Layer Security for RADIUS over TCP 2. Normative: Transport Layer Security for RADIUS over TCP
2.1. TCP port and packet types 2.1. TCP port and packet types
The default destination port number for RADIUS over TLS is TCP/2083. The default destination port number for RADIUS over TLS is TCP/2083.
There are no separate ports for authentication, accounting and There are no separate ports for authentication, accounting and
dynamic authorisation changes. The source port is arbitrary. dynamic authorisation changes. The source port is arbitrary.
2.2. Connection Setup 2.2. TLS negotiation
RADIUS has no notion of negotiating TLS in an established connection.
Servers and clients need to be preconfigured to use RADIUS/TLS for a
given endpoint.
2.3. Connection Setup
RADIUS/TLS nodes RADIUS/TLS nodes
1. establish TCP connections as per [I-D.dekok-radext-tcp-transport] 1. establish TCP connections as per [I-D.dekok-radext-tcp-transport]
2. negotiate TLS sessions according to [RFC5246] or its predecessor 2. immediately negotiate TLS sessions. The following restrictions
TLS 1.1. The following restrictions apply: apply: according to [RFC5246] or its predecessor TLS 1.1. The
following restrictions apply:
* The authentication MUST be mutual, i.e. both the RADIUS/TLS * Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2
server and the RADIUS/TLS client authenticate each other. [RFC5246]]) is REQUIRED.
* The client MUST NOT negotiate cipher suites which only provide * Support for certificate-based mutual authentication is
integrity protection. REQUIRED.
* The TLS session MAY use mutual PSKs for connection setup. * Negotiation of mutual authentication is REQUIRED.
* Negotiation of compression for the TLS session is OPTIONAL. * Negotiation of a ciphersuite providing for confidentiality as
well as integrity protection is REQUIRED.
* RADIUS/TLS implementations MUST support the mandatory to * Support for and negotiation of compression is OPTIONAL.
implement cipher suites specified in TLS (i.e.
TLS_RSA_WITH_3DES_EDE_CBC_SHA). For purposes of compatibility * Support for TLS-PSK mutual authentication [RFC4279] is
with some current deployments implementations SHOULD support OPTIONAL.
TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as
well (see Section 3.2 (1) ). * RADIUS/TLS implementations MUST at a minimum support
negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD
support TLS_RSA_WITH_RC4_128_SHA and
TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.2 (1) ).
* In addition, RADIUS/TLS implementations MUST support
negotiation of the mandatory-to-implement ciphersuites
required by the versions of TLS that they support.
3. If TLS is used in an X.509 certificate based operation mode, the 3. If TLS is used in an X.509 certificate based operation mode, the
following list of certificate validation options applies: following list of certificate validation options applies:
* Implementations MUST allow to configure a list of acceptable * Implementations MUST allow to configure a list of acceptable
Certification Authorities for incoming connections. Certification Authorities for incoming connections.
* Certificate validation MUST include the verification rules as * Certificate validation MUST include the verification rules as
per [RFC5280], using information from trusted sources only per [RFC5280].
(e.g. locally configured names). If service names as per
[RFC4985] are present in the certificate and dynamic discovery
utilizing SRVs in DNS is used (see
[I-D.winter-dynamic-discovery]) and the TLS implementation
supports evaluation of the extensions in [RFC4985], the SRV
entry MUST be validated. In cases where no DNS SRV resolution
took place to arrive at the TLS peer, subjectAltName:SRV
entries can be ignored.
* Implementations SHOULD indicate their acceptable Certification * Implementations SHOULD indicate their acceptable Certification
Authorities as per section 7.4.4 (server side) and x.y.z Authorities as per section 7.4.4 (server side) and x.y.z
["Trusted CA Indication"] (client side) of [RFC5246] (see ["Trusted CA Indication"] (client side) of [RFC5246] (see
Section 3.1) Section 3.1)
* Implementations SHOULD allow to configure a list of acceptable * Implementations SHOULD allow to configure a list of acceptable
certificates, identified via certificate fingerprint. When a certificates, identified via certificate fingerprint. When a
fingerprint configured, the fingerprint is prepended with an fingerprint configured, the fingerprint is prepended with an
ASCII label identifying the hash function followed by a colon. ASCII label identifying the hash function followed by a colon.
skipping to change at page 6, line 9 skipping to change at page 6, line 12
precedence over CN; for IP address validation, subjectAltName: precedence over CN; for IP address validation, subjectAltName:
iPAddr has precedence over CN. iPAddr has precedence over CN.
* Implementations SHOULD allow to configure a set of acceptable * Implementations SHOULD allow to configure a set of acceptable
values for subjectAltName:URI. values for subjectAltName:URI.
4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The
shared secret to compute the (obsolete) MD5 integrity checks and shared secret to compute the (obsolete) MD5 integrity checks and
attribute encryption MUST be "radsec" (see Section 3.3 (2) ). attribute encryption MUST be "radsec" (see Section 3.3 (2) ).
2.3. Connecting Client Identity 2.4. Connecting Client Identity
In RADIUS/UDP, clients are uniquely identified by their IP address. In RADIUS/UDP, clients are uniquely identified by their IP address.
This does not permit to determine whether the connecting entity is a The IP address alone does not permit the server to determine whether
NAS or a different server which proxies a request. When NAT is used the connecting entity is a NAS or a different server which proxies a
on the path to the server, it also does not permit to determine request. When NAT is used on the path to the server, it also does
whether there is more than one entity connecting from the same IP not permit to determine whether there is more than one entity
address. connecting from the same IP address.
RADIUS/TLS makes it possible to preserve this traditional RADIUS RADIUS/TLS makes it possible to preserve this traditional RADIUS
semantics by identifying a connecting client by the IP address which semantics by identifying a connecting client by the IP address which
initiated the TLS connection. In addition, it permits a much more initiated the TLS connection. In addition, it permits a much more
fine-grained identification. The parameters of the TLS connection fine-grained identification. The parameters of the TLS connection
can be attributed to the RADIUS packets inside the TLS connection. can be attributed to the RADIUS packets inside the TLS connection.
An implementation of RADIUS/TLS should expose as many details of the An implementation of RADIUS/TLS should expose as many details of the
TLS connection which belongs to an incoming RADIUS packet as possible TLS connection which belongs to an incoming RADIUS packet as possible
to the application layer to allow the administrator to define the to the application layer to allow the administrator to define the
identification criteria which are applicable to his desired identification criteria which are applicable to his desired
skipping to change at page 6, line 48 skipping to change at page 7, line 4
o all X509v3 Extended Key Usage o all X509v3 Extended Key Usage
o all X509v3 Subject Alternative Name o all X509v3 Subject Alternative Name
o all X509v3 Certificate Policies o all X509v3 Certificate Policies
In TLS-PSK operation, at least the following parameters of the TLS In TLS-PSK operation, at least the following parameters of the TLS
connection should be exposed: connection should be exposed:
o Originating IP address o Originating IP address
o TLS Identifier o TLS Identifier
2.4. RADIUS Datagrams 2.5. RADIUS Datagrams
Authentication, Accounting and Authorization packets are sent Authentication, Accounting and Authorization packets are sent
according to the following rules: according to the following rules:
RADIUS/TLS clients handle the following packet types from [RFC2865], RADIUS/TLS clients handle the following packet types from [RFC2865],
[RFC2866], [RFC5176] on the connection they initiated (see [RFC2866], [RFC5176] on the connection they initiated (see
Section 3.3 (3) and (4) ): Section 3.3 (3) and (4) ):
o send Access-Request o send Access-Request
skipping to change at page 9, line 11 skipping to change at page 9, line 13
is used, peer authentication alone is not sufficient; the peer must is used, peer authentication alone is not sufficient; the peer must
also be authorised to perform user authentications. In these cases, also be authorised to perform user authentications. In these cases,
the trust fabric cannot depend on peer authentication methods like the trust fabric cannot depend on peer authentication methods like
DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be
properly authorised. Typically, this can be achieved by adding properly authorised. Typically, this can be achieved by adding
appropriate authorisation fields into a X.509 certificate. Such appropriate authorisation fields into a X.509 certificate. Such
fields include SRV authority [RFC4985], subjectAltNames, or a defined fields include SRV authority [RFC4985], subjectAltNames, or a defined
list of certificate fingerprints. Operators of a RADIUS/TLS list of certificate fingerprints. Operators of a RADIUS/TLS
infrastructure should define their own authorisation trust model and infrastructure should define their own authorisation trust model and
apply this model to the certificates. The checks enumerated in apply this model to the certificates. The checks enumerated in
Section 2.2 provide sufficient flexibility for the implementation of Section 2.3 provide sufficient flexibility for the implementation of
authorisation trust models. authorisation trust models.
3.2. Ciphersuites and Compression Negotiation Considerations 3.2. Ciphersuites and Compression Negotiation Considerations
Not all TLS ciphersuites in [RFC5246] are supported by available TLS Not all TLS ciphersuites in [RFC5246] are supported by available TLS
tool kits, and licenses may be required in some cases. The existing tool kits, and licenses may be required in some cases. The existing
implementations of RADIUS/TLS use OpenSSL as cryptographic backend, implementations of RADIUS/TLS use OpenSSL as cryptographic backend,
which supports all of the ciphersuites listed in the rules in the which supports all of the ciphersuites listed in the rules in the
normative section. normative section.
skipping to change at page 9, line 42 skipping to change at page 9, line 44
(1) After the TLS session is established, RADIUS packet payloads are (1) After the TLS session is established, RADIUS packet payloads are
exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet
size can be determined by evaluating the size of the datagram that size can be determined by evaluating the size of the datagram that
arrived. Due to the stream nature of TCP and TLS, this does not hold arrived. Due to the stream nature of TCP and TLS, this does not hold
true for RADIUS/TLS packet exchange. Instead, packet boundaries of true for RADIUS/TLS packet exchange. Instead, packet boundaries of
RADIUS packets that arrive in the stream are calculated by evaluating RADIUS packets that arrive in the stream are calculated by evaluating
the packet's Length field. Special care needs to be taken on the the packet's Length field. Special care needs to be taken on the
packet sender side that the value of the Length field is indeed packet sender side that the value of the Length field is indeed
correct before sending it over the TLS tunnel, because incorrect correct before sending it over the TLS tunnel, because incorrect
packet lengths can no longer be detected by a differing datagram packet lengths can no longer be detected by a differing datagram
boundary. boundary. See section 2.6.4 of [I-D.dekok-radext-tcp-transport] for
more details.
(2) Within RADIUS [RFC2865], a shared secret is used for hiding (2) Within RADIUS [RFC2865], a shared secret is used for hiding
of attributes such as User-Password, as well as in computation of of attributes such as User-Password, as well as in computation of
the Response Authenticator. In RADIUS accounting [RFC2866], the the Response Authenticator. In RADIUS accounting [RFC2866], the
shared secret is used in computation of both the Request shared secret is used in computation of both the Request
Authenticator and the Response Authenticator. Since TLS provides Authenticator and the Response Authenticator. Since TLS provides
integrity protection and encryption sufficient to substitute for integrity protection and encryption sufficient to substitute for
RADIUS application-layer security, it is not necessary to configure a RADIUS application-layer security, it is not necessary to configure a
RADIUS shared secret. The use of a fixed string for the obsolete RADIUS shared secret. The use of a fixed string for the obsolete
shared secret eliminates possible node misconfigurations. shared secret eliminates possible node misconfigurations.
skipping to change at page 12, line 5 skipping to change at page 12, line 7
is fixed and well-known, failure to comply with this requirement will is fixed and well-known, failure to comply with this requirement will
expose the entire datagram payload in plain text, including User- expose the entire datagram payload in plain text, including User-
Password, to intermediate IP nodes. Password, to intermediate IP nodes.
If peer communication between two devices is configured for both If peer communication between two devices is configured for both
RADIUS/TLS and RADIUS/UDP, a failover from TLS security to classic RADIUS/TLS and RADIUS/UDP, a failover from TLS security to classic
RADIUS security opens the way for a down-bidding attack if an RADIUS security opens the way for a down-bidding attack if an
adversary can maliciously close the TCP connection, or prevent it adversary can maliciously close the TCP connection, or prevent it
from being established. In this case, security of the packet payload from being established. In this case, security of the packet payload
is reduced from the selected TLS cipher suite packet encryption to is reduced from the selected TLS cipher suite packet encryption to
the classic MD5 per-attribute encryption. the classic MD5 per-attribute encryption. Such an attack can be
mitigated by delisting the RADIUS/UDP client from the server
configuration after successfully migrating that client to RADIUS/TLS.
The RADIUS/TLS transport provides authentication and encryption The RADIUS/TLS transport provides authentication and encryption
between RADIUS peers. In the presence of proxies, the intermediate between RADIUS peers. In the presence of proxies, the intermediate
proxies can still inspect the individual RADIUS packets, i.e. "end- proxies can still inspect the individual RADIUS packets, i.e. "end-
to-end" encryption is not provided. Where intermediate proxies are to-end" encryption is not provided. Where intermediate proxies are
untrusted, it is desirable to use other RADIUS mechanisms to prevent untrusted, it is desirable to use other RADIUS mechanisms to prevent
RADIUS packet payload from inspection by such proxies. One common RADIUS packet payload from inspection by such proxies. One common
method to protect passwords is the use of EAP methods which utilize method to protect passwords is the use of EAP methods which utilize
TLS. TLS.
skipping to change at page 12, line 50 skipping to change at page 13, line 6
March 1997. March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, [RFC2865] Rigney, C., Willens, S., Rubens,
A., and W. Simpson, "Remote A., and W. Simpson, "Remote
Authentication Dial In User Service Authentication Dial In User Service
(RADIUS)", RFC 2865, June 2000. (RADIUS)", RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", [RFC2866] Rigney, C., "RADIUS Accounting",
RFC 2866, June 2000. RFC 2866, June 2000.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-
Shared Key Ciphersuites for
Transport Layer Security (TLS)",
RFC 4279, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The
Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346,
April 2006.
[RFC4985] Santesson, S., "Internet X.509 [RFC4985] Santesson, S., "Internet X.509
Public Key Infrastructure Subject Public Key Infrastructure Subject
Alternative Name for Expression of Alternative Name for Expression of
Service Name", RFC 4985, Service Name", RFC 4985,
August 2007. August 2007.
[RFC5280] Cooper, D., Santesson, S., Farrell, [RFC5280] Cooper, D., Santesson, S., Farrell,
S., Boeyen, S., Housley, R., and W. S., Boeyen, S., Housley, R., and W.
Polk, "Internet X.509 Public Key Polk, "Internet X.509 Public Key
Infrastructure Certificate and Infrastructure Certificate and
skipping to change at page 13, line 26 skipping to change at page 13, line 40
Mitton, D., and B. Aboba, "Dynamic Mitton, D., and B. Aboba, "Dynamic
Authorization Extensions to Remote Authorization Extensions to Remote
Authentication Dial In User Service Authentication Dial In User Service
(RADIUS)", RFC 5176, January 2008. (RADIUS)", RFC 5176, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The [RFC5246] Dierks, T. and E. Rescorla, "The
Transport Layer Security (TLS) Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246, Protocol Version 1.2", RFC 5246,
August 2008. August 2008.
[I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", [I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", draft
draft-dekok-radext-tcp-transport-01 -ietf-dekok-radext-tcp-transport-08
(work in progress), November 2008. (work in progress), July 2010.
9.2. Informative References 9.2. Informative References
[I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport [I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport
Layer for RADIUS", Layer for RADIUS",
draft-dekok-radext-dtls-01 (work in draft-dekok-radext-dtls-02 (work in
progress), June 2009. progress), March 2010.
[I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery [I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery
for RADIUS over TLD and DTLS", for RADIUS over TLD and DTLS",
draft-winter-dynamic-discovery-00 draft-winter-dynamic-discovery-00
(work in progress), February 2009. (work in progress), February 2009.
[RFC3588] Calhoun, P., Loughney, J., Guttman, [RFC3588] Calhoun, P., Loughney, J., Guttman,
E., Zorn, G., and J. Arkko, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, "Diameter Base Protocol", RFC 3588,
September 2003. September 2003.
[radsec-whitepaper] Open System Consultants, "RadSec - [radsec-whitepaper] Open System Consultants, "RadSec -
a secure, reliable RADIUS a secure, reliable RADIUS
Protocol", May 2005, <http:// Protocol", May 2005, <http://
www.open.com.au/radiator/ www.open.com.au/radiator/
radsec-whitepaper.pdf>. radsec-whitepaper.pdf>.
[MD5-attacks] Black, J., Cochran, M., and T.
Highland, "A Study of the MD5
Attacks: Insights and
Improvements", October 2006, <http:
//www.springerlink.com/content/
40867l85727r7084/>.
[radsecproxy-impl] Venaas, S., "radsecproxy Project [radsecproxy-impl] Venaas, S., "radsecproxy Project
Homepage", 2007, <http:// Homepage", 2007, <http://
software.uninett.no/radsecproxy/>. software.uninett.no/radsecproxy/>.
[eduroam] Trans-European Research and [eduroam] Trans-European Research and
Education Networking Association, Education Networking Association,
"eduroam Homepage", 2007, "eduroam Homepage", 2007,
<http://www.eduroam.org/>. <http://www.eduroam.org/>.
[geant2] Delivery of Advanced Network [geant2] Delivery of Advanced Network
 End of changes. 28 change blocks. 
61 lines changed or deleted 83 lines changed or added

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