One document matched: draft-howlett-radsec-knp-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2743 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml">
<!ENTITY rfc2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY rfc3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY rfc4279 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4279.xml">
<!ENTITY rfc4401 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4401.xml">
<!ENTITY rfc4559 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4559.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc5247 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml">
<!ENTITY I-D.ietf-abfab-gss-eap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-abfab-gss-eap.xml">
<!ENTITY I-D.ietf-radext-radsec SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-radext-radsec.xml">
<!ENTITY I-D.ietf-emu-chbind SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-emu-chbind.xml">
]>
<rfc category="info" docName="draft-howlett-radsec-knp-02" ipr="trust200902">
<front>
<title abbrev="KNP">Key Negotiation Protocol (KNP)</title>
<author initials="J." surname="Howlett" fullname="Josh Howlett">
<organization>JANET(UK)</organization>
<address>
<postal>
<street>Lumen House, Library Avenue, Harwell</street>
<city>Oxford</city>
<code>OX11 0SG</code>
<country>UK</country>
</postal>
<phone>+44 1235 822363</phone>
<email>Josh.Howlett@ja.net</email>
</address>
</author>
<author initials="S." surname="Hartman" fullname="Sam Hartman">
<organization>Painless Security</organization>
<address>
<email>hartmans-ietf@mit.edu</email>
</address>
</author>
<date year="2011" />
<area>Security Area</area>
<keyword>Internet-Draft</keyword>
<keyword>Federated Authentication</keyword>
<keyword>RADIUS</keyword>
<keyword>RADIUS</keyword>
<keyword>GSS-API</keyword>
<keyword>EAP</keyword>
<abstract>
<t>
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.
</t>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
TLS encryption for RADIUS (RadSec) <xref target="I-D.ietf-radext-radsec" />
provides a mechanism for securing the communication between a RADIUS <xref target="RFC2865" /> client and
server on the transport layer by using TLS <xref target="RFC5246" />.
</t>
<t>
RadSec mandates the use of one of the <xref target="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 <xref target="RFC4279" />,
may be used providing that it supports encryption.
</t>
<t>
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.
</t>
<t>
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".
</t>
<t>
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".
</t>
<t>
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.
</t>
</section>
<section title="Motivation">
<t>
The KNP is motivated by the following requirements:
<list style="symbols">
<t>
In the case of a non-federated RADIUS environment where a RADIUS client and RADIUS §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).
</t>
<t>
In the case of a federated RADIUS environment where RADIUS clients and RADIUS servers are associated
with different domains, 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.
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section title="Overview">
<t>
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:
<list style="numbers">
<t>
Credentialing: the RADIUS client and RADIUS server can use the key to credential a TLS PSK ciphersuite
applied to a RadSec connection.
</t>
<t>
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.
</t>
</list>
</t>
<t>
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.
</t>
<t>
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:
<list style="symbols">
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
<t>
The use of RADIUS Proxies and Introducers are not mutually exclusive; deployers may choose to use both.
</t>
</section>
<section title="Conventions used in this document">
<t>
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 <xref target="RFC2119" />.
</t>
</section>
<section title="The KNP Actors">
<t>
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".
</t>
<t>
Figure 1 below depicts the trust relationships for a RADIUS client, RADIUS server and
Introducer before the KNP has been invoked.
</t>
<figure>
<artwork><![CDATA[
Introducer
/\
/ \
/ \
RADIUS RADIUS
Client Server
Figure 1
]]></artwork>
</figure>
<t>
Figure 2 below depicts the new trust relationship between the RADIUS client, RADIUS server
and Introducer after the KNP has been invoked.
</t>
<figure>
<artwork><![CDATA[
Introducer
/\
/ \
/ \
RADIUS------RADIUS
Client Server
Figure 2
]]></artwork>
</figure>
<t>
Figure 3 below depicts the flow of RADIUS packets from the RADIUS client to the RADIUS
server using the new trust relationship.
</t>
<figure>
<artwork><![CDATA[
Introducer
RADIUS ---> RADIUS
Client Server
Figure 3
]]></artwork>
</figure>
<t>
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.
</t>
</section>
<section title="Relationships With Other Protocols">
<t>
The KNP builds on a variety of protocols. This section describes the relationship of KNP to these.
</t>
<section title="Relationship to EAP">
<t>
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.
</t>
<t>
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 <xref target="RFC5247" />.
</t>
<t>
The RADIUS client must possess an EAP credential for the Introducer, allowing mutual
authentication of both parties.
</t>
<t>
Figure 4 below depicts the relationships between these actors:
</t>
<figure>
<artwork><![CDATA[
Introducer
/\
/ \
/ \
RADIUS RADIUS
Client Server
(possessing an EAP
credential for
the Introducer)
Figure 4
]]></artwork>
</figure>
</section>
<section title="Relationship to RADIUS">
<t>
The RADIUS server uses the RADIUS protocol to forward the EAP transaction to the Introducer.
</t>
<t>
The RADIUS server must share a RADIUS secret with the Introducer, allowing mutual
authentication of both actors.
</t>
<t>
Figure 5 below depicts the relationships between these actors:
</t>
<figure>
<artwork><![CDATA[
Introducer
/\
/ \
/ \
RADIUS RADIUS
Client Server
(possessing an EAP (possessing a RADIUS
credential for secret for
the Introducer) the Introducer)
Figure 5
]]></artwork>
</figure>
</section>
<section title="Relationship to the GSS API">
<t>
The KNP builds on the GSS API <xref target="RFC2743" /> framework by using the GSS EAP mechanism
<xref target="I-D.ietf-abfab-gss-eap" /> and EAP <xref target="RFC3748" />. The GSS EAP tokens
are transported between the RADIUS client and RADIUS server using the HTTP Negotiate authentication scheme
<xref target="RFC4559" />.
</t>
</section>
<section title="Relationship to the HTTP">
<t>
The KNP uses HTTP to transport its request and response protocol messages between the RADIUS Client
and RADIUS server.
</t>
</section>
</section>
<section title="Key Negotiation Protocol">
<t>
As described previously, the KNP provides two operations: Credentialing and Introduction.
</t>
<t>
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:
<list style="symbols">
<t>
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 ciphersuite and RadSec.
</t>
<t>
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.
</t>
</list>
</t>
<t>
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.
</t>
<figure>
<artwork><![CDATA[
+===============+===============+==================+===============+
| 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
]]></artwork>
</figure>
<section title="Operation Independent Flow" anchor="KNP_Operation">
<t>
The RADIUS Client invokes the KNP by establishing an HTTP connection with the Target's
KNP end-point.
</t>
<t>
The RADIUS Client MUST use the GSS EAP mechanism <xref target="I-D.ietf-abfab-gss-eap" />
to authenticate to the Introducer, requesting mutual authentication from the GSS layer.
</t>
<t>
The RADIUS Client, Target and Introducer MUST support EAP channel bindings
<xref target="I-D.ietf-emu-chbind" />. The Introducer MUST use validate the EAP channel bindings
<xref target="I-D.ietf-emu-chbind" /> provided by the RADIUS Client. If the
channel binding verification fails, the Introducer MUST reject the authentication.
</t>
<t>
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.
</t>
<t>
The RADIUS Client and Target, in possession of the EAP MSK, create a GSS-API security
context as described in section 6 of <xref target="I-D.ietf-abfab-gss-eap" />.
</t>
<t>
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:
<list style="symbols">
<t>Version: the version of the KNP.</t>
<t>Request-Identifier: a unique alphanumeric identifier for the request.</t>
<t>Requestor-Name: the requestor's GSS EAP initiator name.</t>
<t>Operation-Type: the type of operation.</t>
<t>Authenticator-Type: message authentication algorithm.</t>
<t>Authenticator-Value: message authenticator value.</t>
</list>
</t>
<t>
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.
<list style="symbols">
<t>Version: the version of the KNP.</t>
<t>Request-Identifier: the identifier for the request that this is a reponse to.</t>
<t>Responder-Name: the requestor's GSS EAP acceptor name.</t>
<t>Operation-Type: the type of operation.</t>
<t>Status-Code: a status code.</t>
<t>Expires-After: a timestamp indicating the time of expiration.</t>
<t>Authenticator-Type: message authentication algorithm.</t>
<t>Authenticator-Value: message authenticator value.</t>
</list>
</t>
<t>
TODO: consider use of SAML authentication assertion instead?
</t>
<t>
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.
</t>
</section>
<section title="The Credentialing Operation">
<t>
This section describes the Credentialing operation-specific extensions to the general KNP flow.
</t>
<t>
The RADIUS Client MUST specify the following control values within the key negotiation request:
<list style="symbols">
<t>Operation-Type: Credentialing</t>
</list>
</t>
<t>
The PSK identity and value shall be outputs of GSS_Pseudo_random() <xref target="RFC4401" />
using the Pseudo-Random Function defined for the GSS EAP mechanism <xref target="I-D.ietf-abfab-gss-eap" />.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Note: these output values should use base64 encoding
</t>
</section>
<section title="The Introduction Operation">
<t>
This section describes the Introduction operation-specific extensions to the general KNP flow.
</t>
<t>
The RADIUS Client MUST specify the following control values within the key negotiation request:
<list style="symbols">
<t>Operation-Type: Introduction"</t>
</list>
</t>
<t>
The EAP identity and credential shall be outputs of GSS_Pseudo_random() <xref target="RFC4401" />
using the Pseudo-Random Function defined for the GSS EAP mechanism <xref target="I-D.ietf-abfab-gss-eap" />.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Note: these output values should use base64 encoding.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
TODO
</t>
</section>
<section title="IANA Considerations">
<t>
TODO
</t>
</section>
<section title="Acknowledgements">
<t>
TODO
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2743;
&rfc2865;
&rfc3748;
&rfc4279;
&rfc4401;
&rfc4559;
&rfc5246;
&rfc5247;
&I-D.ietf-abfab-gss-eap;
&I-D.ietf-radext-radsec;
&I-D.ietf-emu-chbind;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:54:57 |