Subject: [Sip-security] Proxy routed requirements in draft-thomas-sip-sec-framework-00.txt

From: Jari Arkko <[email-masked]>
Date: Wed, 29 Aug 2001 11:05:25 +0300

Michael (cc list),

Reading section 3.2 in your draft, am I correct in
concluding that the requirements for the four
different cases (UA->Proxy, UA->Intermediate,
UA->UA, Proxy->Proxy) are the same?

There seems to be quite a bit of discussion using
different language in the subsections, but it
seems to me that the four basic requirements of
mutual authentication, integrity, confidentiality,
and authorization are relevant for all cases.

Jari

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 29 Aug 2001 14:16:22 +0300

Some further discussion: comparing Michael's
draft and draft-ietf-sip-security-requirements-00.txt,
I see that the former doesn't handle availability
and non-repudiation requirements at all. Yet these
are mentioned in the latter. I believe availability
and DoS is a concern, and should perhaps be treated
somewhere. Non-repudiation on the other hand is
propably a can of worms we don't want to open...

Also, in 3.2.5 you talk about the case for
non-adjacent proxies, and wonder if there is
any need for security measures in this
interface. My comment on this is that
protocol-wise you wouldn't even know if
someone who e.g. sent some protected bits
to you was a proxy or an end-node. So,
if we provide tools to get security on the
user->intermediate interface, then non-adjacent
proxies can take advantage of the same
mechanisms. (This comment doesn't of course
say anything about the requirements for such use.
It is perhaps not unthinkable to have a
proxy that would handle security for you
in certain situations.)

Jari

---

From: Michael Thomas <[email-masked]>
Date: Fri, 31 Aug 2001 09:08:49 -0700 (PDT)

> and authorization are relevant for all cases.

   Yeah, I wrote it at different times and was rather
   rushed to get it submitted before cutoff. I also
   cut out a DoS bullet too, which should probably be
   reinserted.

   I believe that they all have similar if not identical
   requirements. I couldn't think of anything different
   off the top of my head, but it's probably worth
   testing more to see if that is actually the case.

	   Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 31 Aug 2001 09:22:49 -0700 (PDT)

> propably a can of worms we don't want to open...

   Yes, I really don't want to go down the 
   non-repudiation path. Maybe we just need to
   say that it is an explicit non-goal. DoS is
   a more fertile ground, but as we all know is
   an open ended problem. In order to include
   discussion of DoS requirements, I think we
   first need to create some artificials bounds
   on the discussion so that we have some chance
   of creating a set of requirements which 
   a potential solution can objectively measure
   whether it meets. Ie, open ended statements like
   "should be DoS resistant" aren't helpful.

   How we frame this is an interesting question.
   For outside attackers, we clearly need go no
   farther than countering a pure flooding attack.
   From the inside, however, is a lot trickier, and
   involves potential tradeoffs (tradeoffs that we
   probably don't want to make at this point, I'll
   add). 

   Maybe if we rounded up a bunch of potential DoS
   attacks we could see a pattern so that we could
   extract what our expectations are for SIP's 
   resilience to them is?

 > proxy that would handle security for you

   If there are no requirements, or the requirements
   are identical, that's fine -- good even, I'd say.
   The reason I created the fully connected graph
   was to assess whether that was indeed the case.
   It appears to me to be the case, but I'd like 
   to see if other people have sceanrios I hadn't
   considered, or don't fit that model well.

		Mike