RE: [SECMECH] AAA requirement for middleware

Hi Sam,

On Tue, 28 Jun 2005, Salowey, Joe wrote:
> I tried to state your requirements below as requirements for generally
> useful authentication mechanisms.

Your restatements are good. I have appended the additional
clarifications as requested below.

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

FWIW, a useful outcome of the SECMECH discussion might be a consistent
glossary :-)

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

This is a special case of the previous requirement. Attributes can be
passed from the AAA/H to the NAS and the peer within independent
channel bindings (?) but over the same transport (ie. TTLS (binding
to peer), over EAP, over RADIUS (binding to NAS)).

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

Tunneled cleartext credentials.

best regards, josh.

------------------------------------------------------------
Josh Howlett, Networking & Digital Communications,
Information Systems & Computing, University of Bristol, U.K.
'phone: 0117 928 7850 email: josh.howlett@bris.ac.uk
------------------------------------------------------------

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