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

[Miguel Garcia <Miguel.An.Garcia@nokia.com>]

Wolfgang:

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.

/Miguel

Beck01, Wolfgang wrote:

> What scenarios do we have?
>
> 1) plain IETF SIP providers, web servers, using HTTP Digest
> - client-side nonce generation is sufficient
>
> 2) plain IETF SIP providers, web servers, using AKA Digest
> - server-side nonce generation is required
>
> 3) providers using Diameter servers
> - server-side nonce generation is required, as Diameter does not (yet?) support
> client-side nonce generation.
>
> 4) 3GPP2 IMS
> - client-side nonce generation is required
>
> Will there be mixed environments?
>
> A) RADIUS clients connected to distinct service providers (RADIUS roaming using NAI)
> - This is unlikely in SIP/HTTP environments, as RADIUS is not used for layer 2
> access authentication here. A user can access directly his SIP/HTTP server.
> This is different from the classical RADIUS use.
>
> In IMS -- where there is a coupling between SIP and lower layers --, roaming
> is done on the the SIP level. As far as I know, there is no RADIUS or Diameter
> connection between different IMS providers.
>
> B) A provider changes its equipment gradually from plain HTTP digest to AKA digest.
>
> In the case of Digest Authentication, RADIUS clients are never talking to RADIUS
> or Diameter servers of a different provider.
>
> My feeling is that there will be providers that will never bother about server-side
> nonce generation. Others will never consider client-side nonce generation. Mandating
> both modes will only complicate the initial configuration for them.
>
> What does the group think?
>
>
> Wolfgang
>
> --
> T-Systems
> Next Generation IP Services and Systems
> +49 6151 937 2863
> Am Kavalleriesand 3
> 64295 Darmstadt
> Germany 

--
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.an.garcia@openlaboratory.net
Nokia Research Center      Helsinki, Finland


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