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:[EMAIL PROTECTED] Sent: Sunday, November 11, 2007 12:47 AM To: [EMAIL PROTECTED] Cc: Jonathan Rosenberg; Jon Peterson; [email protected]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
