RE: RADIUS Attribute Hiding and radext-digest-auth

[Avi Lior <avi@bridgewatersystems.com>]

Hi Wolfgang,

My initial "gut" reaction is not to solely rely on Ipsec because of
deployment issues.  That is, we should encrypt these values because there
are not that many IPSec RADIUS deployements out there.

However, on second thought it seems that in most commercial deployments the
RADIUS infrastructure is secure anyway.  As well, there seems to be a lot of
SIP deployments but I am not aware of SIPS which is where you would use this
anyway right?

So perhaps we can just state in the security section that if HTTPS or SIPS
is being used then we need to use Ipsec.

Regarding Digest-HA1. If you must send it back from the server to the client
then you can use 2868.



> -----Original Message-----
> From: Beck01, Wolfgang [mailto:BeckW@t-systems.com] 
> Sent: Wednesday, January 05, 2005 10:43 AM
> To: radiusext@ops.ietf.org
> Subject: RADIUS Attribute Hiding and radext-digest-auth
> 
> 
> Hi,
> 
> so we have some ways to encrypt individual RADIUS attributes. 
> When authorizing sips or https connections, at least RADIUS 
> attributes revealing the identity must be encrypted. In 
> radext-digest-auth this applies to the following attributes:
> - User-Name
> - Digest-Username
> - Digest-URI
> - SIP-AOR [not yet in the draft]
> 
> Digest-HA1 would profit from encryption, too.
> 
> We can re-define Digest-Username, Digest-URI and SIP-AOR to 
> use one of the encryption algorithms Bernard summarized in a 
> previous post. We can't do this for User-Name, a new 
> Encrypted-User-Name attribute would be necessary.
> 
> Message-Authenticator does not help here.
> 
> Should I change the document to use the attribute hiding 
> mechanism (Tunnel-Password) described in RfC 2868, despite 
> its weaknesses?
> 
> Or is making IPSec mandatory in the relevant cases acceptable 
> (as it is in the current version)?
> 
> 
> Wolfgang
> 
> --
> T-Systems
> Internet Platforms
> +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/>
> 

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