Subject: Re: [secdir] SecDir review of draft-camarillo-rai-media-policy-dataset-01

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 5 Jul 2012 12:46:32 +0300

Hi Yaron,

per your comments, I have added a reference to RFC 3470 to the Security
Considerations Section. I have written the following:

    Section 7 of RFC 3470 [RFC3470] provides general
    security considerations regarding the transport of XML documents
    in network protocols.

With respect to the other reference you would like to see included in
the draft:

http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xinclude-20061115.xml

How do you want me to include this reference in the draft? That is,
which particular part of this W3C document do you want the draft to
reference?

Thanks,

Gonzalo

On 31/05/2012 1:06 PM, Gonzalo Camarillo wrote:
> Hi Yaron,
> 
> thanks for reviewing the document. I will add the two references you
> suggest in your last point to the next revision of the draft.
> 
> With respect to the remainder of your comments on the event package
> document, that draft has already been in the RFC Editor's queue for a
> while. So, at this point, we will not change it (although I would be
> happy to replace that "should not" with a "SHOULD NOT" in AUTH48). Also,
> SIP security is getting deployed on the field slowly as time goes by. It
> is true that it is taking a while, but we are getting there.
> 
> Cheers,
> 
> Gonzalo
> 
> 
> On 25/05/2012 7:07 PM, Yaron Sheffer wrote:
>> I have reviewed this document as part of the security directorate's 
>> ongoing effort to review all IETF documents being processed by the IESG. 
>> These comments were written primarily for the benefit of the security 
>> area directors.  Document editors and WG chairs should treat these 
>> comments just like any other last call comments.
>>
>> Summary
>>
>> Nothing much here - this is not where the security action is. However a 
>> companion document may need some deeper security review.
>>
>> Details
>>
>> This draft defines the contents/format of a media document. The document 
>> allows a SIP policy server to dictate the media policy that should be 
>> implemented by a UA, in general or on a per-session basis.
>>
>> • The draft requires that all documents be well-formed and valid XML, 
>> which is good - not only for security.
>> • The real security stuff is in draft-ietf-sipping-policy-package-08. I 
>> will not review that document here, but I find it puzzling that session 
>> (media) information is transmitted/secured along with session encryption 
>> keys. Mixing together data of such disparate security sensitivity levels 
>> is likely to result in either over-engineering or under-security.
>> • Reading further down the said security considerations, this issue is 
>> addressed ("the user agent should not insert" etc.), but none of that 
>> discussion is normative!
>> • Moreover, recent discussion on SAAG 
>> (http://www.ietf.org/mail-archive/web/saag/current/msg03695.html) 
>> suggests that some of the security solutions mandated by the Policy 
>> Package draft as well as the current draft are, to put it mildly, not 
>> widely implemented.
>> •  Back to the current document. Re: XML security considerations, please 
>> reference the security considerations of RFC 3470, and possibly also: 
>> Marsh, J., Orchard, D., and D. Veillard, "XML Inclusions (XInclude) 
>> Version 1.0 (Second Edition)", World Wide Web Consortium Recommendation 
>> REC-xinclude-20061115, November 2006, 
>> <http://www.w3.org/TR/2006/REC-xinclude-20061115>.
>>
>> Thanks,
>>      Yaron
>>
>

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 15 Jul 2012 00:13:30 +0300

This protocol defines a new AVP that encapsulates multiple PANA AVPs 
within one message, and encrypts them. The encryption key is derived 
from EAP's MSK, and the only encryption algorithm defined is AES128-CTR.

Summary

I'm a bit worried about the quality of the proposed cryptographic
solution. While using Counter Mode as the preferred encryption mode is
completely legit, it does require some extra care.

Details

Please note that I am neither a PANA expert nor a cryptographer.

- Sec. 2: I am not clear why MSK is used for deriving the keys, in 
preference to EMSK. I understand that one of the main differences 
between the two is that MSK is possibly shared with an Authenticator 
server (where one exists), but the EMSK is not. It would seem to me that 
a generic confidentiality mechanism should use the key that's shared 
with fewer partners.

- Sec. 2: please clarify whether Encr-Encap can already be used in the 
first message that completes negotiation of the algorithm, i.e. the 
initial PANA-Auth-Answer.

- Sec. 2: according to RFC 5191 (PANA), Sec. 5.4, the AUTH AVP is not 
mandatory (or am I missing something?) It should be made mandatory for 
messages that contain an Encr-Encap (possibly with the exception of 
authenticated encryption algorithms, but none are defined in the current 
document). Emphatically so if Counter Mode is used.

- Sec. 3: I understand why the nonces are used in the derivation. I do 
not understand why the initial messages are used - cryptographic binding 
of message contents is appropriate for authentication 
(integrity-protection) messages, but seems redundant for generation of 
confidentiality keys.

- Sec. 4: Counter Mode is infamous for being extremely sensitive to the 
quality of the IV (a.k.a. "nonce"). So I would expect a random nonce to 
be used for this purpose, rather than the concatenation of 3 protocol 
values. Specifically, what is the likelihood of these parameters 
repeating after a reboot?

- Sec. 4: please explain where the initial 02 octet of the counter block 
comes from.

- Sec. 5: The value of the Encr-Encap AVP is defined as 13 here, but is 
left open in the IANA Considerations.

- Sec. 5: I suppose there is no (block cipher) padding. Please say so 
explicitly. In fact this AVP cannot be generic if neither padding nor IV 
are catered for. In other words, it's good for Counter Mode but for 
little else.

- Sec. 6.1: the Nonce AVPs used for deriving the encryption key 
obviously cannot be encrypted.

Thanks,
      Yaron