RADIUS Extensions Working Group                                S. Winter
Internet-Draft                                                   RESTENA
Intended status: Experimental                                M. McCauley
Expires: December 19, 2008 February 23, 2009                                           OSC
                                                               S. Venaas
                                                                 UNINETT
                                                           June 17,
                                                             K. Wierenga
                                                                   Cisco
                                                         August 22, 2008

              TLS encryption for RADIUS over TCP (RadSec)
                      draft-ietf-radext-radsec-00
                      draft-ietf-radext-radsec-01

Status of This Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 19, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008). February 23, 2009.

Abstract

   This document specifies security on the transport layer (TLS) for the
   RADIUS protocol [2] [RFC2865] when transmitted over TCP [9].
   [I-D.dekok-radext-tcp-transport].  This enables dynamic trust
   relationships between RADIUS servers.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Normative: Transport Layer Security for RADIUS over TCP  . . .  4
     2.1.  TCP port and packet types  . . . . . . . . . . . . . . . .  4
     2.1.  Operation
     2.2.  Connection Setup . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . .  5
   3.  Informative: Design Decisions  . . . . . . .  4
     2.2.  Ciphersuites and Compression Negotiation . . . . . . . . .  6
     2.3.  RADIUS Shared Secret Usage in RadSec
     3.1.  X.509 Certificate Considerations . . . . . . . . . . . . .  6
   3.  Comparison of Diameter vs. RadSec
     3.2.  Ciphersuites and Compression Negotiation Considerations  .  8
     3.3.  RADIUS Datagram Considerations . . . . . . . . . . . . . .  7  8
   4.  Diameter Compatibility . . . . . . . . . . . . . . . . . . . .  7  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9 10
     8.1.  Informative References . . . . . . . . . . . . . . . . . .  9 10
     8.2.  Normative References . . . . . . . . . . . . . . . . . . .  9 11
   Appendix A.  DNS NAPTR Peer Discovery  . . . . . . . . . . . . . . 10 12
   Appendix B.  Implementation Overview: Radiator . . . . . . . . . . 11 13
   Appendix C.  Implementation Overview: radsecproxy  . . . . . . . . 12 14

1.  Introduction

   The RADIUS protocol [2] [RFC2865] is a widely deployed authentication and
   authorisation protocol.  The supplementary RADIUS Accounting
   specification [3] [RFC2866] also provides accounting mechanisms, thus
   delivering a full AAA solution.  However, RADIUS is experiencing
   several shortcomings, such as its dependency on the unreliable
   transport protocol UDP and the lack of security for large parts of
   its packet payload.

   Several enhancements have been proposed to overcome RADIUS'
   limitations.  An IETF Standards Track protocol, Diameter [6], has
   been designed to provide an AAA protocol that should deprecate
   RADIUS.  However, given that current implementations of Diameter are
   either not freely accessible, or do not provide the flexibility of
   current  RADIUS deployments, or both, an intermediate solution that security is based on RADIUS but provides mechanisms to overcome many of its
   drawbacks the MD5 algorithm,
   which has been implemented by several vendors.  These
   implementations are interoperable and deployed in a world-wide
   wireless roaming infrastructure.  The protocol is called RadSec.
   This document describes version 2 of the RadSec protocol.  Version 1
   of RadSec is defined in the RadSec whitepaper [10].  The two
   currently existing implementations of RadSec version 2 are described
   in Appendix B and Appendix C. proven to be insecure.

   The main focus of RadSec is to provide a means to secure the
   communication between RADIUS/TCP peers on the transport layer.  The
   most important use of RadSec lies in roaming environments where
   RADIUS packets need to be transferred through different
   administrative domains and untrusted, potentially hostile networks.
   An example for a world-wide roaming environment that uses RadSec to
   secure communication is "eduroam", see [15].

   The new features [eduroam].

   There are multiple known attacks on the MD5 algorithm which is used
   in RADIUS to provide integrity protection and a limited
   confidentiality protection.  RadSec obsolete wraps the use of IP addresses entire RADIUS packet
   payload into a TLS stream and thus mitigates the risk of attacks on
   MD5.

   Because of the static trust establishment between RADIUS peers (IP
   address and shared secret) the only scalable way of creating a
   massive deployment of RADIUS-servers under control by different
   administrative entities is to introduce some form of a proxy chain to
   route the access requests to their home server.  This creates a lot
   of overhead in terms of possible points of failure, longer
   transmission times as well as middleboxes through which
   authentication traffic flows.  These middleboxes may learn privacy-
   relevant data while forwarding requests.  The new features in RadSec
   obsolete the use of IP addresses and shared MD5 secrets to identify
   other peers and thus allow the dynamic establishment of connections
   to peers that are not previously
   configured. configured, and thus makes it
   possible to avoid intermediate aggregation proxies.  The definition
   of lookup mechanisms is out of scope of this document, but an
   implementation of a DNS NAPTR lookup based mechanism exists and is
   described as an example lookup mechanism in Appendix A.

   Transitioning from a plain RADIUS infrastructure to a RadSec
   infrastructure is very easy, since the RADIUS packet payload is
   identical in both protocols.  Enabling RadSec can be done on a per-
   server basis.  Unlike in Diameter, the learning curve for a new
   protocol does not exist, which makes it almost trivial for an
   experienced RADIUS server administrator to switch to a RadSec-secured
   transport for RADIUS packets.

   The security layer does not require any new assignments of codepoints
   for the RADIUS protocol.  No new attributes are defined and no new
   packet codes are used.

1.1.  Requirements Language

   In this document, several words are used to signify the requirements
   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" in this document are to be interpreted as described in
   [1].
   [RFC2119].

1.2.  Terminology

   RadSec node: a RadSec client or server

   RadSec Client: a RadSec instance which initiates a new connection.

   RadSec Server: a RadSec instance which listens on a RadSec port and
   accepts new connections

2.  Normative: Transport Layer Security for RADIUS over TCP

2.1.  Operation

   Once the  TCP connection between two port and packet types

   The default destination port number for RadSec nodes is established, a
   TLS session is established.  At least TLSv1.1 [7] TCP/2083.  There
   are no separate ports for authentication, accounting and dynamic
   authorisation changes.  The source port is used.  Both arbitrary.

2.2.  Connection Setup

   RadSec nodes either mutually present a X.509 certificate which is verified

   1.  establish TCP connections as per [I-D.dekok-radext-tcp-transport]

   2.  negotiate TLS sessions according to [5] [RFC5246] or use a shared key authentication for its predecessor
       TLS which
   needs to be pre-configured out-of-band prior to the connection
   attempt. 1.1.  The list of following restrictions apply:

       *  When using X.509 certificates, RadSec servers SHOULD indicate
          their acceptable Certification Authorities that a node which acts as a
   server per section
          7.4.4 of [RFC5246] (see Section 3.1 (1) )

       *  When using X.509 certificates, the TLS Extension "Trusted CA
          Indication" from [RFC5246] or its TLS 1.1 predecessor SHOULD
          be used to indicate trusted CAs for the client (see
          Section 3.1 (2) )

       *  When using X.509 certificates, certificate validation is willing
          performed as per [RFC5280] or its TLS 1.1 predecessor.  The
          client MAY perform additional checks to accept accomodate for
          different trust models.

       *  The client MUST NOT negotiate cipher suites which only provide
          integrity protection.

       *  The cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be
          supported.

       *  The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and
          TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2
          (1) )

   3.  start exchanging RADIUS datagrams.  Note Section 3.3 (1) ).  The
       shared secret to compute the (obsolete) MD5 integrity checks and
       attribute encryption MUST be "radsec" (see Section 3.3 (2) ).

