Digest Authentication: Security issue with https/sips

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

Wolfgang, and the Radius extensions WG:

I was revising the RADIUS Digest authentication draft, to find out 
missing features that should be transposed to the Diameter SIP app. On 
doing this exersice I came to a paragraph on the RADIUS Client section 
that reads:

   If the packets between RADIUS client and RADIUS server are not
   protected with IPsec, the RADIUS client MUST NOT accept secured
   connections (like https or sips) from its HTTP-style clients, so that
   HTTP-style clients are not provided with a false sense of security.

I think this paragraph is not totally correct, and deserves a bit more 
of discussion. Here are my thoughts:

First, I don't like the idea that a RADIUS draft (soon to be RFC) puts a 
normative statement to non-RADIUS protocols, namely HTTP(RFC 2616/17) 
and SIP (RFC 3261). I am referring to the sentence that reads "... the 
RADIUS client MUST NOT accept secured connections (like https or sips) 
from its HTTP-style clients ...". At least in the Diameter SIP 
application we have put a lot of effort to just define the behaviour of 
the Diameter client, not the SIP server or SIP User Agent that is 
co-located with the Diameter client. In your document, even when the 
text says "the RADIUS client" it is not correct, because it refers to 
refusing an HTTP or SIP session, which takes place outside the RADIUS 
client, presumably in an HTTP/SIP server.

The second thing is that you are (IMHO) wrongly overloading the 
semantics of at least the SIPS URI, which is clearly defined in RFC 3261:

   "A call
   made to a SIPS URI guarantees that secure, encrypted transport
   (namely TLS) is used to carry all SIP messages from the caller to the
   domain of the callee.  "

Notice that a SIPS URI has nothing to do with the mechanism whereby a 
SIP proxy authenticates a user who has created some SIP request, and has 
nothing to do with the security of protocols beyond SIP. Notice even 
that the semantics of the SIPS URI does not mean that TLS is in every 
two hops from the caller to the callee, but rather that TLS is used from 
the caller to ***the domain of the callee*** (from them onwards, there 
could be anything). Similar things apply to HTTP, where I don't expect 
that the TLS security between the client and the server is mixed up with 
the security in the network to authorize the client's requests.

So do people have an opinion on this topic? In my opinion the above 
paragraph should be deleted from the current section. I think you can 
add some discussion of the threats and provide recommendations in the 
Security Consideration sections, but the current text is not acceptable 
(it is not even implementable, since it does not affect RADIUS).

/Miguel


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