RE: [Sip] media-security-requirements and lawful intercept

["Frank W. Miller" <fwmiller at cornfed.com>]

I suppose that even if some third-party key management scheme is
adopted, ZRTP will still exist.

My point is that in this requirements, there are so many and they appear
to be fairly random in their ordering and what they are targeting the
way the draft is written that I would be concerned that some requirement
or combination of requirements would preclude and end-to-end solution.
While Section 5 does make an effort to try to group them, it seems a bit
more philosophical rather than focused on actually rounding up sets of
the requirements in Section 4.

At a minimum, I would recommend the following before further discussion
is had.  Move Section 5 before Section 4 and call it Architectural Basis
or something like that.  Then partition the requirements that are
currently in Section 4 based on that discussion.  The goal would be to
make sure there aren't any sneaky interactions between the requirements.

Also, as an aside, I would recommend that anyone that is not familiar
with SCIP should try to become familiar with it.  Those protocols follow
closely what is done currently with PSTN based STU/STEs, bringing that
operational paradigm to the packet world.  The operational approach
described by that protocol design is reflective of one set of
requirements used by the military and intelligence communities for
secure communications.

FM


-----Original Message-----
From: Dean Willis [mailto:dean.willis at softarmor.com] 
Sent: Sunday, November 11, 2007 12:47 AM
To: fwmiller at cornfed.com
Cc: Jonathan Rosenberg; Jon Peterson; sip at ietf.org; pkyzivat at cisco.com;
john.elwell at siemens.com; dwing at cisco.com
Subject: Re: [Sip] media-security-requirements and lawful intercept



> Our security requirements and implementation MUST include use cases
that
> involve true end-to-end security that does not include the ability for
> eavesdropping of any kind, let alone LI.

So when your service provider asks you for your session key, do not tell
them. Whether they allow the call or not, we're all happy because our
principles and 
use cases have been upheld. However, some people DO want to use service
providers that will require key disclosure. Should we deny their use
case?

The approach Dan has suggested allows the user to decide whether or not
they wish to disclose their keys. And it allows service providers to
decide whether or 
not they will require the disclosure of session keys. It works in
enterprises that are subject to auditing. It also works in regulated
networks subject to LI. 
And it works in classified networks with maximal security requirements.
It does all this with one code base, one protocol, and full
interoperability between 
domains.

What use cases does this exclude?

--
dean



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip