Keith, Thanks for resurfacing this, it has been a while! To refresh the group's memory the origin of the I-D was the need to allow a UA to mutually authenticate with proxies other than the next-hop (UA<->Proxies<->Proxy). For authenticating with the next-hop proxy, TLS should be used (as acknowledged in the I-D). The earlier versions (-01 and -02) raised more questions than answers! With -03 there seemed to be a few interested people within this WG (and outside) who saw value in this I-D (e.g., Scott Lawrence, Milan Patel, Christer Holmberg, Martin Dolly, Francois Audet; see emails from around July '08). It would be nice to get their feedback once again on the need (or not) for this requirement (independent of the I-D). If we still see a need for this requirement, I would solicit suggestions to revise the I-D to clearly articulate the requirement and the potential solution(s).
Additionally, I had offline discussions (in Ireland) with one of the ADs (Cullen) who saw value in (or at least did not dismiss) this I-D; unless I misunderstood the conversation. We left the conversation with a plan to discuss further with the security adviser. Did we miss any further communication (from the ADs)? Ekr, Thanks for your response. To clarify, perhaps the I-D is not the answer to the requirement we are trying to solve, in which case we need to look at other alternatives (or surface other I-Ds). I (personally) would not like the I-D to be the holdup for us to solve the need (stated above). I have a few follow-up responses to your comments. When you say "cryptographic authentication followed by clear text messaging", I am hoping that you are not dismissing subsequent challenges. For example, if there is a UA request which is deemed sensitive, the proxy should challenge it. To ensure that an 'impersonator' cannot get away without a challenge, the UA can be configured to discontinue further messaging in the absence of a challenge (this is because we don't have a mechanism for the UA to challenge the proxy, unless I am mistaken). This may not prevent a passive attack, but would it not thwart an active attack? If not, given the limited integrity protection offered by the header, should we extend the requirements to provide better integrity protection? Is that an option? In response to your second point about the non-applicability of secure signaling, the I-D allows for the UA to mutually authenticate with multiple non-next-hop proxies, each of which can share unique credentials with the UA. This model works even in the presence of TLS. Why is this not applicable, or am I missing the point (sorry, it has been a while since we discussed this issue)? Thanks! - S -----Original Message----- From: DRAGE, Keith (Keith) [mailto:[EMAIL PROTECTED] Sent: Sunday, November 16, 2008 1:07 PM To: sip@ietf.org Cc: Eric Rescorla; Sumanth Channabasappa Subject: draft-dotson-sip-mutual-auth (As WG chair) A long while back there was some interest in getting this chartered as a SIP WG item. We have been having a long and delayed thread external to the list on this which may be summarised as: - the AD wants evidence of a clear use case - the security adviser to the SIP WG not seeing that there is a use case. - the authors having so far failed to convince either. I attach the two key mails that relate to the technical discussion and you can scroll down and see the rest of the thread. I invite other members of the SIP WG to add further input to this discussion. regards Keith _______________________________________________ Sip mailing list https://www.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
