[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

Network Working Group                                      J. Howlett
Internet Draft                                              JANET(UK)
Intended status: Informational                               S. Hartman
Expires: January 2011                                Painless Security
                                                          July 5, 2010



                 Key Negotiation Protocol for RadSec (KNP)
                      draft-howlett-radsec-knp-00.txt


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, except to publish it
   as an RFC and to translate it into languages other than English.

   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 January 5, 2011.







Howlett                Expires January 5, 2011                [Page 1]


Internet-Draft   Key Negotiation Protocol for RadSec         July 2010


Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   RadSec provides a means to secure the communication between a RADIUS
   client and server on the transport layer by using a TLS cipher-suite.
   This avoids the security weaknesses inherent in RADIUS' use of the
   MD5 algorithm.

   The Key Negotiation Protocol for RadSec enables a RADIUS client and
   RADIUS server to derive a key that can be used with a TLS PSK
   ciphersuite and applied with a RadSec connection.

Table of Contents


   1. Introduction ................................................ 3
   2. Conventions used in this document                                            ............................ 4
   3. Motivation .................................................. 4
   4. The KNP Actors .............................................. 5
   5. Relationships With Other Protocols                                             ........................... 6
      5.1. Relationship to GSS-API and EAP ......................... 6
      5.2. Relationship to AAA                                   ..................................... 7
      5.3. Relationship to HTTP Negotiate .......................... 7
   6. Key Negotiation Protocol                                   ..................................... 7
      6.1. Invocation by RADIUS Client                                           ............................. 7
      6.2. Discovery of the RADIUS Server and KNP Endpoint                                                              .......... 8
      6.3. Trust Establishment                                   ..................................... 8
         6.3.1. Client and Introducer                                          .............................. 9
         6.3.2. Server and Introducer                                          .............................. 9
         6.3.3. Server to Client                                     .................................. 10
         6.3.4. Client to Server                                     .................................. 10
      6.4. Keying ................................................ 10
      6.5. TLS Encryption Negotiation                                          ............................. 11
   7. Context and PSK Management                                     .................................. 11
   8. Security Considerations                                  ..................................... 11
   9. IANA Considerations ........................................ 11


Howlett                Expires January 5, 2011                [Page 2]


Internet-Draft   Key Negotiation Protocol for RadSec         July 2010


   10. References ................................................ 11
      10.1. Normative References                                     .................................. 11
      10.2. Informative References                                       ................................ 12
   11. Acknowledgments ........................................... 12

1. Introduction

   TLS encryption for RADIUS (RadSec) [RADSEC] provides a means to
   secure the communication between a RADIUS [RFC2865] client and server
   on the transport layer by using a TLS [RFC5246] cipher-suite. This
   avoids the security weaknesses inherent in RADIUS' use of the MD5
   algorithm. It may mitigate the need for proxies in large-scale
   federated RADIUS environments, which can result in more points of
   failure, longer transmission times and exposure of privacy-sensitive
   information.

   RadSec mandates the use of one of the [RFC5246] ciphersuites and
   recommends the use of two other ciphersuites specified in that
   document. However any ciphersuite, including the TLS Pre-Shared Key
   (PSK) ciphersuites [RFC4279], may be used providing that it supports
   encryption.

   The Key Negotiation Protocol (KNP) provides two facilities.

   1. It enables a RADIUS client and RADIUS server to derive a
      credential that can be used with a TLS PSK ciphersuite applied to
      a RadSec connection between these peers. This credential is
      obtained as a result of an EAP authentication between the RADIUS
      client, a trusted third-party EAP server known as the Introducer
      and the RADIUS server acting as an EAP pass-through authenticator.

   2. It enables a RADIUS client and RADIUS server to derive an EAP
      credential that the client may subsequently use to authenticate
      against that RADIUS server, now acting as Introducer, via a second
      RADIUS server acting as an EAP pass-through authenticator. This
      credential may be used to establish a TLS PSK (using facility 1
      above); or, through the iterative application of this facility, to
      establish yet another credential with another RADIUS server.

   In summary, the first facility enables a RADIUS client and server to
   establish trust by means of a trusted third-party Introducer. The
   second facility enables a RADIUS client to establish an Introducer
   which it might subsequently use the first facility against; or, in an
   iterative manner, repeat the second facility to establish yet another
   Introducer.




Howlett                Expires January 5, 2011                [Page 3]


Internet-Draft   Key Negotiation Protocol for RadSec         July 2010


   Note to reader: this document currently only documents the first of
   these facilities. The second facility will be documented in a later
   revision.

   The composition of these two facilities enables a RADIUS client to
   dynamically establish a trust relationship with a RADIUS server in
   the absence of any pre-existing relationship, providing that there
   exists a chain of one or more intermediate Introducers.

   Conceptually the role of an Introducer as a trust broker is not
   dissimilar to that of a conventional AAA proxy. The key difference is
   that the trust path between the RADIUS client and server does not
   need to bear any resemblance to the transit path taken by the AAA
   messages between the RADIUS client and server.

2. Conventions used in this document

   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 RFC 2119 [RFC2119].

3. Motivation

   The KNP is motivated by the following requirements:

   o Improved security while using a familiar credential technology

   RADIUS traditionally uses shared secrets to establish trust between
   RADIUS peers. For some AAA operational models it may be more
   convenient to continue using secrets rather than introduce a new
   credential technology (such as X.509 certificates) when transitioning
   to the use of TLS encryption.

   o Agnosticism with respect to credential technology

   In complex federated AAA environments it may often be convenient not
   to impose any particular credential technology or trust anchor to
   establish trust between RADIUS peers. In other words, it may be
   desirable for RADIUS peers in different administrative domains to
   establish trust in the absence of a common understanding of their
   respective credential technologies or trust anchors.

   This agnosticism may improve interoperability within, and facilitate
   the scaling of, large heterogeneous AAA environments where it may be
   difficult - for technical or administrative reasons - to impose
   support for a common (or even a small number of) technologies or
   trust anchors.


Howlett                Expires January 5, 2011                [Page 4]


Internet-Draft   Key Negotiation Protocol for RadSec         July 2010


   o Online trust management

   Similarly, the use of a variety of different trust anchors and
   credential technologies may impede essential trust management
   functions such as timely revocation. In complex federated AAA
   environments, it would be desirable to permit online trust management
   in a way that is independent of the underlying credential technology.

4. The KNP Actors

   The KNP does not require the RADIUS client and RADIUS server to share
   a trust relationship. Instead, it only requires that these parties
   share a trust relationship with a mutually trusted third party. In
   the KNP, this party is known as the "Introducer".

   Figure 1 below depicts the trust relationships for a RADIUS client,
   RADIUS server and the Introducer before the KNP has been invoked.

                                Introducer
                                    /\
                                   /  \
                                  /    \
                            RADIUS      RADIUS
                            Client      Server

                                Figure 1

   Figure 2 below depicts the new trust relationship between the RADIUS
   client, RADIUS server and the Introducer after the KNP has been
   invoked.

                                Introducer
                                    /\
                                   /  \
                                  /    \
                            RADIUS------RADIUS
                            Client      Server

                                Figure 2

   Figure 3 below depicts the flow of RADIUS packets from the RADIUS
   client to the RADIUS server using the new trust relationship.







Howlett                Expires January 5, 2011                [Page 5]


Internet-Draft   Key Negotiation Protocol for RadSec         July 2010


                                Introducer



                            RADIUS ---> RADIUS
                            Client      Server

                                Figure 3

5. Relationships With Other Protocols

   The KNP builds on a variety of protocols. This section describes the
   relationship of KNP to these.

5.1. Relationship to GSS-API and EAP

   The KNP builds on the GSS-API [RFC2743] framework, the GSS EAP
   mechanism [GSSEAP] and EAP [RFC3748]. The RADIUS client, acting as
   the GSS initiator and EAP peer, establishes a GSS-API security
   context with the RADIUS server, acting as the GSS acceptor and EAP
   authenticator, by reference to an EAP server that acts as the
   Introducer.

   The KNP enables all three parties - RADIUS client, RADIUS server and
   Introducer - to establish a common view of their mutual relationships
   as described by the names and keys that the KNP generates.

   The RADIUS client must possess an EAP credential for the introducer,
   allowing mutual authentication of both parties when applied with an
   appropriate EAP method.

   Figure 4 below depicts the relationships between these entities:

                                Introducer
                                    /\
                                   /  \
                                  /    \
                            RADIUS      RADIUS
                            Client      Server
                     (wielding EAP
                    credential for
                   the introducer)

                                Figure 4





Howlett                Expires January 5, 2011                [Page 6]


Internet-Draft   Key Negotiation Protocol for RadSec         July 2010


5.2. Relationship to AAA

   The RADIUS server uses an AAA protocol to forward the EAP transaction
   to the Introducer.

   The RADIUS server must possess an AAA credential for the Introducer,
   allowing mutual authentication of both parties.

   Figure 5 below depicts the relationships between these entities:

                                Introducer
                                    /\
                                   /  \
                                  /    \
                            RADIUS      RADIUS
                            Client      Server
                     (wielding EAP      (wielding AAA
                    credential for      credential for
                   the Introducer)      the Introducer)

                                Figure 5

   The Introducer is always a single system entity: the EAP server.
   However, the AAA link between the RADIUS server and Introducer may
   not be direct, and instead may be composed of one or more proxies.

   For the purposes of KNP, the RADIUS server and Introducer must have
   equivalent or greater trust in any intermediate proxies than they do
   with each other.

5.3. Relationship to HTTP Negotiate

   The GSS EAP mechanism is transported using the HTTP Negotiate
   authentication scheme [RFC4559] between the RADIUS client and the
   RADIUS server's KNP endpoint.

6. Key Negotiation Protocol

   This section describes the KNP.

6.1. Invocation by RADIUS Client

   The KNP is invoked when the RADIUS client creates or receives (in the
   case that it is also a proxy) a RADIUS message which must be
   forwarded towards a RADIUS server but for which the RADIUS client
   lacks a PSK. For example:



Howlett                Expires January 5, 2011                [Page 7]


Internet-Draft   Key Negotiation Protocol for RadSec         July 2010


   o The RADIUS client may not have any local configuration for the
      RADIUS server.

   o The RADIUS client may have a cached PSK for the RADIUS server and
      may have already attempted a RADIUS over TLS connection, but this
      has been refused by the RADIUS server; possibly because the RADIUS
      server has deleted the key.

6.2. Discovery of the RADIUS Server and KNP Endpoint

   The RADIUS client first selects a RADIUS server. Implementations MUST
   support the use of Dynamic Peer Discovery [RADDSC], but MAY use any
   selection algorithm.

   Having selected a RADIUS server and obtained its network location,
   the RADIUS client MUST attempt to establish an HTTP [RFC2616]
   connection with the RADIUS server's KNP end-point.

   This specification defines the SRV prefix "_knp._tcp". This MAY be
   used to describe the network location of the KNP endpoint.
   Implementations MUST support the use of this SRV RR. The label used
   for this record is the RADIUS server.

   Example:

     _knp._tcp.radsec.example.com.  IN SRV 0 10 TODO knp.example.com.

   TODO: obtain a port.

6.3. Trust Establishment

   It is essential that all three actors - RADIUS Client, Server and
   Introducer - are able to validate each other's respective claims to
   their names. These are determined using different processes for each
   relationship, and are summarised in Figure 6 below.













Howlett                Expires January 5, 2011                [Page 8]


Internet-Draft   Key Negotiation Protocol for RadSec         July 2010


   +===============+===============+==================+===============+
   |    Subject    | Relying Party |     Process      | Evidence from |
   +===============+===============+==================+===============+
   | RADIUS Client |  Introducer   |     EAP GSS      |  EAP method   |
   +---------------+---------------+  authentication  | w/ qualifying |
   |  Introducer   | RADIUS Client | (section 6.3.1. )|Security Claims|
   +===============+===============+==================+===============+
   |  Introducer   | RADIUS Server |       AAA        |      AAA      |
   +---------------+---------------+  authentication  |     shared    |
   | RADIUS Server |  Introducer   | (section Error! Reference source
   not found.)|     secret    |
   +===============+===============+==================+===============+
   |    RADIUS     |     RADIUS    | Channel bindings | Assertion by  |
   |    Server     |     Client    | (section 6.3.3. )|  Introducer   |
   +---------------+---------------+------------------+---------------+
   |    RADIUS     |     RADIUS    | RADIUS attribute | Assertion by  |
   |    Client     |     Server    | (section 6.3.4. )|  Introducer   |
   +===============+===============+==================+===============+
                                Figure 6

   The following sections describe how these processes are used by the
   KNP to establish trust between the actors and, in particular, how
   they determine their respective names.

6.3.1. Client and Introducer

   The RADIUS client invokes the GSS authentication handshake using the
   GSS EAP mechanism [GSSEAP] using an empty POST method. The RADIUS
   client, in its role as GSS initiator, MUST request mutual
   authentication from the GSS layer.

   The RADIUS server, acting as an EAP authenticator as described in
   section 2.3 of [RFC3748], MUST forward the EAP Request messages from
   the RADIUS client towards the Introducer over RADIUS; and also all
   EAP Responses received from the Introducer over RADIUS from the
   Introducer to the RADIUS client.

   The RADIUS client and Introducer MUST negotiate an EAP method
   supporting the following EAP Security Claims: mutual authentication,
   integrity protection, replay protection, confidentiality, key
   derivation, dictionary attack resistance, session independence and
   channel binding.

6.3.2. Server and Introducer

   The RADIUS Server and Introducer MUST each possess a shared secret to
   protect the RADIUS exchange described in section 6.3.1. The shared


Howlett                Expires January 5, 2011                [Page 9]


Internet-Draft   Key Negotiation Protocol for RadSec         July 2010


   secret MUST be established out-of-band prior to the invocation of the
   KNP; this is not within the scope of the KNP.

6.3.3. Server to Client

   The RADIUS client and Introducer MUST use the EAP channel binding
   protocol [EAPCHB]. If the channel binding verification fails, the
   Introducer MUST reject the authentication.

6.3.4. Client to Server

   If the Introducer successfully authenticates the RADIUS client, the
   Introducer MUST send the client's authenticated name to the RADIUS
   server using the X RADIUS Attribute. The RADIUS server MAY use this
   name to perform authorisation.

   TODO: select an appropriate RADIUS attribute

6.4. Keying

   The completion of the EAP method exchange results in the derivation
   of an EAP MSK known only to the client and server and Peer-Id(s) and
   Server-Id(s) identifying these respectively. The Introducer MUST
   replicate the keying material and Server-Id to the RADIUS server.

   The RADIUS client and server, in possession of the EAP MSK, establish
   a GSS-API security context as described in section 6 of [GSSEAP].

   The PSK identity and value shall be the output of GSS_Pseudo_random()
   [RFC4401] using the Pseudo-Random Function defined for the GSS EAP
   mechanism [GSSEAP].

   For the PSK identity, the prf_in input string MUST be prepended with
   the string "tls-psk-identity"; desired_out_len MUST be set to 128
   octets.

   Note: this should use base64 representation

   Note: should we append an NAI realm to the PSK identity?

   For the PSK value, the prf_in input string MUST be prepended with the
   string "tls-psk-value"; desired_out_len MUST be set to 64 octets.







Howlett                Expires January 5, 2011               [Page 10]


Internet-Draft   Key Negotiation Protocol for RadSec         July 2010


6.5. TLS Encryption Negotiation

   Finally the RADIUS client invokes RadSec, requesting a PSK TLS
   ciphersuite. The RADIUS client MUST include its PSK identity in the
   ClientKeyExchange message.

7. Context and PSK Management

   The RADIUS server and client MAY cache the GSS context until expiry
   of the GSS context. However, either party MAY delete a GSS context at
   any time up to expiry. When a GSS context is deleted, the
   corresponding PSK value MUST also be deleted. The PSK identity MAY be
   retained for auditing or other purposes.

8. Security Considerations

   TODO

9. IANA Considerations

   Note: register KNP TCP port and SRV RR label.

10. References

10.1. Normative References

   [GSSEAP]  Hartman, S. and Howlett, J., "A GSS-API Mechanism for the
             Extensible Authentication Protocol", draft-howlett-eap-gss-
             01 (work in progress), July 2010.

   [RADSEC]  Winter, S., McCauley, M., Venaas and Wierenga, K., "TLS
             encryption for RADIUS", draft-ietf-radext-radsec-06 (work
             in progress), March 2010.

   [RADDSC]  Winter, S. and McCauley, M., "NAI-based Dynamic Peer
             Discovery for RADIUS over TLS and DTLS", draft-ietf-radext-
             dynamic-discovery-02 (work in progress), March 2010.

   [EAPCHB]  Clancy, T. and Hoeper, K., "Channel Binding Support for EAP
             Methods", draft-ietf-emu-chbind-04 (work in progress),
             October 2009.

   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Masinter, L., Leach,
             P., Berners-Lee, T., "Hypertext Transfer Protocol --
             HTTP/1.1", RFC 2616, June 1999.




