[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                         J. Howlett
Internet-Draft                                                 JANET(UK)
Intended status: Informational                                S. Hartman
Expires: April 23, 2012                                Painless Security
                                                        October 21, 2011


                     Key Negotiation Protocol (KNP)
                      draft-howlett-radsec-knp-02

Abstract

   The Key Negotiation Protocol enables an untrusting RADIUS client and
   RADIUS server to derive a key by reference to a mutually trusted
   actor called the Introducer.  This key may subsequently be used for
   one of two purposes.  First, it can credential a TLS PSK ciphersuite
   applied to a RadSec connection between the RADIUS client and RADIUS
   server; or secondly, to establish a trust relationship between the
   RADIUS client and a second Introducer that is trusted by the first
   Introducer.

   The composition of these capabilities enables a RADIUS client to
   establish a RadSec connection with any RADIUS server with whom it
   shares a direct or indirect trust relationship via one or more
   Introducers.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 23, 2012.

Copyright Notice

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




Howlett & Hartman        Expires April 23, 2012                 [Page 1]


Internet-Draft                     KNP                      October 2011


   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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Conventions used in this document  . . . . . . . . . . . . . .  5
   5.  The KNP Actors . . . . . . . . . . . . . . . . . . . . . . . .  5
   6.  Relationships With Other Protocols . . . . . . . . . . . . . .  6
     6.1.  Relationship to EAP  . . . . . . . . . . . . . . . . . . .  6
     6.2.  Relationship to RADIUS . . . . . . . . . . . . . . . . . .  7
     6.3.  Relationship to the GSS API  . . . . . . . . . . . . . . .  7
     6.4.  Relationship to the HTTP . . . . . . . . . . . . . . . . .  7
   7.  Key Negotiation Protocol . . . . . . . . . . . . . . . . . . .  7
     7.1.  Operation Independent Flow . . . . . . . . . . . . . . . .  8
     7.2.  The Credentialing Operation  . . . . . . . . . . . . . . . 10
     7.3.  The Introduction Operation . . . . . . . . . . . . . . . . 10
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 11





















Howlett & Hartman        Expires April 23, 2012                 [Page 2]


Internet-Draft                     KNP                      October 2011


1.  Introduction

   TLS encryption for RADIUS (RadSec) [I-D.ietf-radext-radsec] provides
   a mechanism for securing the communication between a RADIUS [RFC2865]
   client and server on the transport layer by using TLS [RFC5246].

   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 enables an untrusting RADIUS client and
   RADIUS server to derive a key by means of a mutually trusted actor
   called the Introducer.  This key may subsequently for two purposes.

   First, the key can be used to credential a TLS PSK ciphersuite when
   applied to a RadSec connection between the RADIUS client and RADIUS
   server, permitting a trusted exchange of RADIUS messages in the
   absence of a pre-existing relationship between the RADIUS client and
   RADIUS server.  This is described as "Credentialing".

   Secondly, the key can used as a credential by a RADIUS client to
   establish a trust relationship with a second Introducer that happens
   to be trusted by the first Introducer.  This is described as
   "Introduction".

   The composition of Credentialing and Introduction enables a RADIUS
   client to establish a RadSec connection with any RADIUS server with
   whom it shares an indirect trust relationship via one or more
   Introducers.

2.  Motivation

   The KNP is motivated by the following requirements:

   o  In the case of a non-federated RADIUS environment where a RADIUS
      client and RADIUS AS.server shares a direct trust relationship, a
      shared secret credential is used as the trust anchor between these
      systems.  In transitioning to the use of RadSec, it may be more
      convenient if these systems are able to continue using the
      existing credential technology rather than introduce a new
      credential technology (such as X.509 certificates), as this may
      impose significant changes to operational practices (such as
      deploying a Public Key Infrastructure).

   o  In the case of a federated RADIUS environment where RADIUS clients
      and RADIUS servers are associated with different domains,



Howlett & Hartman        Expires April 23, 2012                 [Page 3]


Internet-Draft                     KNP                      October 2011


      transitioning to the use of RadSec may impose a requirement to
      distribute and manage multiple trust anchors.  It may be more
      convenient if the systems within these domains were able to use a
      single trust anchor for RADIUS systems in all other domains, in
      addition to those systems within its own domain.  This may
      facilitate the scaling of large heterogeneous RADIUS environments
      where it may be difficult - for technical and/or administrative
      reasons - to impose support for even a small set of trust anchors.

   o  The use of multiple trust anchors within complex federated
      environments may impede essential trust management functions such
      as timely revocation.  Reducing the number of trust anchors may
      therefore improve trust management within these environments,
      particularly if it can be reduced to a single trust anchor.

3.  Overview

   The Key Negotiation Protocol (KNP) enables a RADIUS client and RADIUS
   server that do not share a direct trust relationship to derive a
   shared key by virtue of both systems having a trust relationship with
   an EAP server called the Introducer.  This key may be used for the
   following purposes:

   1.  Credentialing: the RADIUS client and RADIUS server can use the
       key to credential a TLS PSK ciphersuite applied to a RadSec
       connection.

   2.  Introduction: a credential can be derived from the key that can
       be used to authenticate the RADIUS client against a second
       Introducer that is trusted by the first Introducer.

   The composition of these capabilities enables a RADIUS client to
   derive a key that can be used to credential a RadSec connection with
   any other RADIUS server with whom it shares a common Introducer and,
   through transitivity, any number of intermediate Introducers.

   This transitivity of trust between a RADIUS client and RADIUS server
   across a chain of intermediate Introducers may appear very similar to
   the use of RADIUS proxies to establish a chain of trust between a
   RADIUS client and RADIUS server.  There is however a very significant
   difference:

   o  In the case of RADIUS proxy, the RADIUS messages emitted by the
      RADIUS client and RADIUS server must transit through the
      intermediate RADIUS proxy(ies).  There is no end-to-end
      relationship between the RADIUS client and RADIUS server, either
      in terms of connectivity or trust.




Howlett & Hartman        Expires April 23, 2012                 [Page 4]


Internet-Draft                     KNP                      October 2011


   o  In the case of KNP, the RADIUS messages are able to transit
      directly between RADIUS client and RADIUS server.  The path of
      transmissions between these systems is therefore entirely
      decoupled from the path of trust .  There is an end-to-end
      relationship between the RADIUS client and RADIUS server, both in
      terms of connectivity and trust.

   The use of RADIUS Proxies and Introducers are not mutually exclusive;
   deployers may choose to use both.

4.  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].

