Subject: [Sipping] Review of draft-saito-mmusic-sdp-ike

From: Richard Barnes <[email-masked]>
Date: Mon, 13 Aug 2007 14:17:22 -0400

Draft:  draft-saito-mmusic-sdp-ike-01
Reviewer: Richard Barnes
Review Date: 13 Aug 07

General Comments:
------------------------------------------------------------------------
1. This document seems to be doing two things: (1) Using SDP carried in 
SIP to initiate an IKE session, and (2) Defining how SIP Identity can be 
used in lieu of IKE authentication.

1.1. With respect to signaling IKE in SIP/SDP:

1.1.1 What is this document trying to get out of SIP/SDP?   If it's 
trying to get redirection to various IP addresses, there's already the 
DNS for that.  If it's trying to do NAT traversal, IKE already has 
mechanisms for that. (RFC 3497)

1.1.2.  SDP attributes defined by this document provide an incomplete 
definition of the resulting traffic stream. The document doesn't say 
anything about how IPsec traffic negotiated by this mechanisms should be 
handled.  As Ekr has pointed out, if you're going through NATs you'd 
probably want to do something like ICE for IPsec or encapsulating IPsec 
in UDP.  Whatever the solution is, even if it's just doing RFC 3947 NAT 
traversal, this document should say how the negotiated IPsec traffic 
should be carried.

1.2. With respect to re-using SIP Identity & self-signed certificates:

1.2.1. The security model you're using here is not clear.  This document 
should describe in detail (referring to RFC 4474 and RFC 4306) how the 
two parties authenticate each other, both at the SIP layer and at the 
IKE and IPsec layers.

1.2.2. This document does not address how the authenticated identity is 
connected to IPsec's authorization mechanism, i.e., the PAD.  RFC 4301 
defines the contents of PAD entries, including specific sets of 
acceptable identifiers, and acceptable authentication protocols and 
mechanisms.  In order to use SIP identity to identify IPsec peers, you 
need to define how one constructs and retrieves the relevant PAD entries.

1.2.3. Likewise, the IPsec authorization process uses either the remote 
IP address or the content of the IKE ID payload as an identifier.  So 
you'll need to fill the authenticated identity into the IKE ID payload, 
but you'll need to make sure this doesn't cause IKE authentication to fail.

2. The document suggests several times a relationship between the 
lifetime of the SIP-negotiated session, the lifetime of the IKE 
exchange, and the lifetime of the IPsec SA.  Please clarify this.

3. There's no reason to limit the mechanisms here to tunnel mode (and 
hence no need to involve VPNs).  I think this can be mostly fixed by 
changing instances of "VPN tunnel" to "IPsec SA".

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 13 Aug 2007 17:09:08 -0700

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]] 
> Sent: Monday, August 13, 2007 11:17 AM
> To: MMUSIC; SIPPING
> Subject: [Sipping] Review of draft-saito-mmusic-sdp-ike
> 
> 1. This document seems to be doing two things: (1) Using SDP 
> carried in SIP to initiate an IKE session, and (2) Defining 
> how SIP Identity can be used in lieu of IKE authentication.

In *conjunction* with IKE authentication.  IKE authentication
still occurs, even with draft-saito-mmusic-sdp-ike -- very much
like comedia-tls (RFC4572) uses TLS for authentication and
also conveys the certificate fingerprint in SDP (a=fingerprint).

What the draft says is that instead of using certificates
for your identity assertion (a meaningful subjectAltName,
validation of the CA signature, and checking CRLs), you could
instead use SIP-Identity's assertion of identity.

> mechanisms for that. (RFC 3497)

The advantage of SIP over Dynamic DNS is explained in
slide 3 of http://www3.ietf.org/proceedings/07jul/slides/sipping-11.ppt,
namely;

  * Name resolution to a floating IP address (admittedly, this
    is also possible with DynDNS, as indicated in the slide).
  * ability to delegate user authentication (identity) to a 
    3rd party (rely on SIP-Identity's signature rather than
    a meaningful subjectAltName).
  * hole punching.  RFC3497 won't work if both endpoints are behind
    NATs; RFC3497 only works if the IKE initiator is behind a NAT
    and the IKE 'server' (VPN concentrator, most typically) has a 
    public IP address and its IKE UDP port is not firewalled.
  * re-use of existing SIP infrastructure, which takes advantage
    of the above features for VoIP, to deploy a new, non-VoIP service

> traversal, this document should say how the negotiated IPsec traffic 

I agree it should be clearer about what happens after IKE is 
negotiated, and if we switch to RFC3948 (IPsec-over-UDP) or try
to do plain IPsec (protocol 50).

> 1.2.1. The security model you're using here is not clear.  
> This document should describe in detail (referring to RFC 4474 
> and RFC 4306) how the two parties authenticate each other, both 
> at the SIP layer and at the IKE and IPsec layers.

Thanks.  We'll improve that.

> need to define how one constructs and retrieves the relevant 

draft-saito-mmusic-sdp-ike does not replace or supercede IKE,
so I don't understand what needs to be said.  Can you provide
additional guidance on what you'd like to see here?

> but you'll need to make sure this doesn't cause IKE 

IKE still works as-is.

> exchange, and the lifetime of the IPsec SA.  Please clarify this.

I only found one such discussion in section 2, Protocol Overview:

   If the high-level application thinks a VPN session as the media
   session, it will discard the security policy and terminate IKE when
   that media session is terminated by BYE request. 

> changing instances of "VPN tunnel" to "IPsec SA".

That would be a worthwhile enhancement.  Thanks for suggesting it!

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 13 Aug 2007 17:09:08 -0700

IKE still works as-is.

-d

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Richard Barnes <[email-masked]>
Date: Tue, 14 Aug 2007 09:59:01 -0400

Hi Dan,

> slide 3 of http://www3.ietf.org/proceedings/07jul/slides/sipping-11.ppt,
<snip>
>     a meaningful subjectAltName).

You can already delegate authentication to a CA in IKE.  You're just 
replacing the CA key with the Authentication Service's key.

>     public IP address and its IKE UDP port is not firewalled.

I'm not sure of the utility of this.  It's not like IKE uses a whole 
bunch of different ports like RTP does -- it's always on port 500.  If 
you want to allow IKE, just open port 500.

>     of the above features for VoIP, to deploy a new, non-VoIP service

This is irrelevant -- "SIP infrastructure" includes DNS infrastructure 
(to support REFC 3693 routing), so if you've got SIP infrastructure, you 
might as well use the DNS.  And conversely, not using SIP (just DNS) 
allows people who only have DNS to do the same redirection.

> additional guidance on what you'd like to see here?

Sure.  Section 4.4.3 of RFC 4301 defines the authorization mechanism for 
IPsec -- the Peer Authorization Database, or PAD.  The PAD has entries 
that contain:
1. An identifier or set of identifiers
2. Authentication protocol(s) (e.g. IKE, KINK)
3. Authentication method(s) (either X.509 or PSK)
4. Authentication data (either X.509 trust anchor or the PSK)

When an request for a new SA comes in (via IKE), the IPsec endpoint 
checks (in order) that
1. The authenticated identifier (e.g. X.509 DN) has a PAD entry
2. The authentication parameters in the PAD match what actually 
happened, e.g., the identifier was authenticated through IKE with a 
certificate verified by the included trust anchor.

With respect to the first check, you need to specify how identifiers are 
derived from the self-signed certificate (i.e., where the SIP identity 
needs to be placed)

Without more explanation, I'm not sure how you would handle the second 
check: You're obviously not using a PSK, and there's no trust anchor to 
verify a self-signed certificate.  You may want to look into the work 
that the BTNS working group is doing.

> I only found one such discussion in section 2, Protocol Overview:

That paragraph seems to imply that the IPsec (Child) SA should be 
terminated when the BYE request is accepted, and that any IKE 
negotiations in process should be terminated.  (Note that it's the SA 
that's discarded, not the policy!)  Is this what you meant to say?

If so, you need to address two issues:
1. IKE has its own mechanisms for negotiating SA lifetimes, so you'll 
need to specify how to set IKE parameters to be compatible with this.
2. How should IKE SAs be handled?  Should they be terminated on the BYE 
as well?

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 14 Aug 2007 09:44:58 -0700

> > slide 3 of 
> http://www3.ietf.org/proceedings/07jul/slides/sipping-11.ppt,
> > namely;
> <snip>

To delegate authentication to a CA in IKE, you need a certificate
whose subjectAltName matches something that makes sense -- such
as being the hostname or username or friendly name.  This is what
we're trying to avoid.

> bunch of different ports like RTP does 

RTP only needs one port, now-a-days (draft-ietf-avt-rtp-and-rtcp-mux).

> -- it's always on port 
> 500.  If you want to allow IKE, just open port 500.

IKE doesn't always have to run on 500, it could run on any port
you want.  And, certainly, if two hosts are behind their own
respective NATs and want to establish IKE between themselves
(and thereafter IPsec), it is very unlikely either of them will
get UDP/500 from their NAT.

RFC3974 (section 4) explains that using UDP/500 can, itself,
be problematic because IKE-aware NATs try to be overly helpful
but instead cause more problem for IKE.  

To your argument, though, DNS SRV records (in conjunction with
dynamic DNS) could also advertise a non-UDP/500 port.  However,
if you're behind a NAT, and you don't have NAT-PMP or UPnP,
it's difficult to keep that port open.  Existing SIP techniques
(SIP-Outbound) keep SIP signaling active, allowing a SIP-
initiated call to the device which can then, for that call,
open the pinholes through the necessary NATs.

> allows people who only have DNS to do the same redirection.

Dynamic DNS doesn't provide the same functionality.

> derived from the self-signed certificate (i.e., where the SIP 
> identity needs to be placed)
> 

Ok, thanks.

> 2. How should IKE SAs be handled?  Should they be terminated 
> on the BYE as well?

Yes, I don't see any reason to keep IKE active after the SIP BYE.

-d

---

From: Richard Barnes <[email-masked]>
Date: Tue, 14 Aug 2007 16:11:03 -0400

> as being the hostname or username or friendly name.  This is what

IKE and IPsec don't make any particular demands on the relationship 
between the certificate and the authenticated identifier, just on what 
goes in the IKE ID payload.  To quote RFC 4301:
"
    This document does not require that the IKE ID asserted by a peer be
    syntactically related to a specific field in an end entity
    certificate that is employed to authenticate the identity of that
    peer.
"

However, you will need to define what identifier gets put in the IKE ID 
field, since that's the identifier that gets used for IPsec 
authorization.  So if you define which identifiers to use, the 
certificate can be whatever you want (subject to policy) -- provided 
that you work out the issues with self-signed certs I mentioned before.

> Yes, I don't see any reason to keep IKE active after the SIP BYE.

On the other hand, I don't know if you should necessarily throw the IKE 
SA away after the SIP BYE.  There are reasons to keep IKE SAs around for 
some time, namely that it saves a Diffie-Hellman computation from the 
next setup (in IKEv2; there are other, different savings in IKEv1). 
It's reminiscent of credential caching used by other protocols.

I guess you need to clarify what the SDP in the SIP transaction is 
describing: The IKE negotiation, the IKE SA, the IPsec SA, or some 
combination of the above.  If it's just the IKE packets that you're 
worried about, you could send the BYE after I think 6 IKE packets and 
let the SAs carry on.  If you're worried about the BYE tearing down 
whatever NAT magic you've done, then you'll need to postpone it until 
the IPsec SA is done.  Perhaps instead of saying "tear down the IPsec 
stuff when you see a BYE", you should say "don't send a BYE until you're 
done doing IPsec".

--Richard

---

From: Dean Willis <[email-masked]>
Date: Thu, 16 Aug 2007 10:32:38 -0500

On Aug 13, 2007, at 1:17 PM, Richard Barnes wrote:

> carried in SIP to initiate an IKE session, and (2) Defining how SIP  
> Identity can be used in lieu of IKE authentication.
>

I think you're looking at the side-effects, not the central theme.  
And I'm not sure the draft really brings the central them into clear  
focus.

The question to ask is "Why do people want to use SIP to establish an  
IPSEC SA"?

And the answer, I think, has to do with:

1) SIP's utility as a cross-nat rendezvous mechanism. We currently  
don't have any other good way for node A, which is behind a NAT, to  
find and establish communication with node B, which is also behind a  
NAT. Much of the complexity of SIP, including "ice", "outbound", and  
"gruu", is involved in solving this problem. This is a very difficult  
problem to solve, and many communications modalities suffer from it.  
Having solved it in SIP, we can expect to see attempts to use SIP to  
bootstrap a solution to all those communication modalities.

2) SIP's extension of the domain namespace to include "user parts",  
allowing more flexible addressing that includes subaddressing at a  
given host without burning more IP address space.

Of course, one might argue that we'd have a cleaner model if we  
replaced many of these SIP graft-ons with a transport protocol that  
handles them transparently and independently from the application.  
We've started talking about ways to do that in P2PSIP. But for now,  
SIP is the only hammer we have that appears to succeed in driving  
this kind of nail.

--
Dean

---

From: Makoto SAITO <[email-masked]>
Date: Thu, 16 Aug 2007 19:45:29 -0400

Hi Richard and Dean,
Thank you for your comments.

As Dean pointed, it will be a decisive reason of using SIP
that SIP is the most effective way to launch the NAT-T mechanism.
I don't see any reasons not to use SIP to establish IPsec in this
situation (although the current draft only specifies the NAT-free
cases).

By the way, I also believe it is a big advantage to delegate
authentication to 3rd party (sip proxy) very easily by just riding
existing SIP infrastructure and SIP-identity mechanism.
I may also have to look closely at BTNS works as Richard said,
but I think using finger print of self-signed cert endorsed by
SIP-Identity is fairly simple way because your application only
keeps the faithful fingerprint for the following IKE authentication.
Of course, we need to brush-up the technical details not mentioned
in the current draft, so it is very helpful to dig down the details.

-- 
Makoto Saito

Dean Willis wrote:
>> 1. This document seems to be doing two things: (1) Using SDP carried 
>> in SIP to initiate an IKE session, and (2) Defining how SIP Identity 
>> can be used in lieu of IKE authentication.
>>
> 
> I think you're looking at the side-effects, not the central theme. And 
> I'm not sure the draft really brings the central them into clear focus.
> 
> 1) SIP's utility as a cross-nat rendezvous mechanism. We currently don't 
> have any other good way for node A, which is behind a NAT, to find and 
> establish communication with node B, which is also behind a NAT. Much of 
> the complexity of SIP, including "ice", "outbound", and "gruu", is 
> involved in solving this problem. This is a very difficult problem to 
> solve, and many communications modalities suffer from it. Having solved 
> it in SIP, we can expect to see attempts to use SIP to bootstrap a 
> solution to all those communication modalities.
> 
> allowing more flexible addressing that includes subaddressing at a given 
> host without burning more IP address space.
> 
> Of course, one might argue that we'd have a cleaner model if we replaced 
> many of these SIP graft-ons with a transport protocol that handles them 
> transparently and independently from the application. We've started 
> talking about ways to do that in P2PSIP. But for now, SIP is the only 
> hammer we have that appears to succeed in driving this kind of nail.
> 
> -- 
> Dean
> 
> 
>