On 4/26/17 2:36 PM, Kathleen Moriarty wrote:
On Wed, Apr 26, 2017 at 2:42 PM, Adam Roach <[email protected]> wrote:
On 4/26/17 11:34 AM, Kathleen Moriarty wrote:
Since the following text int he Security Considerations section is a
recommendation, IMO it would be better to drop "or otherwise obfuscated"
from the sentence as encrypting the keys really should be the
recommendation. Can we make this update?
It is RECOMMENDED that keys be encrypted or otherwise obfuscated
when
stored internally on a network device supporting this specification.
If obfuscation is what happens more often in practice, maybe mention this
as a fallback from the recommendation, but not make them sound
equivalent?
To be clear -- the current guidance from the security area is to perform
this kind of encryption, where you have encrypted material living
side-by-side with the key necessary to decrypt it?
We are talking about using a key encrypting key (KEK) and storing
that, not storing the raw key next to the encrypted data as far as I
can tell.
Right.
Additionally, I haven't seen a discussion on the hardware
this is expected to run on.
That might be appropriate matter for the draft, if it is going to make
this recommendation.
Some implementations of KEK solutions use dedicated hardware for the
KEK and require authentication for access to the key, hence preventing
generic access and side-by-side storage of the KEK's protected key,
and encrypted data. I'd rather see a KEK used than just a key stored
in any case. Are you arguing for not using any encryption at all?
I'll defer to you, of course, since you have presumably given the topic
more thought than I have, but: yes.
Absent something like an HSM or forcing human intervention whenever a
process starts (or restarts), it seems that the scheme described in
section 5 doesn't actually deter a competent attacker from obtaining the
keys. My impression is that storing information in an encrypted form
that can be trivially decrypted by an attacker provides a false sense of
security to equipment operators.
If the scheme in section 5 *does* require the kind of prerequisites you
posit, such as dedicated security hardware, it seems that such
prerequisites should be mentioned alongside the recommendation.
For YANG modules, couldn't the application via NETCONF/RESTCONF
accessing the module provide the credentials to access the key
protected by the KEK?
That solves the issues with provisioning, but doesn't seem to help the
processes actually involved in routing.
Some implementations could store the KEK in
dedicated hardware as well. In this way, storing the KEK and data
together is not the same as storing a key right next to the data it is
protecting.
This makes perfect sense; and it should probably be in the document.
Use of a KEK is better then not encrypting and can be done
well.
It can also be done poorly, and the mention of obfuscation (along with
the exchange I cite below) leads me to believe that -- absent concrete
guidance to the contrary -- implementors will choose to do it poorly.
It's not clear that doing this poorly provides any benefit, and it seems
to me that it may cause harm: if something _looks_ secure but isn't,
doesn't that have the potential for operators to incorrectly treat it as
secure? Again, this is more your area than mine and so I will defer to
your opinion on the topic; but from a lay perspective, this seems likely
to result in the lack of guarding against compromise of the encrypted
information under the mistaken impression that it can't be decrypted
trivially.
Am I missing something? Was there something implementation specific
that has the raw key stored with the encrypted data?
Perhaps the following exchange with the author:
Adam: "By my reading, this is just talking about encrypting 'on the
disk' storage on the device. Any processes involved in provisioning the
values or using them to process traffic would have access to the
plaintext, presumably by reading the encrypted form off disk, reading
some keying material off disk, and combining them to retrieve the
plaintext key."
Acee: "This is the correct interpretation."
/a
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
