Subject: [6tisch] proposed security text for architecture draft

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Nov 2014 11:50:45 -0500

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 12 Nov 2014 18:37:39 +0000

Hello Michael:

For the initial connection to the join assistant, we said that we'd use a well-known key by default, following René's initial recommendation. At some point of time, we also discussed the possibility to override that key by configuration to allow to differentiate networks, making that key effectively a sort of ssid.

I do not see any of this reflected below. Do I miss anything, else would you agree that we add that stuff?

Cheers,

Pascal

> -----Original Message-----
> From: 6tisch-security [mailto:[email-masked]] On Behalf Of
> Michael Richardson
> Sent: mercredi 12 novembre 2014 08:51
> To: [email-masked]; [email-masked]
> Subject: [6tisch-security] proposed security text for architecture draft
> 
> 
> 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
> 
> 
> Michael Richardson <[email-masked]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
> 
>

---

From: <[email-masked]>
Date: Wed, 12 Nov 2014 20:12:41 +0000

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:[email-masked]] On Behalf Of Michael Richardson
Sent: Thursday, November 13, 2014 1:51 AM
To: [email-masked]; [email-masked]
Subject: [6tisch-security] proposed security text for architecture draft

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

12.1.1.1.  IPIP tunnel

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Rene Struik <[email-masked]>
Date: Wed, 12 Nov 2014 15:14:52 -0500

Hi Pascal:

Correction: I don't think I ever suggested the use of well-known keys 
(as you seemed to suggest below): (ab)using crypto with a well-known 
keys is a way (promoted by some, not by me) to make the mechanics of a 
protocol work (in terms of I/O parameters), but does not accomplish any 
of the semantics (in terms of delivered security properties: 
confidentiality, authenticity, and so on). In fact, it may cause lots of 
security problems, e.g., in the context of 802.15.4e, since it would 
allow poisoning frame counters (the ASN entry in the MAC PIB table).

BTW - the text blurb (proposed security text) presumably comes from a 
"secure zero touch design team" effort. To my knowledge, such a design 
team has never been put in place. So, I am extremely puzzled here. Let 
us discuss during the 6TiSCH meeting tomorrow.

Best regards, Rene

On 11/12/2014 1:37 PM, Pascal Thubert (pthubert) wrote:
> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Nov 2014 15:53:09 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > For the initial connection to the join assistant, we said that we'd use
    > a well-known key by default, following René's initial
    > recommendation. At some point of time, we also discussed the
    > possibility to override that key by configuration to allow to
    > differentiate networks, making that key effectively a sort of ssid.

I'll fix the text to include these points, which I agree that we said.

---

From: Subir Das <[email-masked]>
Date: Wed, 12 Nov 2014 16:11:05 -0500

Michael,
Are you suggesting to add this entire text to the architecture document?  I
am afraid that the text is more than architecture elements and
requirements?  I was not able to attend the last Tuesday's call. You are
claiming that the ad hoc security team recommended this text to the WG for
consideration. Is this happened during last call? I understand that you
didn't get time yet to publish the  minutes.

-Subir

On Wed, Nov 12, 2014 at 11:50 AM, Michael Richardson <[email-masked]>
wrote:

> implementation

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 12 Nov 2014 23:06:12 +0000

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

> [email-masked]
> Sent: mercredi 12 novembre 2014 12:13
> To: [email-masked]; [email-masked]; [email-masked]
> 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
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Nov 2014 18:27:52 -0500

> us discuss during the 6TiSCH meeting tomorrow.

The "secure zero touch design team" is my attempt to consisely elucidate the
mandate of the 6tisch security design team.  I claim that this text is the
rough consensus of the design team; I do not claim that it is endorsed by
anyone other than myself, and I would welcome other approaches to solving the
zero touch enrollment problem.

I do not agree that there is any issue with the well-known beacon key.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Nov 2014 18:36:04 -0500

<[email-masked]> wrote:
    > 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.  

Yoshihiro has correctly pointed out that in IPv6 some of the loose source
route options are not as rich as we envisioned; and we need to think which
exact option is appropriate.  I think this is a detail, and I think that we
can deal with this.

    > is proven to work in ZigBee IP.

I can not comment directly; some contributors felt that this would not work
for them. Too much single use code, too much total byte count, packets too big.

    > 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.

Perhaps you can more clearly say what kind of EAP methods you would propose.
Username+password?  SIM or AKA authentication?  Kerberos/NTLM(ActiveDirectory)?
What else is there?

The TLS methods do not count, as they are usually used just to create a
secure container for a username/password, and in the situations where the
certificate is relevant, the *DTLS* method proposed can use certificates in
the same way. 

    > 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?

Already connected nodes listen to beacons sent under the production key,
none of this text not changes that: can you offer some edits to make that
clearer.

---

From: Rene Struik <[email-masked]>
Date: Wed, 12 Nov 2014 18:38:51 -0500

I am afraid using the words you used puts people on the wrong footing 
and is a shame.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Nov 2014 18:41:43 -0500

Subir Das <[email-masked]> wrote:
    > Michael, Are you suggesting to add this entire text to the architecture
    > document?  I am afraid that the text is more than architecture elements
    > and requirements?  

Yes, it could well be the case; so I am would welcome ways to clarify things
so that the it fits better.  

I like to think of architecture in terms of how houses are specified,
designed and built... the architect does not decide how many mm thick the
concrete foundation shall be (the civil engineer does that), but the
architect does decide that a foundation will be required due to the height of
the house, and that the foundation shall contain a basement that can be used
as a TV room; vs if it will just be a crawl space. 

    > I was not able to attend the last Tuesday's
    > call. You are claiming that the ad hoc security team recommended this
    > text to the WG for consideration. Is this happened during last call? I
    > understand that you didn't get time yet to publish the minutes.

Sorry, did I not get to the minutes for the call on Tuesday?
Oh. Damn. You are probably right... I will do that.

I plead insanity due to nomcom-chair.

---

From: <[email-masked]>
Date: Thu, 13 Nov 2014 00:24:10 +0000

Michael,

Regarding EAP method, I mentioned EAP-TLS.  EAP-TLS works for both certificate-based authentication and pre-shared key based authentication (EAP-TLS-PSK) without EAP tunneling method such as EAP-TTLS.  In the latter case, TLS session is typically terminated at AAA server.   

It is unfortunate that some contributors felt that EAP-based approach does not work for them, but there is another use case where EAP-based approach is definitely needed (smart meters).  Having said that it would make sense to have two options (DTLS-based and EAP-based approaches) for joining operation.

Regarding beacon security, I can send clarification text.

Yoshihiro Ohba

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Thursday, November 13, 2014 8:36 AM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: [email-masked]; [email-masked]
Subject: Re: [6tisch] [6tisch-security] proposed security text for architecture draft

    > authentication at join assistant node.  

Yoshihiro has correctly pointed out that in IPv6 some of the loose source route options are not as rich as we envisioned; and we need to think which exact option is appropriate.  I think this is a detail, and I think that we can deal with this.

    > is proven to work in ZigBee IP.

I can not comment directly; some contributors felt that this would not work for them. Too much single use code, too much total byte count, packets too big.

The TLS methods do not count, as they are usually used just to create a secure container for a username/password, and in the situations where the certificate is relevant, the *DTLS* method proposed can use certificates in the same way. 

    > dynamic key also be needed for protecting beacons for already-connected

Already connected nodes listen to beacons sent under the production key, none of this text not changes that: can you offer some edits to make that clearer.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 13 Nov 2014 00:43:31 +0000

