End-to-middle Security in the Session Initiation Protocol (SIP)
draft-ietf-sip-e2m-sec-06

Folks, I am very sorry to do this because I know of all the time and effort that has been put into this and I believe there eventually will be use for this. I am going to send this draft back to the working group to sort out the problems.

The last call comments raise the issues around people would find the work here acceptable for experimental but are very uncomfortable with PS.

The is also a significant issue that we would need to be able to address around knowing the trusted proxies.

IANA Last Call Comments:

Upon approval of this document, the IANA will take
the following Actions:

Action 1 [section 9.1]:

Upon approval of this document, the IANA will make
the following assignments in the "Session Initiation
Protocol (SIP) Parameters" registry located at

http://www.iana.org/assignments/sip-parameters

sub-registry "Header Fields"

Header Name compact Reference
----------------- ------- ---------
Proxy-Inspect-Body [sip-e2m-sec-05]


Action 2 [sections 9.2, 9.3]:

Upon approval of this document, the IANA will make
the following assignments in the "Session Initiation
Protocol (SIP) Parameters" registry located at

http://www.iana.org/assignments/sip-parameters

sub-registry "Response Codes"
sub-sub-registry "Request Failure 4xx"

Response Code Reference
------------- ---------
495 Signature Required [sip-e2m-sec-05]
496 Proxy Undecipherable [sip-e2m-sec-05]


Action 3 [section 9.4]:

Upon approval of this document, the IANA will make
the following assignments in the "Session Initiation
Protocol (SIP) Parameters" registry located at

http://www.iana.org/assignments/sip-parameters

sub-registry "Warning Codes (warn-codes)"

Code Description Reference
---- --------------------------------------------------- ---------
380 Required to View Content-Type [sip-e2m-sec-05]


We understand the above to be the only IANA Actions
for this document.

GEN ART Comments...


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

Update note for Cullen .....


In the bottom of the abstract of the document, add a paragraph that says:

"This specification is approved at the proposed standards level due to to the IANA registration requirements. It is of sufficient quality for that level however the uses of this mechanism in this specification are considered experimental."

Thanks, Cullen



From: Eric Rescorla
Date: June 27, 2006 1:43:03 PM PDT
To: fluffy@cisco.com
Subject: Review: draft-ietf-sip-e2m-sec-02

Cullen,

As you asked, I took a look at this document.

All the figures appear to show the recipientInfos field
after the encryptedContentInfo field. In CMS the order
is the opposite to allow streaming processing.

I'm concerned about the ability of the UAC to determine
that a legitimate proxy is requesting a cleartext copy.
The rules in S 8.1 don't appear to work if there are
three proxies in the chain.






On Aug 9, 2006, at 3:56 PM, Rohan Mahy wrote:


During my review of e2m-sec, I came up with a few suggestions, which are below.


s/Indecipherable/Undecipherable/

I think Proxy-Body-Required is a better name.

Section 1 para 1:
old:
The mechanisms consist of generating S/MIME-secured
  message body and indicating the target message body for a proxy
  server selected by the UA.
proposed:
The mechanisms consist of generating an S/MIME-secured
  message body and indicating that the target message body is for a specific proxy
  server selected by the UA.

Section 2.2 para 2:
old:
Note: There are other mechanisms which can provide data integrity,
      such as S/MIME CMS AuthenticatedData, which requires that a UA
      obtains the credential of the recipient, that is a proxy server,
      in advance.  However, this is not used in [1] and require a
      mechanism to securely transmit the credential from the proxy
      server to the UA.
proposed:
Note: There are other mechanisms which could provide data integrity,
      such as S/MIME CMS AuthenticatedData, which requires that a UA
      obtains the credential of the recipient proxy server
      in advance.  However, AuthenticatedData is not used in [1] and requires a
      mechanism to securely transmit the credentials from the proxy
      server to the UA.

Section 6 (BNF)
I think you want to allow multiple required-proxies.  This means you need to reserve comma-separated syntax for the individual header field values.  I also added support for extension parameters.  This would give you a BNF that starts like this:

Proxy-Required-Body  = "Proxy-Required-Body" HCOLON required-proxy
*(COMMA required-proxy)
require-proxy = host SEMI target-body-params
target-body-params = cid-param *(SEMI gen-param)
etc...

Section 6 (table of methods/headers)
table should include REFER and PUBLISH methods

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the
Internet Draft (ID), and in particular, do they believe this ID is
ready to forward to the IESG for publication?  Which chair is the WG Chair
Shepherd for this document?

Dean Willis will act as the WG shepherd for this document, and has
personally reviewed this draft.


1.b) Has the document had adequate review from both key WG members
and key non-WG members?  Do you have any concerns about the
depth or breadth of the reviews that have been performed?

The draft has been reviewed to the extent it will be by the working
group. There are potentially undiscovered security issues, which is in
part why we recommend publishing this as an experimental RFC.

1.c) Do you have concerns that the document needs more review from
a particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, internationalization, XML, etc.)?

Some additional security review might be appropriate, but this seems
to be less a significant issue than gaining real operational
experience with the protocol.

1.d) Do you have any specific concerns/issues with this document
that you believe the ADs and/or IESG should be aware of?  For
example, perhaps you are uncomfortable with certain parts of
the document, or have concerns whether there really is a need for
it.  In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance
the document, detail those concerns in the write-up.

There is some concern in the working group about the constituency for
this draft. Some participants feel the problem is critical and must be
solved, whereas others view it as a non-problem. This has been
discussed extensively in the working group, resulting in a final
disposition of general apathy.


1.e) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The working group in general understands and agrees with the technical
aspects of this document, but remains divided on its utility.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in
separate email to the Responsible Area Director.  (It should
be separate email because this questionnaire will be entered into
the tracker).

There have been no indications of extreme discontent in the
development of this document.