Microsoft files EU Android complaint

D. Hugh Redelmeier hugh-pmF8o41NoarQT0dZR+AlfA at public.gmane.org
Sat Apr 13 21:36:19 UTC 2013


| From: James Knott <james.knott-bJEeYj9oJeDQT0dZR+AlfA at public.gmane.org>

| D. Hugh Redelmeier wrote:
| > Forgot to mention, SIP support IPSec, for encrypted calls.
| >
| > SIP doesn't support IPSec, IPSec supports SIP and essentially all
| > other IP protocols.
| 
| While SIP can certainly travel over an IPSec VPN, and I have set that up,
| that's not what I was referring to.  IPSec can also be used directly by
| applications, without a VPN.

Is that a standard?  Is it generally implemented by a reasonable
number of suppliers?

| >From 
| http://www.softwell.se/index.php?option=com_content&view=article&id=82&Itemid=131
| 
| "A successful IMS AKA Registration is accomplished by two SIP Register request
| messages sent to the subscriber's S-CSCF and two SIP Register response
| messages to the requesting subscriber. Information neccesary to performa
| authentication and set up the two IPsec channels are provided in the SIP
| message headers. Some of the SIP message headers are specific for IMS."
| 
| With this, the connection is set up to use IPSec, for carrying the connection.

I don't know what that is.

Shotwell seems to be a testing company.

IMS <https://en.wikipedia.org/wiki/IP_Multimedia_Subsystem> seems to
be "IP Multimedia Subsystem" of "IP Multimedia Core Network
Subsystem"(?).  It seems t be 3GPP, whatever that is.

AKA <https://en.wikipedia.org/wiki/AKA_%28security%29> is for mobile
telephony.  It sounds like it corresponds to IPSec's IKE, but is
different.  Not part of IPsec.

Reading between the lines, they may be using ESP protocol.

Does any of this exist?  From ITSPs?  From ATA devices or SIP phones?

| And this:
| http://pic.dhe.ibm.com/infocenter/wvraix/v6r1m0/index.jsp?topic=%2Fcom.ibm.wvraix.voip.doc%2Fipsec.html

That is pretty vague, but nothing in that suggests that it is anything
but SIP over an (otherwise negotiated) VPN.

| Or from this book:
| http://www1.avaya.com/pc/SIP_for_Dummies.pdf
| 
| Pg 45
| "Secure Real-Time Transport Protocol (SRTP) or IP Security (IPSEC) using
| Advance Encryption Standard (AES) encryption to provide authentication,
| cofigentiality, and integrity for protection of the media

That document seems to wave its hand in the IPSec direction but does
not imply anything but VPN.

| SIP normally uses Real Time Protocol (RTP) to carry a call, but it can also
| use SRTP to provide end to end encryption of the call. That is right from one
| phone to the other, encrypted all the way.

Last I looked, there was no universal (i.e. interoperable) way of
negotiating security with strangers.  SRTP does not protect the SIP
part of the call either.

For this stuff to work in general, Opportunistic Encryption is the
only way to get there in a standards-based environment.

| So, bottom line, IPSec *IS* supported by SIP.

I still don't see this.

BTW, I'm not demanding IPSec.  SRTP could be good enough (I haven't
checked).  But:

1) as much of the communication as possible must be private and
   secure.  Including the SIP part.

2) the security must be solid (so much of what passes for security is
   known to be weak).  Usually this is best accomplished by security
   folks designing the protocol, not adding it later or by amateurs.

3) traffic analysis is a hard threat to defeat.  A standard should
   accommodate countermeasures.  Since they are expensive, it probably
   cannot require them.

   IPSec allows tunnels to be less correlated with call sessions
   so enables some approaches for limiting traffic analysis.

4) The authentication infrastructure is a really tough nut to crack
   and should not be designed just by techies.  It's got to be
   user-visible and must be tractable for ordinary users.
   On the web, we've punted that and allowed "servers" but not
   "clients" to be authenticated automatically (TLS).
   I don't want a server/client distinction in general, and
   certainly not in telephony.

5) Opportunistic Encryption needs to be considered from the outset.
   It is quite hard and made much harder if it must be retrofitted.
   It has to include authentication if one wants to be secure from
   man-in-the-middle attacks.

6) I want all this to be end-to-end: no designed-in middleman.
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list