draft-ietf-radext-radsec-08.txt   draft-ietf-radext-radsec-09.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 15, 2011 OSC Expires: January 9, 2012 OSC
S. Venaas S. Venaas
UNINETT UNINETT
K. Wierenga K. Wierenga
Cisco Cisco
March 14, 2011 July 8, 2011
TLS encryption for RADIUS TLS encryption for RADIUS
draft-ietf-radext-radsec-08 draft-ietf-radext-radsec-09
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 37
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 September 15, 2011. This Internet-Draft will expire on January 9, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . 8
3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 8 3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 8
3.2. Ciphersuites and Compression Negotiation Considerations . 9 3.2. Ciphersuites and Compression Negotiation Considerations . 9
3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 9 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10
4. Compatibility with other RADIUS transports . . . . . . . . . . 11 4. Compatibility with other RADIUS transports . . . . . . . . . . 11
5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Implementation Overview: Radiator . . . . . . . . . . 15 Appendix A. Implementation Overview: Radiator . . . . . . . . . . 15
Appendix B. Implementation Overview: radsecproxy . . . . . . . . 16 Appendix B. Implementation Overview: radsecproxy . . . . . . . . 16
Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 17
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
several shortcomings, such as its dependency on the unreliable several shortcomings, such as its dependency on the unreliable
transport protocol UDP and the lack of security for large parts of transport protocol UDP and the lack of security for large parts of
its packet payload. RADIUS security is based on the MD5 algorithm, its packet payload. RADIUS security is based on the MD5 algorithm,
skipping to change at page 6, line 10 skipping to change at page 6, line 10
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 locally * Peer validation always includes a check on whether the locally
configured expected DNS name or IP address of the server that configured expected DNS name or IP address of the server that
is contacted matches its presented certificate. DNS names and is contacted matches its presented certificate. DNS names and
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 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.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.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 makes it possible to preserve this traditional RADIUS RADIUS/TLS supports multiple operation modes.
semantics by identifying a connecting client by the IP address which
initiated the TLS connection. In addition, it permits a much more In TLS-PSK operation, a client is uniquely identified by its TLS
fine-grained identification. The parameters of the TLS connection identifier.
can be attributed to the RADIUS packets inside the TLS connection.
An implementation of RADIUS/TLS should expose as many details of the In TLS-X.509 mode using fingerprints, a client is uniquely identified
TLS connection which belongs to an incoming RADIUS packet as possible by the fingerprint of the presented client certificate.
to the application layer to allow the administrator to define the
identification criteria which are applicable to his desired In TLS-X.509 with PKI infrastructure, a client is uniquely identified
operational model. In X.509 certificate operation, at least the by the serial number of the tuple (presented client
following parameters of the TLS connection should be exposed: certificate;Issuer).
Note well: having identified a connecting entity does not mean the
server necessarily wants to communicate with that client. E.g. if
the Issuer is not in a trusted set of Issuers, the server may decline
to perform RADIUS transactions with this client.
There are numerous trust models in PKI environments, and it is beyond
the scope of this document to define how a particular deployment
determines whether a client is trustworthy. Implementations which
want to support a wide variety of trust models should expose as many
details of the presented certificate to the administrator as possible
so that the trust model can be implemented by the administrator. As
a suggestion, at least the following parameters of the X.509 client
certificate should be exposed:
o Originating IP address o Originating IP address
o Certificate Fingerprint o Certificate Fingerprint
o Issuer o Issuer
o Subject o Subject
o all X509v3 Extended Key Usage o all X509v3 Extended Key Usage
o all X509v3 Subject Alternative Name o all X509v3 Subject Alternative Name
o all X509v3 Certificate Policies o all X509v3 Certificate Policies
In TLS-PSK operation, at least the following parameters of the TLS In TLS-PSK operation, at least the following parameters of the TLS
connection should be exposed: connection should be exposed:
o Originating IP address o Originating IP address
skipping to change at page 7, line 22 skipping to change at page 7, line 35
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 handle the following packet types from [RFC2865], RADIUS/TLS clients transmit the same packet types on the connection
[RFC2866], [RFC5176] on the connection they initiated (see they initiated as a RADIUS/UDP client would (see Section 3.3 (3) and
Section 3.3 (3) and (4) ): (4) ). E.g. they send
o send Access-Request
o send Accounting-Request
o send Status-Server
o send Disconnect-ACK o Access-Request
o send Disconnect-NAK o Accounting-Request
o send CoA-ACK o Status-Server
o send CoA-NAK o Disconnect-ACK
o receive Access-Challenge o Disconnect-NAK
o receive Access-Accept o ...
o receive Access-Reject and they receive
o Access-Accept
o receive Accounting-Response o Accounting-Response
o receive Disconnect-Request o Disconnect-Request
o receive CoA-Request o ...
RADIUS/TLS servers handle the following packet types from [RFC2865],
[RFC2866], [RFC5176] on the connections they serve to clients:
o receive Access-Request RADIUS/TLS servers transmit the same packet types on connections they
have accepted as a RADIUS/UDP server would. E.g. they send
o receive Accounting-Request o Access-Challenge
o receive Status-Server o Access-Accept
o receive Disconnect-ACK o Access-Reject
o receive Disconnect-NAK o Accounting-Response
o receive CoA-ACK o Disconnect-Request
o receive CoA-NAK o ...
o send Access-Challenge and they receive
o send Access-Accept o Access-Request
o send Access-Reject o Accounting-Request
o send Accounting-Response o Status-Server
o send Disconnect-Request o Disconnect-ACK
o send CoA-Request 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. 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
skipping to change at page 10, line 10 skipping to change at page 10, line 20
arrived. Due to the stream nature of TCP and TLS, this does not hold arrived. Due to the stream nature of TCP and TLS, this does not hold
true for RADIUS/TLS packet exchange. Instead, packet boundaries of true for RADIUS/TLS packet exchange. Instead, packet boundaries of
RADIUS packets that arrive in the stream are calculated by evaluating RADIUS packets that arrive in the stream are calculated by evaluating
the packet's Length field. Special care needs to be taken on the the packet's Length field. Special care needs to be taken on the
packet sender side that the value of the Length field is indeed packet sender side that the value of the Length field is indeed
correct before sending it over the TLS tunnel, because incorrect correct before sending it over the TLS tunnel, because incorrect
packet lengths can no longer be detected by a differing datagram packet lengths can no longer be detected by a differing datagram
boundary. See section 2.6.4 of [I-D.ietf-radext-tcp-transport] for boundary. See section 2.6.4 of [I-D.ietf-radext-tcp-transport] for
more details. more details.
(2) Within RADIUS [RFC2865], a shared secret is used for hiding (2) Within RADIUS/UDP [RFC2865], a shared secret is used for hiding
of attributes such as User-Password, as well as in computation of of attributes such as User-Password, as well as in computation of
the Response Authenticator. In RADIUS accounting [RFC2866], the the Response Authenticator. In RADIUS accounting [RFC2866], the
shared secret is used in computation of both the Request shared secret is used in computation of both the Request
Authenticator and the Response Authenticator. Since TLS provides Authenticator and the Response Authenticator. Since TLS provides
integrity protection and encryption sufficient to substitute for integrity protection and encryption sufficient to substitute for
RADIUS application-layer security, it is not necessary to configure a RADIUS application-layer security, it is not necessary to configure a
RADIUS shared secret. The use of a fixed string for the obsolete RADIUS shared secret. The use of a fixed string for the obsolete
shared secret eliminates possible node misconfigurations. shared secret eliminates possible node misconfigurations.
(3) RADIUS [RFC2865] uses different UDP ports for authentication, (3) RADIUS/UDP [RFC2865] uses different UDP ports for authentication,
accounting and dynamic authorisation changes. RADIUS/TLS allocates a accounting and dynamic authorisation changes. RADIUS/TLS allocates a
single port for all RADIUS packet types. Nevertheless, in RADIUS/TLS single port for all RADIUS packet types. Nevertheless, in RADIUS/TLS
the notion of a client which sends authentication requests and the notion of a client which sends authentication requests and
processes replies associated with it's users' sessions and the notion processes replies associated with it's users' sessions and the notion
of a server which receives requests, processes them and sends the of a server which receives requests, processes them and sends the
appropriate replies is to be preserved. The normative rules about appropriate replies is to be preserved. The normative rules about
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 [RFC2865] used 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.
(5) RADIUS [RFC2865] used 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.
4. Compatibility with other RADIUS transports 4. Compatibility with other RADIUS transports
skipping to change at page 13, line 38 skipping to change at page 13, line 44
(RADIUS)", RFC 2865, June 2000. (RADIUS)", RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", [RFC2866] Rigney, C., "RADIUS Accounting",
RFC 2866, June 2000. RFC 2866, June 2000.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre- [RFC4279] Eronen, P. and H. Tschofenig, "Pre-
Shared Key Ciphersuites for Shared Key Ciphersuites for
Transport Layer Security (TLS)", Transport Layer Security (TLS)",
RFC 4279, December 2005. RFC 4279, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The
Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346,
April 2006.
[RFC4785] Blumenthal, U. and P. Goel, "Pre- [RFC4785] Blumenthal, U. and P. Goel, "Pre-
Shared Key (PSK) Ciphersuites with Shared Key (PSK) Ciphersuites with
NULL Encryption for Transport Layer NULL Encryption for Transport Layer
Security (TLS)", RFC 4785, Security (TLS)", RFC 4785,
January 2007. January 2007.
[RFC4985] Santesson, S., "Internet X.509 [RFC4985] Santesson, S., "Internet X.509
Public Key Infrastructure Subject Public Key Infrastructure Subject
Alternative Name for Expression of Alternative Name for Expression of
Service Name", RFC 4985, Service Name", RFC 4985,
skipping to change at page 14, line 51 skipping to change at page 15, line 5
based Dynamic Peer Discovery for based Dynamic Peer Discovery for
RADIUS over TLS 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.
[RFC4346] Dierks, T. and E. Rescorla, "The
Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346,
April 2006.
[radsec-whitepaper] Open System Consultants, "RadSec - a [radsec-whitepaper] Open System Consultants, "RadSec - a
secure, reliable RADIUS Protocol", secure, reliable RADIUS Protocol",
May 2005, <http://www.open.com.au/ May 2005, <http://www.open.com.au/
radiator/radsec-whitepaper.pdf>. radiator/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 Improvements", Attacks: Insights and Improvements",
October 2006, <http:// October 2006, <http://
www.springerlink.com/content/ www.springerlink.com/content/
skipping to change at page 18, line 5 skipping to change at page 17, line 46
sent to a RadSec server just like they would to a UDP server. sent to a RadSec server just like they would to a UDP server.
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
The RADIUS Crypto-Agility Requirements (link to RFC once issued here)
defines numerous classification criteria for protocols that strive to
enhance the security of RADIUS. It contains mandatory (M) and
recommended (R) criteria which crypto-agile protocols have to
fulfill. The authors believe that the following assessment about the
crypto-agility properties of RADIUS/TLS are true.
By virtue of operating on the transport layer with TLS, the
cryptographically agile properties of TLS are inherited, and RADIUS/
TLS subsequently meets the following points:
(M) negotiation of cryptographic algorithms for integrity and auth
(M) negotiation of cryptographic algorithms for encryption
(M) replay protection
(M) define mandatory-to-implement cryptographic algorithms
(M) generate fresh session keys for use between client and server
(R) support for Perfect Forward Secrecy in session keys
(R) support X.509 certificate based operation
(R) support Pre-Shared keys
(R) support for confidentiality of the entire packet
(M/R) support Automated Key Management
The remainder of the requirements is discussed individually below in
more detail:
(M) "avoid security compromise, even in situations where the
existing cryptographic alogrithms used by RADIUS implementations
are shown to be weak enough to provide little or no security" -
The existing algorithm, based on MD5, is not of any significance
in RADIUS/TLS; its compromise does not compromise the outer
transport security.
(R) mandatory-to-implement alogrithms are to be NIST-Acceptable
with no deprecation date - The mandatory-to-implement algorithm is
TLS_RSA_WITH_3DES_EDE_CBC_SHA. This ciphersuite supports three-
key 3DES operation, which is classified as Acceptable with no
known deprecation date by NIST.
(M) demonstrate backward compatibility with RADIUS - There are
multiple implementations supporting both RADIUS and RADIUS/TLS,
and the translation between them.
(M) After legacy mechanisms have been compromised, secure
algorithms MUST be used, so that backward compatibility is no
longer possible - In RADIUS, communication between client and
server is always a manual configuration; after a compromise, the
legacy client in question can be de-configured by the same manual
configuration.
(M) indicate a willingness to cede change control to the IETF -
Change control of this protocol is with the IETF.
(M) be interoperable between implementations based purely on the
information in the specification - At least one implementation was
created exclusively based on this specification and is
interoperable with other RADIUS/TLS implementations.
(M) apply to all packet types - RADIUS/TLS operates on the
transport layer, and can carry all packet types.
(R) message data exchanged with Diameter SHOULD NOT be affected -
The solution is Diameter-agnostic.
(M) discuss any inherent assumptions - The authors are not aware
of any implicit assumptions which would be yet-unarticulated in
the draft
(R) provide recommendations for transition - The Security
Considerations section contains a transition path.
(R) discuss legacy interoperability and potential for bidding-down
attacks - The Security Considerations section contains an
corresponding discussion.
Summarizing, it is believed that this specification fulfills all the
mandatory and all the recommended requirements for a crypto-agile
solution and should thus be considered UNCONDITIONALLY COMPLIANT.
Authors' Addresses Authors' Addresses
Stefan Winter Stefan Winter
Fondation RESTENA Fondation RESTENA
6, rue Richard Coudenhove-Kalergi 6, rue Richard Coudenhove-Kalergi
Luxembourg 1359 Luxembourg 1359
LUXEMBOURG LUXEMBOURG
Phone: +352 424409 1 Phone: +352 424409 1
Fax: +352 422473 Fax: +352 422473
 End of changes. 42 change blocks. 
62 lines changed or deleted 161 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/