On Thu, Oct 31, 2019 at 10:49:07PM +0200, Tero Kivinen wrote: > Benjamin Kaduk via Datatracker writes: > > I think we may need to say more about how a JP knows that "secExempt" is > > in effect (see comment in Section 5), since that affects a critical > > piece of the security posture of the network. > > secExempt process comes from the 802.15.4 and is not that well > described even there how it is used, only what it does. > > The basic idea is that upper layer (application) can set secExempt > flag to true for each device it wants to allow bypassing security > checks in the MAC. > > Normally the MAC will do security filtering, i.e., check that each > frame received must have at least security level of n and so on, but > this secExempt allows option for upper layer to temporarely skip those > checks for the incoming frames for certain device. > > I.e., when the joining node sends first unencrypted and > unauthenticated frame to JP, the JP will notice that it does not match > the policy, thus it will drop the frame and call upper layer using > MLME-COMM-STATUS.indication telling that it received frame from device > having address of aa:bb:...:ff with security level of 0, and this > frame was not accepted because it violated the security processing > rules in MAC. > > Then the upper layer can go and install secDeviceDescriptor for the > device having address of aa:bb:...:ff with secExempt flag set to TRUE, > so next time the device sends frame this frame will be exempted for > the security processing and frame is passed to the upper layer. > > The upper layer will then check the frame and process it. In this case > it will forward request to JRC. The secExempt flag for the device is > kept true until the device has successfully joined the network, and > then upper layer can go and turn the secExempt flag off, as there is > no longer need to receive frames from the node that violate security > policy. > > In many implementations all of this security filtering / policy > checking is actually done in the upper layer, not in the MAC, thus > they most likely will not even implement secExempt as such, but they > just know that all joining traffic are exemptions to the normal > security policy requiring frame authentication and optionally > encryption. > > The 802.15.4 description is conceptual API meaning it tells which kind > of features you would need to provide features used, but the actual > implementation can be very different from one device to another. > > The concept described in the 802.15.4 is that you want to have ability > to say do not accept frames that are not protected with suitable > security level, but in addition to that you need to have a way to > exempt those checks in certain cases, like when you are joining the > network.
Thanks for the additional explanation; it really helps to frame the broader context in which this sits. (It also seems like remembering to turn the secExempt flag off is going to be pretty important to the security properties of the system!) To be clear, the paragraph I commented upon was: When sending frames during the join process, the pledge sends unencrypted and unauthenticated frames. The JP accepts these unsecured frames for the duration of the join process. This behavior may be implemented by setting the "secExempt" attribute in the IEEE Std 802.15.4 security configuration tables. How the JP learns whether the join process is ongoing is out of scope of this specification. I'd suggest a rewording/clarification to: NEW: When sending frames during the join process, the pledge sends unencrypted and unauthenticated frames. In order for the join process to be possible, the JP must accept these unsecured frames for the duration of the join process. This behavior may be implemented by setting the "secExempt" attribute in the IEEE Std 802.15.4 security configuration tables. It is expected that the lower layer provides an interface to indicate to the upper layer that unsecured frames are being received from a device, and that the upper layer can use that information to make a determination that a join process is in place and the unsecured frames should be processed. How the JP makes such a determination and interacts with the lower layer is out of scope of this specification. > > Finally, can we discuss whether a 32-bit MIC is the most appropriate > > default for the key usage? I lack the domain background to know how > > much impact there is in going to an ENC-MIC64 or ENC-MIC128 scheme. > > The max frame length is 127 octets, the MAC header is typically around > 23 octets, and with MIC length of 4-octets that leaves 100 octets for > the actual payload. 64-bit MIC would reduce that down to 96 octets, > meaning 4% less than MIC-32. > > Because the "default" algorithm comes from the fact that integer value > 0 in key_usage of the Link_Layer_Key can be omitted (making > Link_Layer_Key structure one octet shorter), it is meaningful to make > the default key usage similarly to value that provides the maximum > saving of octets. > > I.e., if you are so short on octets that you want to save the one > octet from the Link_Layer_Key you are most likely going to use minimal > length for MIC keys too... > > I would expect that quite common usage will be combination of > 6TiSCH-K1-MIC32 and 6TiSCH-K2-ENC-MIC64, i.e., 32-bit MICs for EB, and > 64-bit (or even 128-bit) MICs for data etc. > > Also when using only one key the MIC length must be same for each > frame types (the security proofs of 802.15.4 do not apply any more if > same key is used with different MIC lengths when using TSCH mode), so > thats why you need two keys when you want to have short MICs in EBs, > and longer MICs in other frames. > > In EBs (Enhanced beacons) you want to use short MIC, as the MIC there > does not really serve that much of purpose. The EB contents is mostly > static (ASN and join metrics will be updated but other information is > same), it is not going to change after the network is set up. This > means that nodes who already have key do not have any use for the data > in EB. Those who need that data to be able to join the network, do not > have they to verify the EB... And as there is lots of EBs sent out by > nodes in the network, you really want to save octets from them... Thanks for the extra explanation; I agree that the current assignments do make the most sense. (It's perhaps unfortunate that the word "default" is serving to convey more than one meaning, and I'd welcome extra text that gave the 32-bit MIC less of an implicit recommendation, but there's no Discuss-level point here.) > > o Optionally, a network identifier. The network identifier > > identifies the 6TiSCH network. The network identifier MUST be > > carried within Enhanced Beacon (EB) frames. Typically, the 16-bit > > > > Isn't this an inherent property of EBs and not a new requirement for > > minimal-security? If so, the MUST may not be needed, in favor of > > descriptive language. > > I think 802.15.4 do allow sending Enhanced Beacons without PAN ID at > all, i.e. the Source Address could be extended address of the > coordinator, the Destination address could be broadcast address with > extended address format, and the PAN ID Compression could be set to 1, > in which case both Source and Destination PAN ID fields would be > omitted. > > This text here explicitly says you cannot use such frame even when it > would be allowed by 802.15.4. On the other hand RFC8180 already says > that EBs use Destination Address of 0xffff, and PAN ID Compression is > set, which means Source PAN ID is Not Present, and Destination PAN ID > will be there to contain the network identifier... > > > Section 4.1 > > > > using the cells contained in the EB. The pledge can hear multiple > > EBs; the selection of which EB to use is out of the scope for this > > document, and is discussed in [RFC7554]. Implementers should make > > > > nit: This reads as a statement of fact, as if it will universally be > > true that the pledge can hear multiple EBs. I can suggest a specific > > rewording if you want, though there should be several possibilities. > > As all non-leaf nodes do send EBs, I think it is very common to hear > multiple EBs. I think it is rare case where you set up 6TSCH network > and you can only hear exactly one other node... > > TSCH and 6TSCH is meant for managed networks where someone plans and > sets up the network properly, so normally adminstrator would try to > plan for outages, and provide multiple routes for reliability... Of course; I'm just quibbling about the grammar, is all. Thanks again, Ben > > Section 5 > > > > When sending frames during the join process, the pledge sends > > unencrypted and unauthenticated frames. The JP accepts these > > unsecured frames for the duration of the join process. This behavior > > may be implemented by setting the "secExempt" attribute in the IEEE > > Std 802.15.4 security configuration tables. How the JP learns > > whether the join process is ongoing is out of scope of this > > specification. > > > > This seems like a very important piece of information (whether the join > > process is ongoing, i.e., whether to accept and process unauthenticated > > frames). Is it discussed in 802.15.4 or somewhere else? > > 802.15.4 provides ways of doing it, but does not tell how they are > used. SecExempt is the way of doing it, but how secExempt is used is > up to the upper layer == this document. > -- > kivi...@iki.fi _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
