Re: [MMUSIC] Review of draft-saito-mmusic-sdp-ike-06

[Makoto Saito <[e-mail]>]

Eric,

Thank you very much for your comments again.
My comments inline..

(2009/12/27 5:38), Eric Rescorla wrote:
> At Tue, 22 Dec 2009 00:36:49 +0900,
> Makoto Saito wrote:
>>> My skepticism is that setting up a VPN for applications like this
>>> seems like overkill. VPNs have a bunch of ancillary security
>>> implications that aren't really necessary for these applications.
>>> It's important to remember that IPsec provides not only a network
>>> connectivity function but also a firewalling function.  (RFC 4301 S 2.1),
>>> and I worry that we're confusing these two to some extent. Consider
>>> the last case, the gaming system. In this case, we don't want to
>>> open a generic VPN connection, we want to open a connection directly
>>> to the gaming up. Why is IPsec a good mechanism here? The
>>> other examples seem to raise the same issue.
>>
>> Actually, joining the same local network makes DLNA perform very
>> effectively.
>>
>>    We are particularly focusing on LAN-based applications
>> so that it is not necessarily an overkilling to set up VPN for those
>> applications. For example, DLNA is used to share private contents
>> inside the LAN but it doesn't have sufficient security mechanisms
>> for the use over the Internet. So we think VPN is a simple solution
>> for that purpose. Anyway, we already have the implementation for
>> this application and start to deploy them.
>
> So, this likely is bad design by DLNA--the distinction between LAN and
> WAN just isn't strong enough security-wise to support this. ISTM
> better to fix this issue than to perpetuate it.

We don't have a strong opinion on the design of DLNA's framework.
We just want to make use of VPN to use applications over the Internet
which are supposed to work in relatively secure environments of LAN.
We believe it is not unusual to use VPN for such purposes.

>>> I should also mention that in terms of implementation complexity,
>>> ICE seems like a real problem. The issue here is file descriptor
>>> and channel management. The obvious way to implement an ICE stack
>>> (and the way that mine works) is that the stack opens socket(s)
>>> locally and then presents an abstraction to the application which
>>> it can then use to read and write on. However, in this case, we
>>> have three separate pieces of code (and probably execution contexts)
>>> which all need to send/receive data on the same socket:
>>>
>>> - The ICE stack
>>> - The IKE stack
>>> - The IPsec stack
>>>
>>> And the demultiplexing between these is data dependent. Doesn't this
>>> mean that we'll need a central dispatcher process whose job it is
>>> to hand off the packets to each other module? I'm having trouble
>>> visualizing this being something people are willing to implement.
>>
>> The demultiplexing process is simply a combination of existing
>> demultiplexing processes of ICE and IKE-NAT-T. That is,
>>      if bits 0..31 == 0, dispatch to IKE module
>>      else if bits 32..63 == magic-cookie, and parsing packet yields
>>         STUN fingerprint, dispatch to ICE module
>>      else dispatch to IPsec module
>>
>> Anyway, it is true that the combination of ICE and IKE/IPsec is
>> complicated because ICE by its nature complicated. We don't think
>> ICE should be a MUST in this specification. In fact the environment
>> where we are deploying this we actually don't need ICE, but we
>> foresee a need for ICE despite its complexity in different
>> environment where this specification may be deployed.
>
> I think you're missing my point, which is that intermixing
> IPsec packets with STUN/ICE/IKE packets requires a fairly
> inconvenient system architecture.

We made ICE implementation optional.

Although it is not the case in our deployment, in some environment
where ICE is necessary to traverse NAT/FW, intermixing ICE/IKE/IPsec
packets would be necessary if ICE is to be used with RFC3947 and
3948. If there is a better way other than ICE for NAT traversal,
we'd be happy to recommend it over ICE.

>>> 3. Security Model
>>> As I understand it, the way that this system is intended
>>> to work is that the home system has an ACL indexed by remote
>>> AOR. If a SIP call comes through allegedly from a permitted AOR
>>> (via RFC 4474) it allows the VPN connection to be established.
>>> That seems to place a very large amount of trust in the SIP
>>> proxy. In essence you're giving the SIP proxy the keys to your
>>> firewall. I can't really see any circumstances in which I would
>>> be willing to do that.
>>>
>>> By contrast, classic IPsec/SSH/SSL VPNs rely on credentials
>>> that are immediately on the the remote side. That seems far
>>> more secure.
>>
>> SIP proxy is not necessarily given a strong authority to
>> establish a VPN into a home network.
>> This draft does not eliminate other authorization or
>> authentication that a user or an implementation might
>> want to perform before bringing up the VPN.  For example,
>> password authentication can be used in addition to what
>> is described in the draft.  This is described in Section 8.
>
> Wait, so I now need two separate authentication mechanisms
> plus I have to worry about coordinating my firewall and IPsec
> with the SIP authentication? This seems problematic.

It is true that that under following circumstances, security
based on SIP authentication provided by SIP proxy may be breached.
So, we will be adding the following items in Security Considerations
and clarifying the issues and countermeasures.

1. If a legitimate user's terminal is used by another person,
    it can establish a VPN with the legitimate identity information.
    This issue also applies to the general VPN cases based on the
    shared secret key. Furthermore, in SIP we have a similar problem
    when file transfer, IM or Comedia where non-voice/video is used
    as a communication.

2. If the proxy is hijacked by malicious users, he or she can use
    whatever credential on the ACL to gain access to the home network.

For the countermeasures to these issues, it is recommended to use
unique information such as password which only a legitimate user knows
for VPN establishment. Checking the originating user by voice or video
before establishing VPN would be another method.

>>> I am also concerned about the fairly loose coupling between the
>>> authentication at the IKE layer and the firewall hole punching.
>>> As I understand it, the SIP/ICE system doesn't do any authentication
>>> at all: it just punches a hole and then propagates the packets to
>>> the IKE/IPsec system without looking at them at all. I don't
>>> see any immediate way to exploit this, but it's not clear to me
>>> that it's safe either.
>>
>> I'm afraid that there is a misunderstanding here, and likely
>> there is a text in the draft that is misleading.
>> In our use cases, a home router is a SIP UA and it doesn't
>> open a hole to the home network until IPsec tunnel is established.
>> The holes which SIP/ICE try to open are on external routers such
>> as a large scale NAT on ISP network. In either case, the home network
>> never sees a packet until both SIP and IKE negotiations have completed
>> successfully.
>
> I'm not talking about the home network. I'm talking about the
> interaction between the NAT/firewall on the home router
> and the rest of the networking system on the same router.

The packets which IKE/IPsec system accepts are only the IKE/IPsec
packets which are authenticated and encrypted at IKE/IPsec layer.
The packets related to SIP/ICE don't invade the IKE/IPsec system.
It is totally the same as how a VPN router deals with VPN packets,
so we don't see any particular problem.

>>> 4. Multiplexing
>>> Why are you using the same channel for IKE and IPsec tunnelling?
>>> IKE supports multiple media channels. This seems like an architectural
>>> issue, which is why I have it in general comments.
>>
>> RFC3947 and 3948 specify the method of IPsec NAT traversal and
>> it uses the same channel for IKE and IPsec. We don't try to do
>> anything special here.
>
> Hmm... I'm surprised to hear that, but I guess if/when this goes up
> for IETF LC the IPsec experts can weigh in if there is a problem.
>
> -Ekr
>

I'll modify the draft as for the points I already agreed in
the previous mail.
Again, thank you very much for your helpful comments.

Best regards,

Makoto