[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [HOKEY] a transparent proposal

>   It is up to that domain to ensure all of it's AAA servers have the
> same policy.  This includes managing state for multiple login detection,
> and potentially re-auth keys.

Doesn't this imply a significant degree of complexity?  For example, one argument for the RFC 4507 PAC is that avoiding server-side state enables better scaling and authentication performance, because RADIUS servers don't replicate TLS key state.  It's hard to reconcile that argument with the idea of having the domain keeping track of server side state. 

If there is a way to push that state on the peer, things would be much simpler.  For example, if the ERX exchange were to leave the peer with an NAI identifying the "local server" and corresponding key state, then the peer could use that "re-auth" NAI in subsequent requests. 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>