2.3.  RADIUS Datagrams

   Authentication, Accounting and Authorization packets are sent during
   according to the Certificate
   Request message following rules:

   RadSec clients handle the following packet types from [RFC2865],
   [RFC2866], [RFC5176] on the connection they initiated (see
   Section 3.3 (3) and (4) ):

   o  send Access-Request

   o  send Accounting-Request

   o  send Status-Server

   o  send Disconnect-ACK

   o  send Disconnect-NAK

   o  send CoA-ACK

   o  send CoA-NAK

   o  receive Access-Challenge

   o  receive Access-Accept

   o  receive Access-Reject

   o  receive Accounting-Response

   o  receive Disconnect-Request

   o  receive CoA-Request

   RadSec servers handle the following packet types from [RFC2865],
   [RFC2866], [RFC5176] on the connections they serve to clients:

   o  receive Access-Request
   o  receive Accounting-Request

   o  receive Status-Server

   o  receive Disconnect-ACK

   o  receive Disconnect-NAK

   o  receive CoA-ACK

   o  receive CoA-NAK

   o  send Access-Challenge

   o  send Access-Accept

   o  send Access-Reject

   o  send Accounting-Response

   o  send Disconnect-Request

   o  send CoA-Request

3.  Informative: Design Decisions

   This section explains the design decisions that led to the rules
   defined in the CertificateRequest struct (section 7.4.4 of
   [7]).  Rationale: previous section.

3.1.  X.509 Certificate Considerations

   (1) If a RadSec node acts as a client and is in possession of multiple certificates from
   different CAs (i.e. is part of multiple roaming consortia) and
   dynamic discovery is used, and the
   dynamic discovery mechanism possibly does not provide
   yield sufficient meta information to identify the server's roaming consortium, then consortium uniquely
   (e.g.  DNS discovery).  Subsequently, the client may not know by
   itself which client certificate to use for the TLS handshake.  Then
   it is necessary to for the server to signal which consortium it
   belongs to, and which certificates it expects.  If there is connecting to.

   The list no risk
   of Certification Authorities that a node which acts as a
   client confusing multiple roaming consortia, providing this information
   in the handshake is willing to accept can not be signaled within the TLS 1.1
   handshake.  This makes it impossible to select the right certificate
   if crucial.

   (2) If a RadSec node which is acting as a server for multiple roaming
   consortia (in is in possession of multiple certificates from
   different CAs)
   is contacted by a client.  This situation CAs (i.e. is likely part of multiple roaming consortia), it will
   need to change in TLS
   1.2, according select one of its certificates to [8].  "Trusted present to the RadSec
   client.  If the client sends the Trusted CA Indication" as Indication, this hint can
   make the server select the appropriate certificate and prevent a
   handshake failure.  Omitting this indication makes it impossible to
   deterministically select the right certificate in [8], section 6,
   SHOULD be used. this case.  If
   there is no risk of confusing multiple roaming consortia, providing
   this indication in the handshake is not crucial.

   (3) When using X.509 certificate validation, peer validation always
   includes a check on whether the DNS name or the IP address of the
   server that is contacted matches its certificate.  When a RadSec peer
   establishes a new connection (acts as a client) to another peer, the
   following rules of precedence are used during validation:

   o  If the client expects a certain fully qualified domain name (FQDN)
      and the presented certificate contains both at least one instance
      of the subjectAltName field with type dNSName and a Common Name,
      then the certificate is considered a match if any one of those
      subjectAltName fields matches the expected FQDN.  The Common Name
      field is not evaluated in this case.

   o  If the client expects a certain fully qualified domain name (FQDN)
      and the presented certificate does not contain any subjectAltName
      field with type dNSName, then the certificate is considered a
      match if the Common Name field matches the expected FQDN.

   o  If the client expects a certain IP address and the presented
      certificate contains both at least one instance of the
      subjectAltName field with type iPAddr and a Common Name, then the
      certificate is considered a match if any one of those
      subjectAltName fields matches the expected IP address.  The Common
      Name field is not evaluated in this case.

   o  If the client expects a certain IP address and the presented
      certificate does not contain any subjectAltName field with type
      iPAddr, then the certificate is considered a match if the Common
      Name field matches the expected IP address.
   Further restrictions on the certificate MAY be verified, depending on
   the trust fabric of the peering agreement.

   (4) If dynamic peer resolution is used, the above verification steps MAY
   may not be sufficient to ensure that a connecting peer is authorised
   to perform user authentications.  In these cases, the trust fabric
   SHOULD NOT
   cannot depend on untrusted peer resolution authentication methods like DNS DNSSEC to identify and authorise
   RadSec nodes.  Instead, the operators  The RadSec nodes also need to be properly authorised.
   Operators of the a RadSec infrastructure SHOULD should define their own
   authorisation trust model and apply this model to the certificates
   after they have passed the standard validity checks above.  Current
   RadSec implementations offer varying degrees of versatility for
   defining criteria which certificates to accept.

   NOTE WELL: None of the current

