One document matched: draft-howlett-radsec-knp-01.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 rfc2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml">
<!ENTITY rfc2579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml">
<!ENTITY rfc2580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml">
<!ENTITY rfc2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.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 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-radext-dynamic-discovery SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-radext-dynamic-discovery.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-01" ipr="trust200902">
<front>
<title abbrev="KNP for RadSec">Key Negotiation Protocol for RadSec (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>
<postal>
<street> </street>
<city> </city>
<code> </code>
<country> </country>
</postal>
<phone> </phone>
<email>hartmans-ietf@mit.edu</email>
</address>
</author>
<date year="2011" />
<area>Security Area</area>
<workgroup>ABFAB</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Federated Authentication</keyword>
<keyword>AAA</keyword>
<keyword>RADIUS</keyword>
<keyword>GSS-API</keyword>
<keyword>EAP</keyword>
<abstract>
<t>
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.
</t>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The ABFAB architecture <xref target="I-D.lear-abfab-arch"/> provides an overview
of how AAA protocols, such as RADIUS<xref target="RFC2865"/>, can be used to
support application layer authentication. In this architecture, the AAA protocols
are part of the 'federation substrate' that ultimately binds relying parties to
identity providers. The ABFAB substrate provides the architectural roles:
<list style="symbols">
<t>Deciding where to route messages addressed to a given Network Access Identifier (NAI)</t>
<t>Providing integrity protection and authentication so the relying party can
trust the authenticity of messages from the identity provider</t>
<t>When multiple sets of business rules are possible, indicate which rules are being used</t>
<t>Provide appropriate technical validation of information exchanged through the federation.</t>
</list>
</t>
<t>Today, AAA protocols are already commonly employed for federation between different
domains. These system generally exhibit many of these behaviours.
</t>
<section title="Federation with RADIUS">
<t>
In a simple federated relationship, static configuration of RADIUS is used to achieve
technical trust. The RADIUS proxy is configured with a static set of mappings from realm
suffix to RADIUS server. There are statically configured shared secrets with each of
these servers. Statically configured attribute release policies describe what attributes
may be expressed by RADIUS servers outside of the local realm.
</t>
<t>
Another common deployment involves an organization running a network of RADIUS proxies.
These proxies are statically configured with routing, credentials and filtering information.
A RADIUS proxy network and this static configuration is sometimes known as a proxy fabric.
</t>
<t>
One disadvantage of a proxy fabric is that the intermediate proxies can see information
exchanged between the RADIUS client (or the relying party in the ABFAB architecture) and
terminal RADIUS server (or the identity provider in the ABFAB architecture). Sometimes this
might be desirable: for example if an intermediate proxy is needed to validate some of this
information. However, it does create a significant privacy exposure. </t>
<t>
Also, especially for the Extensible Authentication Protocol <xref target="RFC3748"/>,
reducing the latency of a round trip can provide a significant performance advantage.
</t>
</section>
<section title="Federation with RadSec">
<t>
TLS encryption for RADIUS (RadSec) <xref target="I-D.ietf-radext-radsec" />
provides a means to secure the communication between a RADIUS and server on
the transport layer by using a TLS <xref target="RFC5246" />
cipher-suite. This avoids the security weaknesses inherent in RADIUS' use of the
MD5 algorithm and removes the requirement for a RADIUS client to be preconfigured
with a shared secret to communicate with a particular RADIUS server. This can be
a significant part of reducing the intermediaries in a RADIUS deployment.
</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>
</section>
<section title="Requirements">
<t>
The KNP is motivated by the following requirements:
<list style="symbols">
<t>
Improve security while using a familiar credential technology. RADIUS uses shared secrets to
establish trust between RADIUS clients and servers. 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.
</t>
<t>
Agnosticism with respect to credential technology. In complex multi-domain federated AAA systems
it may often be convenient not to impose any particular credential technology(s) or trust anchor(s)
to establish trust between RADIUS peers. In other words, it may be desirable for RADIUS peers in
different administrative domains to negotiate keys in the absence of any 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.
</t><t> 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.
</t>
<t>Avoiding intermediaries. Reducing the number of intermediaries improves privacy and system
robustness, and reduces end-to-end latencies.</t>
</list>
</t>
</section>
<section title="Federating RADIUS">
<t>In order to provide a scalable substrate for federation, the AAA fabric needs to provide authentication and exchange of policy information between RADIUS clients and servers that cross organizational boundaries. That is, federated access management is required for RADIUS as an application.
</t>
<t>As with other applications, the ABFAB technologies can be applied to provide federated access management. RADIUS clients act as clients and subjects. They have identities issued by the organization establishing the federation, which acts as an identity provider. The foreign RADIUS server acts as a relying party.
</t>
<t>This specification defines a protocol that permits the ABFAB architecture to be used for federated access to RADIUS, providing the technical details for interactions between parties. In an environment where ABFAB is in use, this technology may provide significant advantages over other approaches such as a public-key infrastructure. In ABFAB, credentials are always managed between two parties. The subject and identity provider (in this case, the RADIUS client and federation) share a credential. The relying party and identity provider share a secure channel created by AAA credentials. Since only two parties need to interact with each credential, their requirements dictate the complexity of enrollment, revocation, policies, practices, and other credential management issues. Trust anchor management may be significantly simpler.</t>
</section>
<section title="Introducing KMP">
<t>
The Key Negotiation Protocol (KNP) provides two functions:
<list style="numbers">
<t>
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.
</t>
<t>
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 the function described above); or to establish yet
another credential with another RADIUS server.
</t>
</list>
</t>
<t>
In summary, the first function enables a RADIUS client and server to negotiate a key by means
of a trusted third-party called the Introducer. The second function 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.
</t>
<t>
TODO: this document currently only documents the first of these functions. The second facility
will be documented in a later revision.
</t>
<t>
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 path between the RADIUS client and server via one or more intermediate Introducers.
</t>
<t>
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 need not
bear any resemblance to the transit path taken by the AAA messages between the RADIUS client and server.
</t>
</section>
<section title="Trust Router">
<t>Static configuration of routing information does not scale. Instead it would be desirable to have a protocol that dynamically assembles the necessary configuration information for RADIUS proxies.</t>
<t>This protocol has a lot in common with a routing protocol. The protocol maintains a distributed database synchronized across a number of replicas. It's likely that multiple paths will be able to reach the same destination in some cases. Thus, some sort of shortest-path algorithm is required. The metric often will be more complex than simply length of path: business rules may prefer certain paths. Business rules may also filter out certain paths at various points.
</t>
<t>We propose that as ABFAB deployment complexity increases,
such a protocol will be required. Within a federation, local
procedures, such as frequently updated static configuration
could be used. However, to provide scalable inter-federation,
a trust router protocol is required to exchange the
information necessary to establish technical trust in a
dynamic manner. This
document does not define a specific instantiation of a trust
routing protocol. Instead, it focuses on a problem that
results once a trust routing protocol exists. Efforts to
design a proposal for a trust router protocol are ongoing but
less mature than this proposal.
</t>
</section>
</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>
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".
</t>
<t>
Figure 1 below depicts the trust relationships for a RADIUS client, RADIUS server and the 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 the 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>
</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 GSS-API and EAP">
<t>
The KNP builds on the GSS-API <xref target="RFC2743" /> framework, the GSS EAP mechanism <xref target="I-D.ietf-abfab-gss-eap" /> and EAP <xref target="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.
</t>
<t>
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.
</t>
<t>
The RADIUS client must possess an EAP credential for the introducer, allowing mutual authentication of both parties when applied with an appropriate EAP method.
</t>
<t>
Figure 4 below depicts the relationships between these entities:
</t>
<figure>
<artwork><![CDATA[
Introducer
/\
/ \
/ \
RADIUS RADIUS
Client Server
(wielding EAP
credential for
the introducer)
Figure 4
]]></artwork>
</figure>
</section>
<section title="Relationship to AAA">
<t>
The RADIUS server uses an AAA protocol to forward the EAP transaction to the Introducer.
</t>
<t>
The RADIUS server must possess an AAA credential for the Introducer, allowing mutual authentication of both parties.
</t>
<t>
Figure 5 below depicts the relationships between these entities:
</t>
<figure>
<artwork><![CDATA[
Introducer
/\
/ \
/ \
RADIUS RADIUS
Client Server
(wielding EAP (wielding AAA
credential for credential for
the Introducer) the Introducer)
Figure 5
]]></artwork>
</figure>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Relationship to HTTP Negotiate">
<t>
The GSS EAP mechanism is transported using the HTTP Negotiate authentication scheme <xref target="RFC4559" /> between the RADIUS client and the RADIUS server's KNP endpoint.
</t>
</section>
</section>
<section title="Key Negotiation Protocol">
<t>
This section describes the KNP.
</t>
<section title="Invocation by RADIUS Client">
<t>
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:
</t>
<t>
<list style="symbols">
<t>
The RADIUS client may not have any local configuration for the RADIUS server.
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section title="Discovery of the RADIUS Server and KNP Endpoint">
<t>
The RADIUS client first selects a RADIUS server. Implementations MUST support the use of Dynamic Peer Discovery <xref target="I-D.ietf-radext-dynamic-discovery" />, but MAY use any selection algorithm.
</t>
<t>
Having selected a RADIUS server and obtained its network location, the RADIUS client MUST attempt to establish an HTTP <xref target="RFC2616" /> connection with the RADIUS server's KNP end-point.
</t>
<t>
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.
</t>
<t>
Example:
</t>
<t>
_knp._tcp.radsec.example.com. IN SRV 0 10 TODO knp.example.com.
</t>
<t>
TODO: obtain a port.
</t>
</section>
<section title="Trust Establishment">
<t>
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.
</t>
<figure>
<artwork><![CDATA[
+===============+===============+==================+===============+
| 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 6.3.2. )| 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
]]></artwork>
</figure>
<t>
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.
</t>
<section title="Client and Introducer" anchor="KNP_Trust_ClientAndIntroducer">
<t>
The RADIUS client invokes the GSS authentication handshake using the GSS EAP mechanism <xref target="I-D.ietf-abfab-gss-eap" /> using an empty POST method. The RADIUS client, in its role as GSS initiator, MUST request mutual authentication from the GSS layer.
</t>
<t>
The RADIUS server, acting as an EAP authenticator as described in section 2.3 of <xref target="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.
</t>
<t>
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.
</t>
</section>
<section title="Server and Introducer" anchor="KNP_Trust_ServerAndIntroducer">
<t>
The RADIUS Server and Introducer MUST each possess a shared secret to protect the RADIUS exchange described in section <xref target="KNP_Trust_ClientAndIntroducer" />. The shared secret MUST be established out-of-band prior to the invocation of the KNP; this is not within the scope of the KNP.
</t>
</section>
<section title="Server to Client" anchor="KNP_Trust_ServerToClient">
<t>
The RADIUS client and Introducer MUST use the EAP channel binding protocol <xref target="I-D.ietf-emu-chbind" />. If the channel binding verification fails, the Introducer MUST reject the authentication.
</t>
</section>
<section title="Client to Server" anchor="KNP_Trust_ClientToServer">
<t>
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.
</t>
<t>
TODO: select an appropriate RADIUS attribute
</t>
</section>
</section>
<section title="Keying">
<t>
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.
</t>
<t>
The RADIUS client and server, in possession of the EAP MSK, establish a GSS-API security context as described in section 6 of <xref target="I-D.ietf-abfab-gss-eap" />.
</t>
<t>
The PSK identity and value shall be the output 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-identity"; desired_out_len MUST be set to 128 octets.
</t>
<t>
Note: this should use base64 representation
</t>
<t>
Note: should we append an NAI realm to the PSK identity?
</t>
<t>
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.
</t>
</section>
<section title="TLS Encryption Negotiation">
<t>
Finally the RADIUS client invokes RadSec, requesting a PSK TLS ciphersuite. The RADIUS client MUST include its PSK identity in the ClientKeyExchange message.
</t>
</section>
</section>
<section title="Context and PSK Management">
<t>
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.
</t>
</section>
<section title="Security Considerations">
<t>
TODO
</t>
</section>
<section title="IANA Considerations">
<t>
Note: register KNP TCP port and SRV RR label.
</t>
</section>
<section title="Acknowledgements">
<t>
TODO
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2616;
&rfc2743;
&rfc2865;
&rfc3748;
&rfc4279;
&rfc4401;
&rfc4559;
&rfc5246;
&I-D.ietf-abfab-gss-eap;
&I-D.ietf-radext-radsec;
&I-D.ietf-radext-dynamic-discovery;
&I-D.ietf-emu-chbind;
</references>
<references title="Informative References">
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.lear-abfab-arch'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:20:43 |