AW: Digest Authentication: Security issue with https/sips

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

Miguel,

> 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 ...".
Unfortunately, the SIP/HTTP RfCs do not mention AAA servers. Do
you propose a separate draft "https/sips usage with AAA protocols"?
Is there a better behaviour than refusing the sips/https?

> 
> 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.  "
> 
RfC 3261, section 19.1 tells us (emphasis by me):
"
   A SIPS URI specifies that the resource be contacted securely.  This
   means, in particular, that TLS is to be used between the UAC and the
   domain that owns the URI.  From there, >>>secure<<< communications are used
   to reach the user, where the specific security mechanism depends on
   the policy of the domain."

So, secure communications has to be used, but not necessarily TLS. If
I recall the SIP WG discussions correctly, the whole point of sips was
to guarantee secure hops along the path of a SIP request.

> it is not even implementable, since it does not affect RADIUS
The question is whether implementors will understand the desired
behaviour. Introducing the concept of RADIUS and SIP/HTTP subsystems
interacting with some internal protocol will not help.

Wolfgang

--
T-Systems International GmbH
Systems Integration
Technologiezentrum
Engineering Networks, Products & Services
Next Generation IP Services & Systems
Am Kavalleriesand 3
64295 Darmstadt
Tel +49 6151 937 2863



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