Clone wiki

meetings / 140505_webex_security

Minutes Webex 05 Ma 2014, 6TiSCH Security

Taking notes (using Etherpad)

  1. Pascal Thubert

Present (alphabetically)

  1. Maik Seewald
  2. Michael Behringer
  3. Michael Richardson
  4. Nancy Cam-Winget
  5. Pascal Thubert
  6. Pat Kinney
  7. Paul Duffy
  8. René Struik
  9. Robert Moskowitz
  10. Subir Das
  11. Tom Phinney
  12. Yoshihiro Ohba

Recording

Action Items

Detail how EST plays and alternative

Agenda

1) Robert Moskowitz on 802.1AR
2) Michael Behringer on Autonomic Setup

Minutes

  • [07.03] Meeting starts
  • [07.04] Michael introduces agenda.

Robert Moskowitz: AR was triggered by voice vendors but value for telematics and sensors is huge. Deliver owner and app certificate at boot time.
Addresses how to get certificates, always a pain.

Michael Richardson: Michael Behringer, are you familiar with that work

Michael Behringer: no eager to learn more

Robert Moskowitz: I provided slides, compatible with ??SEDP??

Michael Richardson: device enrols using vendor cert to provide secure bootstrap between device and domain certificateAuth.

Robert Moskowitz: can do ??CNPv2??

Michael Richardson to Michael Behringer: the EAP TLS creates a secured channel, would you imagine using that channel as enrolment channel

Michael Behringer: that would be a starting point. Too heavy?

Michael Richardson: does device start again with the new domain certificate?

Michael Behringer: up to archi, but in our case yes. We use 1AR till the device joins domain and then domain certificate

Robert Moskowitz: Elliptic Curve Digital Signature Algorithm (ECDSA) saves

Michael Richardson: constraints are more that f the network than that of the device

Subir Das: are you assuming dependency if the domain certificate goes through vendor cloud?

Michael Behringer: no

Robert Moskowitz: you have your vendor chain you can use it to validate. We have a secure channel to customer PKI to validate the vendor certificate with a trusted chain. No connection back to vendor for that state

Michael Richardson: it could involve connection back to autonomic MASA as an online process but does not have to be, chains can be provided on USB key or QR code with device packaging

Michael Behringer: vendor trust chain can be locally downloaded. The MASA provides additional benefits;

  1. vendor tracks purchased devices and
  2. vendor checks that new device only reaches the right network through AUTH TOKEN

Robert Moskowitz: you may not want to go back to vendor if the devoce is originated in another country for some geopolitical reason. We have
this use case.

Subir Das agree

Michael Behringer: we also understand that some customers to not want that to happen. The AUTH TOKEN can be obtained at purchase time when online with bootstrap is not appropriate.

René Struik: is vendor vs. domain certificate

Robert Moskowitz: you have to watch your trust boundary

Subir Das: can revert back to original vendor?

Robert Moskowitz: all private keys stay in the device. Can revert back.

Michael Richardson: see flows at the end of etherpad, old and my update. what's the form of Auth token? In EAP-TLS client hello and server hello then server presents cert and then client may present its certificate. Problem is often server presents certs before knowing which resource client wants to access.
Now we can have the resource indicated in the client hello. Domain needs to respond with cert / chain routed where the device can validate.

Robert Moskowitz: need to validate with other people who do EAP TLS

Michael Behringer: not clear. I understand for HTTP but here it is only bootstrap, once in a lifetime. Isn't the server obviously the bootstrap server?

Michael Richardson: boot can happen all along the net lifetime;

Robert Moskowitz: if vendor cert then bootstrap so req can be routed to the boot server
Subir Das unless 2 vendors?

Michael Richardson: client device can indicate which CAs it trusts in hello. That is enough clue for the server, if it has a chain from that vendor

Michael Behringer: in our model device send AR which is cert from vendor therefore I know whom to talk

Michael Richardson: in TLS server cert comes first so cannot pick vendor cert to respond to with appropriate chain

Michael Behringer and Michael Richardson agree need to send a hint with hello.

Michael Richardson: EAP TLS over WiFi used selects the network, not zero touch

Subir Das: what discovery in part 1?

Michael Richardson: answer later? I think RS, NS from IPv6 NDP

Subir Das: TLS server in domain

Michael Richardson: yes, proxied over PANA, radius, etc... Your L2 peer proxies you do not know the server address but the proxy does.

Subir Das: even client hello sent to server its know ho it is talking to

Michael Richardson: browser knows where gmail.com is but the server does not know whom the client wishes to talk to, thus the need for Server Name Indication (SNI)

Michael Richardson: domain needs idevID very early on to respond with a cert chain in step H that proves it is owner of device