5.  The KNP Actors

   In the KNP, the RADIUS client and RADIUS server do not initially
   share a trust relationship.  Instead, these actors share a trust
   relationship with a mutually trusted third party known as the
   "Introducer".

   Figure 1 below depicts the trust relationships for a RADIUS client,
   RADIUS server and 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 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



Howlett & Hartman        Expires April 23, 2012                 [Page 5]


Internet-Draft                     KNP                      October 2011


   client to the RADIUS server using the new trust relationship.

                                   Introducer



                               RADIUS ---> RADIUS
                               Client      Server

                                   Figure 3

   Note that the RADIUS messages are not routed by the Introducer, as
   they would in the case of a RADIUS Proxy.  Instead, they flow
   directly from RADIUS client to RADIUS server.

6.  Relationships With Other Protocols

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

6.1.  Relationship to EAP

   In the KNP the RADIUS client assumes the role of an EAP peer.  In
   this role, it attempts to authenticate against a RADIUS server that
   assumes the role of a pass-through EAP authenticator.  An EAP server
   acts as the Introducer.

   The KNP enables all three actors - RADIUS client (EAP peer), RADIUS
   server (EAP authenticator) and Introducer (EAP server) - to establish
   a common view of their mutual relationships as described by the EAP
   names and keys that the EAP exchange yields, using the norms
   established by the EAP Key Management Framework [RFC5247].

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

   Figure 4 below depicts the relationships between these actors:

                                   Introducer
                                       /\
                                      /  \
                                     /    \
                               RADIUS      RADIUS
                               Client      Server
                   (possessing an EAP
                       credential for
                      the Introducer)




Howlett & Hartman        Expires April 23, 2012                 [Page 6]


Internet-Draft                     KNP                      October 2011


                                   Figure 4

6.2.  Relationship to RADIUS

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

   The RADIUS server must share a RADIUS secret with the Introducer,
   allowing mutual authentication of both actors.

   Figure 5 below depicts the relationships between these actors:

                                  Introducer
                                       /\
                                      /  \
                                     /    \
                               RADIUS      RADIUS
                               Client      Server
                   (possessing an EAP      (possessing a RADIUS
                       credential for      secret for
                      the Introducer)      the Introducer)

                                   Figure 5

6.3.  Relationship to the GSS API

   The KNP builds on the GSS API [RFC2743] framework by using the GSS
   EAP mechanism [I-D.ietf-abfab-gss-eap] and EAP [RFC3748].  The GSS
   EAP tokens are transported between the RADIUS client and RADIUS
   server using the HTTP Negotiate authentication scheme [RFC4559].

6.4.  Relationship to the HTTP

   The KNP uses HTTP to transport its request and response protocol
   messages between the RADIUS Client and RADIUS server.

7.  Key Negotiation Protocol

   As described previously, the KNP provides two operations:
   Credentialing and Introduction.

   The KNP provides these operations using a common protocol pattern.
   This pattern is applied against two types of Target actor, depending
   on the operation in question:

   o  In the case of Credentialing, the Target actor is a RADIUS server.
      If Credentialing is successful, the RADIUS client and RADIUS
      server will derive a common PSK that can be applied with a TLS-PSK



Howlett & Hartman        Expires April 23, 2012                 [Page 7]


Internet-Draft                     KNP                      October 2011


      ciphersuite and RadSec.

   o  In the case of Introduction, the Target actor is an Introducer.
      If an Introduction is successful, the RADIUS client and Introducer
      will derive an EAP credential that can subsequently be used for
      subsequent Credentialing or Introduction operations.

   For both operations it is essential that all three actors - RADIUS
   Client, Introducer and Target (whether a RADIUS server, in the case
   of Credentialing, or another Introducer, in the case of Introduction)
   - are able to authorise the claims that the other actors make about
   their respective names.  These claims are validated using different
   processes for each relationship; these are summarised in Figure 6
   below.

   +===============+===============+==================+===============+
   |    Subject    | Relying Party |     Process      | Evidence from |
   +===============+===============+==================+===============+
   | RADIUS Client |  Introducer   |     GSS EAP      |  EAP method   |
   +---------------+---------------+  authentication  | w/ qualifying |
   |  Introducer   | RADIUS Client |                  |Security Claims|
   +===============+===============+==================+===============+
   |  Introducer   |     Target    |      RADIUS      |     RADIUS    |
   +---------------+---------------+  authentication  |     shared    |
   |    Target     |  Introducer   |                  |     secret    |
   +===============+===============+==================+===============+
   |    Target     |     RADIUS    | Channel bindings | Assertion by  |
   |               |     Client    |                  |  Introducer   |
   +---------------+---------------+------------------+---------------+
   |    RADIUS     |     Target    | RADIUS attribute | Assertion by  |
   |    Client     |               |                  |  Introducer   |
   +===============+===============+==================+===============+
                               Figure 6

7.1.  Operation Independent Flow

   The RADIUS Client invokes the KNP by establishing an HTTP connection
   with the Target's KNP end-point.

   The RADIUS Client MUST use the GSS EAP mechanism
   [I-D.ietf-abfab-gss-eap] to authenticate to the Introducer,
   requesting mutual authentication from the GSS layer.

   The RADIUS Client, Target and Introducer MUST support EAP channel
   bindings [I-D.ietf-emu-chbind].  The Introducer MUST use validate the
   EAP channel bindings [I-D.ietf-emu-chbind] provided by the RADIUS
   Client.  If the channel binding verification fails, the Introducer
   MUST reject the authentication.



Howlett & Hartman        Expires April 23, 2012                 [Page 8]


Internet-Draft                     KNP                      October 2011


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

   The RADIUS Client and Target, in possession of the EAP MSK, create a
   GSS-API security context as described in section 6 of
   [I-D.ietf-abfab-gss-eap].

   The RADIUS Client POSTs a key negotiation request, encoded as an HTML
   form dataset, to the Target.  This request contains a set of
   operation-specific controls that specifies key negotiation
   parameters.  A key negotiation request MUST contain the following
   controls:

   o  Version: the version of the KNP.

   o  Request-Identifier: a unique alphanumeric identifier for the
      request.

   o  Requestor-Name: the requestor's GSS EAP initiator name.

   o  Operation-Type: the type of operation.

   o  Authenticator-Type: message authentication algorithm.

   o  Authenticator-Value: message authenticator value.

   The Target extracts the key negotiation parameters and assesses their
   compliance to the Target's key negotiation policies.  The Target MUST
   return an operation-specific document providing information about the
   resulting key negotiation context.

   o  Version: the version of the KNP.

   o  Request-Identifier: the identifier for the request that this is a
      reponse to.

   o  Responder-Name: the requestor's GSS EAP acceptor name.

   o  Operation-Type: the type of operation.

   o  Status-Code: a status code.

   o  Expires-After: a timestamp indicating the time of expiration.





