RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard

["Christian Huitema" <[e-mail]>]

There are multiple issues with your reference to the DHCPv6 draft.
First, let me observe that the DHCPv6 draft proposes two security
solutions, the use of "delayed authentication", which relies on a
pre-shared key, and the use of IPSEC, for which key negotiation and key
validation is not specified. At a minimum, the SIP option draft should
explain how these mechanisms can be used to mitigate the SIP-specific
security risks. We should also explain in which contexts these security
mechanisms can be used. For example, the DHCPv6 draft states that:

   The "delayed authentication" protocol does not attempt to address
   situations where a client may roam from one administrative domain
   to another, i.e.  interdomain roaming. This protocol is focused on
   solving the intradomain problem where the out-of-band exchange of a
   shared key is feasible.

Shall we conclude that the SIP option should not be used in roaming
scenarios? If that is the case, then we have a serious application
domain restriction, which should be very clearly stated in the SIP
option draft. If you actually want to address a roaming scenario, then
you have to describe how you are going to use IPSEC between the server
and the client, and how you are going to validate the IPSEC keys.

The DHCPv6 document itself is still a draft. Since you need a normative
reference, the publication of the SIP option has to be gated by the
publication of DHCPv6 itself.

Finally, there are security issues with the very concept of an outgoing
proxy, which is essentially a "man-in-the-middle" by design.  I would
expect SIP agents to perform some level of validation before they decide
to use the outgoing proxy proposed by the local network. In most roaming
scenarios, the SIP agent will probably elect to simply maintain a secure
connection with its "home server", and ignore the local proxy -- just
like most mail agent simply get their mail using an IMAP or POP3
connection to their mail server, instead of forwarding the mail to a
local server.

-- Christian Huitema

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[e-mail]]
> Sent: Tuesday, May 28, 2002 9:22 AM
> To: Christian Huitema
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Sip] Last Call: DHCPv6 Options for SIP Servers to
Proposed
> Standard
> 
> Christian,
> 
> thanks for your comment. I'm slightly confused, however, why this
> particular problem is any different for SIP servers than for any
other,
> non-SIP server identified by a DHCPv6 server. Also, Section 21 of
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-25.txt
> addresses this particular issue. Could you clarify your comments in
> these two aspects?
> 
> Henning
> 
> Christian Huitema wrote:
> > I have a major issue with this spec, namely that the security
problems
> > are not addressed. The security section correctly lists one of the
main
> > security threats, the spoofing of a DHCP server:
> >
> >    The security considerations in RFC XXXX [1], RFC 3261 [2] and RFC
> >    3263 [3] apply. If an adversary manages to modify the response
from a
> >    DHCP server or insert its own response, a SIP user agent could be
led
> >    to contact a rogue SIP server, possibly one that then intercepts
call
> >    requests or denies service. A modified DHCP answer could also
omit
> >    host names that translated to TLS-based SIP servers, thus
> >    facilitating intercept.
> >
> > This is a very real attack, especially in the deployment phase of
IPv6,
> > when there may not even be an actual DHCPv6 server on the local
network.
> > Think for example of an 802.11 hotpoint, in which any enterprising
> > attacker could publish his very own DHCPv6 server. Yet, the security
> > work seems to stop here. There is no attempt at mitigating the
attack.
> > IMHO, we should not publish a spec that open the door for a grave
attack
> > and offers no mitigation.
> >
> > -- Christian Huitema
> >
> >
> >>-----Original Message-----
> >>From: The IESG [mailto:[e-mail]]
> >>Sent: Wednesday, May 22, 2002 12:21 PM
> >>Cc: [e-mail]
> >>Subject: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed
> >>Standard
> >>
> >>
> >>The IESG has received a request from the Session Initiation Protocol
> >>Working Group to consider DHCPv6 Options for SIP Servers
> >><draft-ietf-sip-dhcpv6-00.txt> as a Proposed Standard.
> >>
> >>The IESG plans to make a decision in the next few weeks, and
solicits
> >>final comments on this action.  Please send any comments to the
> >>[e-mail] or [e-mail] mailing lists by June 5, 2002.
> >>
> >>Files can be obtained via
> >>http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt
> >>
> >>
> >>
> >>
> >>
> >>_______________________________________________
> >>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>This list is for NEW development of the core SIP Protocol
> >>Use [e-mail] for questions on current sip
> >>Use [e-mail] for new developments on the application of sip
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [e-mail] for questions on current sip
> > Use [e-mail] for new developments on the application of sip
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip