Hi Peter,
See inline.
Mališa
> On 16 Dec 2016, at 09:17, peter van der Stok wrote:
>
> Hi Malisa,
>
> Just one point to understand the temporary secure link between JN and JA.
>
>>> Consequently, that means during the whole bootstrap process the link
>>> between JA and JN is not secured by
Hi Malisa,
Just one point to understand the temporary secure link between JN and
JA.
Consequently, that means during the whole bootstrap process the link
between JA and JN is not secured by layer2 keys.
This is still under discussion within the design team, but the
conclusion is the same —
Hi Peter,
Thanks for your comments. See my responses inline.
Mališa
> On 15 Dec 2016, at 09:56, peter van der Stok wrote:
>
> Hi Malisa,
>
> I read the 6tisch-minimal-security draft.
> I do have some detailed questions, which probably have to do with my reading
> things which are not there.
Hi Malisa,
I read the 6tisch-minimal-security draft.
I do have some detailed questions, which probably have to do with my
reading things which are not there.
If I understand correctly, the Join response returns the link2 keys to
secure the the links between JN, JA and possibly other neighbour
Apologies for the previous empty mail, this is the mail I wanted to
comment on.
On 2016-12-01 01:18, "6tisch on behalf of Michael Richardson"
<6tisch-boun...@ietf.org on behalf of mcr+i...@sandelman.ca> wrote:
>
>Hi, I haven't read the entire thread yet, but I wanted to pull out another
>email fr
replying to three of your messages, and trying to repoint the thread at
6tisch-security.
peter van der Stok wrote:
> all in favor of one approach to merge the push/pull aspects. (I have to
> understand the protocol exchange below, but it looks feasibale)
> I am not sure about underst
Hi Goran,
thanks for this low overhead and clear explanation.
If you are interested in a simple lightweight enrolment protocol, EDHOC
and OSCOAP may be used for that. For authentication of enrolment using
e.g. manufacturer certificates, you may run EDHOC and OSCOAP in
sequence
and carry the
Hi Peter,
On 2016-12-01 10:01, "6tisch on behalf of peter van der Stok"
<6tisch-boun...@ietf.org on behalf of stokc...@xs4all.nl> wrote:
>I am not sure about understanding EDHOC, but may be that is not
>important.
EDHOC is a key exchange protocol, analogous to the TLS handshake, but with
less f
Hi Michael,
all in favor of one approach to merge the push/pull aspects. (I have to
understand the protocol exchange below, but it looks feasibale)
I am not sure about understanding EDHOC, but may be that is not
important.
I still see all the mime formats. is that phase 1?
Is phase 2 then swi
Hi Michael,
thanks for a clear answer.
I think the Registrar/JCE will need to support three protocols:
1) a push protocol over CoAP.
2) a pull protocol (RFC7030/EST).
3) a protocol to talk to the MASA (TBD)
As discussed earlier, having a push/pull agnostic protocol would be
nice. (and prob
peter van der Stok wrote:
> My concern is with the number of protocols that the central authority has
to
> support.
I think the Registrar/JCE will need to support three protocols:
1) a push protocol over CoAP.
2) a pull protocol (RFC7030/EST).
3) a protocol to talk to the MASA (TBD)
Hi, I haven't read the entire thread yet, but I wanted to pull out another
email from a private thread about some ideas I had before I forgot.
This would be the phase 1. Now that I understand more about EDHOC,
I think that the certificate exchange and EDHOC setup would occur
at the GET /nonce ph
Hi Peter,
Yes, that is correct, we propose to use OSCOAP for communication between JN and
JCE. In the model, JA is a CoAP proxy so the choice of OSCOAP and EDHOC was
quite natural. We use CBOR/COSE to transport the keys and the short 15.4
address. Certificate enrollment belongs to Phase 1, and
Hi Malisa,
thanks for the answer. I am happy to read that there is a shared concern
about reuse.
My concern is the communication between joining node and central node.
Did I understand correctly that you propose to use oscoap for the
communication between joning node and central node?
what c
Hello Peter,
My understanding of the IETF 97 meeting outcome is that Phase 1 solution will
be anima-compatible i.e., it will provide zero-touch bootstrapping with
manufacturer-installed certificate as the start state and locally relevant
credential as the end state. At the moment, I believe tha
Hi 6tisch bootstrap followers,
Curently, we live in a confusing world wih many bootstrap proposals.
They all seem to have in common; a joining node, an assistant, a central
authority, and Michael Richardson.
While each bootstrap proposal seems to have a different naming history.
Joking apart,
16 matches
Mail list logo
