Subject: [MMUSIC] 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

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

---

From: Kumiko Ono <[email-masked]>
Date: Wed, 26 Nov 2003 18:44:40 +0900

Hi Mark,

Thanks for your comments. Inline-

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

Thanks a lot,

Kumiko

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