Howlett & Hartman        Expires April 23, 2012                 [Page 9]


Internet-Draft                     KNP                      October 2011


   o  Authenticator-Type: message authentication algorithm.

   o  Authenticator-Value: message authenticator value.

   TODO: consider use of SAML authentication assertion instead?

   The RADIUS server and client SHOULD cache the GSS context until
   expiry of the GSS context.  However, either party MAY delete a GSS
   context at any time.  If a GSS context is deleted, any operation-
   specific derived materials SHOULD also be deleted, although such
   materials MAY be retained for auditing purposes.

7.2.  The Credentialing Operation

   This section describes the Credentialing operation-specific
   extensions to the general KNP flow.

   The RADIUS Client MUST specify the following control values within
   the key negotiation request:

   o  Operation-Type: Credentialing

   The PSK identity and value shall be outputs of GSS_Pseudo_random()
   [RFC4401] using the Pseudo-Random Function defined for the GSS EAP
   mechanism [I-D.ietf-abfab-gss-eap].

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

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

   Note: these output values should use base64 encoding

7.3.  The Introduction Operation

   This section describes the Introduction operation-specific extensions
   to the general KNP flow.

   The RADIUS Client MUST specify the following control values within
   the key negotiation request:

   o  Operation-Type: Introduction"

   The EAP identity and credential shall be outputs of
   GSS_Pseudo_random() [RFC4401] using the Pseudo-Random Function
   defined for the GSS EAP mechanism [I-D.ietf-abfab-gss-eap].



Howlett & Hartman        Expires April 23, 2012                [Page 10]


Internet-Draft                     KNP                      October 2011


   For the EAP identity, the prf_in input string MUST be prepended with
   the string "tls-psk-eap-identity"; desired_out_len MUST be set to 128
   octets.  The output string MUST be appended with the realm of the
   Introducer to form an NAI.

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

   Note: these output values should use base64 encoding.

8.  Security Considerations

   TODO

9.  IANA Considerations

   TODO

10.  Acknowledgements

   TODO

11.  Normative References

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

   [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 W.
                             Simpson, "Remote Authentication Dial In
                             User Service (RADIUS)", RFC 2865,
                             June 2000.

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

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

   [RFC4401]                 Williams, N., "A Pseudo-Random Function



Howlett & Hartman        Expires April 23, 2012                [Page 11]


Internet-Draft                     KNP                      October 2011


                             (PRF) API Extension for the Generic
                             Security Service Application Program
                             Interface (GSS-API)", RFC 4401,
                             February 2006.

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

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

   [RFC5247]                 Aboba, B., Simon, D., and P. Eronen,
                             "Extensible Authentication Protocol (EAP)
                             Key Management Framework", RFC 5247,
                             August 2008.

   [I-D.ietf-abfab-gss-eap]  Hartman, S. and J. Howlett, "A GSS-API
                             Mechanism for the Extensible Authentication
                             Protocol", draft-ietf-abfab-gss-eap-03
                             (work in progress), October 2011.

   [I-D.ietf-radext-radsec]  Winter, S., McCauley, M., Venaas, S., and
                             K. Wierenga, "TLS encryption for RADIUS",
                             draft-ietf-radext-radsec-09 (work in
                             progress), July 2011.

   [I-D.ietf-emu-chbind]     Hartman, S., Clancy, T., and K. Hoeper,
                             "Channel Binding Support for EAP Methods",
                             draft-ietf-emu-chbind-10 (work in
                             progress), October 2011.

Authors' Addresses

   Josh Howlett
   JANET(UK)
   Lumen House, Library Avenue, Harwell
   Oxford  OX11 0SG
   UK

   Phone: +44 1235 822363
   EMail: Josh.Howlett@ja.net







Howlett & Hartman        Expires April 23, 2012                [Page 12]


Internet-Draft                     KNP                      October 2011


   Sam Hartman
   Painless Security

   EMail: hartmans-ietf@mit.edu















































Howlett & Hartman        Expires April 23, 2012                [Page 13]


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