This is a lot of text, but reading it I have trouble simplifying much. A bit of trimming may help, and this would justify that we maintain and extend Michael’s doc for the next round.
What do others think?

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Subir Das
Sent: mercredi 12 novembre 2014 13:11
To: Michael Richardson
Cc: [email-masked]; [email-masked]
Subject: Re: [6tisch] [6tisch-security] proposed security text for architecture draft

Michael,
Are you suggesting to add this entire text to the architecture document?  I am afraid that the text is more than architecture elements and requirements?  I was not able to attend the last Tuesday's call. You are claiming that the ad hoc security team recommended this text to the WG for consideration. Is this happened during last call? I understand that you didn't get time yet to publish the  minutes.
-Subir

On Wed, Nov 12, 2014 at 11:50 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

12.1.1.1.  IPIP tunnel

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
 -= IPv6 IoT consulting =-

_______________________________________________
6tisch-security mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch-security

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Nov 2014 20:42:58 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > 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?

Yes, because the RA is always sent.

An open question was: could we find a way to hide the RA in the Enhanced
Beacon, which reduces a packet on the wire.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Nov 2014 20:44:23 -0500

<[email-masked]> wrote:
    > It is unfortunate that some contributors felt that EAP-based approach
    > does not work for them, but there is another use case where EAP-based
    > approach is definitely needed (smart meters).  Having said that it
    > would make sense to have two options (DTLS-based and EAP-based
    > approaches) for joining operation.

1) Can you explain why smart meters have to use EAP methods?
2) can someone explain why smart meters are in scope for this WG?

I thought it was mostly industrial applications.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 14 Nov 2014 01:49:44 +0000

CC ing Pat

Pat, would you confirm whether we can we piggy back an IPv6 RA with an EB?

Thanks a bunch!

Pascal

> Le 13 nov. 2014 à 15:43, Michael Richardson <[email-masked]> a écrit :
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Nov 2014 22:07:16 -0500

{Please note that I am very familiar with EAP mechanisms, and I wrote EAP-SIM
 for Freeradius a decade ago, when the document was going through many changes}

<[email-masked]> wrote:
    > Regarding EAP method, I mentioned EAP-TLS.  EAP-TLS works for both
    > certificate-based authentication and pre-shared key based
    > authentication (EAP-TLS-PSK) without EAP tunneling method such as
    > EAP-TTLS.  In the latter case, TLS session is typically terminated at
    > AAA server.

But, since the EAP-TLS session terminates at the the AAA server, all of the
communications that we want to do (the 6top data), would have to come from
the AAA server.   

That means installing all of 6top/DTLS/CoAP code into the radius server.  
(That's because the EAP-TLS is between AAA(radius) server and joining node)
Is that really what you want to do?

What other things would the AAA server provide to the joining node?
Are you thinking about various kinds of group policies, etc?

---

From: <[email-masked]>
Date: Fri, 14 Nov 2014 03:13:57 +0000

I mentioned EAP because it does not require to change AAA infrastructure to interwork with, and AAA is needed where a huge number of nodes have to be managed.  In smart meter use case, the number can be tens of millions of smart meters with hundreds of thousands of PCE for a single utility company.

Yoshihiro Ohba

---

From: <[email-masked]>
Date: Fri, 14 Nov 2014 03:26:24 +0000

Michael,

Use of EAP-TLS and terminating TLS session at AAA server does not mean that all parameters have to be coming from AAA server.  Especially when PANA is used, PAA can be co-located with JCE and provide 6top data over a secure PANA SA.  Actually this model applies to any EAP method.

Also, use of PANA with relay function neither requires a routable solution such as loose source routing to convey authentication message between JCE and JN nor requires a per-JN state on JA.

Regards,
Yoshihiro Ohba

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Friday, November 14, 2014 12:07 PM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: [email-masked]; [email-masked]
Subject: Re: [6tisch] [6tisch-security] proposed security text for architecture draft

{Please note that I am very familiar with EAP mechanisms, and I wrote EAP-SIM  for Freeradius a decade ago, when the document was going through many changes}

    > EAP-TTLS.  In the latter case, TLS session is typically terminated at

But, since the EAP-TLS session terminates at the the AAA server, all of the communications that we want to do (the 6top data), would have to come from
the AAA server.   

That means installing all of 6top/DTLS/CoAP code into the radius server.  
(That's because the EAP-TLS is between AAA(radius) server and joining node) Is that really what you want to do?

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Nov 2014 01:11:55 -0500

<[email-masked]> wrote:
    > Use of EAP-TLS and terminating TLS session at AAA server does not mean
    > that all parameters have to be coming from AAA server.  Especially when
    > PANA is used, PAA can be co-located with JCE and provide 6top data over
    > a secure PANA SA.  Actually this model applies to any EAP method.

So, we would be creating a masterkey with EAP-TLS, and then we would use PANA
as a transport for CoAP?

I understand why we want to use EAP when we have devices with humans at the
far end; 
1) it means the pieces in the middle do not need to know anything about the
   kind of authentication will be done

2) we can deploy new forms of authentication (such as challenge response
   methods, and things like EAP-SIM or EAP-AKA) without changes to the middle
   machines.

