Wiki
Clone wikimeetings / 140505_webex_security
Minutes Webex 05 Ma 2014, 6TiSCH Security
Taking notes (using Etherpad)
- Pascal Thubert
Present (alphabetically)
- Maik Seewald
- Michael Behringer
- Michael Richardson
- Nancy Cam-Winget
- Pascal Thubert
- Pat Kinney
- Paul Duffy
- René Struik
- Robert Moskowitz
- Subir Das
- Tom Phinney
- Yoshihiro Ohba
Recording
- Webex recording
- TODO [TODOmin]
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;
- vendor tracks purchased devices and
- 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