This sounds great. But the reality seems to me to actually not match this perspective.
Firstly, a solution with a mechanism for requesting a key by a third party is clearly introducing security complexity, which seems to imply security vulnerability from all the things I have read. More importantly, a solution in which as a practical deployment we teach the users to say "yes, deliver a copy of my key" when asked seems a recipe for an insecure system even if each and every protocol component is secure. This makes me very uncomfortable. Yours, Joel M. Halpern Dean Willis wrote: > >> 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 > _______________________________________________ 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
