Subject: [Sip] Re: Comments on draft-ietf-sip-e2m-sec-00.txt

From: Kumiko Ono <[email-masked]>
Date: Sun, 31 Jul 2005 11:10:11 -0400

Hi,

Thank you for your close reading. Please see my comments inline.
I'll fix the typos you pointed out in the next version.

At 02:40 2005/07/26, "MARJOU Xavier RD-MAPS-LAN" wrote:
>Hi,
>
>Here are some comments about your draft, which I find very good.
>
>Best Regards,
>Xavier Marjou
>
>
>Section 2.1:
>- typo: replaces "if a UAC send" by "if a UAC sends"
>
>Section 2.1
>- is there a link to CEK and KEK mecanisms, explaining more in details
>how it works? (I think the level in the draft is ok, but refering to
>another document would help implementors)

The reference, RFC2630, for S/MIME CMS EnvelopedData which covers CEK 
and KEK mechanisms has already included in the draft. 

>Section 2.2
>-typo: replace "a UA SHOULD generate either S/MIME CMS SignedData" by "a
>UA SHOULD generate S/MIME CMS SignedData"
>- in the next sentence, why mentioning "SIP Identity header", which
>looks more related to "authentication" rather than to "data integrity".
>If "authentication" topic is needed, why not modifying the Introduction
>and add a 2.3 section?

The SIP Identity mechanism provides the data integrity of the message 
body in addition to the authentication. I mentioned the SIP identity 
mechanism as one of mechanisms for data integrity.

>Section 3
>- typo: replace "A UA needs a way to indicate content that it expects to
>be viewed by a proxy server" 
>             by "A UA needs a way to indicate that it expects the
>content to be viewed by a proxy server".
>- in this sentence, I would prefer "allows" rather than "expects",
>because I would prefer "Proxy-Allow-Body" instead of
>"Proxy-Required-Body". This would be in line with the text page 12 "it
>allows a proxy server to view the SDP". 

I believe that the naming depends who has the initiative to request the 
use of the body. Although there is no way for a UA to confirm the 
proxy's compliance, from the SIP perspective, the initiaitve should 
reside on endpoints. Therefore, I believe, "Proxy-Required-Body" is 
prefered. 

This comment addresses a core issue of this mechanism. For e2m to 
function properly, end and middle both have to comply its execution. The 
"Proxy-Required" header was considered as one of the way to accomplish 
this, but it is only effective for the first proxy server. It can not be 
used for non-adjacent proxy server. 
I could think of proxy adding confirmation flag indicating its 
complicance. 

>Section 4
>- How can the Content-Type be in the Warning header if the Content-Type
>is in the encrypted data, which can not be decrypted by Proxy. (cf also
>example of page 12)

This is used for a proxy to express what is desired to inspect in the 
decrypted data. 

>Section 3, 4 and 5
>- Personally, there are a lot of SHOULD in the documents. I prefer MUST
>and MUST NOT, otherwise this leads to a lot of interop problems between
>equipments. But I agree I can not discuss on them, as I do not know the
>discussions which have leaded to these SHOULDs ;-)

Could you be more specific?

>Section 5.3
>- "If a proxy does not support this mecanism... The proxy MUST ignore
>the herder and operate as usual" : A action is "required" to the proxy
>(as suggested by the name of Proxy-Required-Body), and if the proxy can
>not do it, this is ignored !? ;-). This would suggest again to rename
>the header in Proxy-Allowed-Body

I will delete this text, because it is redundant to the statement in 
RFC3261 which defines a proxy server to ignore unsupported headers. 

>- I have a very stupid question: if a UAC sends a SIP MESSAGE with
>envelop with message1 for a UAS and another envelop with message2 for
>its "allowed" proxy. Message2 could be a fake message for the proxy
>logs, whereas message1 will not be logged. I have the impression that in
>this case, the proxy can not respond a 493 undecipherable response.
>Perhaps that another negative response is possible in case the proxy
>would like to see decrypt.

This could happen. But a proxy could enforce disclosure of the whole 
body in order to avoid such situation. I'll add some text to describe 
how this can be accomlished as follows:

"If the proxy server reuqires disclosre of the whole body, the Warning 
header is not included."

>Section 6
>- if there is SDP in an ACK message, why not require Proxy-Required-Body
>on this request too?

I'll fix this for ACK and PRACK. 

>Section 7.1
>- maybe remove the parameter "received" in 493 of MESSAGE, as it does
>not help for the topic of this draft.
>
>Section 7.1 and 7.2
>- maybe remove Date header in examples, as it is not in relation with
>this draft
>- what is the CEKReference
The CEKReference is used for the CEK reuse mechanism that I mentioned in 
Section 5.1.

>Section 9
>- where does the header Content-ID come from?	
RFC2045. I'll add this in the references.	

-- Kumiko Ono

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