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

["Ono, Kumiko" <[e-mail]>]

Hi David,

Thank you for your close review. I'll try to resolve them.

Regards,
Kumiko Ono

[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