Subject: Re: Comments on draft-srivastava-sip-e2e-ciphersuites-00 || was RE: [Sip] Comments on draft-audet-sip-sips-guidelines

From: Paul Kyzivat <[email-masked]>
Date: Sun, 02 Jul 2006 18:46:53 -0400

Samir Srivastava wrote:
> Hi Mike,
>  
>      My answers below. IMHO, it's an important piece of work. Now we
> have much cleaner solution with Proxy-Require instead of
> mess of SIPS etc. 
>  
> I remember in wacky thread  Paul Kyzivat mentioning that if SIPS etc so
> bad, why not we define a new clean
> solution. I request his comments on this approach. Hoping that Dave Oran
> who raised the question and Paul listening.

I don't consider myself competent as a security guy.

Seems like there are limits on what you can do with Via header checking. 
Mike covered some of that, but I guess you still have to trust all the 
proxies on the path. But presumably that is assumed.

Having the UAC enumerate the acceptable ciphersuites seems problematic 
to me. (But I am way out of my depth here.) It could be that some part 
of the path has proxies that don't support anything listed, but support 
something newer and stronger that isn't listed. I wonder if it would be 
better to somehow rank ciphersuites by their strength, and have the UAC 
simply specify the minimum strength it will accept.

	Paul

> Thx
> Samir
> 
> ________________________________
> 
> From: Michael Hammer (mhammer) [mailto:[email-masked]] 
> Sent: Wednesday, June 28, 2006 8:05 AM
> To: [email-masked]
> Subject: [Sip] Comments on draft-audet-sip-sips-guidelines
> 
> 
> 
> Samir,
> 
> Read through the draft and had a few nits and comments.
> 
> Nits: 
> 
> Sec 3, 2) "need to use" -> MUST use? 
> 
> page 4, top: "renegotiate"
> 
> Will need UAC, Proxy, UAS sections in future draft.
> 
> Comments:
> 
> Option tag: e2e-ciphersuite: Include description of semantic for
> Supported header as well. When text is expanded these could be separate
> sub-sections.
> 
> Suggestion: q-value should order the suites both by strength of
> algorithm/key size (first) and then by preference (second). Reason is to
> see degree of downgrade. 
> 
> SS>> Will fix in the next version. 
> 
> Via header should describe action that a proxy node MUST verify that the
> Via header added by the previous hop is valid, i.e. that it did in fact
> use the cipher named in the Via for the incoming link. May want to send
> a report directly back to the UAC Contact notifying of the compromise. 
> 
> SS>> Will fix in the next version. 
> 
> Not sure error code sent back would help.
> 
> Not sure how this would work with IPSEC. The applications may not have
> as much control of the host or communication with it (cross-layer
> indicators). I could see the IPSEC cipher listed as a substitute. But,
> then the application needs to have a means to know if it is equivalent,
> unless it names those up front in the new header. For fairly well known
> systems (e.g. follows the ANSI Generic Security standard), this might be
> a managable list. 
> 
> SS>> It's still an OPEN ISSUE. I need to consult IPSEC experts, on how
> difficult it is for application to get the info/control ? 
> 
> Does IANA already have a registry of the exact string names used for
> each ciphersuite? 
> 
> SS>> Will have more details on this, in the next version.
> 
> Last half of second paragraph above Sec 4 should be in Sec 5 security
> considerations. Should also point out that this may not prevent a proxy
> from dropping out Security-Level header. Thought, should the cipher also
> be included in the Record-Route header? The UAC should approve the route
> set for continuing the call? 
> 
> SS>> Good Catch. Will have discussions on this in the next version.
> 
> The draft is a good start. Thanks for taking the ball and running with
> it.
> 
> Mike
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip