Subject: RE: [Sip] TLS section

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 28 Jan 2002 17:24:23 -0600

Thanks Brian, I'm actually really interested in this topic as well.

I think it would be interesting first to learn who on this distribution
prefers to provide lower-layer security for SIP with IPSec rather than TLS,
and then moreover whether those that do prefer IPSec would rather use
transport mode (host-by-host, integrated with SIP applications) or tunnel
mode (not integrated with SIP applications, using security gateways).

Just to be clear about a couple of things surrounding this proposed IPSec
profile:

- Can we spell out a bit what we mean by HMAC-MD5-NULL? The string doesn't
appear in 2406, anyway. For example, is the NULL for authentication, or
encryption, or both?

- Will implementations supporting this profile by be compliant with the
minimum conformance requirements in rfc2406 section 5?

- This assumes pre-shared keys, and entails no key exchange capabilities
(i.e. IKE), right?

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Monday, January 28, 2002 2:27 PM
> To: 'Peterson, Jon'; 'Michael Thomas'; [email-masked]
> Subject: RE: [Sip] TLS section
>
> 
> I'm curious about the following:
> > >    ................ Any deployment of IPSec for SIP would 
> > require an
> > >    IPSec profile describing the protocols tools that would 
> > be required
> > >    to secure SIP and the modes in which they would 
> operate. No such
> > >    profile is given in this document.
> > > 
> > > Please, this doesn't have to be hard. ESP RFC 2406
> > > in transport mode with HMAC-MD-5-NULL should be
> > > all that needs to be supported to get
> > > interoperability.
> > 
> > I'm not sure this is sufficient; most of the other advocates 
> > of IPSec seem
> > to want some sort of security gateway solution. I think we 
> > should shake this
> > out somewhere other than bis.
> 
> Can we see some comments from IPSec advocates whether a
> MUST IMPLEMENT for transport mode with HMAC-MD-5-NULL
> is acceptable?
> 
> Brian
> 
> *********This message is definately not confidential and it does
> not matter in practice who sees it and whether or not it goes 
> astray. No
> harm whatever would come to anyone even if it were published in a
> national newspaper. I apologise therefore for the unnecessary and
> irritating message that may or may not follow (I don't know 
> because it is
> invisible to me)!!!!******
> 
> 
> This e-mail and any attachments are confidential. If you are not the
> intended recipient, please notify us immediately by reply 
> e-mail and then
> delete this message from your system. Do not copy this e-mail or any
> attachment, use the contents for any purposes, or disclose 
> the contents to
> any other person: to do so could be a breach of confidence.
> 

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

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Jan 2002 15:38:41 -0800 (PST)

> mode (not integrated with SIP applications, using security gateways).

I think the important question to ask here is how
many people are implementing UDP UA's.
 
 > appear in 2406, anyway. For example, is the NULL for authentication, or

NULL encryption transform. RFC 2410 describes it.

 > minimum conformance requirements in rfc2406 section 5?

Not to the letter of the law. The only encryption
manadatory is DES and NULL; you can say that DES
is forbidden by policy and optimized out of the
code (many do, actually). Beyond that, you'd need
SHA-1, though I frankly think that might have been
overkill.
 
 > - This assumes pre-shared keys, and entails no key exchange capabilities

Right. As in, you punt on key exchange.

	  Mike

---

From: Dean Willis <[email-masked]>
Date: Tue, 29 Jan 2002 09:54:11 -0600

Jon asked:
> I think it would be interesting first to learn who on this
> distribution prefers to provide lower-layer security for SIP with
> IPSec rather than TLS, and then moreover whether those that do prefer
> IPSec would rather use transport mode (host-by-host, integrated with
> SIP applications) or tunnel mode (not integrated with SIP
> applications, using security gateways).

Making either one a "MUST" is a BAD idea. It means that far too many 
smaller systems, or systems with other security mechanisms, can never 
comply with the specification. 

The implementors, forced to selectively ignore some requirements of the 
specification, are likely to ignore other parts of the spec as well.  
It's kind of like "having shot the security gaurd, you might as well go 
ahead and rob the bank -- the penalty is not any worse".

Or those implementors may just demonstrate good sense and switch to an 
implementable protocol and ignore our further academic and irrrelevant 
ramblings.

Requirements which significantly impact applicability must be carefully 
bounded, with specific exemptions granted and alternatives allowed.

--
Dean

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Jan 2002 09:15:59 -0800 (PST)

> comply with the specification. 

   If you choose TLS, that is correct. If you
   chose IPsec and are silent on key distribution,
   that is not correct unless you're going to tell
   me that we can't get people to burn a maximum
   of 6kb of code (probably less than 1kb since digest
   is already a MUST).

	      Mike

---

From: Dean Willis <[email-masked]>
Date: Tue, 29 Jan 2002 12:50:04 -0600

On Tuesday 29 January 2002 11:15 am, Michael Thomas wrote:
>  > > distribution prefers to provide lower-layer security for SIP
>  > > with IPSec rather than TLS, and then moreover whether those that
>  > > do prefer IPSec would rather use transport mode (host-by-host,
>  > > integrated with SIP applications) or tunnel mode (not integrated
>  > > with SIP applications, using security gateways).
>  >
>  > Making either one a "MUST" is a BAD idea. It means that far too
>  > many smaller systems, or systems with other security mechanisms,
>  > can never comply with the specification.
>

