From daemon@optimus.ietf.org Mon Dec 3 11:12:03 2001 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 LAA11350 for ; Mon, 3 Dec 2001 11:12:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01048 for sip-security-archive@odin.ietf.org; Mon, 3 Dec 2001 11:12:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00939; Mon, 3 Dec 2001 11:07:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00903 for ; Mon, 3 Dec 2001 11:07:32 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11057 for ; Mon, 3 Dec 2001 11:07:29 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fB3G7Qu16511 for ; Mon, 3 Dec 2001 17:07:26 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id fB3G7QQ4004425 for ; Mon, 3 Dec 2001 18:07:26 +0200 (EET) Message-ID: <3C0BA33E.9FB9FB55@lmf.ericsson.se> Date: Mon, 03 Dec 2001 18:07:26 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip-security@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip-security] New internet drafts on security Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit I posted this a while back on the sip list but began to worry that maybe I should have done it on this list instead. Sorry for the double-post but here goes. Comments and discussion very wellcome: Dear all, We've published two new internet drafts around security and SIP. They may take a few days to get to the official I-D directories so I'll list below some URLs from which you can access them in the meantime. The first draft [1] is titled "HTTP (SIP) Authentication with EAP". HTTP EAP authentication enables SIP and HTTP to be authenticated using any of the methods supported in EAP, a generic authentication framework used in PPP, IPsec remote access, and various other situations. It is useful for the SIP protocol because it opens up several new authentication methods without additional specification work: token cards, public keys, SRP, 2g/3g sim cards, and so on. These can be run both h2h and e2e as desired, and without requiring intermediate nodes to understand it. For instance, strong e2e authentication could be run even if the hops were protected using some lower layer method. Similarly, corporate networks could use this as a client authentication method under TLS, reusing the token cards and authentication databases the company already has for other purposes. This draft also satisfies one of the requirements in draft-garcia for supporting legacy authentication in SIP. The second draft [2] is titled "Security Mechanism Agreement for SIP Connections". The purpose of this draft is to (a) correct a vulnerability in HTTP Digest authentication for man-in-the-middle attackers, and (b) to allow SIP peers to *securely* pick the security method they are going to use. A number of proposals have been made that could also be used for 'negotiation', but this proposal attempts to provide security against man-in-the-middle attackers. On small networks policy configuration and software updates are sufficient to deal with these attacks, but on large networks that evolve over time, it isn't possible to demand all devices must support the latest and strongest methods and algorithms, yet where such support is available it should be possible to take advantage of it without allowing trivial attacks to downgrade the security. The draft works for both the hop-by-hop and end-to-end cases, and as above satisfies one of the requirements in draft-garcia for secure agreement of access domain security mechanisms. Of course, the above drafts are just one way of solving a part of the complete problem. I'd like to invite discussion on what the complete SIP security picture should be, as well as various alternative approaches. For instance, both Michael Thomas and Henning Schulzrinne have described multi-security-scheme frameworks, perhaps we should discuss if [2] is needed in such contexts. Also, some EAP methods are capable of producing session keys in a secure manner, these would potentially be useful for doing some sort of symmetric crypto afterwards, maybe with Sanjoy Sen's draft or with Michael's 'preshared secret crypto system'. Perhaps the sip-security list is the appropriate list to discuss these further. What about the next meeting, how are the various security issues going to be discussed in there? The framework proposal(s)? Various drafts filling 3gpp wishes? Other stuff? Jari ---- [1] http://standards.ericsson.net/sip/drafts/draft-torvinen-http-eap-01.txt [2] http://standards.ericsson.net/sip/drafts/draft-arkko-sip-sec-agree-00.txt _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Wed Dec 12 11:05:07 2001 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 LAA11818 for ; Wed, 12 Dec 2001 11:05:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA25700 for sip-security-archive@odin.ietf.org; Wed, 12 Dec 2001 11:05:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25593; Wed, 12 Dec 2001 11:01:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25561 for ; Wed, 12 Dec 2001 11:01:34 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11600 for ; Wed, 12 Dec 2001 11:01:29 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA00554 for ; Wed, 12 Dec 2001 11:01:01 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA05367 for ; Wed, 12 Dec 2001 11:01:02 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Dec 2001 11:01:01 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57C691@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sip-security@ietf.org'" Date: Wed, 12 Dec 2001 11:00:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip-security] Call for Volunteers Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org At the sip-security bof last night, I put out a call for volunteers to participate in a design team to finish a requirements document and work towards mechanism selections for near term (e.g. bis) documents. In case there were people who could not make the meeting but are interested, please send me an email expressing your interest. The team will be appointed by the SIP chairs, it will be small, and therefore just because you volunteer, you may not be asked to participate. Please understand that we need to do this quickly, but correctly and that we need a mix of expertise and viewpoints. A full report of the meeting will be published to this list soon. Brian _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Thu Dec 13 12:36:25 2001 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 MAA24843 for ; Thu, 13 Dec 2001 12:36:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA08488 for sip-security-archive@odin.ietf.org; Thu, 13 Dec 2001 12:35:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08332; Thu, 13 Dec 2001 12:31:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08298 for ; Thu, 13 Dec 2001 12:31:41 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24728 for ; Thu, 13 Dec 2001 12:31:37 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fBDHVAo15167 for ; Thu, 13 Dec 2001 09:31:10 -0800 (PST) Received: from CJ650 (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ABQ11261; Thu, 13 Dec 2001 09:31:15 -0800 (PST) From: "Cullen Jennings" To: Date: Thu, 13 Dec 2001 09:34:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [Sip-security] Summary Minutes from BOF Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit If you only take one thing out of this meeting - it should be "Go read the stuff from Eric and Mike." http://search.ietf.org/internet-drafts/draft-rescorla-sec-cons-03.txt http://search.ietf.org/internet-drafts/draft-thomas-sip-sec-req-00.txt http://search.ietf.org/internet-drafts/draft-thomas-sip-sec-framework-00.txt There is going to be a Design Team to look at the trying to put together some improved security requirements. Requirements includes all SIP security issues including things like Refer. Once we have requirements, we will prioritize. Goal is to improve bis security by Jan 02. If you want to volunteer for this design team, email Brian.Rosen@marconi.com. It's going to be small - it's going to include people who know sip and security people. It will be selected by the Chairs. The mailing list for this stuff is sip-security@ietf.org and you can subscribe by sending an email with the word subscribe in it to sip-sequirty-request@ietf.org (Of course this is the only place I am going to send this email so I'm not sure this helps much :-) Now to get into a bit more about what happened .... It was pointed out it would be nice to define the following: * who the participants are * who the attackers are * what is the trust relationship between parties There are two types of environments we are initially interested in Type 1 A phone service provider where first hop goes from subscriber to service provider. Type 2 Like above but add mobility so first hop can be from a subscriber to a visited network then to home a service provider. Also some people want end to end secure calls The definition of a trust relationship is who is allowed to do what and under what circumstances. Our first goal is to figure out the requirements for security not work on the mechanism. We spent considerable time working through the basic model of how SIP might work and looked at the Jack-in-the-box from the Thomas draft. It was pointed out that if we never modified headers but only appended new ones, some security things would be much easier. We have not decided what headers need to be covered by and integrity check. We do want to call people that you don't know and have no trust relationship with. Reasonable End to end post dial delay is a requirement. Integrity detection is going to be very important Jon, Jonathan, Brian R, Cullen and others offered to spend time to help explain SIP to any of the security folks. Looked at some scenarios provided by Jari Avkko. Fist one has all network elements are in the same company. Second is service provider. Third is network is evil trust nobody model but still want security with friends. It is a requirement to be able to negotiate different mechanisms. There is an email that compares Thomas draft to 3GPP requirements. The scenario with 2 providers and with thing in the middle that is not trusted is an important and hard one scenario. We have multi-users problems but do not have multicast security issues. We then moved on to some slides from Vesa Torvinen that compare 3GPP and Thomas requirements. 3GPP wants long term secret keys (from/with AAA) and faster short term keys. Binging up AAA is interesting. Asking for delegation means that AAA servers provide trust between client and other services. AAA does not do this today but it is a requirement they are interested in. This is all very Kerberos like. Mike pointed out that this is a requirement to other groups like kerberos. Issues raised of negotiating security in a secure way. Rohan explained a common deployment model. Where a Phone (A) goes to proxy B which goes to proxy C which goes to proxy D which goes to PSTN gateway E. The transport from A to B is TLS then IPSec is used to C then TLS to D which is in the same secure network and trust domain as E. A is in one trust domain, B in another, C in another, D and E in the another. B authenticates itself to A by certificate in TLS. A authenticates to B using Digest. C trusts traffic it gets from B over IpSec. D could make A separately authenticate to it using Digest. RTP traffic flows from A to D. Things somewhat like this are deployed. List of attendants - I apologize for the huge number of typos in this but I believe there is enough info to search the email archives and figure out what was there. Jorg Ott jo@ipdialog.com Jonathan Rosenber jdrosen@dynamicsoft.com Jor Arkko Jari.Arkko@ericsen.ci Jiguel A FGarcia liguel.A.Garcia@ericsson.com Sunnil Chotai sunil.chotai@os.com Vesa Torvinen vesa.torvien@lmt.ericson.se Keith Drange drange@lucent.com (who wins the prize for most clearly printed name) Giuseppa Ricejim Riczgui@nortelnetwork.com Mark Watson mwatson@nortelnetworks.com Mary Barnes mbarnes@nortelnetworks.com Dan Petrie dpetrie@pingtel.com Jaysshree Bharatia jayshree@nortelnetworks.com Aki Neimi aki.neime@nokia.com Oris Levin orit@radvision.com Sasha Ruditski sasha@radvision.com Itamor Gilad itamarg@radvision.cm Dirk Kreslbey did.kreeeselbuy@mchp.siemens.cde Georg Hayer georg.mayer@icn.siemens.cde Xin Chen xchen@lucent.com Kristain Kiss krisztain.kiss@nokia.com jorge R Cuellar jorge.coellar@mchp.siemenet.de Hannos Tschofeng Hannes.Tschofeng@mchp.siemens.de James M Polk jmpolk@cisco.com Alan Johnsof alan.johnson@wcom.com James Underly james@ubiquity.net SharadheVijay sharadha.vijay@wcomc.com Helen Hwa-Jung Han hwa-jung.han@wcom.com Guarglu Want guaaglu_wang@3com.com tin dao truung tin.daotrung@faucetelecom.com Dean Willis dwillis@greycouncil.com Bill Marshal wtn@research.att.com Kijoaska Shinoda shinoda.kiyotaka@lab.ntt.co.jp Souhwan Jung souhwanj@saint.ssu.ac.jp Ben Campbell bcampbell@dynamicsoft.com Jiri Kdlhari jkulhaur@guaureaerch.com Hugh Shei hugh.sheis@attws.com Cerdirc Aucoc cedrick.auron@nortelnetowrks.com Wlfgang Beck wolfgand.beckor@telecom.de Laura Liess laura.liess@t.systems.de Adan Roach adam@who.net (vote now for you favorite address aroach@dynamicsoft.com, ar@sysco.com, adam.roach@cowboy_neil.org ) suresh Levoy saresh.leroy@alcatel.dde Wolfoang Klasen worlgeo.klausen.mchp.siemens.com Martin Erichmen marcin.euchemen@ich.siems.code Senhil Sengoadan senthinl.sengodun@nokia.com Mahfour Rhamam mahfure@research.panasonk.com Dennis Beard beardd@nortelnetorks.com Tom Taylor taylor@nortelnetworks.com Brina Stucker bstucker@nortelnetworks.com Cullen Jening cluffy@cisco.com Rohan Mahy rohan@cisco.com The following names I tried to get right because the seemed like people someone might actually want to email about any of this stuff. I may have it all wrong who is in security or not. Brian Rosen brian.rosen@marcomi.com (chair) Jon Peterson jon.pertson@neustar.biz (working on bis secuirty section) Allison Mankin mankin@isi.edu (Area director) Mike Tommas mat@cisco.com (sip secuirty expert) Eric Rescorla ekr@rtfm.com (security dude) Jackson Chan jykchan@nortelnetworks.com (security dude) Join Loannidis ji@reaserch.att.com (security dude) Robert Moskowitz rgm@truesecure.com (security dude) Jonathan Trostle jtrostle@cisco.com (security dude) _______________________________________________ Sip-security mailing list Sip-security@ietf.org http://www1.ietf.org/mailman/listinfo/sip-security