RE: [Sip] Reviewers for the sec-agree draft

"James Undery" <jundery@ubiquity.net> Tue, 21 May 2002 14:28 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11876 for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 10:28:35 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20993 for sip-archive@odin.ietf.org; Tue, 21 May 2002 10:28:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19502; Tue, 21 May 2002 10:01:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19467 for <sip@optimus.ietf.org>; Tue, 21 May 2002 10:01:12 -0400 (EDT)
Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10780 for <sip@ietf.org>; Tue, 21 May 2002 10:00:53 -0400 (EDT)
Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 21 May 2002 14:01:34 UT
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Sip] Reviewers for the sec-agree draft
Date: Tue, 21 May 2002 15:01:11 +0100
Message-ID: <45730E094814E44488F789C1CDED27AEC552F4@GBNEWP0758M.eu.ubiquity.net>
Thread-Topic: [Sip] Reviewers for the sec-agree draft
Thread-Index: AcIAsRCSYZA7u0SdQbm/8OSUMLuMrQAHedKQ
From: James Undery <jundery@ubiquity.net>
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>, sip <sip@ietf.org>
Cc: "Jari Arkko (LMF)" <Jari.Arkko@lmf.ericsson.se>, "Vesa Torvinen (LMF)" <Vesa.Torvinen@lmf.ericsson.se>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA19468
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Hi,

I'll have to admit myself of being guilty of not reading drafts
recently. But I'd note digest-integrity needs to be dropped as it
protects the body of messages only. If it can't be dropped a lpidf like
extension would be required 
(http://www.jdrosen.net/papers/draft-rosenberg-impp-lpidf-00.txt) to
place your headers in the body.

James

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: 21 May 2002 11:02
> To: sip
> Cc: Allison Mankin; Jari Arkko (LMF); Vesa Torvinen (LMF)
> Subject: [Sip] Reviewers for the sec-agree draft
> 
> 
> Hello folks,
> 
> we need SIP people willing to have a look at the new version 
> (01) of the
> sec-agree draft (released one week and a half ago).
> 
> http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-se
> c-agree-01.txt
> 
> As you proabbly know, the previous version (00) had some problems that
> were discovered during the iterim meeting in Vegas. The discovery of
> problems (such as a broken SIP syntax) at that point of time 
> (after the
> WGLC had finished) indicates that nobody in the SIP WG 
> bothered to read
> the document.
> 
> I am not saying that this draft is so interesting that everyone will
> enjoy reading it, but we would need at least a couple of 
> reviewers that
> are familiar with SIP and have the energy to review the document. We
> cannot let the SIP WG send documents to the IESG that have 
> major flaws!
> 
> 
> Here you have a brief summary of the changes we introduced to the new
> version of the draft (01):
> 
> The syntax has been fixed. Now it is allowed to have 
> different security
> mechanisms listed (separated by commas or in different lines). The
> previous draft used commas to separate security mechanism tokens. That
> made the header field non-SIP compliant.
> 
> The scope has been narrowed down. Before, the draft tried to 
> solve every
> security negotiation problem that could be found in a SIP network. Now
> the draft only tries to resolve the security negotiation 
> between a host
> and its next SIP hop (e.g., UA and the outbound proxy).
> 
> 
> The negotiation works as follows. The UA sends a SIP message 
> (typically
> OPTIONS) to its outbound proxy listing its security 
> capabilities (e.g.,
> TLS and IPSec). The outbound proxy sends a response with its own
> capabilities (it is important that the list in the server is static).
> With this information, client and server initiate the 
> security mechanims
> (e.g., initiate a TLS conection).
> 
> When the client sends another SIP message to the outbound proxy, this
> time using the TLS connection, it includes a header field 
> that contains
> the list obtained previously from the server. This way, the server can
> check whether a MitM changes the list in order to perform a bid-down
> attack.
> 
> Of course, this security negotiation mechanism requires that all the
> security mechanisms advertised provide integrity protection, at least.
> 
> Thank you,
> 
> Gonzalo
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> Finland                   http://www.hut.fi/~gonzalo
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip