RE: [SECMECH] AAA requirement for middleware

Hi Josh,

I just posted a link to an Internet draft I have been working on about
creating generally useful authentication mechanisms (GUAM).  

I tried to state your requirements below as requirements for generally
useful authentication mechanisms. 

>  - plays nicely with the cross-realm AAA protocol _du jour_, 
> RADIUS, and successor, Diameter;

[Joe] Generally useful mechanisms should be usable in the EAP
framework/protocol. 

Currently to support RADIUS or DIAMETER it is helpful to be able to use
an authentication mechanism within the EAP framework.  There are other
possibilities but EAP provides a nice interface to AAA servers. 

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

[Joe] Generally useful mechanisms should perform authentication between
two parties and should expect than an arbitrary number of proxies
between the parties may handle the messages.

>  - negotiation of EAP methods;

[Joe] There should be a secure means of negotiating generally useful
mechanisms.  I assume you mean protected negotiation of EAP methods
(perhaps within a tunnel). 

>  - extensible attributes: can be returned by the AAA/H to 
> allow richer AuthZ at the resource;

[Joe] Generally useful mechanism should be able to exchange
authenticated data between authenticated parties and export this data to
the calling framework. In the GUAM draft I referred to this as channel
bindings (EAP).  

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

[Joe] can you elaborate on this?

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

[Joe] Generally useful mechanisms should provide the ability to provide
confidentiality for the data exchanged as channel binding (eap). This
might not be a general requirement for all mechanisms, but a desirable
feature (integrity protection should be required).    

>  - use of anonymous NAIs ("anonymous@example.com") to allow 
> anonymous proxying of requests;

[Joe] Generally useful mechanisms should allow for privacy of the
identity of one of the parties. This might not be a general requirement
for all mechanisms, but it is desirable feature of mechanisms.   

>  - support for legacy AuthN mechanisms;

[Joe] I expect that this would depend upon the specific generally useful
mechanism  and the legacy mechanism.  Not all generally useful
mechanisms will support legacy AuthN mechanisms. What legacy mechanisms
are you interested in supporting?  

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