3.2.  Ciphersuites and Compression Negotiation Considerations

   RadSec implementations provide configuration
   options for using TLS with pre-shared keys.  However, the underlying
   libraries support it, so need not necessarily support for that should be implementable
   easily.

   After the all TLS session is established, RADIUS packet payloads
   ciphersuites listed in [RFC5246]. Not all TLS ciphersuites
   are
   exchanged over the encrypted supported by available TLS tunnel.  In plain RADIUS, the packet
   size can tool kits and licenses may be determined by evaluating the size of the datagram that
   arrived.  Due to the stream nature required
   in some cases.  The existing implementations of TCP and TLS, this does not hold
   true for RadSec packet exchange.  Instead, packet boundaries use OpenSSL as
   cryptographic backend, which supports all of
   RADIUS packets that arrive the ciphersuites listed
   in the stream are calculated by evaluating rules in the packet's Length field.  Special care MUST be normative section.

   The TLS cphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to-
   implement according to [RFC5246] and thus has to be supported by
   RadSec nodes.

   The two other ciphersuites in the normative section
   (TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA) are
   widely implemented in TLS toolkits and are considered good practice
   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

   (1) After the TLS session is established, RADIUS packet payloads are
   exchanged over the encrypted TLS tunnel.  In plain RADIUS, the packet
   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
   true for RadSec packet exchange.  Instead, packet boundaries of
   RADIUS packets that arrive in the stream are calculated by evaluating
   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
   correct before sending it over the TLS tunnel, because incorrect
   packet lengths can no longer be detected by a differing datagram
   boundary.

2.2.  Ciphersuites and Compression Negotiation

   RadSec implementations need not necessarily support all TLS
   ciphersuites listed in [7]. Not all TLS ciphersuites are supported by
   available TLS tool kits and licenses may be required in some cases.
   The existing implementations of RadSec use OpenSSL as cryptographic
   backend, which supports all of the ciphersuites listed in the rules
   below:

   To ensure interoperability, RadSec clients and servers MUST
   support the TLS [7] mandatory-to-implement ciphersuite:
   TLS_RSA_WITH_3DES_EDE_CBC_SHA.

   In addition, RadSec servers SHOULD support and be able to
   negotiate all of the following TLS ciphersuites:
   o  TLS_RSA_WITH_RC4_128_MD5
   o  TLS_RSA_WITH_RC4_128_SHA
   o  TLS_RSA_WITH_AES_128_CBC_SHA
   In addition, RadSec clients SHOULD support the following
   TLS ciphersuites [4]:
   o  TLS_RSA_WITH_AES_128_CBC_SHA
   o  TLS_RSA_WITH_RC4_128_SHA
   Since TLS supports ciphersuite negotiation, peers completing the
   TLS negotiation will also have selected a ciphersuite, which
   includes encryption and hashing methods.

   TLS also supports compression as well as ciphersuite
   negotiation. During the RadSec conversation the client and server MAY
   negotiate compression.  However, a peer MUST continue the
   conversation even if the other peer rejects compression.

2.3.  RADIUS Shared Secret Usage in RadSec

   (2) Within RADIUS [2], [RFC2865], a shared secret is used for hiding
   of attributes such as User-Password, as well as in computation of
   the Response Authenticator.  In RADIUS accounting [3], [RFC2866], the
   shared secret is used in computation of both the Request
   Authenticator and the Response
   Authenticator.

   Since in RADIUS a shared secret is used to provide confidentiality
   as well as integrity protection and authentication, the use of TLS
   ciphers which encrypt the stream payload in RadSec can provide
   security services sufficient to substitute for RADIUS application-
   layer security. Therefore, where TLS ciphers that provide encryption
   are used, it will not be necessary to configure a RADIUS shared
   secret.

   Then, the secret shared between two RadSec peers MAY not
   be configured. In this case, the shared secret defaults to "radsec"
   (without the quotes). However, if the RadSec nodes negotiated a TLS
   cipher that provides integrity assurance only, the connection MUST be
   configured with a non-default RADIUS shared secret.