3) we can proxy things all the way back to the users home service, which is 
   how GSM roaming works these days.

I'm unaware that industrial/deterministic uses of 15.4 have requirements for
ths kind of thing.  I seem to recall a conversation about whether or not
including a SIM card into nodes would work from a power, size, and cost point
of view.  Having a replaceable SIM card would definitely be a really easy way
to imprint new devices.  If someone can do that, then we really don't need
any of this...

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Nov 2014 01:20:41 -0500

<[email-masked]> wrote:
    > I mentioned EAP because it does not require to change AAA
    > infrastructure to interwork with, and AAA is needed where a huge number
    > of nodes have to be managed.  In smart meter use case, the number can
    > be tens of millions of smart meters with hundreds of thousands of PCE
    > for a single utility company.

I agree with your concern about the need for a scalable backend when there
are millions of smart meters.

Can you tell me a bit about the legacy AAA infrastructure whose existence 
you want to leverage: I'm all for resuing existing, fully paid-up infrastructure.

What does it do now (before smart meters are installed).  
Will this AAA infrastructure already have the capacity for these tens of
millions of smart meters?

If an interface to an AAA infrastructure was desired, I would add that as a
northbound interface on the JCE.  For millions of smart meters, I would
imagine deploying JCEs for groups of maybe ~10^3 to ~10^5 meters, and the the
JCE would speak radius to the AAA. It would use the joining node's IDevID to
discovery the right policy for this meter. It could also take this from LDAP,
From a RESTful interface, or via database interface directly.  
It doesn't really matter... I don't think meters need roaming support, but
maybe there is a use case I don't know about.

Also, I do not claim that any of the 6tisch industrial zero-touch system is
appropriate for non-industrial uses.  It probably a non-starter in the
home that lacks any kind of professional manager, and also lacks someone to
run the authorization authority.

---

From: <[email-masked]>
Date: Fri, 14 Nov 2014 09:50:11 +0000

Here is main PANA use:

1. Creating a PANA SA (based on EAP MSK) between JCE and JN where JCE is PAA, JN is PaC, and JA is PANA relay.
(PANA relay is a stateless relay as described in RFC 6345, and no need for loose source routing or ULA allocation.)

2. Using the SA to securely distribute locally significant credentials such as a 802.11AR LDevID certificate or a network-wide shared symmetric key, and I am not in favor of the latter though :) 

For 1), existing RADIUS servers can be used if EAP server is a physically separated from PCE box where scalability is needed.  EAP-based approach can also support roaming cases where electric vehicles are authenticated via smart meters.

For 2) we can define new PANA attributes to carry RFC 4210 CertRequest and CertResponse defined by PKIX for distributing 802.11AR LDevID certificate.

