Subject: [Sip-security] SIP Security Framework

From: James Undery <[email-masked]>
Date: Mon, 13 Aug 2001 14:52:18 +0100

Hi,

Ooops this time I'll try not to post, until I've finished this time.

In order to try and keep up the momentum we got in London, I'll post my
thoughts on sections 1-3 (I assume I was right in thinking section 4
will go from the framework I hope).

Section 1.1 (Nits about terminology)
Crypto-System seems a bit wide in scope, I'd expect it to only cover
privacy.
Message-Intergrity is a little too strong for SIP, some parts need to be

changed (draft-undery-sip-digest include the headers I'd expect to
change en route).
Challange, this is authentication only really (see Crypto Systems)
Transform, This is a bit vague, should digest and encryption/decryption
be separated.

Section 2

One of my main concerns with the outside / inside taxonomy is that the
scariest outside attacks are ones that lead to inside attacks. (I
realise most of the outside concerns are designed to prevent this, but
it's the way I'd be trying to attack SIP networks!)

Section 3.1

Are these supposed to be in order of significance, because
confidentiality from outside, rates way higher than inside in my book.
Also Integrity from outside attacks is surely forgery, inside attacks
are more integrity based.
MITM "as must as possible" should go from the requirements.
The firewall requirements are outside the scope of this frame work in my
opinion too.
Cached credentials are asking for trouble using Authenticate-Info server
can provide the next nonce in responses (and one time nonces are really
desirable).

Section 3.2

(Real Nit) The 3rd Sentence I would be better stating, A trusts B does
not imply B trusts A.

Also The JITB model potentially is missing a scenario (Assuming I has no
direct trust relationship with either end point) that is the case where
it's proxy to proxy (neither has a direct trust relationship with either
endpoint). This is where I'd be most worried about info leakage.

Section 3.2.5

A simple (contrived) case where this could apply is, given a central
trusted certificate store. I offers to route to entities in the strore.
H doesn't trust I will find J and wants H to check J is really the owner
of the certificate.

James Undery

_______________________________________________
Sip-security mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/sip-security