3.  Comparison of Diameter vs. RadSec

   The feature set in the Diameter Base Protocol is almost a superset of
   the features present in RadSec.  Sophisticated mechanisms for
   keepalive, reliable transmission and payload security exist.  The
   reason for specifying a short-term intermediate solution as opposed
   to using Diameter at the moment are the lack of suitable, publicly
   available Response Authenticator.  Since TLS provides
   integrity protection and versatile implementations.

   Typically, encryption sufficient to substitute for
   RADIUS servers do application-layer security, it is not only support the RADIUS protocol
   itself, but also provide interfaces necessary to configure a wide variety
   RADIUS shared secret.  The use of backends
   (credential stores) to actually verify a user's credentials.  In
   highly heterogeneous environments like eduroam, where a lot of
   different backends are in use by fixed string for the participating home servers
   (OpenLDAP, Novell eDirectory, ActiveDirectory, SQL databases or plain
   text files, just to name a few), such versatility is obsolete
   shared secret eliminates possible node misconfigurations.

   (3) RADIUS [RFC2865] uses different UDP ports for authentication,
   accounting and dynamic authorisation changes.  RadSec allocates a requirement.
   Current Diameter server implementations focus on
   single port for all RADIUS packet types.  Also in RadSec, the validation notion
   of a
   small set of EAP methods (mostly EAP-SIM client which sends authentication requests and EAP-TLS) processes replies
   associated with it's users' sessions and
   consequently on a small set the notion of backends to verify these credentials.

   A further requirement in environments like eduroam is affordability.
   Public institutions like schools and universities often face tight
   budgets, a server which
   receives requests, processes them and so an open source implementation of Diameter would be
   desirable (just as FreeRADIUS sends the appropriate replies
   is to be preserved.  The normative rules about acceptable packet
   types for clients and servers mirror the packet flow behaviour from
   RADIUS.

   (4) RADIUS protocol).
   Unfortunately, the few Open Source Software implementations of the
   Diameter protocol like OpenDiameter [12] or JDiameter [13] only
   provide a set of libraries, but no server at all.

   Diameter's ability [RFC2865] used negative ICMP responses to resolve peers dynamically is limited a newly
   allocated UDP port to using
   either SLPv2 or DNS, whereas RadSec allows arbitrary signal that a peer resolution
   mechanisms.  This greater amount RADIUS server does not
   support reception and processing of flexibility can pay off in many
   roaming federations.  In eduroam's case, a central SAML-based meta
   data repository ("eduGAIN-MDS") is the packet types in place which is able [RFC5176].
   These packet types are listed as to provide
   peer addresses.  Using be received in RadSec
   implementations.  Note well: it is possible not required for an implementation
   to resolve a peer's
   address through actually process these packet types.  It is sufficient that upon
   receiving such a meta data system, whereas with Diameter it packet, an unconditional NAK is
   not possible sent back to use this repository natively.
   indicate that the action is not supported.

4.  Diameter Compatibility

   Since RadSec is only a new transport profile for RADIUS,
   compatibility of RadSec - Diameter [RFC3588] vs. RADIUS [RFC2865] -
   Diameter [RFC3588] is identical.  The considerations regarding
   payload size in [9] [I-D.dekok-radext-tcp-transport] apply.

5.  Security Considerations

   The computational resources to establish a TLS tunnel are
   significantly higher than simply sending mostly unencrypted UDP
   datagrams.  Therefore, clients connecting to a RadSec node will more
   easily create high load conditions and a malicious client might
   create a Denial-of-Service attack more easily.

   In the case of dynamic peer discovery, a RadSec 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
   RadSec 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).

   Some TLS ciphersuites only provide integrity validation of their
   payload, and provide no encryption.  When such ciphersuites are
   negotiated in a RadSec TLS handshake, the only means of protecting
   sensitive payload contents is  This specification forbids the RADIUS shared secret.  If
   use of such ciphersuites.  Since the RADIUS payload's shared secret
   is set fixed and well-known, failure to comply with this requirement will
   expose the default "radsec" and a non-
   encrypting TLS ciphersuite is used, implementations should either
   forbid transmitting entire datagram payload over this connection completely or at
   least issue a warning in plain text, including User-
   Password, to whatever logging destination is configured
   by the administrator. intermediate IP nodes.