I did not think to use PANA to carry CoAP messages. I think DTLS should be used for protecting CoAP for 6top as being discussed.  The DTLS session for CoAP can be established, e.g., by using the locally significant credentials distributed in 2).

Support for UIM card (via EAP-SIM, EAP-AKA or a new EAP method) would make 6tisch more attractive to cover  certain business scenarios.

Please note that I do not disagree with DTLS-based approach for more resource constrained device (although more work seems to be needed to carry DTLS message between JCE and JN via JA), but we should support multiple options if one solution is difficult to cover all cases.  

Best Regards,
Yoshihiro Ohba

-----Original Message-----
From: 6tisch-security [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Friday, November 14, 2014 3:12 PM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: [email-masked]; [email-masked]
Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft

    > a secure PANA SA.  Actually this model applies to any EAP method.

So, we would be creating a masterkey with EAP-TLS, and then we would use PANA as a transport for CoAP?

I understand why we want to use EAP when we have devices with humans at the far end;
1) it means the pieces in the middle do not need to know anything about the
   kind of authentication will be done

I'm unaware that industrial/deterministic uses of 15.4 have requirements for ths kind of thing.  I seem to recall a conversation about whether or not including a SIM card into nodes would work from a power, size, and cost point of view.  Having a replaceable SIM card would definitely be a really easy way to imprint new devices.  If someone can do that, then we really don't need any of this...

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 14 Nov 2014 12:31:29 +0100

Hi Yoshi:

I think this is a reasonable architecture for security, which would cover several important use cases in my opinion. Some comments inline...

> For 1), existing RADIUS servers can be used if EAP server is a physically separated from PCE box where scalability is needed.  EAP-based approach can also support roaming cases where electric vehic…

Not only RADIUS but also Diameter which is, by the way, widely used to support many users in 3G,4G networks.

> For 2) we can define new PANA attributes to carry RFC 4210 CertRequest and CertResponse defined by PKIX for distributing 802.11AR LDevID certificate.

+1 

> I did not think to use PANA to carry CoAP messages. I think DTLS should be used for protecting CoAP for 6top as being discussed.  The DTLS session for CoAP can be established, e.g., by using the lo…

Perhaps for very small deployments a pre-installed PSK could be used for DTLS (as happens with WPA2-PSK) but certainly it is not scalable.

> Support for UIM card (via EAP-SIM, EAP-AKA or a new EAP method) would make 6tisch more attractive to cover  certain business scenarios.

This is related with my comment about 3g,4g networks.
> Please note that I do not disagree with DTLS-based approach for more resource constrained device (although more work seems to be needed to carry DTLS message between JCE and JN via JA), but we shou…

+1

Best Regards.

> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Subir Das <[email-masked]>
Date: Fri, 14 Nov 2014 12:51:44 -0500

It does not have to use but the reality is Advanced Metering Networks is
using EAP today.

    I can mention one use case: Zigbee NAN  is using TSCH as one of the
MACs and then IPv6...

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 14 Nov 2014 18:25:09 +0000

Hello Yoshi:

Please see below and many thanks for all this 

Pascal
> Le 13 nov. 2014 à 23:50, "[email-masked]" <[email-masked]> a écrit :
> 
> Here is main PANA use:
> 

On this I respectfully disagree.

The IP address of the PaC is not sufficient information to identify the join bundle should there be more than one.

This is why RH usually carries ULA or global addresses, with the intention that the prefix indicates the next interface - to your earlier point.

But then in a ML subnetwork this is no help whatsoever since multiple interfaces may be on a same subnet.

This is where the ULA comes into play; hiding the network ID from untrusted lurkers and yet providing an unequivocal bundle ID.

Makes sense?

Pascal

---

From: <[email-masked]>
Date: Fri, 14 Nov 2014 19:59:54 +0000

Hi Pascal,

Can you please explain a use case where a JA has multiple LLN interfaces as I could find it in draft-ietf-6tisch-architecture?

