Internet DRAFT - draft-howlett-radsec-knp
draft-howlett-radsec-knp
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]