6.  IANA Considerations

   This document has no actions for IANA.  The TCP port 2083 was already
   previously assigned by IANA for RadSec.  The Status-Server  No new RADIUS attributes or
   packet was
   already assigned by IANA for [2]. codes are defined.

7.  Acknowledgements

   RadSec version 1 was first implemented by Open Systems Consultants,
   Currumbin Waters, Australia, for their "Radiator" RADIUS server
   product.
   product (see [radsec-whitepaper]).

   Funding and input for the development of this Internet Draft was
   provided by the European Commission co-funded project "GEANT2" [16]
   [geant2] and further feedback was provided by the TERENA Task Force
   Mobility
   [17]. [terena].

8.  References

8.1.  Informative References

   [1]

   [RFC2119]                         Bradner, S., "Key words for use in
                                     RFCs to Indicate Requirement
                                     Levels", BCP 14, RFC 2119,
                                     March 1997.

   [radsec-whitepaper]               Open System Consultants, "RadSec -
                                     a secure, reliable RADIUS
                                     Protocol", May 2005, <http://
                                     www.open.com.au/radiator/
                                     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
                                     Homepage", 2007, <http://
                                     software.uninett.no/radsecproxy/>.

   [eduroam]                         Trans-European Research and
                                     Education Networking Association,
                                     "eduroam Homepage", 2007,
                                     <http://www.eduroam.org/>.

   [geant2]                          Delivery of Advanced Network
                                     Technology to Europe, "European
                                     Commission Information Society and
                                     Media: GEANT2", 2008,
                                     <http://www.geant2.net/>.

   [terena]                          TERENA, "Trans-European Research
                                     and Education Networking
                                     Association", 2008,
                                     <http://www.terena.org/>.

8.2.  Normative References

   [2]

   [RFC2865]                         Rigney, C., Willens, S., Rubens,
                                     A., Simpson, W., and S. Willens, W. Simpson, "Remote
                                     Authentication Dial In User Service
                                     (RADIUS)", RFC 2865, June 2000.

   [3]

   [RFC2866]                         Rigney, C., "RADIUS Accounting",
                                     RFC 2866, June 2000.

   [4]   Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
         Transport Layer Security (TLS)", RFC 3268, June 2002.

   [5]

   [RFC5280]                         Cooper, D., Santesson, S., Farrell,
                                     S., Boeyen, S., Housley, R., and T. W.
                                     Polk, "Internet X.509 Public Key
                                     Infrastructure Certificate and
                                     Certificate Revocation List (CRL)
                                     Profile", RFC 5280, May 2008.

   [6]

   [RFC5176]                         Chiba, M., Dommety, G., Eklund, M.,
                                     Mitton, D., and B. Aboba, "Dynamic
                                     Authorization Extensions to Remote
                                     Authentication Dial In User Service
                                     (RADIUS)", RFC 5176, January 2008.

   [RFC3588]                         Calhoun, P., Laughney, J., Arkko, Loughney, J., Guttman,
                                     E., and G. Zorn, G., and J. Arkko,
                                     "Diameter Base Protocol", RFC 3588,
                                     September 2003.

   [7]

   [RFC5246]                         Dierks, T. and E. Rescorla, "The
                                     Transport Layer Security (TLS)
                                     Protocol Version 1.1", 1.2", RFC 4346, April 2006.

   [8]   Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions:
         Extension Definitions", February 2008, <http://www.ietf.org/
         internet-drafts/draft-ietf-tls-rfc4366-bis-02.txt>.

   [9]   Winter, S., "Reliable Transport Profile for RADIUS", 5246,
                                     August 2008.

   [I-D.dekok-radext-tcp-transport]  DeKok, A., "RADIUS Over TCP",
                                     draft-dekok-radext-tcp-transport-00
                                     (work in progress), July 2008,
         <http://www.ietf.org/internet-drafts/
         draft-ietf-radext-radius-tcp-00.txt>.

   [10]  Open System Consultants, "RadSec - a secure, reliable RADIUS
         Protocol", May 2005,
         <http://www.open.com.au/radiator/radsec-whitepaper.pdf>.

   [11]  Open System Consultants, "Radiator Radius Server - Installation
         and Reference Manual", 2006,
         <http://www.open.com.au/radiator/ref.html>.

   [12]  Open Diameter Project, "Open Diameter", 2006,
         <http://www.opendiameter.org/>.

   [13]  Svenson, E., "JDiameter Project Homepage", 2006,
         <https://jdiameter.dev.java.net/>.

   [14]  Venaas, S., "radsecproxy Project Homepage", 2007,
         <http://software.uninett.no/radsecproxy/>.

   [15]  Trans-European Research and Education Networking Association,
         "eduroam Homepage", 2007, <http://www.eduroam.org/>.

   [16]  Delivery of Advanced Network Technology to Europe, "European
         Commission Information Society and Media: GEANT2", 2008,
         <http://www.geant2.net/>.

   [17]  TERENA, "Trans-European Research and Education Networking
         Association", 2008, <http://www.terena.org/>. 2008.

Appendix A.  DNS NAPTR Peer Discovery

   The following text is quoted from the file goodies/dnsroam.cfg in the
   Radiator distribution; further documentation of the <AuthBy DNSROAM>
   feature in Radiator can be found at [11]. [radiator-manual].  It describes
   an algorithm to retrieve the RadSec route information from the global
   DNS using NAPTR and SRV records.  The input of the algorithm is the
   realm part of the user name.

   The following algorithm is used to discover a target server from a
   Realm using DNS:

   1.  Look for NAPTR records for the Realm.

   2.  For each NAPTR found record, examine the Service field and use
       that to determine the transport protocol and TLS requirements for
       the server.  The Service field starts with 'AAA' for insecure and
       'AAAS' for TLS secured.  The Service field contains '+RADSECS'
       for RadSec over SCTP, '+RADSECT' for RadSec over TCP or '+RADIUS'
       for RADIUS protocol over UDP.  The most common Service field you
       will see will be 'AAAS+RADSECT' for TLS secured RadSec over TCP.

   3.

       A.  If the NAPTR has the 'S' flag, look for SRV records for the
           name.  For each SRV record found, note the Port number and
           then look for A and AAAA records corresponding to the name in
           the SRV record.

       B.  If the NAPTR has the 'A' flag, look for a A and AAAA records
           for the name.

   4.  If no NAPTR records are found, look for A and AAAA records based
       directly on the realm name.  For example, if the realm is
       'examplerealm.edu', it looks for records such as
       '_radsec._tcp.examplerealm.edu', '_radsec._sctp.examplerealm.edu'
       and '_radius._udp.examplerealm.edu',

   5.  All A and AAAA records found are ordered according to their Order
       and Preference fields.  The most preferable server address is
       used as the target server address, along with any other server
       attributes discovered from DNS.  If no SRV record was found for
       the address, the DNSROAM configured Port is used.

   For example, if the User-Name realm was 'examplerealm.edu', and DNS
   contained the following records:

      examplerealm.edu.  IN NAPTR 50 50 "s" "AAAS+RADSECT" ""
      _radsec._tcp.examplerealm.edu.

      _radsec._tcp.examplerealm.edu.  IN SRV 0 10 2083
      radsec.examplerealm.edu.

      radsec.examplerealm.edu.  IN AAAA 2001::202:44ff:fe0a:f704

   Then the target selected would be a RadSec server on port 2083 at
   IPv6 address 2001::202:44ff:fe0a:f704.  The connection would be made
   over TCP/IP, and TLS encryption would be used.  This complete
   specification of the realm is the most flexible and is recommended.

