AW: AW: AW: Digest Authentication: Security issue with https/sips

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

Miguel,

> So if A calls B, it is only A's network that can authenticate and 
> authorize A's call. If A uses a SIPS URI to address B, it 
> just want to have secured signalling connection betweeen A and B, and does 
> not care  about the sortages of A's network and not protecting the 
> RADIUS interface.
But A's RADIUS connection is part of the signalling connection
between A and B.

> 
> And then we come to the normative statements that you are placing for 
> HTTP and SIP, I don't think it is valid for a RADIUS document 
> to contain such statements. The WG that deal with those protocols should 
> attack the problem and extend the protocol, if needed.
> 

Consider the following proposal (section RADIUS client behaviour):
"If the scheme in the digest-uri directive indicates a secure HTTP-style
connection (eg sips, https) and the RADIUS client does not have a secure
connection to its RADIUS server, it MUST act as if it had received an
Access-Reject."

Less comprehensible, but no normative statement for SIP or HTTP.


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