If multiple LLN interfaces need to be supported, then I agree that link-local address solely does not work for a JN to communicate with a JCE via a JA using a relay or a RH or whatsoever.

Yoshihiro Ohba

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Saturday, November 15, 2014 3:25 AM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft

Hello Yoshi:

Pascal
> (PANA relay is a stateless relay as described in RFC 6345, and no need 
> for loose source routing or ULA allocation.)

Makes sense?

Pascal

> 
> 2. Using the SA to securely distribute locally significant credentials 
> such as a 802.11AR LDevID certificate or a network-wide shared 
> symmetric key, and I am not in favor of the latter though :)
> 
>> Use of EAP-TLS and terminating TLS session at AAA server does not 
>> mean that all parameters have to be coming from AAA server.  
>> Especially when PANA is used, PAA can be co-located with JCE and 
>> provide 6top data over a secure PANA SA.  Actually this model applies to any EAP method.
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 15 Nov 2014 23:13:09 -0500

> For 2) we can define new PANA attributes to carry RFC 4210 CertRequest
    > and CertResponse defined by PKIX for distributing 802.11AR LDevID
    > certificate.
    
The EAP-TLS security is between joining node (supplicant) and radius/diameter
server (authentication server).  

The PANA is between the authenticator and the joining node (supplicant). 
The PANA has no security attached.   

How can the supplicant know that the CertResponse it is getting is legitimate?

---

From: Michael Richardson <[email-masked]>
Date: Sat, 15 Nov 2014 23:15:23 -0500

<[email-masked]> wrote:
    > Can you please explain a use case where a JA has multiple LLN
    > interfaces as I could find it in draft-ietf-6tisch-architecture?

Any device with more than one radio.
Any device with a radio and an ethernet.
Technically, any device with a loopback device configured...

---

From: Michael Richardson <[email-masked]>
Date: Sat, 15 Nov 2014 23:23:14 -0500

>    It does not have to use but the reality is Advanced Metering
    > Networks is using EAP today.

Can you tell me how they are using EAP today (what method).
What is their authentication?    What happens after EAP?
Is there any kind of provisioning occuring?  How large is the EAP-TLS code?
How many packets does the EAP method take?  How long?   Are these electrical
meters, or water or gas? Battery or line powered?

