[secdir] Fwd: Re: SecDIR review of draft-holmberg-dispatch-received-realm-10

[Stephen Farrell <[e-mail]>]

(Just forwarding this here as it the list wasn't cc'd on the discussion
but I wanted to be able to point at this in the archive in my ballot.)

S


-------- Forwarded Message --------
Subject: Re: SecDIR review of draft-holmberg-dispatch-received-realm-10
Date: Thu, 1 Dec 2016 08:52:10 +0000
From: Christer Holmberg <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
CC: [e-mail]
<[e-mail]>, The IESG <[e-mail]>

Hi,

>>>>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: Needs some additional explanation
>>>
>>>The basic mechanisms look fine. What I am less happy with are the security considerations.
>>>
>>>>The security challenge in SIP is trying to introduce security into a legacy infrastructure that has none. As such, there is inevitably an element of attempting to nail jello to a wall: the nails
>>>>are strong enough but the jello is not. I think there needs to be more discussion of the potential shortcomings of the input data.
>>>
>>>I am not sure I understand. Is your comment related to the SIP information used to create the signature, or?

​>>Yes, how is the interpreter meant to interpret the signed data? Just
because data is signed does not make it trustworthy. All that is known
is who signed it. There are two main sources of concern:
>>
>>1) The signer may be malicious
>>
>>2) The signer may be signing data received from an untrustworthy source.
>>
>>The second is the bigger concern as it may well be inevitable. But it is a concern that needs to be explained.​
>>
>>Note that the received realm parameter value is inserted, signed, verified and consumed within the same operator network. It is not received from elsewhere.
>>
>>The other SIP information elements that are used when calculating the signature will be forwarded anyway (which is the reason we use Annex F).
>>
>>In the initial versions of the draft, the information wasn’t even signed. The operator network entry node simply inserted the received-realm parameter in the SIP request unsigned.
>>
​>>That was not apparent when I read the draft. I think it needs to be
made explicit in the security considerations section. ​
>>
​>>Intra-organization trust is easier to manage than inter-organization
trust.​
>
>What about adding the following paragraph to the Security Considerations?
>
>"The received-realm Via header field parameter is inserted, signed, verified and consumed within an operator network.
>The operator MUST discard parameters received >from another network, and the parameter MUST only be inserted by
>SIP entities that are able to verify from which adjacent upstream network a SIP request is received."

​>That helps a lot​

Great! I will add it.


>>>>The other issue I had was with the requirements for administration of keys. There is a MUST here: "The operator MUST change the key on a frequent basis."
>>>>
>>>>What is the security concern driving this requirement? Changing keys has security costs as well as benefits. It is not something that should be done for the sake of it.
>>>
>>>I think the concern is the same as for keys in general: to avoid a valid key getting into the "wrong hands".
>>>
​>>> Every security control should have a reason.
>>>
>>> Key rollover limits the damage that a single key compromise can cause but introduces an additional point of vulnerability. So it is not to be done just because
​​
it is assumed to be good practice. ​
>>>
​>>> Rather than introducing a MUST here, it would be more appropriate
to point to a document on key management. I think EKR wrote one. I will
look it up.
>>
​>> Given the previous comment, I think it would be rather more useful
to adopt an approach where every signing device has its own key, the key
is bound to the device using hardware techniques that resist extraction
and any expiry mechanism is driven by the system for tracking​

​the devices.​
>
> In today’s world of clouds, virtualisation etc, where users have little or no influence/access to the hardware, I think it would be difficult to mandate such thing.
>
​> True, but right now you have a MUST in the security considerations
that cuts against that approach.
>
> I suggest you drop the MUST - which isn't actually enforceable as I see it and instead state the considerations that should drive key management.​


Ok, I will drop the MUST.

Regarding “state the considerations that should drive key management”,
does the following text help?

“The operator MUST use a key management policy that protects agains
unauthorised access to the stored keys within nodes where they keys are
stored, and that protects against crypto analysis attacks using captured
data sent on the wire.”

I am sure there is LOTS more details that could be said about key
management, but in that case it would probably be better to add a
reference rather than copy/paste everything :)

Regards,

Christer