Subject: [Sipping] RE: [MMUSIC] Re: e2m, m2m security drafts

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 8 Dec 2003 18:54:34 -0600

A couple of notes on all this.

> Thanks.  One more clarification, please.  By "encrypted data" (which in
> my case is the SDP crypto attribute that carries keying material and
> parameters), do you mean the entire SDP message or can it be restricted
> to selected lines of the SDP message?  Will it be possible to share
> all needed information in the SDP message *except* the security
> descriptions attribute in the SDP message?

Today, we don't really have a way in SIP to encrypt only part of an SDP
message - a requirement for partial encryption has never really been fully
articulated or understood. I imagine that any such requirement would be
satisfied by splitting an SDP body into different MIME components to which
separate security properties would be applied.

I understand why you'd think that sdescriptions should be end-to-end, since
they are only for the consumption of endpoints that aspire to use sRTP, or
something similar. But I'm not sure that we should grant keying material for
sRTP a specific exemption from the principles underlying the e2m work.
Unfortunately, I suspect that operators are as likely to want a degree of
control over the use of e2e media encryption as they are to want to munge
anything else in SDP.

[snip]
> 
> It is also possible that an X.509 PKI
> is found to be not the most deployable solution for global
> telephony.  Hence, my point about accommodating different
> structures in the future.  Today, there are S/MIME and PGP MIME.

I doubt that PGP MIME is any more 'deployable' than PKI, unfortunately. The
original version of the SIP standard (RFC2543) contained some PGP-related
text, and it was not included in subsequent revisions for a number of
reasons. But certainly it's very unlikely that we'll get any closer to
interoperable end-to-end security by introducing more alternatives for e2e
security in SIP. Giving implementers a choice between S/MIME and PGP MIME
is, in fact, guaranteed to get us farther from our goal.

It is also important to note that support for S/MIME does not directly
entail the use of X.509. There are a number of specifications (notably
RFC3211) that define symmetric key schemes usable by S/MIME in place of
X.509. Self-signed certificates are also meaningful for S/MIME - in fact,
there's a great deal of text in RFC3261 (notably in Section 23.1/23.2)
dedicated to exchanging self-signed certs.

> A core specification would enable one to apply what you develop
> for one security specification (S/MIME) to others (PGP MIME, etc).
> To do this would require one to take out the features of the
> e2m and m2m security that are general to all secure multipart
> specifications, put these features into one document and then put
> the features that are specific to S/MIME in a second document.

I agree that the e2m work is not the right place to explore whether or not
we should introduce new options for e2e security in SIP. That is a core SIP
issue, and not something that should be considered solely in light of the
e2m requirements. That much said, I do not advocate reopening the underlying
principles of MIME security for SIP. I think the e2m work should focus on
the existing security mechanisms that have been established for SIP in
RFC3261, and should not complicate itself by creating modularities that
depend on the (speculative) use of other MIME security systems.

Jon Peterson
NeuStar, Inc.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Kumiko Ono <[email-masked]>
Date: Tue, 09 Dec 2003 17:22:08 +0900

Jon,

I agree with your comments for the scope.
See inline.

# I am not sending this mail to the mmusic ML to avoid cross posting.

>separate security properties would be applied.

We don't have a Content-Type that indicates only part of an SDP message.
Is that the reason why you said that we don't have a way in SIP to 
encrypt only part of an SDP?

I want to note that the e2m work is applied not only for SDP, but also 
for some SIP headers or some XML data, such as message contents or 
location data.

Thanks a lot,

Kumiko
--
Kumiko Ono
NTT Network Service Systems Labs.
Tel +81 422 59 4508/Fax +81 422 60 4012