The water meters in my neighbourhood are definitely not zero-touch, and 
the batteries can't even be replaced; the system is a pre-IP Itron system,
with the street lights being routers (I'm told). 
The electrical (we call it "hydro", which is really confusing to
non-Canadians) meters are Elster, also pre-IP, and apparently not encrypted
at all. see: <https://github.com/argilo/gr-elster> . Sure am glad they
are field upgradable.

---

From: <[email-masked]>
Date: Sun, 16 Nov 2014 23:21:05 +0000

I am not sure if Ethernet and loopback should be considered as LLN interface where mesh routing is needed.  Let's focus on a case with multiple LLN radio interfaces (though such a case seems not very common).

Is a distinct routable IP address allocated to each of the multiple LLN radio interfaces on a JA?  If so, relay can still work even if there are multiple JNs having the same link-local address accessing via different LLN radio interfaces.

Yoshihiro Ohba

---

From: <[email-masked]>
Date: Sun, 16 Nov 2014 23:36:54 +0000

An issued certificate in a CertResponse is signed by a CA trusted by JN, and the CertResponse is protected by the PANA SA.

The PANA SA is derived from an EAP MSK which is established between EAP peer and EAP server and is transported by EAP server to authenticator, and therefore the PANA SA is attached to the EAP method security.

Yoshihiro Ohba

-----Original Message-----
From: 6tisch-security [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Sunday, November 16, 2014 1:13 PM
To: [email-masked]; [email-masked]
Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft

    > and CertResponse defined by PKIX for distributing 802.11AR LDevID
    
The EAP-TLS security is between joining node (supplicant) and radius/diameter server (authentication server).

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 17 Nov 2014 10:27:33 +0100

Regarding issuing a certificate, we have discussed internally here at UMU that the PAA could certify a public key, which is sent by the PaC/JN through the PANA SA built after a successful PANA authentication  (e.g. a PNR/PNA exchange could be used for that). In this sense, there is no need for a global CA.

Best Regards.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Nov 2014 14:48:30 -0500

<[email-masked]> wrote:
    > For 1), existing RADIUS servers can be used if EAP server is a
    > physically separated from PCE box where scalability is needed.
    > EAP-based approach can also support roaming cases where electric
    > vehicles are authenticated via smart meters.

I don't understand this: we are not looking for distributed authenetication,
we are looking for centralized authorization.

    > Support for UIM card (via EAP-SIM, EAP-AKA or a new EAP method) would
    > make 6tisch more attractive to cover certain business scenarios.

really?  WG chairs can you tell me if requiring UIM cards is an option.
If so, there is no join problem; it's already solved and Yoshihiro is right:
use EAP-SIM, followed by 6top authenticated with the EAP-SIM created
MasterKey. 

    > Please note that I do not disagree with DTLS-based approach for more
    > resource constrained device (although more work seems to be needed to

That's the only nodes which are in scope.

I don't want to boil the ocean here!

---

From: <[email-masked]>
Date: Mon, 17 Nov 2014 23:05:32 +0000

That would be a good model for issuing 802.1AR LDevID certificates.

Thanks,
Yoshihiro Ohba

-----Original Message-----
From: Rafa Marin Lopez [mailto:[email-masked]] 
Sent: Monday, November 17, 2014 6:28 PM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: Rafa Marin Lopez; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [6tisch] [6tisch-security] proposed security text for architecture draft

Best Regards.

El 17/11/2014, a las 00:36, [email-masked] escribió:

>> For 2) we can define new PANA attributes to carry RFC 4210 
>> CertRequest and CertResponse defined by PKIX for distributing 
>> 802.11AR LDevID certificate.
> 

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Nov 2014 23:23:58 -0500

<[email-masked]> wrote:
    > I am not sure if Ethernet and loopback should be considered as LLN
    > interface where mesh routing is needed.  Let's focus on a case with
    > multiple LLN radio interfaces (though such a case seems not very
    > common). 

Take two constrained devices with a generous power supply, wire ethernet
between them so that the "signal" can get through that metal door/wall. 
That's the whole point of doing this all at layer 3.

    > Is a distinct routable IP address allocated to each of the multiple LLN
    > radio interfaces on a JA?  If so, relay can still work even if there
    > are multiple JNs having the same link-local address accessing via
    > different LLN radio interfaces. 

Assuming that your source route references the correct outgoing link-local
address, I agree; I think we can make it work. It might be not to spec, but
maybe running code should trump the spec.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Nov 2014 23:26:04 -0500

<[email-masked]> wrote:
    > The PANA SA is derived from an EAP MSK which is established between EAP
    > peer and EAP server and is transported by EAP server to authenticator,
    > and therefore the PANA SA is attached to the EAP method security. 

I was unaware that the PANA channel was secured by MSK.
So it links the Join Assistant to the Joining Node.

I think I'd like a diagram of what you envision.

---

From: <[email-masked]>
Date: Tue, 18 Nov 2014 07:07:55 +0000

-----Original Message-----
From: 6tisch-security [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Tuesday, November 18, 2014 1:24 PM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft

    > multiple LLN radio interfaces (though such a case seems not very

Take two constrained devices with a generous power supply, wire ethernet between them so that the "signal" can get through that metal door/wall. 
That's the whole point of doing this all at layer 3.

[YO] OK.

    > different LLN radio interfaces. 

Assuming that your source route references the correct outgoing link-local address, I agree; I think we can make it work. It might be not to spec, but maybe running code should trump the spec.

[YO] Yes, that's what I meant.

Thanks,
Yoshihiro Ohba