Subject: Re:[Sipping] I-D ACTION:draft-ietf-sipping-e2m-sec-reqs-00.txt

From: Kumiko Ono <[email-masked]>
Date: Thu, 06 Nov 2003 22:02:04 +0900

Dear SIPPING folk,

I have recently updated my end-to-middle security draft to a version 00 
of the requirements draft, draft-ietf-sipping-e2m-sec-reqs-00.txt, (the 
mechanism draft will follow). I wanted to point out some major changes 
since the last individual submission:
	- Organized the requirements better
	- Added requirements for discovery
	
I also have some open issues that I wanted to share and get your 
feedback on. 

First, some background on my thinking: I think that in the real world 
there is sometimes a need for proxy servers to inspect the contents of 
SIP message bodies.  In addition, proxy servers sometimes need to  
delete a message body in a request in order to delete a user 
authentication data (ex. Proxy-Authorization) that is protected with S/
MIME.  Or, proxy servers sometimes need to even append a message body in 
a request in order to indicate some requirements for a response, such as 
recommended SDP for 200 OK response.  There is also a great need for 
security end to end. 

There are currently many proxy servers that add, modify and/or delete 
message bodies as proscribed in RFC 3261. We want to enable an end-point 
to communicate with a proxy somewhere in the chain of proxy servers. 

There needs to be a way to balance the desire allow features (ex. 
logging, firewall traversal) and preserve end-to-end integrity and 
confidentiality. In order to balance them and improve usability of end-
to-end security, it is important to define a means of e2m security.

There is no way at the end-points to determine whether or not the 
message body has been appended if network services are only available to 
end-points that do not use end-to-end security (S/MIME). 

Open Issues:
*** Should RFC3261 be amended to allow proxies to append SIP message 
bodies or fragments that are addressed to it? (they　would still  be 
forbidden from adding, modifying or deleting SIP message　bodies that 
are not addressed to them.)

*** Is this important enough to support the creation of a new SIP 
header? (I feel that it is, but I want to hear any arguments to the 
contrary.)

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

_______________________________________________
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