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

From: Mark Baugher <[email-masked]>
Date: Mon, 01 Dec 2003 17:06:34 -0800

hi Kumiko-san,

At 01:44 AM 11/26/2003, Kumiko Ono wrote:
>Hi Mark,
>
>Thanks for your comments. Inline-
>
><[email-masked]> wrote:
> >1. Section 5.1 of
> >http://www.ietf.org/internet-drafts/draft-ono-sipping-end2middle-security-
> >00.txt
> >shows an example of an encrypted SDP in an INVITE but the key to this
> >encrypted SDP is selectively shared with some proxies so they can view the
> >encrypted data.  There is undoubtedly some information in the SDP that a
> >proxy needs to view and some that it does not need to view, such as the
> >end-to-end keying material.  Can we accommodate this requirement in the
> >current proposals?  That is, could we keep the keying material encrypted
> >end-to-end while allowing a proxy to view other parts of the SDP message?
>
>Yes, definitely.
>Section 3.1 of the requirement draft says that
>"The solution MUST work even with  SIP end-to-end encryption for
>confidentiality service enabled".
>
>To clarify this requirement, I would say:
>- It MUST work even with end-to-end encryption of some data.
>   That is, encrypted data can be shared with the end user and selected
>proxies.
>- It MUST NOT violate end-to-end encryption when the encrypted data does
>not need to be shared with any proxies.

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?

>
> >2. Have you considered writing a core specification like RFC 1847 and allow
> >for one or more profiles such as S/MIME (today) and PGP MIME (in the
> >future)?  I understand that S/MIME is the designated SIP solution, but it
> >might be wise to allow for future extensions.
>
>Hmm... in the future, such extensions might be needed.
>However, I have not considered that yet.
>I think there are still more work to use S/MIME practically in SIP.

Yes,  I think so, too.  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.
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.

Just a thought.  I can understand how this seems less important
in the context of the current SIP specification.  But I am a bit
skeptical about the future of X.509 PKI and expect that other
approaches might be tried in the future.

Regarding S/MIME, do you intend to give a PKI design for the
solution?  That is, who is going to design the PKI that is needed
for e2m security?

I have some more questions on the I-Ds.  I won't list all of them
and won't present them in any particular order.

3. In the requirements document and in your previous I-D, I read that
"it is not appropriate for the UA on the opposite-side to have
knowledge of the public key certificate of the proxy server on
the originating network."  Number 7, p. 7 of the requirements I-D.
Why is the public key protected in this way?

4.  Requirements Number 4 and 5 on p. 7 state that it should allow
a UA to discover which proxy needs to view some data and what they
need to view.  This sounds like it can add a lot of time to call
establishment.  I'm curious to know how this can be done without
a very large number of exchanges taking place prior to establishing
the call.

5. The words "trusted" and "partially trusted" appear in the I-D.
The word "trusted" to me always begs the question "trusted to do
what?"  Since I don't have a clear idea about what you mean by
"trusted," it's hard to tell what you mean by "partially trusted."
Precision is important here.  Have you considered doing an "assets,
risks and threats" analysis on the information to identify the
particular assets in the SIP message, such as caller, callee, SDP
message fields, etc.?  What are the risks to these assets?  And
who might try to gain unauthorized read or write access to them?

regards, Mark

>Thanks a lot,
>
>Kumiko
>
>--
>Kumiko Ono
>NTT Network Service Systems Labs.
>Tel +81 422 59 4508/Fax +81 422 60 4012

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

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

A couple of notes on all this.

> 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

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.

> 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.