Subject: [Sip] SIP security requirements (this might mean you!)

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Nov 2001 13:55:45 -0800 (PST)

As promised, I separated out the requirements from
the framework I hacked up for the last meeting,
and they're currently available in
draft-thomas-sip-sec-req-00.txt. Not a whole lot
has changed here: I've mainly tried to capture
the comments from our ad hoc meeting, and flesh
out the requirements I had before.

So here's my dark confession: I can't keep up with
the vast expanse of this working group's
in-progress and proposed extensions to determine
whether the set of requirements I've already come
up with are necessary and sufficient. I've mainly
paid attention to 2543bis and a few other drafts
which I'm familiar, like the privacy draft. It is
quite possible that any assumptions and hopes for
SIP security that are being made in other drafts
-- and I sure hope that their security
considerations sections enumerate all of them --
are not well accounted for in these requirements.

Therefore, it would be really, really helpful if
the authors of these drafts helped out here by
comparing their expectations for security with
what is being claimed as requirements in the
draft. Henning's questions on REFER security are
exactly the kind of input that is needed to test
to see if we're missing things -- either
specifics, or general trends. If you all don't
help out, you're probably going to be faced with
the prospect of my limited understanding of many
of these drafts, aided by their perfect security
considerations section, filling in the blanks.
This should probably not give you comfort.

	 Mike

_______________________________________________
Sip mailing list  http://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: [email-masked]
Date: Wed, 28 Nov 2001 15:53:54 EST

Mat,

Comments on draft-thomas-sip-req-00:

Looks like a good identification of the requirements. At least on the high 
level, it appears to identify the security requirements of 
draft-pierce-sipping-assured-service-00.

Nits (to prove I read it):

2.4.5 4th line "upon" should be "open"

2nd paragraph of section 3:
Second word ("trapezoid") should be deleted (or replaced with "trust 
boundaries").
Phrase "Neither the UAC or UAS have no direct..." should be "neither the UAC 
nor the UAS have a direct.."

Section 3.0.4: word "of" missing in third line after "shades"

Questions:

12th bullet in Section 4 ("consider the cost of any public key"). It isn't 
clear to me what this means, especially as a requirement. It seems to be 
saying that an implementation should be able to keep a copy and reuse 
something that it is supposed to pay for on a per use basis.

14th bullet in Section 4 ("compress any encrypted portions"). It isn't clear 
what the requirement here is. If size of messages is a problem, the 
requirement to compress would be independent from any security aspects such 
as encryption. compression would have to be done before encryption. Once 
encrypted, compression if impossible. Properly encrypted data can not be 
compressed since it consists of totally random data. I suppose you meant "to 
first compress any portion of the message to be encrypted." This brings up 
another possible requirement, which is to be able to hide the length of 
messages by padding them to a specific length before encryption. I don't know 
if this is needed.

Mike Pierce
Artel