David, Cullen,
I really appreciate your closely reviewing and your patience.
I updated the document and uploaded at
www.cs.columbia.edu/~kumiko/IETF_doc/draft-ietf-sip-e2m-sec-04.txt.
See comments inline.
[EMAIL PROTECTED] 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.
To clarify this, I added a note that the label doesn't indicate what
kind of content-type is encrypted in Section 3. A proxy needs to decrypt
to see if a necessary content is contained or not.
> 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.
Added Section 2.3 to explain how to generate S/MIME body for
confidentiality and data integrity.
I understand "MUST" is simpler, but for integrity, generating SignedData
is not only a way. Alternatively, SIP identity mechanism can be used.
Thus, I keep it "SHOULD".
Using Digest-data is not acceptable, because RFC3261 doesn't accept it.
Added text in Section 2.2.
> 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.
Fixed.
> 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.
I understand the design philosophy, and simplicity is important.
First I wanted to minimize the requirements to UA implementation.
Generating S/MIME EnvelopedData for multiple is MUST, and indicating the
target body is SHOULD. This constraints are based on the requirement
document, RFC4189. I think it is better to keep the constraints as is.
> 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.
I added the proxy behavior of handling this header in Section 3.
> 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.
I see your point. The SIP "Proxy-Require" header requires a proxy to
process specific features that is specified in the header. In the e2m,
the specified body with "Proxy-Required-Body" doesn't contain any
features to be processed at a proxy, but contains just data to be viewed
by the proxy. Is my interpretation right?
If so, I'm afraid "Proxy-Recipient-Body" implies the body that is
received only by proxy. This end-to-middle security allows the body to
be shared by proxy and destination user. In this case, is it still fine?
For the present, I haven't changed the header name. After receiving your
answer, I'll consider the change again.
> 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).
I'm not sure I understand your point exactly.
I added an example of the Warning header to specify the content-type to
be viewed. The content-type specify the target content e.g.
'application/sdp', not a container such as 'application/pkcs7-mime'.
> 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 2 discusses only the inside of CMS EnvelopedData. That doesn't
affect a SIP message. The examples of SIP messages in Section 7 show how
a SIP message contains S/MIME-secured body.
> 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.
I added how a proxy server requires tunneling message, both for
confidentiality and integrity in Section 4.1. For these cases, the error
message contains "message/sip" Content-Type.
> *** 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.
Checking the freshness is an interesting idea.
However, a simple solution, authentication is effective enough here.
I added some text in Section 8.3 to explain that user authentication or
server authentication (for inter-server connection) are effective to
prevent such attack.
> 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.
Fixed.
> 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.
I moved examples from the behavior section to the message example section.
> 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.
Added.
> 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.
I moved the text to Setion 2.3.
I keep it "SHOULD", because RFC3261 defines signing after encrypting,
and the SIP identity also provide signature after encrypting.
> 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).
I added text in Section 8.1 and RFC3280 in the normative reference.
> 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.
I tried to change to use "MUST" by specifying the condition at the whole
text.
I hope I understand your comments and incorporate them properly.
Thank you so much.
Kumiko Ono
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