Michael Behringer: what would that be a hack?

Michael Richardson: need a place holder in the hello to put the idevID. No need for secured, maybe issues with dos attacks. Then server can come with proof that device belongs to this domain

Michael Behringer: draft-pritikin is a blueprint. Are you mapping it to eap tls? We did not make a decision that eap tls is the correct one did we? Enrollment over Secured Transport (EST) should be looked at also.

Michael Richardson: correct. This is IF over EAP TLS

Michael Behringer: auth token is statement by vendor that device X is bound to domain Y. used as a validation.

Michael Richardson: not necessarily a certificate then

Michael Behringer: correct Message is passed through to the device, an indirection to tell the domain this is your device/

Michael Richardson: it is specific to owner domain foo. Token does not give ownership. What is cert in step H that causes to trust domain

Michael Behringer: cert chain presented from the domain, auth token signed by vendor, 1AR has root CA of vendor and can validate that the vendor said yes this is domain.

Robert Moskowitz: who's the owner is assumed at bootstrap, device cannot know who bought it.

Michael Behringer: you are saying that when device init join it does not know whether domain legit or not correct?

Robert Moskowitz: yes, domain could lie

Michael Richardson: failure could be I ship a void phone to Mc DOnalds in Pittsburgh rather than in Paris. Phone comes up and sees Mc D is a vouch for Verizon but domain owner is wrong for devID token

Michael Richardson: is there a format seg X509

Michael Behringer: asym would have a different format as symmetrical

Michael Richardson: reason for not using certif?

Michael Behringer: what you send is a message from vendor telling device this is your domain? Message format to be defined.

Michael Richardson: the issuer of a certificate is factory and subject is domain

Michael Behringer: no the issuer of vendor cert is vendor. Issuer of domain cert is domain.

Next call in 2 weeks?

Pascal Reminds about recording and BCPs

  • 08.04 meeting ends

======

FROM LAST TIME:

  • Michael Richardson: base on calculation, between 10-15s for each node to join?

  • in this specification, we are going to say that joining messages will go over a different slot/colour, and therefore join messages can not overrun the network.

Using SCEP:

Existing flow

  +---------+                +----------+                +-----------+
  |  New    |                |          |                |  Factory  |
  | Entity  |                |  Domain  |                |   Cloud   |
  |         |                |          |                |  Service  | 
  +---------+                +----------+                +-----------+
     |                           |                            |
     |<-------discovery--------->|                            |
     |---802.1AR credential----->|                            |
     |                           |                            |
     |                    [ accept device? ]                  |
     |                           |                            |
     |                           |---802.1AR identity-------->|
     |                           |---Domain ID--------------->|
     |                           |                            |
     |                           |                    [device belongs]
     |                           |                    [to domain?    ]
     |                           |                            |
     |                           |                  [update audit log]
     |                           |                            |
     |                           |<---device history log------|
     |                           |<-- authorization token-----|
     |                           |                            |
     |                  [ still accept device?]               |
     |                           |                            |
     |<----authorization token---|                            |
     |<----domain information----|                            |
     |                           |                            |
  [auth token valid?]              |                            |
     |                           |                            |
     |----domain enrolment------>|                            |
     |<----domain certificate----|                            |

Michael's flow

  +---------+                +----------+                +-----------+
  |  New    |                |          |                |  Factory  |
  | Entity  |                |  Domain  |                |   Cloud   |
  |         |                |          |                |  Service  |
  +---------+                +----------+                +-----------+
     |                           |                            |
     |<-------discovery-(A)----->|                            |
     |-----TLS ClientHello (B)-->|                            |
     |     (802.1AR cred**)      |                            |
     |                           |---802.1AR identity(C)----->|
     |                           |---Domain ID--------------->|
     |                           |                    [device belongs]
     |                           |                    [to domain?    ]
     |                           |                            |
     |                           |<---device history log(D)---|
     |                    [ accept device? ]                  |
     |<------ServerHello-(E)-----|                            |
     |                           |------- claim device -(F)-->|
     |                           |                  [update audit log]
     |                           |<----- authz token --(G)----|
     |                           |      (802.1AR cert)        |
     |                           |                            |
     |                  [ still accept device?]               |
     |<----ServerCertificate-(H)-|                            |
     |                           |                            |
  [validate cert chain? (I)]       |                            |
     |                           |                            |
     |---ClientCertificate-(J)-->|                            |
     |                           |                            |
     |                           |                            |
     |----domain enrolment------>|                            |
     |<----domain certificate----|                            |

The device can not know, at H, who bought it, only that the Domain is vouched for by the Factory.

MCR to draft what the certificate would contain.

Updated