Subject: [SECMECH] AAA requirement for middleware

From: Josh Howlett <[email-masked]>
Date: Fri, 24 Jun 2005 11:05:34 +0100 (BST)

Cross-realm AAA over RADIUS is growing extremely rapidly in my
environment (UK & European academic networking); for example, see
http://www.eduroam.org. This is being driven by an inter-Campus national
and international roaming requirement.

There is growing interest in re-using this infrastructure for
cross-realm Middleware functionality for other applications (thereby
providing similiar functionality to M/W architectures such as
Shibboleth).

However, there are no available means to provide an equivalent degree
of security as that provided by tunnelled EAP methods over EAPOL.

To a naive observer, it seems that what is required is a means of
encapsulating EAP in-band over TCP for application protocols. There is
a proposal from Funk et al (TLS/IA) to implement this within the TLS
handshake. Something of this ilk - perhaps ideally an EAP over SASL
mechanism - would be very welcome.

best regards, josh.

------------------------------------------------------------
Josh Howlett, Networking & Digital Communications,
Information Systems & Computing, University of Bristol, U.K.
'phone: 0117 928 7850 email: [email-masked]
------------------------------------------------------------

_______________________________________________
SECMECH mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/secmech

---

From: Sam Hartman <[email-masked]>
Date: Sun, 26 Jun 2005 16:06:00 -0400

Well, there's a significant problem with that.  EAP has a rather
narrow applicability statement and general middleware falls outside
that statement.

One of the goals of the secmech effort is to set up the security
frameworks so that you could use an arbitrary mechanism both for AAA
and for other purposes.

I don't think extending EAP to those other frameworks is the right
solution.  I do think that making it possible to use cross-realm AAA
is a requirement.

--Sam

---

From: Josh Howlett <[email-masked]>
Date: Mon, 27 Jun 2005 12:41:16 +0100

> solution. I do think that making it possible to use cross-realm AAA

In which case, it's important to me that these frameworks offer mechanisms 
that share the properties of EAP (or, at least, the tunelled EAP methods) 
that make it so good for cross-realm AAA.

Thanks, josh.

-- 
-----------------------------------------------------------

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Jun 2005 11:10:56 -0400

>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

    Josh> --On Sunday, June 26, 2005 16:06:00 -0400 Sam Hartman
    Josh> <[email-masked]> wrote:
    >> I don't think extending EAP to those other frameworks is the
    >> right solution. I do think that making it possible to use
    >> cross-realm AAA is a requirement.

    Josh> In which case, it's important to me that these frameworks
    Josh> offer mechanisms that share the properties of EAP (or, at
    Josh> least, the tunelled EAP methods) that make it so good for
    Josh> cross-realm AAA.

Mind enumerating these requirements for us?

---

From: Josh Howlett <[email-masked]>
Date: Mon, 27 Jun 2005 16:58:01 +0100

> Mind enumerating these requirements for us?

Off the top of my head:

 - plays nicely with the cross-realm AAA protocol _du jour_, RADIUS, and 
successor, Diameter;
 - passthrough mode (authenticator does not participate in authentication, 
beyond acting as a go-between, and simply honours the success/failure code 
returned by the AAA backend);
 - negotiation of EAP methods;
 - extensible attributes: can be returned by the AAA/H to allow richer 
AuthZ at the resource;
 - ability to pass attributes from the AAA/H to both the peer and the 
authenticator simultaneously, but distinctly and privately, through the 
same AAA transaction;
 - security association can be established between the peer (user) and the 
AAA/H, and used to provide privacy across the hops between the peer and the 
AAA/H.
 - use of anonymous NAIs ("[email-masked]") to allow anonymous 
proxying of requests;
 - support for legacy AuthN mechanisms;

josh.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 28 Jun 2005 12:19:24 -0500

> providing similiar functionality to M/W architectures such as

The point of this BoF, and hopefully WG, as I understand it is to ensure
the availability of various security mechanisms, AAA-types, PKI and
Kerberos V, and maybe even MD5Digest-types, to all of four common
security frameworks -- EAP, TLS, SASL and the GSS-API.

Either SECMECH could be agnostic w.r.t. framework/mechanism use in
middleware vs. other contexts, or it might tackle any technical matters
specific to middleware.  One technical matter that I can think of that
would be of particular interest in middleware scenarios is credential
delegation, constrained credential delegation, SAML assertion token
exchanges, etc...  I note that KITTEN WG is tackling some related
topics, in relation to naming and name attributes (which I suspect may
be of interest to you, given that you mention Shibboleth).

> mechanism - would be very welcome.

SECMECH, as proposed, would provide something along these lines, either
by providing mechanism bridges between security frameworks (like SASL
does for the GSS-API), or by providing framework bindings of mechanisms
for various mechanisms/frameworks.

Nico
--