draft-ietf-radext-radsec-10.txt | draft-ietf-radext-radsec-11.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: July 12, 2012 OSC | Expires: July 30, 2012 OSC | |||
S. Venaas | S. Venaas | |||
UNINETT | ||||
K. Wierenga | K. Wierenga | |||
Cisco | Cisco | |||
January 9, 2012 | January 27, 2012 | |||
TLS encryption for RADIUS | TLS encryption for RADIUS | |||
draft-ietf-radext-radsec-10 | draft-ietf-radext-radsec-11 | |||
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 in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
skipping to change at page 1, line 37 | skipping to change at page 1, line 36 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | 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." | |||
This Internet-Draft will expire on July 12, 2012. | This Internet-Draft will expire on July 30, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 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 25 | skipping to change at page 2, line 24 | |||
outside the IETF Standards Process, and derivative works of it may | outside the IETF Standards Process, and derivative works of it may | |||
not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
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 | |||
1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4 | ||||
2. Normative: Transport Layer Security for RADIUS/TCP . . . . . . 4 | 2. Normative: Transport Layer Security for RADIUS/TCP . . . . . . 4 | |||
2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4 | 2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4 | |||
2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 4 | 2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4 | 2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6 | 2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6 | |||
2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7 | 2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7 | |||
3. Informative: Design Decisions . . . . . . . . . . . . . . . . 8 | 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 9 | |||
3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 8 | 3.1. Implications of Dynamic Peer Discovery . . . . . . . . . . 9 | |||
3.2. Ciphersuites and Compression Negotiation Considerations . 9 | 3.2. X.509 Certificate Considerations . . . . . . . . . . . . . 9 | |||
3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10 | 3.3. Ciphersuites and Compression Negotiation Considerations . 10 | |||
3.4. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10 | ||||
4. Compatibility with other RADIUS transports . . . . . . . . . . 11 | 4. Compatibility with other RADIUS transports . . . . . . . . . . 11 | |||
5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11 | 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 12 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 | 8. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 13 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 15 | ||||
Appendix A. Implementation Overview: Radiator . . . . . . . . . . 16 | Appendix A. Implementation Overview: Radiator . . . . . . . . . . 16 | |||
Appendix B. Implementation Overview: radsecproxy . . . . . . . . 17 | Appendix B. Implementation Overview: radsecproxy . . . . . . . . 17 | |||
Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 18 | Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 18 | |||
1. Introduction | 1. Introduction | |||
The RADIUS protocol [RFC2865] is a widely deployed authentication and | The RADIUS protocol [RFC2865] is a widely deployed authentication and | |||
authorisation protocol. The supplementary RADIUS Accounting | authorisation protocol. The supplementary RADIUS Accounting | |||
specification [RFC2866] also provides accounting mechanisms, thus | specification [RFC2866] also provides accounting mechanisms, thus | |||
delivering a full AAA solution. However, RADIUS is experiencing | delivering a full AAA solution. However, RADIUS is experiencing | |||
skipping to change at page 3, line 40 | skipping to change at page 3, line 40 | |||
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 use of more contemporary | |||
connections to peers that are not previously configured, and thus | trust models, e.g. checking a certificate by inspecting the issuer | |||
makes it possible to avoid aggregation-only RADIUS proxies and reduce | and other certificate properties. | |||
the number of middleboxes which can eavesdrop on traffic. One | ||||
mechanism to discover RADIUS over TLS peers with DNS is specified in | ||||
[I-D.ietf-radext-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", "NOT | "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT | |||
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be | RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be | |||
interpreted as described in RFC 2119. [RFC2119] | interpreted as described in RFC 2119. [RFC2119] | |||
1.2. Terminology | 1.2. Terminology | |||
skipping to change at page 4, line 18 | skipping to change at page 4, line 17 | |||
RADIUS/TLS node: a RADIUS over TLS client or server | RADIUS/TLS node: a RADIUS over TLS client or server | |||
RADIUS/TLS Client: a RADIUS over TLS instance which initiates a new | RADIUS/TLS Client: a RADIUS over TLS instance which initiates a new | |||
connection. | connection. | |||
RADIUS/TLS Server: a RADIUS over TLS instance which listens on a | RADIUS/TLS Server: a RADIUS over TLS instance which listens on a | |||
RADIUS over TLS port and accepts new connections | RADIUS over TLS port and accepts new connections | |||
RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865] | RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865] | |||
1.3. Document Status | ||||
This document is an Experimental RFC. | ||||
It is one out of several approaches to address known cryptographic | ||||
weaknesses of the RADIUS protocol (see also Section 4). The | ||||
specification does not fulfill all recommendations on a AAA transport | ||||
profile as per [RFC3539]; in particular, by being based on TCP as a | ||||
transport layer, it does not prevent head-of-line blocking issues. | ||||
It has yet to be decided whether this approach is to be chosen for | ||||
standards track. One key aspect to judge whether the approach is | ||||
usable at large scale is by observing the uptake, usability and | ||||
operational behaviour of the protocol in large-scale, real-life | ||||
deployments. | ||||
An example for a world-wide roaming environment that uses RADIUS over | ||||
TLS to secure communication is "eduroam", see [eduroam]. | ||||
2. Normative: Transport Layer Security for RADIUS/TCP | 2. Normative: Transport Layer Security for RADIUS/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. See | dynamic authorisation changes. The source port is arbitrary. See | |||
section Section 3.3 (4) and (5) for considerations regarding | section Section 3.4 for considerations regarding separation of | |||
separation of authentication, accounting and dynauth traffic. | authentication, accounting and dynauth traffic. | |||
2.2. TLS negotiation | 2.2. TLS negotiation | |||
RADIUS/TLS has no notion of negotiating TLS in an established | RADIUS/TLS has no notion of negotiating TLS in an established | |||
connection. Servers and clients need to be preconfigured to use | connection. Servers and clients need to be preconfigured to use | |||
RADIUS/TLS for a given endpoint. | RADIUS/TLS for a given endpoint. | |||
2.3. Connection Setup | 2.3. Connection Setup | |||
RADIUS/TLS nodes | RADIUS/TLS nodes | |||
1. establish TCP connections as per [I-D.ietf-radext-tcp-transport]. | 1. establish TCP connections as per [I-D.ietf-radext-tcp-transport]. | |||
Failure to connect leads to continuous retries, with | Failure to connect leads to continuous retries, with | |||
exponentially growing intervals between every try. If multiple | exponentially growing intervals between every try. If multiple | |||
servers are defined, the node MAY attempt to establish a | servers are defined, the node MAY attempt to establish a | |||
connection to these other servers in parallel, in order to | connection to these other servers in parallel, in order to | |||
implement quick failover. | implement quick failover. | |||
2. after completing the TCP handshake, immediately negotiate TLS | 2. after completing the TCP handshake, immediately negotiate TLS | |||
sessions. The following restrictions apply: according to | sessions according to [RFC5246] or its predecessor TLS 1.1. The | |||
[RFC5246] or its predecessor TLS 1.1. The following restrictions | following restrictions apply: | |||
apply: | ||||
* Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 | * Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 | |||
[RFC5246] ]) is REQUIRED. | [RFC5246] ]) is REQUIRED. | |||
* Support for certificate-based mutual authentication is | * Support for certificate-based mutual authentication is | |||
REQUIRED. | REQUIRED. | |||
* Negotiation of mutual authentication is REQUIRED. | * Negotiation of mutual authentication is REQUIRED. | |||
* Negotiation of a ciphersuite providing for confidentiality as | * Negotiation of a ciphersuite providing for confidentiality as | |||
well as integrity protection is REQUIRED. | well as integrity protection is REQUIRED. | |||
* Support for and negotiation of compression is OPTIONAL. | * Support for and negotiation of compression is OPTIONAL. | |||
* Support for TLS-PSK mutual authentication [RFC4279] is | * Support for TLS-PSK mutual authentication [RFC4279] is | |||
OPTIONAL. | OPTIONAL. | |||
* RADIUS/TLS implementations MUST at a minimum support | * RADIUS/TLS implementations MUST at a minimum support | |||
negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD | negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD | |||
support TLS_RSA_WITH_RC4_128_SHA and | support TLS_RSA_WITH_RC4_128_SHA and | |||
TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.2 (1) ). | TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.3 (1) ). | |||
* In addition, RADIUS/TLS implementations MUST support | * In addition, RADIUS/TLS implementations MUST support | |||
negotiation of the mandatory-to-implement ciphersuites | negotiation of the mandatory-to-implement ciphersuites | |||
required by the versions of TLS that they support. | required by the versions of TLS that they support. | |||
* RADIUS/TLS nodes MUST NOT negotiate ciphersuites with NULL | * RADIUS/TLS nodes MUST NOT negotiate ciphersuites with NULL | |||
encryption (e.g. [RFC4785]). | encryption (e.g. [RFC4785]). | |||
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]. | per [RFC5280]. | |||
* 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.2) | |||
* 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- | |||
skipping to change at page 6, line 19 | skipping to change at page 6, line 37 | |||
IP addresses can be contained in the Common Name (CN) or | IP addresses can be contained in the Common Name (CN) or | |||
subjectAltName entries. For verification, only one of these | subjectAltName entries. For verification, only one of these | |||
entries is to be considered. The following precedence | entries is to be considered. The following precedence | |||
applies: for DNS name validation, subjectAltName:DNS has | applies: for DNS name validation, subjectAltName:DNS has | |||
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.4 (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.4 (2) ). | |||
2.4. 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. | |||
Since the shared secret is associated with the origin IP address, if | Since the shared secret is associated with the origin IP address, if | |||
more than one RADIUS client is associated with the same IP address, | more than one RADIUS client is associated with the same IP address, | |||
then those clients also must utilize the same shared secret, a | then those clients also must utilize the same shared secret, a | |||
practice which is inherently insecure as noted in [RFC5247]. | practice which is inherently insecure as noted in [RFC5247]. | |||
RADIUS/TLS supports multiple operation modes. | RADIUS/TLS supports multiple operation modes. | |||
skipping to change at page 7, line 36 | skipping to change at page 8, line 4 | |||
o Originating IP address | o Originating IP address | |||
o TLS Identifier | o TLS Identifier | |||
2.5. 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 transmit the same packet types on the connection | RADIUS/TLS clients transmit the same packet types on the connection | |||
they initiated as a RADIUS/UDP client would (see Section 3.3 (3) and | they initiated as a RADIUS/UDP client would (see Section 3.4 (3) and | |||
(4) ). E.g. they send | (4) ). E.g. they send | |||
o Access-Request | o Access-Request | |||
o Accounting-Request | o Accounting-Request | |||
o Status-Server | o Status-Server | |||
o Disconnect-ACK | o Disconnect-ACK | |||
skipping to change at page 8, line 34 | skipping to change at page 9, line 4 | |||
o ... | o ... | |||
and they receive | and they receive | |||
o Access-Request | o Access-Request | |||
o Accounting-Request | o Accounting-Request | |||
o Status-Server | o Status-Server | |||
o Disconnect-ACK | o Disconnect-ACK | |||
o ... | o ... | |||
3. Informative: Design Decisions | 3. Informative: Design Decisions | |||
This section explains the design decisions that led to the rules | This section explains the design decisions that led to the rules | |||
defined in the previous section. | defined in the previous section. | |||
3.1. X.509 Certificate Considerations | 3.1. Implications of Dynamic Peer Discovery | |||
One mechanism to discover RADIUS over TLS peers dynamically via DNS | ||||
is specified in [I-D.ietf-radext-dynamic-discovery]. While this | ||||
mechanism is still under development and therefore is not a normative | ||||
dependency of RADIUS/TLS, the use of dynamic discovery has potential | ||||
future implications that are important to understand. | ||||
Readers of this document who are considering the deployment of DNS- | ||||
based dynamic discovery are thus encouraged to read | ||||
[I-D.ietf-radext-dynamic-discovery] and follow its future | ||||
development. | ||||
3.2. X.509 Certificate Considerations | ||||
(1) If a RADIUS/TLS client is in possession of multiple certificates | (1) If a RADIUS/TLS client is in possession of multiple certificates | |||
from different CAs (i.e. is part of multiple roaming consortia) and | from different CAs (i.e. is part of multiple roaming consortia) and | |||
dynamic discovery is used, the discovery mechanism possibly does not | dynamic discovery is used, the discovery mechanism possibly does not | |||
yield sufficient information to identify the consortium uniquely | yield sufficient information to identify the consortium uniquely | |||
(e.g. DNS discovery). Subsequently, the client may not know by | (e.g. DNS discovery). Subsequently, the client may not know by | |||
itself which client certificate to use for the TLS handshake. Then | itself which client certificate to use for the TLS handshake. Then | |||
it is necessary for the server to signal which consortium it belongs | it is necessary for the server to signal which consortium it belongs | |||
to, and which certificates it expects. If there is no risk of | to, and which certificates it expects. If there is no risk of | |||
confusing multiple roaming consortia, providing this information in | confusing multiple roaming consortia, providing this information in | |||
skipping to change at page 9, line 19 | skipping to change at page 10, line 5 | |||
(2) If a RADIUS/TLS server is in possession of multiple certificates | (2) If a RADIUS/TLS server is in possession of multiple certificates | |||
from different CAs (i.e. is part of multiple roaming consortia), it | from different CAs (i.e. is part of multiple roaming consortia), it | |||
will need to select one of its certificates to present to the RADIUS/ | will need to select one of its certificates to present to the RADIUS/ | |||
TLS client. If the client sends the Trusted CA Indication, this hint | TLS client. If the client sends the Trusted CA Indication, this hint | |||
can make the server select the appropriate certificate and prevent a | can 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. | |||
(3) If dynamic peer discovery as per | 3.3. Ciphersuites and Compression Negotiation Considerations | |||
[I-D.ietf-radext-dynamic-discovery] is used, peer authentication | ||||
alone is not sufficient; the peer must also be authorised to perform | ||||
user authentications. In these cases, the trust fabric cannot depend | ||||
on peer authentication methods like DNSSEC to identify RADIUS/TLS | ||||
nodes. The nodes also need to be properly authorised. Typically, | ||||
this can be achieved by adding appropriate authorisation fields into | ||||
a X.509 certificate. Such fields include SRV authority [RFC4985], | ||||
subjectAltNames, or a defined list of certificate fingerprints. | ||||
Operators of a RADIUS/TLS infrastructure should define their own | ||||
authorisation trust model and apply this model to the certificates. | ||||
The checks enumerated in Section 2.3 provide sufficient flexibility | ||||
for the implementation of authorisation trust models. | ||||
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. | |||
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 | |||
RADIUS/TLS nodes. | RADIUS/TLS nodes. | |||
The two other ciphersuites in the normative section are widely | The two other ciphersuites in the normative section are widely | |||
implemented in TLS toolkits and are considered good practice to | implemented in TLS toolkits and are considered good practice to | |||
implement. | implement. | |||
3.3. RADIUS Datagram Considerations | 3.4. 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 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 | |||
skipping to change at page 10, line 47 | skipping to change at page 11, line 14 | |||
acceptable packet types for clients and servers mirror the packet | acceptable packet types for clients and servers mirror the packet | |||
flow behaviour from RADIUS/UDP. | flow behaviour from RADIUS/UDP. | |||
(4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly | (4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly | |||
allocated UDP port to signal that a peer RADIUS server does not | allocated UDP port to signal that a peer RADIUS server does not | |||
support reception and processing of the packet types in [RFC5176]. | support reception and processing of the packet types in [RFC5176]. | |||
These packet types are listed as to be received in RADIUS/TLS | These packet types are listed as to be received in RADIUS/TLS | |||
implementations. Note well: it is not required for an implementation | implementations. Note well: it is not required for an implementation | |||
to actually process these packet types. It is sufficient that upon | to actually process these packet types. It is sufficient that upon | |||
receiving such a packet, an unconditional NAK is sent back to | receiving such a packet, an unconditional NAK is sent back to | |||
indicate that the action is not supported. | indicate that the action is not supported. The NAK SHOULD contain an | |||
attribute Error-Cause with the value 406 ("Unsupported Extension"); | ||||
see [RFC5176] for details. | ||||
(5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly | (5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly | |||
allocated UDP port to signal that a peer RADIUS server does not | allocated UDP port to signal that a peer RADIUS server does not | |||
support reception and processing of RADIUS Accounting packets. There | support reception and processing of RADIUS Accounting packets. There | |||
is no RADIUS datagram to signal an Accounting NAK. Clients may be | is no RADIUS datagram to signal an Accounting NAK. Clients may be | |||
misconfigured to send Accounting packets to a RADIUS/TLS server which | misconfigured to send Accounting packets to a RADIUS/TLS server which | |||
does not wish to process their Accounting packet. The server will | does not wish to process their Accounting packet. The server will | |||
need to silently drop the packet. The client will need to deduce | need to silently drop the packet. The client will need to deduce | |||
from the absence of replies that it is misconfigured; no negative | from the absence of replies that it is misconfigured; no negative | |||
ICMP response will reveal this. | ICMP response will reveal this. | |||
skipping to change at page 11, line 35 | skipping to change at page 12, line 5 | |||
transports, which is called a multi-stack implementation. | transports, which is called a multi-stack implementation. | |||
If a given IP device is able to receive RADIUS payloads on multiple | If a given IP device is able to receive RADIUS payloads on multiple | |||
transports, this may or may not be the same instance of software, and | transports, this may or may not be the same instance of software, and | |||
it may or may not serve the same purposes. It is not safe to assume | it may or may not serve the same purposes. It is not safe to assume | |||
that both ports are interchangeable. In particular, it can not be | that both ports are interchangeable. In particular, it can not be | |||
assumed that state is maintained for the packet payloads between the | assumed that state is maintained for the packet payloads between the | |||
transports. Two such instances MUST be considered separate RADIUS | transports. Two such instances MUST be considered separate RADIUS | |||
server entities. | server entities. | |||
As a consequence, the selection of transports to communicate from a | ||||
client to a server is a manual administrative action. An automatic | ||||
fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- | ||||
bidding attacks on the peer communication. | ||||
5. Diameter Compatibility | 5. Diameter Compatibility | |||
Since RADIUS/TLS is only a new transport profile for RADIUS, | Since RADIUS/TLS is only a new transport profile for RADIUS, | |||
compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP | compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP | |||
[RFC2865] - Diameter [RFC3588] is identical. The considerations | [RFC2865] - Diameter [RFC3588] is identical. The considerations | |||
regarding payload size in [I-D.ietf-radext-tcp-transport] apply. | regarding payload size in [I-D.ietf-radext-tcp-transport] apply. | |||
6. Security Considerations | 6. Security Considerations | |||
The computational resources to establish a TLS tunnel are | The computational resources to establish a TLS tunnel are | |||
significantly higher than simply sending mostly unencrypted UDP | significantly higher than simply sending mostly unencrypted UDP | |||
datagrams. Therefore, clients connecting to a RADIUS/TLS node will | datagrams. Therefore, clients connecting to a RADIUS/TLS node will | |||
more easily create high load conditions and a malicious client might | more easily create high load conditions and a malicious client might | |||
create a Denial-of-Service attack more easily. | create a Denial-of-Service attack more easily. | |||
In the case of dynamic peer discovery as per | ||||
[I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be | ||||
able to accept connections from a large, not previously known, group | ||||
of hosts, possibly the whole internet. In this case, the server's | ||||
RADIUS/TLS port can not be protected from unauthorised connection | ||||
attempts with measures on the network layer, i.e. access lists and | ||||
firewalls. This opens more attack vectors for Distributed Denial of | ||||
Service attacks, just like any other service that is supposed to | ||||
serve arbitrary clients (like for example web servers). | ||||
In the case of dynamic peer discovery as per | ||||
[I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only | ||||
proof of authorisation for a connecting RADIUS/TLS nodes. Special | ||||
care needs to be taken that certificates get verified properly | ||||
according to the chosen trust model (particularly: consulting CRLs, | ||||
checking critical extensions, checking subjectAltNames etc.) to | ||||
prevent unauthorised connections. | ||||
Some TLS ciphersuites only provide integrity validation of their | Some TLS ciphersuites only provide integrity validation of their | |||
payload, and provide no encryption. This specification forbids the | payload, and provide no encryption. This specification forbids the | |||
use of such ciphersuites. Since the RADIUS payload's shared secret | use of such ciphersuites. Since the RADIUS payload's shared secret | |||
is fixed to the well-known term "radsec" (see Section 2.3 (4) ) , | is fixed to the well-known term "radsec" (see Section 2.3 (4) ) , | |||
failure to comply with this requirement will expose the entire | failure to comply with this requirement will expose the entire | |||
datagram payload in plain text, including User-Password, to | datagram payload in plain text, including User-Password, to | |||
intermediate IP nodes. | 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 transport (i.e TLS security on the transport layer, shared | |||
RADIUS security opens the way for a down-bidding attack if an | secret fixed to "radsec") and RADIUS/UDP (i.e. shared secret security | |||
with a secret manually configured by the administrator), and where | ||||
the RADIUS/UDP transport is the failover option if the TLS session | ||||
cannot be established, a down-bidding attack can occur 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. Situations where clients are configured in | |||
is reduced from the selected TLS cipher suite packet encryption to | such a way are likely to occur during a migration phase from RADIUS/ | |||
the classic MD5 per-attribute encryption. Such an attack can be | UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker | |||
mitigated by delisting the RADIUS/UDP client from the server | can reduce the security of the packet payload from the selected TLS | |||
configuration after successfully migrating that client to RADIUS/TLS. | cipher suite packet encryption to the classic MD5 per-attribute | |||
encryption. The situation should be avoided by disabling the weaker | ||||
RADIUS/UDP transport as soon as the new RADIUS/TLS transport is | ||||
established and tested. Disabling can happen at either the RADIUS | ||||
client or server side: | ||||
o Client side: de-configure the failover setup, leaving RADIUS/TLS | ||||
as the only communication option | ||||
o Server side: de-configure the RADIUS/UDP client from the list of | ||||
valid RADIUS clients | ||||
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. | |||
7. IANA Considerations | 7. IANA Considerations | |||
This document has no actions for IANA. The TCP port 2083 was already | No new RADIUS attributes or packet codes are defined. IANA is | |||
previously assigned by IANA for RadSec, an early implementation of | requested to update the already-assigned TCP port number 2083 in the | |||
RADIUS/TLS. No new RADIUS attributes or packet codes are defined. | following ways: | |||
8. Acknowledgements | o Reference: list the RFC number of this document as the reference | |||
o Assignment Notes: add the text "The TCP port 2083 was already | ||||
previously assigned by IANA for "RadSec", an early implementation | ||||
of RADIUS/TLS, prior to issuance of this RFC. This early | ||||
implementation can be configured to be compatible to RADIUS/TLS as | ||||
specified by the IETF. See RFC (RFC number of this document), | ||||
Appendix A for details." | ||||
8. Notes to the RFC Editor | ||||
[I-D.ietf-radext-tcp-transport] is currently in the publication queue | ||||
because it has a normative reference on this draft; it has no other | ||||
blocking dependencies. The two drafts should be published as an RFC | ||||
simultaneously, ideally with consequtive numbers. The references in | ||||
this draft to [I-D.ietf-radext-tcp-transport] should be changed to | ||||
references to the corresponding RFC prior to publication. | ||||
This section, "Notes to the RFC Editor" should be deleted from the | ||||
draft prior to publication. | ||||
9. Acknowledgements | ||||
RADIUS/TLS was first implemented as "RADSec" by Open Systems | RADIUS/TLS was first implemented as "RADSec" by Open Systems | |||
Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS | Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS | |||
server product (see [radsec-whitepaper]). | server product (see [radsec-whitepaper]). | |||
Funding and input for the development of this Internet Draft was | Funding and input for the development of this Internet Draft was | |||
provided by the European Commission co-funded project "GEANT2" | provided by the European Commission co-funded project "GEANT2" | |||
[geant2] and further feedback was provided by the TERENA Task Force | [geant2] and further feedback was provided by the TERENA Task Force | |||
Mobility [terena]. | Mobility [terena]. | |||
9. References | 10. References | |||
10.1. Normative References | ||||
9.1. Normative References | ||||
[RFC2119] Bradner, S., "Key words for use | [RFC2119] Bradner, S., "Key words for use | |||
in RFCs to Indicate Requirement | in RFCs to Indicate Requirement | |||
Levels", BCP 14, RFC 2119, | Levels", BCP 14, RFC 2119, | |||
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 | Authentication Dial In User | |||
Service (RADIUS)", RFC 2865, | Service (RADIUS)", RFC 2865, | |||
skipping to change at page 13, line 52 | skipping to change at page 14, line 32 | |||
Transport Layer Security (TLS)", | Transport Layer Security (TLS)", | |||
RFC 4279, December 2005. | RFC 4279, December 2005. | |||
[RFC4785] Blumenthal, U. and P. Goel, | [RFC4785] Blumenthal, U. and P. Goel, | |||
"Pre-Shared Key (PSK) | "Pre-Shared Key (PSK) | |||
Ciphersuites with NULL | Ciphersuites with NULL | |||
Encryption for Transport Layer | Encryption for Transport Layer | |||
Security (TLS)", RFC 4785, | Security (TLS)", RFC 4785, | |||
January 2007. | January 2007. | |||
[RFC4985] Santesson, S., "Internet X.509 | ||||
Public Key Infrastructure | ||||
Subject Alternative Name for | ||||
Expression of Service Name", | ||||
RFC 4985, August 2007. | ||||
[RFC5280] Cooper, D., Santesson, S., | [RFC5280] Cooper, D., Santesson, S., | |||
Farrell, S., Boeyen, S., | Farrell, S., Boeyen, S., | |||
Housley, R., and W. Polk, | Housley, R., and W. Polk, | |||
"Internet X.509 Public Key | "Internet X.509 Public Key | |||
Infrastructure Certificate and | Infrastructure Certificate and | |||
Certificate Revocation List | Certificate Revocation List | |||
(CRL) Profile", RFC 5280, | (CRL) Profile", RFC 5280, | |||
May 2008. | May 2008. | |||
[RFC5176] Chiba, M., Dommety, G., Eklund, | [RFC5176] Chiba, M., Dommety, G., Eklund, | |||
skipping to change at page 14, line 42 | skipping to change at page 15, line 17 | |||
Eronen, "Extensible | Eronen, "Extensible | |||
Authentication Protocol (EAP) | Authentication Protocol (EAP) | |||
Key Management Framework", | Key Management Framework", | |||
RFC 5247, August 2008. | RFC 5247, August 2008. | |||
[I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", dr | [I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", dr | |||
aft-ietf-radext-tcp-transport-09 | aft-ietf-radext-tcp-transport-09 | |||
(work in progress), | (work in progress), | |||
October 2010. | October 2010. | |||
9.2. Informative References | 10.2. Informative References | |||
[I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport | [I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport | |||
Layer for RADIUS", | Layer for RADIUS", | |||
draft-ietf-radext-dtls-01 (work | draft-ietf-radext-dtls-01 (work | |||
in progress), October 2010. | in progress), October 2010. | |||
[I-D.ietf-radext-dynamic-discovery] Winter, S. and M. McCauley, | [I-D.ietf-radext-dynamic-discovery] Winter, S. and M. McCauley, | |||
"NAI-based Dynamic Peer | "NAI-based Dynamic Peer | |||
Discovery for RADIUS/TLS and | Discovery for RADIUS/TLS and | |||
RADIUS/DTLS", draft-ietf-radext- | RADIUS/DTLS", draft-ietf-radext- | |||
dynamic-discovery-03 (work in | dynamic-discovery-03 (work in | |||
progress), July 2011. | progress), July 2011. | |||
[RFC3539] Aboba, B. and J. Wood, | ||||
"Authentication, Authorization | ||||
and Accounting (AAA) Transport | ||||
Profile", RFC 3539, June 2003. | ||||
[RFC3588] Calhoun, P., Loughney, J., | [RFC3588] Calhoun, P., Loughney, J., | |||
Guttman, E., Zorn, G., and J. | Guttman, E., Zorn, G., and J. | |||
Arkko, "Diameter Base Protocol", | Arkko, "Diameter Base Protocol", | |||
RFC 3588, September 2003. | RFC 3588, September 2003. | |||
[RFC4346] Dierks, T. and E. Rescorla, "The | [RFC4346] Dierks, T. and E. Rescorla, "The | |||
Transport Layer Security (TLS) | Transport Layer Security (TLS) | |||
Protocol Version 1.1", RFC 4346, | Protocol Version 1.1", RFC 4346, | |||
April 2006. | April 2006. | |||
[RFC6421] Nelson, D., "Crypto-Agility | ||||
Requirements for Remote | ||||
Authentication Dial-In User | ||||
Service (RADIUS)", RFC 6421, | ||||
November 2011. | ||||
[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. | [MD5-attacks] Black, J., Cochran, M., and T. | |||
Highland, "A Study of the MD5 | Highland, "A Study of the MD5 | |||
Attacks: Insights and | Attacks: Insights and | |||
Improvements", October 2006, <ht | Improvements", October 2006, <ht | |||
skipping to change at page 16, line 23 | skipping to change at page 17, line 8 | |||
using the RadSec protocol. | using the RadSec protocol. | |||
The <ServerRADSEC> clause defines a RadSec server, and causes | The <ServerRADSEC> clause defines a RadSec server, and causes | |||
Radiator to listen on the configured port and address(es) for | Radiator to listen on the configured port and address(es) for | |||
connections from <Authby RADSEC> clients. When an <Authby RADSEC> | connections from <Authby RADSEC> clients. When an <Authby RADSEC> | |||
client connects to a <ServerRADSEC> server, the client sends RADIUS | client connects to a <ServerRADSEC> server, the client sends RADIUS | |||
requests through the stream to the server. The server then handles | requests through the stream to the server. The server then handles | |||
the request in the same way as if the request had been received from | the request in the same way as if the request had been received from | |||
a conventional UDP RADIUS client. | a conventional UDP RADIUS client. | |||
Radiator is compliant to version 2 of RadSec if the following options | Radiator is compliant to RADIUS/TLS if the following options are | |||
are used: | used: | |||
<AuthBy RADSEC> | <AuthBy RADSEC> | |||
* Protocol tcp | * Protocol tcp | |||
* UseTLS | * UseTLS | |||
* TLS_CertificateFile | * TLS_CertificateFile | |||
* Secret radsec | * Secret radsec | |||
skipping to change at page 18, line 11 | skipping to change at page 18, line 46 | |||
The proxy supports Status-Server messages. They are only sent to a | The proxy supports Status-Server messages. They are only sent to a | |||
server if enabled for that particular server. Status-Server requests | server if enabled for that particular server. Status-Server requests | |||
are always responded to. | are always responded to. | |||
This RadSec implementation has been successfully tested together with | This RadSec implementation has been successfully tested together with | |||
Radiator. It is a freely available open-source implementation. For | Radiator. It is a freely available open-source implementation. For | |||
source code and documentation, see [radsecproxy-impl]. | source code and documentation, see [radsecproxy-impl]. | |||
Appendix C. Assessment of Crypto-Agility Requirements | Appendix C. Assessment of Crypto-Agility Requirements | |||
The RADIUS Crypto-Agility Requirements (link to RFC once issued here) | The RADIUS Crypto-Agility Requirements [RFC6421] defines numerous | |||
defines numerous classification criteria for protocols that strive to | classification criteria for protocols that strive to enhance the | |||
enhance the security of RADIUS. It contains mandatory (M) and | security of RADIUS. It contains mandatory (M) and recommended (R) | |||
recommended (R) criteria which crypto-agile protocols have to | criteria which crypto-agile protocols have to fulfill. The authors | |||
fulfill. The authors believe that the following assessment about the | believe that the following assessment about the crypto-agility | |||
crypto-agility properties of RADIUS/TLS are true. | properties of RADIUS/TLS are true. | |||
By virtue of operating on the transport layer with TLS, the | By virtue of operating on the transport layer with TLS, the | |||
cryptographically agile properties of TLS are inherited, and RADIUS/ | cryptographically agile properties of TLS are inherited, and RADIUS/ | |||
TLS subsequently meets the following points: | TLS subsequently meets the following points: | |||
(M) negotiation of cryptographic algorithms for integrity and auth | (M) negotiation of cryptographic algorithms for integrity and auth | |||
(M) negotiation of cryptographic algorithms for encryption | (M) negotiation of cryptographic algorithms for encryption | |||
(M) replay protection | (M) replay protection | |||
skipping to change at page 20, line 30 | skipping to change at page 21, line 17 | |||
9 Bulbul Place | 9 Bulbul Place | |||
Currumbin Waters QLD 4223 | Currumbin Waters QLD 4223 | |||
AUSTRALIA | AUSTRALIA | |||
Phone: +61 7 5598 7474 | Phone: +61 7 5598 7474 | |||
Fax: +61 7 5598 7070 | Fax: +61 7 5598 7070 | |||
EMail: mikem@open.com.au | EMail: mikem@open.com.au | |||
URI: http://www.open.com.au. | URI: http://www.open.com.au. | |||
Stig Venaas | Stig Venaas | |||
UNINETT | cisco Systems | |||
Abels gate 5 - Teknobyen | Tasman Drive | |||
Trondheim 7465 | San Jose, CA 95134 | |||
NORWAY | USA | |||
Phone: +47 73 55 79 00 | EMail: stig@cisco.com | |||
Fax: +47 73 55 79 01 | ||||
EMail: stig.venaas@uninett.no | ||||
URI: http://www.uninett.no. | ||||
Klaas Wierenga | Klaas Wierenga | |||
Cisco Systems International BV | Cisco Systems International BV | |||
Haarlerbergweg 13-19 | Haarlerbergweg 13-19 | |||
Amsterdam 1101 CH | Amsterdam 1101 CH | |||
The Netherlands | The Netherlands | |||
Phone: +31 (0)20 3571752 | Phone: +31 (0)20 3571752 | |||
Fax: | Fax: | |||
EMail: kwiereng@cisco.com | EMail: kwiereng@cisco.com | |||
End of changes. 39 change blocks. | ||||
111 lines changed or deleted | 140 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |