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

From: "Ono, Kumiko" <[email-masked]>
Date: Fri, 01 Dec 2006 03:16:16 -0500

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

---

From: [email-masked]
Date: Fri, 1 Dec 2006 11:28:07 -0500

Ono-san,

Thanks for making these changes.

Unfortunately, I think that there's significant additional work
needed, as only one of the three major issues identified in the
review appears to have been addressed.  Specifically:
- Issue 1) about determining what MIME type was encrypted when it
	can't be decrypted is partially addressed.
- Issue 2) about certificates in error messages appears to still
	be an open issue.
- Issue 3) about requirements specification appears to have been
	addressed.

Detailed comments are inline.

> to see if a necessary content is contained or not.

Ok, but Section 4.1 now has me confused.  If the proxy can't decrypt the
content, how does it figure out what the MIME type was of the content
is?
In the specific example used in Section 4.1, how does the proxy know to
put "application/sdp" as the MIME type in the error message when it
can't
look at the encrypted content to determine whether it contains an
instance of "application/sdp" ?

involved).
sign-before-encrypt
> Thus, I keep it "SHOULD".

This makes it necessary to explain that the SIP identity mechanism is an
alternative for this "SHOULD".  The text in Section 2.2 almost does this
- add the words "If this is not done, then as an alternative" to the
front of the sentence in the first paragraph of Section 2.2 that says
"A UA MAY generate the signature in the SIP Identity [10] mechanism."

> Added text in Section 2.2.

Fine.

Proxy-Required-Body
> document, RFC4189. I think it is better to keep the constraints as is.

It looks like this has removed the test that states the implementation
requirements on UAs and proxies instead of spelling them out.  That's
not an improvement.

> I added the proxy behavior of handling this header in Section 3.

Ok, but that doesn't respond to the issue.  What is needed is
"a discussion of what a proxy implementer MAY do if this header
that SHOULD have been present is actually missing."

Nonetheless,
>  > contrast, the "Proxy-Required-Body" header in this draft tells a
proxy where to

> by the proxy. Is my interpretation right?

Yes.

> be shared by proxy and destination user. In this case, is it still
fine?

"Proxy-Inspect-Body" ?  Cullen ??
 
encrypted
> 'application/sdp', not a container such as 'application/pkcs7-mime'.

If the proxy can't view the encrypted content, how does it figure
out that it contains an "application/sdp" instance?

S/MIME

> a SIP message contains S/MIME-secured body.

Whether anything needs to be done here depends on the answer to the
previous question.

> message contains "message/sip" Content-Type.

Looks ok, provided that the proxy can see enough info to determine
that there is an encrypted "message/sip" instance when it can't do
the decryption.  A SIP expert should check this.

actually
headers
> server authentication (for inter-server connection) are effective to 

I think the new text misses the point - the attack is not on the proxy
servers, it's on the UA based on returning certificates from proxies
that
aren't on the path of the SIP call.  The paragraph does not contain
enough
detail to tell me whether the authentication mechanisms stop the attack
-
it needs to be explicit on who authenticates what and how those
authentications enable a UA to reject certificates for proxies that
aren't actually involved in the call.
 
> I moved examples from the behavior section to the message 

Looks ok on a quick scan.  Please check that the requirements cover
all scenarios, not just the removed example.

> I moved the text to Section 2.3.
> 

Add mentions of those two possibilities in Section 2.3, please.

> I added text in Section 8.1 and RFC3280 in the normative reference.

That's not sufficient - the text only says that a few specific things
need to be done as specified in RFC 3280.  It needs to say that **all**
the verification checks specified in RFC 3280 MUST be performed as
specified there, otherwise this draft will have to reconstruct a large
portion of RFC 3280's certificate (and cert chain) verification
algorithm, one provision at a time, which is a lousy idea.

> I tried to change to use "MUST" by specifying the condition at the
whole 

Where?  I can't find this change.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------