Re: [6tisch] [6tisch-security] proposed security text for architecture draft

["Pascal Thubert (pthubert)" <[e-mail]>]

I agree with Yoshi that the link local in the RH is really looking for trouble, and certainly an unusual operation.
Normally you can only route to a link local if you 1) are directly connected and 2) provide an interface ID associated to the address, which is missing in the RH.
Yesterday we discussed an "optimistic" usage of a global address that the joining device would form.
This requires the joining device to receive an RA. Is that unacceptable?

Cheers,

Pascal


> -----Original Message-----
> From: 6tisch-security [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: mercredi 12 novembre 2014 12:13
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [6tisch-security] proposed security text for architecture draft
> 
> Michael and all,
> 
> I am still in the middle of understanding how loose source routes for joining
> nodes that have only link-local address can work.  Another option that is not
> mentioned in the text below is relaying authentication at join assistant node.
> The authentication relay model is proven to work in ZigBee IP.
> 
> I have a reservation on JCE-initiated TLS session as opposed to what existing
> 802.1X/PANA with EAP-TLS do where TLS session is initiated by joining node.  An
> obvious downside of JCE-initiated TLS session is that it is difficult to use AAA
> infrastructure.
> 
> Beacon security issue should be investigated more.  Integrity protecting beacons
> with a well-known key can allow attackers to easily launch a DoS attack on
> already connected nodes by advertising forged ASN as attackers know the well-
> known key.  Shouldn't network-specific dynamic key also be needed for
> protecting beacons for already-connected nodes?
> 
> Regards,
> Yoshihiro Ohba
> 
> 
> -----Original Message-----
> From: 6tisch-security [mailto:[e-mail]] On Behalf Of
> Michael Richardson
> Sent: Thursday, November 13, 2014 1:51 AM
> To: [e-mail]; [e-mail]
> Subject: [6tisch-security] proposed security text for architecture draft
> 
> 
> This text is the architecture results of the secure (zero-touch) design team.
> The realization that we should use loose source routes is due to Pascal.
> 
> I believe this goes into a new section between 10. Centralized vs.
> and 11. IANA Considerations.  Interspersed is some text that I think goes in to
> section 12. Security Considerations.
> 
> If you are interested in the history of this text, or some additional more
> implementation side ideas, then I recommend reviewing the diff
>      http://www.ietf.org/rfcdiff?url1=draft-richardson-6tisch--security-6top-
> 03&difftype=--html&submit=Go%21&url2=draft-richardson-6tisch--security-
> 6top-04
> 
> 
> 10B.  Architectural requirements of join protocol
> 
> 10B.1.  Entities involves in the join process
> 
>    The following actors are involved: there is a new joining node.  It
>    is (radio) adjacent to the join assistant.  The join assistant is
>    part of the production network, and participates in one or more
>    DODAGs, such that it is reachable from the 6LBR, and the JCE.
> 
> 10B.2.  Join Protocol deliverables
> 
>    This section works from the ultimate goal, and goes backwards to
>    prerequisite actions.  (Section 6 presents the protocol from
>    beginning to end order)
> 
>    The ultimate goal of the join protocol is to provide a new node with
>    a locally significant security credentials that it is able to take
>    part in the network directly.  The credentials may vary by
>    deployment.  They can be one of:
> 
> 
>    1)  a network-wide shared symmetric key (this is the production
>        network key, or MasterKey)
> 
>    2)  a locally significant (one-level only) 802.11AR type LDevID
>        certificate (which allows it to negotiate a pair-wise keys)
> 
>    One of these two items is delivered by JCE to the joining node using
>    the 6top protocol.  That is, the JCE provisions using a secure
>    "northbound" interface.  The authentication of this interface the
>    subject of the Join Protocol as explained below.
> 
>    The above credential are used for authentication to generate per-peer
>    L2, using a key exchange protocol.  The choice of key exchange
>    protocol, and what kind of link and multicast keying needs to be done
>    is also provisioned by the JCE.  There are a number of options for
>    doing this, such as:
> 
>    1)  Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment]
>        (IMPORTANT, a good option.  Uses certificates from common CA)
> 
>    2)  work in 802.15.9 (uses certificates from common CA)
> 
>    3)  Security Framework and Key Management Protocol Requirements for
>        6TiSCH [I-D.ohba-6tisch-security] (this document provides the
>        phase 0 required, using the network-wide shared key)
> 
>    4)  Layer-2 security aspects for the IEEE 802.15.4e MAC
>        [I-D.piro-6tisch-security-issues]: the MasterKey is used to
>        derive per-peer L2 keys
> 
>    Per-peer L2 keying is critical when doing peer-2-peer schedule
>    negotiation over 15.4 Information Elements.  Therefore a network-wide
>    layer-2 key is inappropriate for the self-organizing networks, and a
>    protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys.
> 
>    For networks where there is a PCE present and it will do all schedule
>    computation, then the only trust relationship necessary is between
>    the individual node and the PCE, and it MAY be acceptable to have a
>    network-wide L2 key derived in ways such as
>    [I-D.piro-6tisch-security-issues] describes in section ?.  The trust
>    relationship between the PCE and the joining node flows from the
>    LDevID certificate loaded by the JCE.  When the PCE and JCE are co-
>    located, the existing 6top/DTLS security association could be reused.
> 
> 10B.3.  Join Protocol connection setup
> 
>    The intermediate level goal of the join protocol is to enable a Join
>    Coordination Entity (JCE) to reach out to the new node, and install
>    the credentials detailed above.  The JCE must authenticate itself to
>    the joining node so that the joining node will know that it has
>    joined the correct network, and the joining node must authenticate
>    itself to the JCE so that the JCE will know that this node belongs in
>    the network.  This two way authentication occurs in the 6top/CoAP/
>    DTLS session that is established between the JCE and the joining
>    node.
> 
>    [I-D.ietf-6tisch-6top-interface] presents a way to interface to a
>    6top information model (defined in YANG).  [I-D.ietf-6tisch-coap]
>    explains how to access that information model using CoAP.  This
>    information model will include security attributes for the network.
>    The JCE would therefore reach out to the joining node and simply
>    provision appropriate security properties into the joining node, much
>    like the PCE will provision schedules.
> 
>    This 6top-based secure join protocol has defined a push model for
>    security provisioning by the JCE.  This has been done for three
>    reasons:
> 
>    1)  6tisch nodes already have to have a 6top CoAP server for schedule
>        provising
> 
>    2)  this permits the JCE to manage how many nodes are trying to join
>        at the same time, and limit how much bandwidth/energy is used for
>        the join operation, and also for the JCE to prioritize the join
>        order for nodes.
> 
>    3)  making the JCE initiate the DTLS connection significantly
>        simplies the certificate chains that must be exchanged as the
>        most constrained side (the joining node) provides it's
>        credentials first, and lets the less constrained JCE figure out
>        what kind of certificate chain will be required to authenticate
>        the JCE to the joining node.  In EAP-TLS/802.1x situations, the
>        TLS channel is created in the opposite direction, and it would
>        have to complete in a tentative way, and then further
>        authorization occur in-band.
> 
> 10B.4.  End to End considerations for Join Protocol
> 
>    In order for a 6top/DTLS/CoAP connection to occur between the JCE and
>    the joining node, there needs to be end-to-end IPv6 connectivity
>    between those two entities.  The joining node will not participate in
>    the route-over RPL mesh, but rather will be seen by the network as
>    being a 6lowpan only leaf-node.
> 
>    The joining node sends traffic to the join assistant, which forwards
>    it using the normal RPL DODAG upwards routes, and which will reach
>    the JCE using regular routing.
> 
>    The challenge is getting connectivity from the JCE to the joining
>    node, as the DODAG will have no information about this node.
>    Instead, the JCE will use loose-source routes to address packets
>    first to the Join Assistant, which will then forward to the joining
>    node.  This has an interaction with the (strict) source routes used
>    by non-storing DODAGs which would be used by the 6LBR to reach the
>    Join Assistant.
> 
>    There are some alternatives to having full end to end connectivity
>    which are discussed in the security considerations section.
> 
> 12.1.  Security Considerations: alternatives to source routes
> 
>    This goes into security-considerations section
> 
>    A number of alternatives were considered for creating end to end
>    connectivity between the joining node and the JCE, but were rejected.
> 
>    (1)  IPIP tunnel between Join Assistant and JCE
> 
>    (2)  using straight RPL routing: the Join Assistant sends a DAO
> 
>    (3)  using a separate RPL DODAG for join traffic
> 
>    (4)  establishing a specific multi-hop 6tisch track for join traffic
>       for each Join Assistant
> 
> 12.1.1.1.  IPIP tunnel
> 
>    This mechanism requires 40 bytes overhead per packet, and may require
>    specific state to be created on the Join Assistant, or may open the
>    network up to a resource exhaustion by malicious join nodes.
> 
>    This mechanism was rejected on due to byte count, because it would
>    require code only needed for join, and because doing it securely may
>    require a per-tunnel state to be maintained on the join assistant.
> 
> 12.1.1.2.  join existing DODAG
> 
>    This mechanism is to just have the new node join the DODAG as a leaf
>    node.  The join assistant would issue a DAO for the new node.  If a
>    storing DODAG was used, this would directly cost state in all parent
>    nodes of the Join Assistant, subjecting the lower-rank parts of the
>    network to significant denial of service attacks.
> 
>    On a non-storing DODAG the situation is significantly better: no
>    state is created by the presence of the leaf node except in the 6LBR,
>    where available resources may be higher.
> 
>    This mechanism was rejected in favour of the loose source routed
>    option as this the loose source routed option always works even for
>    storing DODAGs, and is otherwise exactly equivalent in terms of
>    network bandwidth cost.
> 
> 12.1.1.3.  join a DODOAG for joining
> 
>    One option to deal with the problem of resource consumption in the
>    storing DODAG case is to use a second DODAG.
> 
>    This mechanism was rejected as it consumes resources in all nodes for
>    the second DODAG, and many implementations support on a single DODAG.
>    While storing DODAGs have a lighter network impact than non-storing
>    ones (due to the lack of source routes), the PCE can control how much
>    network bandwidth can be wasted by malicious join nodes using the
>    regular 6tisch mechanisms, and this can be tuned.  A second DODAG
>    would be a sunk cost with no tuning possible.
> 
> 12.1.1.4.  create 6tisch track to form mesh-under
> 
>    This mechanism would use 6tisch tracks so that traffic from the JCE
>    would be switched from 6LBR to join node.  A track would be required
>    to each join assistant.  This is an optimized form of source routing.
> 
>    This mechanism was not rejected, rather it was observed that it may
>    be applied to any mechanism that uses source routing, and is an
>    optimization; it has a certain cost in the form of intermediary node
>    state, but that this state is not created by a malicious join node,
>    rather it is created by the PCE.
> 
> 10B.5.  Join node discovery mechanism
> 
>    Continuing to work backwards, in order the JCE reach out to provision
>    the Joining Node, it needs to know that the new node is present.
>    This is done by taking advantage of the 6lowPAN Address Resolution
>    Option (ARO) (section 4.1 [RFC6775]).  The ARO causes the new address
>    to also be sent up to the 6LBR for duplicate detection using the DAR/
>    DAC mechanism.  The 6LBR simply needs to tell the JCE about this.  A
>    new protocol may be required for the situation where the JCE, PCE and
>    6LBR are not co-located; it may be that this protocol could be simply
>    a DAR in some encapsulation.  The details of this are currently out
>    of scope for the architecture, as they affect interoperability
>    between different vendors of JCE/6LBR/PCE rather than
>    interoperability between the assistance/offload infrastructure, and
>    the contrained nodes.  Future work may specify this part.
> 
>    In addition to needing to know the joining devices address from the
>    DAR/NS, the JCE also needs to know the joining node's IDevID.  This
>    is to determine if the node should even get any attention.  At this
>    point, the IDevID can be forged, it will be authenticated during the
>    setup of the 6top control protocol in the DTLS certificate exchange.
>    If the serialNumber attribute of the IDevID is less than 64 bits,
>    then it is possible that it could be placed into the EUI-64 option of
>    the ARO, or the OUI of the [I-D.thubert-6lo-rfc6775-update-reqs]
>    EARO.  The JCE needs to know the joining node's serialNumber to know
>    if this is device that it should even attempt to provision; and if
>    so, it may need to retrieve an appropriate certificate chain (see
>    [I-D.richardson-6tisch-idevid-cert]) from the Factory in order for
>    the JCE to prove it is the legitimate owner of the joining node.
> 
>    Neither 802.1AR nor [RFC5280] provide any structure for the
>    serialNumber, except that they are positive integers of up-to 20
>    octets in size (numbers up to 2^160).  This specification would
>    require that the serialNumber encoded in the IDevID be the same as
>    the EUI-64 used by the device.  Some consideration needs to be given
>    as to whether there are privacy considerations to doing this: any
>    observer that can see the join traffic, can also see the source MAC
>    address of the node as well.
> 
>    Prior to being able to announce itself in a NS, the joining node
>    needs to find the Join Network.  This is done by listening to an
>    extended beacon which are broadcast in designated slotframes by Join
>    Assistants.  The Extended Beacon provides a way for the Joining Node
>    to synchronize itself to the overall timeslot schedule and provides
>    an Aloha period in which the Joining Node can send a Router
>    Soliticiation, and receive an appropriate Router Advertisement giving
>    the Joining Node a prefix and default route to which to send join
>    traffic.
> 
>    It may be possible to eliminate a message exchange if space for a
>    Router Advertisement can be found as part of the Join Network
>    Extended Beacon.  This Enhanced Beacon would be distinct to the Join
>    Network, and would be encrypted with the well-known Join Network key.
> 
> 10B.5.1.  prefixes to use for join traffic
> 
>    What prefix would the joining node for communication?  There are
>    three options:
> 
>    (1)  just use link-local addresses (this may require that some
>       traffic between 6LBR and JCE be IPIP tunneled)
> 
>    (2)  use a prefix specifically for join traffic (may be easier with a
>       join-only DODAG)
> 
>    (3)  use the same prefix as the rest of the traffic (may require more
>       complex ACLs, and leaks information to attackers)
> 
>    The simplest method is to use the link-local addresses for the 6top
>    connection, and the cost of an IPIP tunnel between the unconstrained
>    6LBR and the JCE is not considered significant.
> 
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
> 
> 
> 
> _______________________________________________
> 6tisch-security mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch-security