Subject: Re: MMUSIC at the LA IETF

From: Eve Schooler <[email-masked]>
Date: Fri, 20 Mar 1998 10:07:57 -0800 (PST)

> What you need is a BOF, so that you can discuss the different parts of 
> your proposal in one place and get feedback as to whether anyone
> considers your ideas worthwhile.  

This seems like an effective strategy to me as well.

> But discussing the application level stuff alone seems somewhat 
> pointless to me.

Agreed.

E.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 24 Mar 98 19:21:30 JST

Mark;

> >> The SIP and SAP specs are essentially frozen now, except for
> >> addressing security issues.  
> >
> >Hmmm, but the security issues could take more than 3 years.
> 
> If they do, the IETF is dead, but just doesn't know it yet.

Certinly. IETF is still alive because it is not really insisting
on addressing security issues, not yet.

						Masataka Ohta

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Mar 1998 21:27:37 -0500

Mark Handley wrote:

Still haven't gotten the confctrl version...

> 
> 1) Denial of service attack of a SIP agent.  Proceeds much like the TCP
> SYN attack: bomb a SIP agent with phony INVITE messages, with a forged
> source address.  The effects are ennoyance of the user (too many ringing)
> and sheer saturation of the SIP agent (real calls can make it through).

Not much we can do here (I think), except require authentication of
calls and have a flexible call processing language to dump these early.
Fortunately, the processing costs of INVITEs are pretty low.

The other thing I foresee is IPtel spam. Lot cheaper than actually
calling somebody. You pick up and you get "Hi, this is Dave Rhodes. A
week ago I was in the gutter and then I found this amazing
opportunity...".

> 
> 2) Use of the SIP agents as intermediate relays in a "smurf" attack.  Send
> a multicast message to a group address listing multiple agents, with a
> spoofed source address (that of the target of the smurf attack).

I understand this as "trigger a multicast search", but fake my source
address?

> 
> 3) Use of SIP to establish an unwanted session.  Make an SDP session
> announcement using the desired target's IP/UDP/RTP parameters, and send it
> to some agent to which the target has no desire speaking or listening.
>  This can be done either with point-to-point operation or with multicast
> announces.

The three-way ACK handshake provides some protection against invalid
source addresses, although we'd need to add a callee-added token that
the ACK needs to return to make it work. Something like the following
would work in a backward compatible way:

C->S: INVITE

S->C: 401 Unauthorized
      WWW-Authenticate: Trivial nonce="this-is-your-nonce"

C->S: INVITE
      Authorization: Trivial nonce="this-is-your-nonce"

"Trivial" is a new "authentication" scheme even less 'secure' than
"Basic" - you don't have to know a password, just echo what I sent you.
However, it helps to solve the problem at hand.

That way, the callee knows that the caller actually received the 401
response and thus couldn't be faking the source address.

The agent/weather channel would be legally responsible for sending this
garbage, so it might be well advised to check for authentication.
Another alternative is that it redirects the call to itself, forcing the
client to contact it directly, so that it can use the three-way
handshake mechanism above to make sure (a) the source address is valid
and (b) is the same as the SDP destination address.

> 
> 4) Use of SIP to generate a stream of traffic towards an unsuspecting
> target, resulting in a denial of service attack.  Make an SDP session
> announcement using the desired target's IP address, send it to some public
> point-to-point source, e.g. weather channel.

Same as before.

> 
> 5) Interception of SIP INVITE by a third party, which then manages to send
> a reply before the invited party, possibly redirecting the call to some
> wrong address.  Can also be used to engineer man-in-the-middle attacks.

Addressed by the section on "trusted responses" (forcing response
authentication) in the current (today's...) or by introducing a
mechanism as the following (if caller and callee share a secret):

C->S: INVITE
      WWW-Authenticate: digest

> 
> 6) Use a rogue BYE command to disconnect a user from a session.

Authentication. Without authentication, BYE requires knowledge of
Call-ID, which is required to be cryptographically random, so Trudy
would have to at least intercept the INVITE.

> 
> Obvious protections:
> 
> 1) In a secure environment, only accept SIP request and queries from
> secure associations (using IPSEC).  This effectively shuts down most
> attacks, but is obviously hard to realize in a large, open environment.
>  Also, it will only protects against forged SDP announces if none of the
> secure servers ever relay an announcement obtained through a less secure
> channel.  One problem here is the tight delays imposed in some
> environments (gateways to public telephony) which mandate very short
> response times: setting up an association on demand requires at least 2
> round trips with Oakley/ISAKMP, and possibly three.
> 
> 2) If IPSEC proves to expensive to implement, allow for an application
> level signature of the messages, based either on pre-established keys or
> on public keys and certificates.

This is wwhat we are currently doing, based on PGP. I think this should
prove so easy to implement if you have a PGP implementation that there's
little reason not to.

> 
> 3) Attach a digital signature to the announcement, effectively proving
> that what the invited party receives is exactly what the original inviter
> sent.  The signature should cover the SDP announcement itself, but also
> the name of the inviting and invited parties.  Similarly, attach a
> signature to the 200-OK acknowledgement.

See above.

> 
> 4) Make sure that the INVITE/200 OK/ACK exchange effectively implements a
> three ways handshake.  To that effect, the INVITE should include a unique
> identifier that should be repeated in the 200 OK response; the 200 OK
> response should also include a different unique identifier, generated by
> the invited party, that should be repeated in the ACK.

Should've read to the bottom of the message before replying. See
concrete suggestion above.

> 
> 5) Allow for an optional three ways handshake for the BYE command.

Could be done via a Require header, but the Call-ID mechanism I
mentioned above may solve most of the non-intercept problems.

Henning