Howlett                Expires January 5, 2011               [Page 11]


Internet-Draft   Key Negotiation Protocol for RadSec         July 2010


   [RFC2743] Linn, J., "Generic Security Service Application Program
             Interface Version 2, Update 1", RFC 2743, January 2000.

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

   [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J.,
             Levkowetz, H., "Extensible Authentication Protocol (EAP)",
             RFC 3748, June 2004.

   [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API Extension
             for the Generic Security Service Application Program
             Interface Version (GSS-API)", RFC 4401, Febuary 2006.

   [RFC4279] Eronen, P. and Tschofenig, H., "Pre-Shared Key Ciphersuites
             for Transport Layer Security (TLS)", RFC 4279, December
             2005.

   [RFC4559] Jaganathan, K., Zhu, L. and Brezak, J., "SPNEGO-based
             Kerberos and NTLM HTTP Authentication in Microsoft
             Windows", RFC 4449, June 2006.

   [RFC5246] Dierks, T. and Rescorla, E., "The Transport Layer Security
             (TLS) Protocol Version 1.2", RFC 5246, August 2008.

10.2. Informative References

   TODO

11. Acknowledgments

   TODO















Howlett                Expires January 5, 2011               [Page 12]


Internet-Draft   Key Negotiation Protocol for RadSec         July 2010


Authors' Addresses

   Josh Howlett
   JANET(UK)

   Email: josh.howlett@ja.net


   Sam Hartman
   Painless Security, LLC

   Email: hartmans@painless-security.com




































Howlett                Expires January 5, 2011               [Page 13]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/