On a lightly-loaded 800Mhz PIII: sign verify sign/s verify/s rsa 512 bits 0.0029s 0.0002s 339.9 4256.2 rsa 1024 bits 0.0159s 0.0008s 62.9 1299.2 rsa 2048 bits 0.0974s 0.0026s 10.3 389.5 dsa 512 bits 0.0027s 0.0032s 370.6 308.6 dsa 1024 bits 0.0082s 0.0101s 122.7 98.8 dsa 2048 bits 0.0259s 0.0326s 38.6 30.7 RSA has more expensive signatures, but very cheap verification operations (since, by convention, the public exponent is a small value, e.g. 2^16+1). DSA shows an inverse behavior; so, depending on the system, you can engineer accordingly (e.g., if you're using a handset to generate signatures, you'd probably use DSA). In TLS, assuming you're not using DH key establishment, it makes sense to use RSA encryption (equivalent to the verification operation) and DSA signatures on the handset (if doing client authentication). There was a paper two years ago in USENIX Security, where someone implemented digital signatures in a pager --- it was expensive, but then it was just an 8 or 16-bit processor (order of 3-4 seconds). Again, the expensive part was doing the signature; in anonymous TLS, you could expect the cost to be in the order of half a second or less, and implemented purely in software. I've done the same on the PalmPilot (68K DragonBall) -- 512-bit RSA signing operations are less than 2 seconds. This is *without* any hardware support. PalmVII has native eliptic curve support (unclear whether this is hardware or software, I believe the former), and it's used for CDPD authentication. Among other companies, Broadcom is making PCI crypto cards (it's really just one chip) that claim about 1000 RSA signatures/second; I haven't yet measured that -- it's in my TO-DO list, but preliminary measurements indicate that the real performance is very close to it (I've managed to get within 10% of the claimed number for symmetric-key operations, like 3DES) nCipher makes SSL accelerators (www.ncipher.com, look for nFast); they claim 800 server-side RSA (1024bit) operations (decryptions) per second. JMS says they really do get that performance when deployed. Finally, search for "embedded and cryptography" in citeseer.nj.nec.com: http://citeseer.nj.nec.com/rd/60051529%2C343954%2C1%2C0.25%2CDownload/http%253A%252F%252Fciteseer.nj.nec.com/cache/papers/cs/16824/http%253AzSzzSzwww.dcc.unicamp.brzSzic-tr-ftpzSz2000zSz00-08.ps.gz/lopez00performance.ps.gz http://citeseer.nj.nec.com/rd/81271361%2C344328%2C1%2C0.25%2CDownload/http%253A%252F%252Fciteseer.nj.nec.com/cache/papers/cs/16813/http%253AzSzzSzcacr.uwaterloo.cazSztechreportszSz2000zSzcorr2000-42.ps.gz/hankerson00software.ps.gz AFAICT, the argument of performance is a red-herring: if people want to use strong authentication in an embedded system, the technology exists to do so; and the costs come down, once sufficient demand for these chips exists (the Broadcom card costs about $300 retail). --- > (1) If the issuer of the REFER is the same as the caller or callee. In > that case, the main problem is presumably making sure that the REFER > does indeed come from the same party. As in > > A -- INVITE --> B > A -- REFER (C) -- B > B --- INVITE --> C > R-By: A > > It's not clear that C would care about A's authenticated > identity, as B > is in any event responsible for requests it issues, and shouldn't be > able to "blame" A for waking C at 3 am. There have been requests to not just be able to authenticate A, but to allow B to prove to C that A asked _this_ request be sent (so that C can put the appropriate acceptance policies in place and B can't put the blame on A unless it really belongs there). > > (2) The REFER comes "out of the blue", e.g., > > A -- INVITE --> B > B --- REFER (A) --> C > > A <------------ INVITE ------------ C > > This case is no different than standard request > authentication. C would > want to be sure that it is indeed B that it is talking to. C > also needs > to authenticate itself to A. It suprises me, but this is the case that seems to be scaring people the most. There is FUD circulating that anybody implementing REFER opens themselves to automatically accepting REFERences to place calls to numbers that will incur charges. The thing the FUDsters are choosing to ignore is that any _sane_ implementation of C is going to allow a policy decision to be made before issuing that INVITE (and that policy may or may not involve authenticating B). --- 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)