Just make compliance with both TLS and IPSEC (minimum profile as 
specified)  a very strongly worded SHOULD and I'll be reasonably happy. 
Why force double-protection on links that already have a layer-2 
protection which has key-management in place to coordinate with 
app-layer DIGEST? These mobile devices already have AKA software and in 
many cases DES hardware already in place . . .

--
Dean

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Jan 2002 12:42:34 -0800 (PST)

> many cases DES hardware already in place . . .

   L2 security protects L2. There's still plenty of
   attacks that you can mount even with L2 security.
   For example, even with BPI on DOCSIS cable, I could
   still spoof packets to the UA from somewhere else
   on the net to do annoying things. This is one
   of those "layers of defense is good" things, I
   think.

      Mike

---

From: Dean Willis <[email-masked]>
Date: Tue, 29 Jan 2002 15:40:17 -0600

Bogus. It just gives you another layer with the same threat model.

I'll try and illustrate.

Remember that we have hop-by-hop protection specified. 

Take example:
                                         |--S1----UA2
UA1-----------P1----------|         
                                         |- S2----UA3

where UA2 and UA3 are on the same remote subnet.

UA1 engages in call with UA2.
The path here is UA1-P1-S1-UA2.

Tunnel AH SAs include UA1<->P1, P1<->S1, P1<->S2, S1<->UA1, and 
S2<->UA3

S1 and S2 are stateless.

UA3 deduces the vitals of the UA1-UA2 session (To, From, CallID) and 
spoofs a BYE.
 The BYE traverse know SAs UA33->S2, S2->P1, and P1->UA1, 
thereby taking the call down. UA2's source IP address is discoverable, 
but the attack succeeds.

Now put UA2 and UA3 on the same subnet. UA3 can now spoof the source 
address of UA2. Since we're in tunnel mode, S1 accepts and forwards, 
and the attack continues. Transport mode IPSEC or TLS would have 
blocked it, however, as they institute a reverse-path-forwarding check 
to the singularsource address specified in the SA establishment.

The first attack  can be introduced wherever the SA is "transparent" to 
the SIP-level identity of the remote node. The second attack is blocked 
wherever the transport protection provides node identification and path 
verification, such as reverse-path-forwarding checks.

The 3GPP L2 mechanism actually has some L3 hooks. Each PDP context, in 
addition to being integrity keyed (and optionally privacy keyed) has an 
associated address-set in the GGSN. This rejects address-spoofed 
packets originated from the mobile. If we assume that the network 
between P1 and GGSN is secure, we can preclude the unlikely event of 
spoofed packets being inserted at this layer.

As a consequence, we get exactly the same protection behavior for UA1 
using IPSEC Transport  AH/ESP and using layer 2 AKA. The both defend 
from the same attacks, and fall to the same attacks.

But as it turns out, most of the protection actually comes in at layer 
4. Spoofing requires the presentation of conflicting identity 
information at different layers. Since the 3GPP service proxy "knows" 
the set of identities possible at UA1 and ties the AKA SA to the layer 
4 identity presented (transitively thru control of AKA keying used by 
P1), S1 is effectively prevented from spoofing attacks within the 3G 
network.

It can be readily shown that any link protection which does not bind 
identities across layers 2, 3, and 4 can be spoofed.

The strength of the AKA mechanism here is not an inherent feature of 
AKA, it derives because we use associated keying across multiple 
layers.  One could reproduce this by using IPSEC transport mode (with 
reverse-path checking) anddigest authentication, but only if some 
intermediary mechanism enforces the association between the IPSEC 
identity and the SIP identity. As Michael has demonstrated, the API to 
do this with IPSEC is not well-defined. 

The point of all this is that, barring underlying crypto-weakness, the 
3GPP AKA model provides operational security at least as good as, and 
potentially significantly better than (due to cross-layer integration) 
IPSEC Transport AH when used between the mobile and the first-hop proxy.

Therefore iit would appear to be absolutely pointless to use both AKA 
and IPSEC on this link.

--
Dean

On Tuesday 29 January 2002 02:42 pm, Michael Thomas wrote:
>  > app-layer DIGEST? These mobile devices already have AKA software
>  > and in many cases DES hardware already in place . . .
>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Jan 2002 13:51:58 -0800 (PST)

Dean,

I don't think I said that it was never redundant,
and I'm sure you can find cases where it is. We
need to consider the larger problem where L2
security (or lack thereof) is not an option. I'm
sure that everybody's clued in to the 802.11 WEP
mess, and I've heard tell that most cable MSO's
don't bother turning on DOCSIS BPI (encryption).
As I said, layering is a generally good thing,
because it decreases your vulnerability to broken
protocols and lazy operators.

	      Mike

Dean Willis writes:
 > spoofs a BYE. The BYE traverse know SAs UA33->S2, S2->P1, and P1->UA1,

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 30 Jan 2002 10:08:17 +0200

> UA3 deduces the vitals of the UA1-UA2 session (To, From, CallID) and 

i don't get this.  how can ua3 spoof the bye, because the proxy
digest authenticates it?

-- juha

---

From: Dean Willis <[email-masked]>
Date: Wed, 30 Jan 2002 09:49:01 -0600

I have yet to see a system actually authenticate BYE. Otherwise, an 
external caller could never hang up . . .

--
Dean

On Wednesday 30 January 2002 02:08 am, Juha Heinanen wrote:
> Dean Willis writes:
>  > UA3 deduces the vitals of the UA1-UA2 session (To, From, CallID)
>  > and spoofs a BYE.
>