RE: RADIUS Attribute Hiding and radext-digest-auth

[Avi Lior <avi@bridgewatersystems.com>]

I need to think about your proposal but my immediate reaction to Ipsec is
that its not a good thing to make it mandatory.


> -----Original Message-----
> From: Beck01, Wolfgang [mailto:BeckW@t-systems.com] 
> Sent: January 5, 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/>