Subject: [Sipping] e2m, m2m security drafts

From: Mark Baugher <[email-masked]>
Date: Tue, 25 Nov 2003 16:33:12 -0800

hi
   I have read the three drafts dealing with end-to-middle and 
middle-to-middle security, both requirements and mechanisms.

http://www.ietf.org/internet-drafts/draft-ietf-sipping-e2m-sec-reqs-00.txt
http://www.ietf.org/internet-drafts/draft-barnes-sipping-sec-inserted-info-01.txt
http://www.ietf.org/internet-drafts/draft-ono-sipping-end2middle-security-00.txt

As you may know, we developed SDP security descriptions to describe a key 
and security parameters for a media session.  We need to have end-to-end 
authentication and encryption of this information and secure multiparts 
looks like a promising approach to our security-description needs.  So, 
I'll have a lot of comments and questions on these drafts.

In this note, I'll limit myself to one question and one comment.

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?

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.

Thanks for doing this work.

Mark

_______________________________________________
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: 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
>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?

>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

---

From: Kumiko Ono <[email-masked]>
Date: Tue, 09 Dec 2003 12:55:45 +0900

Mark,

You don't have to add -san when you call me. :-)

[snip]
>> descriptions attribute in the SDP message?

The "encrypted data" is not restricted to the entire SDP message or a 
subset of the SDP message. It depends on the use case. 
In your case, you could set two encrypted SDP in a SIP message: 
one contains keying parameters for SRTP and is encrypted only to a UAS, 
and another doesn't contain them and is encrypted to a selected proxy.

[snip]
>> solution?  That is, who is going to design the PKI that is needed

I don't think that a special PKI design to e2m security is needed. 
So, the PKI design is out of scope, but there is a lot of other work 
going on in the IETF on PKI. Also, non-PKI solutions for S/MIME or CMS 
are being proposed as well.

[snip]
>> Why is the public key protected in this way?

It does not mean that the PKC of the proxy needs to be protected. 

The UA on the opposite-side does not usually know the PKC of the proxy 
on the origination network. It is not a valid assumption for the UA on 
the opposite-side to need to know the PKC of the proxy.

If a SIP response message carries some data to be shared with the proxy 
on the originating network, the UAS would need to encrypt the data for 
the proxy. There are two ways to encrypt the data for proxy: one is to 
use the PKC of the proxy, and the other is to reuse the  CEK of the 
request message. In the former way, the UAS needs to get the PKC of the 
proxy in some way and to validate the PKC. The latter way is simpler. 
Therefore, it is better for the UAS to encrypt the response message to 
the proxy without the PKC of the proxy.

To clafiry this requirement, I would say that "It SHOULD enable  the UA 
on the opposite-side to encrypt some data in a response message to the 
proxy on the originating network without using the PKC of the proxy."

>> a very large number of exchanges taking place prior to establishing

The discovery mechanism will be similar to the challenge-response 
authentication, or an event package mechanism. 
With a similar mechanism to the challenge-response, it will take 
additional three messages per a proxy. These additional messages are not 
always required. If a UA has already known the disclosure requirement of 
the proxies, the UA does not need these additional messages.

>> who might try to gain unauthorized read or write access to them?

Good comments. I have to clafiry the words and describe security threat 
models.

I meant that a "partially trusted proxy" is a proxy that a UA 
trusts to view *only routing-related* SIP headers in a SIP message 
in order to forward the message.

A "trusted proxy" is a proxy that a UA trusts to view *all* the 
information ,or *a part* of the information besides routing-related 
SIP headers in a SIP message in order to provide some features.

Regarding SDP message fields, you know, there are several risks to 
disclose them.
Using TLS in all hops, the risks could  be restricted to all the proxies 
in a request path. Some proxies might need to view RTP port numbers to 
control a firewall, and other malicious proxies might monitor/log media 
streams without notice.

Thanks a lot,

Kumiko