draft-ietf-radext-radsec-04.txt   draft-ietf-radext-radsec-05.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 7, 2009 OSC Expires: January 14, 2010 OSC
S. Venaas S. Venaas
UNINETT UNINETT
K. Wierenga K. Wierenga
Cisco Cisco
March 06, 2009 July 13, 2009
TLS encryption for RADIUS over TCP (RadSec) TLS encryption for RADIUS over TCP (RadSec)
draft-ietf-radext-radsec-04 draft-ietf-radext-radsec-05
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 to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 7, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4
2.3. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 5 2.3. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 5
3. Informative: Design Decisions . . . . . . . . . . . . . . . . 7 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 7
3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 7 3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 7
3.2. Ciphersuites and Compression Negotiation Considerations . 8 3.2. Ciphersuites and Compression Negotiation Considerations . 8
3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8
4. Compatibility with other RADIUS transports . . . . . . . . . . 9 4. Compatibility with other RADIUS transports . . . . . . . . . . 9
5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 10 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Implementation Overview: Radiator . . . . . . . . . . 13 Appendix A. Implementation Overview: Radiator . . . . . . . . . . 13
Appendix B. Implementation Overview: radsecproxy . . . . . . . . 14 Appendix B. Implementation Overview: radsecproxy . . . . . . . . 14
1. Introduction 1. Introduction
skipping to change at page 4, line 39 skipping to change at page 4, line 39
TLS 1.1. The following restrictions apply: TLS 1.1. The following restrictions apply:
* The authentication MUST be mutual, i.e. both the RadSec server * The authentication MUST be mutual, i.e. both the RadSec server
and the RadSec client authenticate each other. and the RadSec client authenticate each other.
* The client MUST NOT negotiate cipher suites which only provide * The client MUST NOT negotiate cipher suites which only provide
integrity protection. integrity protection.
* The TLS session MAY use mutual PSKs for connection setup. * The TLS session MAY use mutual PSKs for connection setup.
* RADSEC implementations MUST support he mandatory to implement * Negotiation of compression for the TLS session is OPTIONAL.
cipher suites specified in TLS. For purposes of compatibility
* RADSEC implementations MUST support the mandatory to implement
cipher suites specified in TLS (i.e.
TLS_RSA_WITH_3DES_EDE_CBC_SHA). For purposes of compatibility
with some current deployments implementations SHOULD support with some current deployments implementations SHOULD support
TLS_RSA_WITH_RC4_128_SHA as well (see Section 3.2 (1) ). TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as
well (see Section 3.2 (1) ).
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]. If service names as per [RFC4985] are present per [RFC5280]. If service names as per [RFC4985] are present
in the certificate and dynamic discovery utilizing SRVs in DNS in the certificate and dynamic discovery utilizing SRVs in DNS
is used (see [I-D.winter-dynamic-discovery]), the SRV entry is used (see [I-D.winter-dynamic-discovery]) and the TLS
SHOULD be validated. implementation supports evaluation of the extensions in
[RFC4985], the SRV entry MUST be validated.
* 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 (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.
Implementations MUST support SHA-1 as the hash algorithm and Implementations MUST support SHA-1 as the hash algorithm and
use the ASCII label "sha-1" to identify the SHA-1 algorithm. use the ASCII label "sha-1" to identify the SHA-1 algorithm.
The length of a SHA-1 hash is 20 bytes and the length of the The length of a SHA-1 hash is 20 bytes and the length of the
corresponding fingerprint string is 65 characters. An example corresponding fingerprint string is 65 characters. An example
certificate fingerprint is: sha- certificate fingerprint is: sha-
1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D 1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D
* Peer validation always includes a check on whether the DNS * Peer validation always includes a check on whether the locally
name or the IP address of the server that is contacted matches configured expected DNS name or IP address of the server that
its certificate. DNS names and IP addresses can be contained is contacted matches its presented certificate. DNS names and
in the Common Name (CN) or subjectAltName entries. For IP addresses can be contained in the Common Name (CN) or
verification, only one these entries is to be considered. The subjectAltName entries. For verification, only one these
following precedence applies: for DNS name validation, entries is to be considered. The following precedence
subjectAltName:DNS has precedence over CN; for IP address applies: for DNS name validation, subjectAltName:DNS has
validation, subjectAltName:iPAddr has precedence over CN. precedence over CN; for IP address validation, subjectAltName:
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. RADIUS Datagrams 2.3. RADIUS Datagrams
skipping to change at page 7, line 36 skipping to change at page 7, line 40
(2) If a RadSec server is in possession of multiple certificates from (2) If a RadSec server is in possession of multiple certificates from
different CAs (i.e. is part of multiple roaming consortia), it will different CAs (i.e. is part of multiple roaming consortia), it will
need to select one of its certificates to present to the RadSec need to select one of its certificates to present to the RadSec
client. If the client sends the Trusted CA Indication, this hint can client. If the client sends the Trusted CA Indication, this hint can
make the server select the appropriate certificate and prevent a make the server select the appropriate certificate and prevent a
handshake failure. Omitting this indication makes it impossible to handshake failure. Omitting this indication makes it impossible to
deterministically select the right certificate in this case. If deterministically select the right certificate in this case. If
there is no risk of confusing multiple roaming consortia, providing there is no risk of confusing multiple roaming consortia, providing
this indication in the handshake is not crucial. this indication in the handshake is not crucial.
(4) If dynamic peer discovery as per [I-D.winter-dynamic-discovery] (3) If dynamic peer discovery as per [I-D.winter-dynamic-discovery]
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 RadSec nodes. The RadSec nodes also need to be DNSSEC to identify RadSec nodes. The RadSec 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 (x.y.z... reference), subjectAltName: fields include SRV authority (x.y.z... reference), subjectAltName:
URI, or a defined list of certificate fingerprints. Operators of a URI, or a defined list of certificate fingerprints. Operators of a
RadSec infrastructure should define their own authorisation trust RadSec infrastructure should define their own authorisation trust
model and apply this model to the certificates. The checks model and apply this model to the certificates. The checks
enumerated in Section 2.2 provide sufficient flexibility for the enumerated in Section 2.2 provide sufficient flexibility for the
implementation of authorisation trust models. implementation of authorisation trust models.
3.2. Ciphersuites and Compression Negotiation Considerations 3.2. Ciphersuites and Compression Negotiation Considerations
RadSec implementations need not necessarily support all TLS Not all TLS ciphersuites in [RFC5246] are supported by available TLS
ciphersuites listed in [RFC5246]. Not all TLS ciphersuites tool kits, and licenses may be required in some cases. The existing
are supported by available TLS tool kits and licenses may be required implementations of RadSec use OpenSSL as cryptographic backend, which
in some cases. The existing implementations of RadSec use OpenSSL as supports all of the ciphersuites listed in the rules in the normative
cryptographic backend, which supports all of the ciphersuites listed section.
in the rules in the normative section.
The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to-
implement according to [RFC5246] and thus has to be supported by implement according to [RFC5246] and thus has to be supported by
RadSec nodes. RadSec nodes.
The two other ciphersuites in the normative section The two other ciphersuites in the normative section are widely
(TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA) are implemented in TLS toolkits and are considered good practice to
widely implemented in TLS toolkits and are considered good practice implement.
to implement.
TLS also supports compression. Compression is an optional
feature. During the RadSec conversation the client and server may
negotiate compression, but must continue the conversation even if the
other peer rejects compression.
3.3. RADIUS Datagram Considerations 3.3. RADIUS Datagram Considerations
(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 plain RADIUS, the packet exchanged over the encrypted TLS tunnel. In plain RADIUS, 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 RadSec packet exchange. Instead, packet boundaries of true for RadSec 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
skipping to change at page 12, line 34 skipping to change at page 12, line 29
draft-dekok-radext-tcp-transport-01 draft-dekok-radext-tcp-transport-01
(work in progress), November 2008. (work in progress), November 2008.
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-00 (work in draft-dekok-radext-dtls-00 (work in
progress), February 2007. progress), February 2007.
[I-D.winter-dynamic-discovery] Winter, S. and M. McCauley, "NAI- [I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery
based Dynamic Peer Discovery for for RADIUS over TLD and DTLS",
RADIUS over TLS 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>.
[radiator-manual] Open System Consultants, "Radiator
Radius Server - Installation and
Reference Manual", 2006, <http://
www.open.com.au/radiator/ref.html>.
[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
skipping to change at page 14, line 42 skipping to change at page 14, line 32
that supports any number and combination of clients and servers, that supports any number and combination of clients and servers,
supporting RADIUS over UDP and RadSec. The main idea is that it can supporting RADIUS over UDP and RadSec. The main idea is that it can
be used on the same host as a non-RadSec client or server to ensure be used on the same host as a non-RadSec client or server to ensure
RadSec is used on the wire, however as a generic proxy it can be used RadSec is used on the wire, however as a generic proxy it can be used
in other circumstances as well. in other circumstances as well.
The configuration file consists of client and server clauses, where The configuration file consists of client and server clauses, where
there is one such clause for each client or server. In such a clause there is one such clause for each client or server. In such a clause
one specifies either "type tls" or "type udp" for RadSec or UDP one specifies either "type tls" or "type udp" for RadSec or UDP
transport. For RadSec the default shared secret "mysecret" (without transport. For RadSec the default shared secret "mysecret" (without
quotes), the same as Radiator, is used. A secret may be specified by quotes), the same as Radiator, is used. For compliance with this
putting say "secret somesharedsecret" inside a client or server document, this setting needs to be configured for the shared secret
clause. "radsec". A secret may be specified by putting say "secret
somesharedsecret" inside a client or server clause.
In order to use TLS for clients and/or servers, one must also specify In order to use TLS for clients and/or servers, one must also specify
where to locate CA certificates, as well as certificate and key for where to locate CA certificates, as well as certificate and key for
the client or server. This is done in a TLS clause. There may be the client or server. This is done in a TLS clause. There may be
one or several TLS clauses. A client or server clause may reference one or several TLS clauses. A client or server clause may reference
a particular TLS clause, or just use a default one. One use for a particular TLS clause, or just use a default one. One use for
multiple TLS clauses may be to present one certificate to clients and multiple TLS clauses may be to present one certificate to clients and
another to servers. another to servers.
If any RadSec (TLS) clients are configured, the proxy will at startup If any RadSec (TLS) clients are configured, the proxy will at startup
 End of changes. 16 change blocks. 
46 lines changed or deleted 40 lines changed or added

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