Hi, First an apology that I didn't get the first five minutes. (I was restarting ssh and paging Mike Thomas). I tried hard to organize the many comments into some kind of structure. I hope this makes sense.
thanks,
-rohan
** Attendance
**
Although we never finished the first item on the agenda (media crypto),
the following topics were all mentioned:** Media protection
Christian stated that there are three options for media crypto:
1. IPsec of whole RTP packet
2. RTP packet crypto
3. RTP payload crypto
Comment was made that IPseced RTP cannot pass through NAT or firewalls. Corrected that NAT has a technical issue but firewalls do not. Concern that IPsec is 5 or 3 RTTs and this could affect postdial delay (or worse, post-answer connection delay).
Someone asked what properties we wanted when securing media.
Discussion ensued: "Does RTP payload crypto make sense without message integrity?" Rough consensus: we should support RTP payload integrity, but we shouldn't require it because it would require more bandwidth and that is not ok for some users. (Flemming)
Jonathan R asked if there an implementation difference between performing integrity and authentication to prevent man in middle attacks.
We would need to write a spec for RTP payload integrity/authentication, if we will refer to it as a SIP recommendation/requirement. Rationale for integrity was documented by Bellovin
There was a further discussion of the RTP payload crypto spec, which contains a spec for how to turn an ASCII passphrase/secret into a key in a standard way. Agreed this part of the spec is orthogonal to a SIP implementation.
** Media keying
Comment that you should be able to use TLS, IPsec, Kerberos, or others to exchange keys.
Henning- I can't do kerberos by myself, but I *can* do PGP Brian- if certs exist, I should be able to use my key and do DH. There was a random comment that it would be nice to use IKE for keying non-IPsec sessions. Comments that it should be possible to use same key for many legs of the same call (mesh or mcast). It should also be possible to do separate keys for each leg of a bridge call (special case).
Jonathan R asked if there is a need for a distributed SIP key exchange mechanism/rekeying mechanism. He said he doesn't want to build a new keying mechanism for SIP. Rohan and Henning both said that k= in SDP is perfectly adequate if the signalling is encrypted.
** Signaling protection and keying
Henning and Jonathan R both asked if PGP crypto of signaling + k= with RTP payload crypto is good enough for a whole solution. consensus was yes (but not as only solution) Rohan had problems with this as the sole solution because of keying issues, but didn't articulate clearly (I'll send mail :-). Jonathan L covered part of the issue: what to do if your PGP key is on another device than the one you are using. which key do you use then? Jonathan L mentioned a mechanism used to pass permissions and credentials around.
Someone asked what to base authentication on. Mentioned were:
Christian proposed the following:
1. plan A: i can do S/MIME with my partner who i already know
2. plan B: i don't know 3rd party/have cert for them. insert token/header/URL to describe how to negotiate
** Wrap
Jonathan asked *active participants* to join sip-security@egroups.com by sending to sip-security-request@egroups.com.
Asked others to send additional notes to rohan@cisco.com, and everyone to send attendance info.
** Transitive trust (while packing up)
Rohan asked about the transitive trust (possibly by Via paramters) proposed at the Adelaide sec team meeting.
Christian commented that this was not OK for VoIP, because carriers are required by law/treaty to "trust" even untrustworthy carriers of other countries. Thus if AT&T said it trusted Nigerian Telecom, this is not a trust endorsement . Better to do end-to-end security here.