Tero wrote:
> Payload IEs are encrypted and authenticated.
Is it not correct to say that payload IEs *may* be encrypted and/or
authenticated,
rather than that they are?
Xavi wrote:
> As for well-known keys [...] My point is to remove it but I want to
see everybody's opinion.
I disagree with this. The discussion is not about whether well-known
keys provide
security. I think that everyone on this list will agree that they do not.
If the choices are:
1) use a PSK so that you have a secure beacon, and you know that it's a
6tisch
network that is the kind that you want to join
2) use a well-known key so that you know that at least someone is
intentionally
sending 6tisch EBs (although they may be faked) and that no bits have
changed in this EB
3) don't use anything at all
Then I am in favor of options 1 or 2. That's what the current text allows.
Is there an argument in favor of option 3?
In WirelessHART, we had a discussion about option 1: "Should we keep
[K1] secret?"
The conclusion was: all devices from now until the end of time need to
know K1,
so that a node that we deploy tomorrow will be able to join a network
that we
deploy today. It's going to be public eventually, we may as well reveal
it today.
Its purpose is not security - it is message integrity.
ksjp
On 4/21/2015 6:32 AM, Xavier Vilajosana wrote:
Dear Tero,
thanks for your comments. I will clarify that headers are only
authenticated and payloads are both authenticated and encrypted. As
for well-known keys, that was exactly the discussion at the meeting.
My point is to remove it but I want to see everybody's opinion.
regards,
Xavi
2015-04-21 13:17 GMT+02:00 Tero Kivinen <[email protected]
<mailto:[email protected]>>:
Xavier Vilajosana writes:
> Hi Rene, Michael and Jonathan,
>
> I am working on the text for the security section in the minimal
draft. I
> included Rene's suggestion but I still have doubts as during the
IETF meeting
> there was some discussion about it.
>
> the security section is composed of 2 paragraphs.
>
> As this document refers to the interaction between Layer 3 and Layer
> 2 protocols, this interaction MUST be secured by L2 security
> mechanisms as defined by [IEEE802154e]. Two security
mechanisms are
> considered, authentication and encryption, authentication
applies to
> the all packet content while encryption applies to header IEs
and MAC
^^^^^^^^^^
Header IEs are not encrypted, they are only authenticated. Payload IEs
are encrypted and authenticated.
Most of the TSCH IEs are Payload IEs (or actually a Nested IEs inside
the MLME payload IE). These include TSCH Synchronization IE, TSCH
Slotframe and Link IE, and TSCH Timeslot IE. Those IEs are encrypted.
TSCH uses also one Header IE, i.e. Time Correction IE, and it is only
authenticated.
> payload. Key distribution is out of scope of this document, but
> examples include pre-configured keys at the nodes, shared
keys among
> peers or well-known keys. Refer to the 6TiSCH architecture
document
> [I-D.ietf-6tisch-architecture] for further details on key
> distribution and advanced security aspects.
>
> The present document assumes the existence of two
cryptographic keys,
> which can be pre-configured. One of the keys (K1) is used to
> authenticate EBs. As defined in Section 4, EBs MUST be
> authenticated, with no payload encryption. This facilitates
logical
> segregation of distinct networks. A second key (K2) is used to
> authenticate DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types and
> respective header IEs, with payload encryption. Depending on
> security policy, these keys could be the same (i.e., K1=K2).
>
> The second paragraph is what Rene proposed and had consensus on
the ML. In
> red is my doubt that raises from the discussions during the WG
meeting at the
> IETF in Dallas. I think that someone was opposing to the text
indicating
> well-known keys.
I think well-known keys will just make security weaker, and completely
remove the security if K1=K2.
Also if the K1 is well-known then it will NOT provide the "logical
segregation of distinct networks".
Also if K1 is well known, then EBs do not have any protection, i.e.
anybody can generate fake EBs and mess up the network totally by
giving completely wrong schedule for everybody. If the K1 is something
that you get after you join the network, then you can verify that EBs
are sent by someone who is part of the network, thus you can trust
them bit more.
Also if well-known K1 and EBs are used for time syncronization, i.e.
keeping the ASN in sync after sleep, then nodes which wake up and
whole do know the well-known K1 and private K2, cannot trust the ASN
he gets from the EBs, as it might be faked, thus he cannot use K2 key
before rejoining the network. Otherwise the attacker might roll ASN
backwards during the sleep and cause the device to use same ASN twice
(== same nonce twice == encryption provided by the K2 key would be
broken).
--
[email protected] <mailto:[email protected]>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
