Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Fri, 01 November 2019 23:45 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF3512007C; Fri, 1 Nov 2019 16:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz1QGykvt17L; Fri, 1 Nov 2019 16:45:48 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2CD0120074; Fri, 1 Nov 2019 16:45:48 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA1NjeEh012914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 19:45:43 -0400
Date: Fri, 1 Nov 2019 16:45:40 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Tero Kivinen <kivinen@iki.fi>
Cc: The IESG <iesg@ietf.org>, 6tisch-chairs@ietf.org, pthubert@cisco.com, draft-ietf-6tisch-minimal-security@ietf.org, 6tisch@ietf.org
Message-ID: <20191101234540.GS55993@kduck.mit.edu>
References: <157250308434.32464.3300056120615958441.idtracker@ietfa.amsl.com> <23995.18627.488068.508211@fireball.acr.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <23995.18627.488068.508211@fireball.acr.fi>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/hkt29ybkPlXuism6Ezs7kU-zz6Q>
Subject: Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Nov 2019 23:45:52 -0000

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.
> -- 
> kivinen@iki.fi