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

[[e-mail]]

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.

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

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" ?

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

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

> Using Digest-data is not acceptable, because RFC3261 doesn't accept
it.
> Added text in Section 2.2.

Fine.

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

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.

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

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

>  > 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?

Yes.

> 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?

"Proxy-Inspect-Body" ?  Cullen ??
 
> 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'.

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

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

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

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

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.

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

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

Looks ok on a quick scan.  Please check that the requirements cover
all scenarios, not just the removed 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.
> 
> 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 Section 2.3.
> 
> I keep it "SHOULD", because RFC3261 defines signing after encrypting, 
> and the SIP identity also provide signature after encrypting.

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

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

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.

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

Where?  I can't find this change.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art