Draft:   draft-ietf-sip-e2m-sec-03.txt
Reviewer: Black_David@emc.com
Review Date: Thursday 9/14/2006 7:17 PM CST
Early Review Date: 9/15/2006

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