[Gen-art] Re: Gen ART Early Review of draft-ietf-sip-e2m-sec-03.txt

[Cullen Jennings <[e-mail]>]

Hi David,

Thank for doing this review - I have not got to go thorught the  
comments yet but I will.

And thank you to the Gen ART team for experimenting doing an early  
review for this draft - I think this will help the draft be clearer  
to people during IETF LC and thus result in a better IETF LC.

Cullen


On Sep 14, 2006, at 5:16 PM, [e-mail] wrote:

> Ono-san and Tachimoto-san,
>
> I am the assigned Gen-ART reviewer for an Early Review of
> draft-ietf-sip-e2m-sec-03.txt .
>
> For background on Gen-ART, please see the FAQ at
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
>
> Please resolve these comments along with any other comments from your
> AD.
>
> This draft is on the right track but has open issues, described
> in the review.
>
> I should first caution everyone that this is my first serious  
> encounter
> with both SIP and S/MIME, so I've probably tripped over some things  
> that
> are obvious to those more familiar with these technologies.
>
> Overall, I think the structure of using multiple explicit S/MIME
> recipients to obtain control over selective disclosure of sensitive
> information to proxies between the SIP UAs is the right design,
> along with the related use of S/MIME integrity, as SIP already uses
> S/MIME.
>
> I consider the following three issues to be significant problems:
> 1) The missing structural explanation that has me confused about  
> whether
> 	a proxy can see that an SDP type was encrypted.
> 2) Section 4.1's failure to authenticate sources of certificates
> 	in error messages.
> 3)  Section 5's mixing of example discussion with protocol  
> requirements.
> I've marked these three issues with *** below.
>
> Here are the details ...
>
> The Abstract says:
>
>    This specification is approved at the proposed standards level  
> due to
>    the IANA registration requirements.  Is is of sufficient quality  
> for
>    that level, however, the use of this mechanism in this  
> specification
>    are considered experimental.
>
> Ouch.  I suspect Cullen is well aware of this issue, and a scan of the
> IANA registration procedures for SIP don't indicate any other  
> obviously
> appropriate way to go about this (e.g., a "P-" header does not appear
> to be appropriate, as there are significant behavioral changes
> involved).
>
> This draft needs to be looked at by an S/MIME expert, which is not me.
> The I-D tracker indicates that Eric Rescorla has looked at the draft,
> which may suffice - Eric is definitely a security expert, I just don't
> know off the top of my head whether he's an S/MIME expert.
>
> Section 2.1:
>
> A discussion is needed in Section 2.1 about how to provide integrity
> for data destined for a proxy.  The answer (to be found much later
> in the draft) is that one puts SignedData inside the envelope.  In
> addition to explaining that, the operational order of
> sign-before-encrypt
> ought to be a MUST, not a SHOULD for simplicity.  Would putting
> Digested-data inside the envelope also be acceptable?  If not, it
> should be prohibited with text here.
>
> Section 2.2:
>
>    A UA MAY generate a signature in the SIP Identity [9]
>    header, only if the UA has its own public and private key.
>
> I think this is combining two statements that should be separated for
> clarity:
> - SIP identity and the signature it contains are optional (MAY)
> - Generating that signature requires that the UA have a public/private
> 	key pair that the UA is not required to have.
>
> Section 3:
>
> This sentence about the "Proxy-Required-Body" header is problematic:
>
>    This indication is not mandatory implementation, since the proxy
>    server that has it own security policy attempts to view the message
>    body due to their own services, regardless of the indication by  
> UAs.
>
> I think "mandatory implementation" needs to be separated into UA and
> proxy requirements.  The "be conservative in what you send, be liberal
> in what you accept" design philosophy suggests that use of
> Proxy-Required-Body
> ought to be a "MUST" for UAs when using the encryption functionality
> in this draft, and a "MAY" for proxies under the same conditions (the
> sentence quoted above is in support of the "MAY"), accompanied by the
> discussion already in the draft about why a proxy might want to use  
> this
> header to optimize message handling.  The current language implies  
> that
> a proxy implementer cannot rely on presence of this header - to change
> that without adding the "MUST", add a discussion of what a proxy
> implementer MAY do if this header that SHOULD have been present is
> actually missing.
>
> Name of "Proxy-Required-Body":  This sort of naming is a "SIP Police"
> issue, and I'm not a member of the "SIP Police" in any sense.
> Nonetheless,
> the SIP "Proxy-Require" header appears to tell a proxy that it MUST  
> deal
> with certain things that it could otherwise choose to ignore.  In
> contrast,
> the "Proxy-Required-Body" header in this draft tells a proxy where to
> find things that it will be able to decrypt.  The use of "Require" for
> this purpose could be interpreted to require a proxy to process  
> anything
> it can decrypt.  If that was not intended, a different name should be
> chosen, perhaps Proxy-Recipient-Body.
>
> Section 4:
>
> *** I think I'm missing something.  If I apply the technique in  
> Section
> 4.1 of this draft to the example in section 23.4 of RFC 3261, then I
> think the error that comes back from a proxy that wants to view
> encrypted
> content will contain the content type application/pkcs7-mime .  If
> that's what happens in general, then there are two types of proxies  
> wrt
> encryption - those that allow encrypted content and those that don't
> (and that really should be explained).  This is similar to the digital
> signature policy (either the proxy requires it or the proxy doesn't).
> OTOH, I'm not clear on where in the structure of a SIP message the
> S/MIME
> message bodies discussed in Section 2 are allowed to occur, so I may
> not be correct about what content type comes back for an encrypted  
> body
> that a proxy wants to read - this suggests that Section 2 ought to be
> expanded with a structural discussion that starts from a complete
> SIP message and includes enough discussion of an SDP request in an
> INVITE to set up the examples later.  This concern also turns up in
> the example in Section 5.1.
>
> Section 4.1 also needs to discuss proxy behavior with respect to
> the SIP security tunneling techniques in Sections 23.4.2 and 23.4.3
> of RFC 3161.  For the latter section, the draft needs to be explicit
> about whether it is ok for a proxy to require that it be able to
> decrypt a tunneled encrypted SIP body.
>
> *** Section 4.1 passes the proxy certificate back in the error  
> messages
> without doing anything that would demonstrate that the certificate  
> came
> from the holder of the corresponding private key.  This allows for  
> some
> interesting mischief that could be denial-of-service - the attacker
> collects all the potentially valid proxy certificates and feeds them
> back to the poor victim one at a time in these new SIP error messages
> resulting in a lot of crypto calculation at the victim, and possibly
> exposing message content to proxies or other entities that don't
> actually
> need to see the data.  The requirements in Section 8.1 do not prevent
> this attack as long as the attacker uses certificates that validate
> appropriately (readily obtainable, as certificates are not secrets).
> The proxy really should use its certificate to actually sign
> something in the error message, and that should be something that  
> the UA
> will know is fresh (i.e., that the proxy could not have seen  
> previously)
> to prevent replay of the signed chunk - the call ID looks like it may
> be sufficiently fresh for this purpose, and hence signing the SIP
> headers
> (or some subset thereof) in the error message should suffice.
>
> Figure 3's ASCII graphics need some tweaking to make it clear that
> both firewall traversal and IM logging are on Proxy #1 and not
> Proxy #2.
>
> Section 5:
>
> *** This whole section has structural problems as it describes a
> specific example, making the use of "MUST" and "SHOULD" questionable.
> The general specification of protocol requirements ought to be
> separated out from this very useful discussion of a specific example.
>
> Section 5.1 - if the only encryption is end-to-end, why is there
> no Content-Type in the error that comes back from the proxy?  The
> answer is in Section 5.3, and needs to be explained here.
>
> The discussion about enveloping SignedData in Section 5.1 needs to
> be repeated in Section 2 - see above comment on Section 2.1.  Also
> the SHOULD for signing before encrypting ought to be a MUST for
> simplicity if that's possible.
>
> Section 8.1
>
> The discussion of certificate verification here needs to explicitly
> invoke the requirements in RFC 3280, otherwise all sorts of security
> sloppiness is possible.  For example, there's no requirement in
> this text to check for certificate revocation and the text on chaining
> doesn't say that one needs to check that all certificates aside
> from the leaf are allowed to sign other certificates.  Just invoke
> RFC 3280 to avoid "death by a thousand cuts" - there are lots of
> details that matter, and they're all in RFC 3280 (Section 6).
>
> Section 8.2
>
>    In order to prevent such tampering, the UA SHOULD protect the data
>    integrity before encryption, when the encrypted data is meant to be
>    shared with multiple proxy servers, or to be shared with the UAS  
> and
>    selected proxy servers.
>
> That "SHOULD" ought to be a "MUST", and similarly for the rest of this
> section.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art