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

["Beck01, Wolfgang" <BeckW@t-systems.com>]

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 

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