RE: Issue: Radius Digest, both modes of operation should be mandatory

["Nelson, David" <dnelson@enterasys.com>]

Miguel Garcia writes...

> I didn't take the same approach for the analysis. Instead, I thought
> that if you are doing an interoperability test between two
independently
> developped implementations, one implementation might have implemented
a
> Radius client that supports only nonces generated in the Radius client
> and the other implementation might have implemented a Radius server
that
> only supports nonces generated in the Radius server.
> 
> Both implementation will be compliant to your draft, but unable to
> interoperate. And will not be able to recover from any error.
> 
> To me this is a severe design failure, and I am trying to avoid it. I
> think that the burden of implementing support for both modes of
> operation is almost negligible compared to the burden of not being
able
> to interoperate. So for the sake of interoperability I would suggest
to
> mandate the support for both modes of operation in both RADIUS clients
> and servers.

I tend to agree with Miguel.  If we are standardizing Digest
Authentication within RADIUS, the traditional multi-vendor
interoperability considerations should apply.  Suggesting that
cross-vendor interoperability will not occur in practical deployments
may be correct, at least in some cases.  Still, having an RFC that
documents inherently non-interoperable protocol options seems like a
poor choice.


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