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

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

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.

[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.

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art