Re: [SECMECH] AAA requirement for middleware

On Fri, Jun 24, 2005 at 11:05:34AM +0100, Josh Howlett wrote:
> 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).

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

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

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

_______________________________________________
SECMECH mailing list
SECMECH@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/secmech