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/ |