Appendix B.  Implementation Overview: Radiator

   Radiator implements the RadSec protocol for proxying requests with
   the <Authby RADSEC> and <ServerRADSEC> clauses in the Radiator
   configuration file.

   The <AuthBy RADSEC> clause defines a RadSec client, and causes
   Radiator to send RADIUS requests to the configured RadSec server
   using the RadSec protocol.

   The <ServerRADSEC> clause defines a RadSec server, and causes
   Radiator to listen on the configured port and address(es) for
   connections from <Authby RADSEC> clients.  When an <Authby RADSEC>
   client connects to a <ServerRADSEC> server, the client sends RADIUS
   requests through the stream to the server.  The server then services
   the request in the same was as if the request had been received from
   a conventional UDP RADIUS client.

   Radiator is compliant to version 2 of RadSec if the following options
   are used:

      <AuthBy RADSEC>

      *  Protocol tcp

      *  UseTLS

      *  TLS_CertificateFile

      <ServerRADSEC>

      *  Protocol tcp

      *  UseTLS
      *  TLS_RequireClientCert

   As of Radiator 3.15, the default shared secret for RadSec connections
   is "mysecret" (without quotes).  The implementation uses TCP
   keepalive socket options, but does not send Status-Server packets.
   Once established, TLS connections are kept open throughout the server
   instance lifetime.

Appendix C.  Implementation Overview: radsecproxy

   The RADIUS proxy named radsecproxy was written in order to allow use
   of RadSec in current RADIUS deployments.  This is a generic proxy
   that supports any number and combination of clients and servers,
   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
   RadSec is used on the wire, however as a generic proxy it can be used
   in other circumstances as well.

   The configuration file consists of client and server clauses, where
   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
   transport.  For RadSec the default shared secret "mysecret" (without
   quotes), the same as Radiator, is used.  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
   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
   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
   multiple TLS clauses may be to present one certificate to clients and
   another to servers.

   If any RadSec (TLS) clients are configured, the proxy will at startup
   listen on port 2083, as assigned by IANA for the OSC RadSec
   implementation.  An alternative port may be specified.  When a client
   connects, the client certificate will be verified, including checking
   that the configured FQDN or IP address matches what is in the
   certificate.  Requests coming from a RadSec client are treated
   exactly like requests from UDP clients.

   The proxy will at startup try to establish a TLS connection to each
   (if any) of the configured RadSec (TLS) servers.  If it fails to
   connect to a server, it will retry regularly.  There is some back-off
   where it will retry quickly at first, and with longer intervals
   later.  If a connection to a server goes down it will also start
   retrying regularly.  When setting up the TLS connection, the server
   certificate will be verified, including checking that the configured
   FQDN or IP address matches what is in the certificate.  Requests are
   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
   server if enabled for that particular server.  Status-Server requests
   are always responded to.

   This RadSec implementation has been successfully tested together with
   Radiator.  It is a freely available open-source implementation.  For
   source code and documentation, see [14]. [radsecproxy-impl].

Authors' Addresses

   Stefan Winter
   Fondation RESTENA
   6, rue Richard Coudenhove-Kalergi
   Luxembourg  1359
   LUXEMBOURG

   Phone: +352 424409 1
   Fax:   +352 422473
   EMail: stefan.winter@restena.lu
   URI:   http://www.restena.lu.

   Mike McCauley
   Open Systems Consultants
   9 Bulbul Place
   Currumbin Waters  QLD 4223
   AUSTRALIA

   Phone: +61 7 5598 7474
   Fax:   +61 7 5598 7070
   EMail: mikem@open.com.au
   URI:   http://www.open.com.au.

   Stig Venaas
   UNINETT
   Abels gate 5 - Teknobyen
   Trondheim  7465
   NORWAY

   Phone: +47 73 55 79 00
   Fax:   +47 73 55 79 01
   EMail: stig.venaas@uninett.no
   URI:   http://www.uninett.no.

   Klaas Wierenga
   Cisco Systems International BV
   Haarlerbergweg 13-19
   Amsterdam  1101 CH
   The Netherlands

   Phone: +31 (0)20 3571752
   Fax:
   EMail: kwiereng@cisco.com
   URI:   http://www.cisco.com.

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgements

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Acknowledgement

   This document was produced using xml2rfc v1.32 v1.33 (of
   http://xml.resource.org/) from a source in RFC-2629 XML format.