Re: [Ace] draft-ietf-ace-coap-est-00

2018-03-18 Thread Panos Kampanakis (pkampana)
I think this is a terminology fix. Let's address it in the next iteration.

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael Richardson
Sent: Sunday, March 18, 2018 5:08 AM
To: consulta...@vanderstok.org
Cc: ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-coap-est-00


peter van der Stok <stokc...@xs4all.nl> wrote:
>> Let me delete "Join" from above sentence.
>>
>> A device that terminates the DTLS security (CoAPS) and then talks to the 
CA
>> is a Registration Authority according to EST and RFC5280.  It's not a
>> proxy.
>> (And it doesn't matter if it speaks HTTPS or CMS or CMP or
>> super-pigeon-telepathy
>> to the CA)

> A http/coap proxy  is specified in RFC8075. It explains "how an HTTP 
request
> is mapped to
> a CoAP request and how a CoAP response is mapped back to an HTTP
> response".

> In the est-coap draft DTLS and TLS connections are terminated in the
> http/coap proxy, and the proxy is therefore connected to an RA (possibly
> running on the same host as the proxy).

> Where is my terminology going astray?

In the EST context, if it's a device with a (D)TLS connection to the Pledge 
(the device enrolling) and a TLS connection to the PKI CA, then it's a
Registrar, not an http/coap proxy.   It may have the same apparent
connectors, but it processes the content.

I can't come with any pure-7030 situations where this official MITM could be 
accomodated between the 7030 client and 7030-registrar.

Perhaps this represents that for generic-7030 use involving COAP+DTLS, that a 
very clear applicability statement will need to detail what the initial EST 
trust is.

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

--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works  -= IPv6 
IoT consulting =-



___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


Re: [Ace] draft-ietf-ace-coap-est-00

2018-03-18 Thread Michael Richardson

peter van der Stok  wrote:
>> Let me delete "Join" from above sentence.
>>
>> A device that terminates the DTLS security (CoAPS) and then talks to the 
CA
>> is a Registration Authority according to EST and RFC5280.  It's not a
>> proxy.
>> (And it doesn't matter if it speaks HTTPS or CMS or CMP or
>> super-pigeon-telepathy
>> to the CA)

> A http/coap proxy  is specified in RFC8075. It explains "how an HTTP 
request
> is mapped to
> a CoAP request and how a CoAP response is mapped back to an HTTP
> response".

> In the est-coap draft DTLS and TLS connections are terminated in the
> http/coap proxy, and the proxy is therefore connected to an RA (possibly
> running on the same host as the proxy).

> Where is my terminology going astray?

In the EST context, if it's a device with a (D)TLS connection to the Pledge
(the device enrolling) and a TLS connection to the PKI CA, then it's a
Registrar, not an http/coap proxy.   It may have the same apparent
connectors, but it processes the content.

I can't come with any pure-7030 situations where this official MITM
could be accomodated between the 7030 client and 7030-registrar.

Perhaps this represents that for generic-7030 use involving COAP+DTLS,
that a very clear applicability statement will need to detail what the
initial EST trust is.

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

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


Re: [Ace] draft-ietf-ace-coap-est-00

2018-03-17 Thread Panos Kampanakis (pkampana)
Sorry, getting to this late. 

Thank you Jim for the feedback.

I think an good point comes out of this discussion. We need to articulate the 
RA role that could at the same time act as a proxy. An RA usually performs 
authentication/authorization before relaying to the CA that already has a 
predetermined relationship with. A proxy acts as a plain COAP2HTTP translator 
that does not necessarily perform any authentication or authorization of the 
client. In either case ESP PoP cannot be performed as DTLS to the client is 
terminated in the middle. 

In summary, reading this discussion I see these things to improve in the draft 
- Clarify DTLS 1.2 and 1.3 in the DTLS section.
- Clarify the use of COSE or CMS for server-side keys and chose the MTI. I 
don't think COSE just for the keys while we use ASN.1 DER for ca/enrolled certs 
will buy us much. And it will alter server-side key generation messages defined 
in RFC7030. I think introducing COSE for these messages is fine as long as it 
is conveyed in the response headers and they key establishment is clear. Given 
that we have a way of doing it based on RFC7030, I think this falls out of 
scope for this draft. 
- Add text about short and long names
- Proxy and RA clarification in Section 6.
- Be explicit about the proxy getting the whole message before forwarding in 
Section 6. 

Rgs,
Panos


-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of peter van der Stok
Sent: Thursday, March 15, 2018 6:11 AM
To: Michael Richardson <mcr+i...@sandelman.ca>
Cc: ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-coap-est-00



Michael Richardson schreef op 2018-03-15 09:00:
> peter van der Stok <stokc...@xs4all.nl> wrote:
> >> >> DTLS connection is going to be required to act as an RA.  RAs
> >> are required
> >> >> to have the entire request for adding authentication as 
> necessary.
> >>
> >> > This is visible in the figure of section 6, but needs 
> elaboration in
> >> the
> >> > text.
> >>
> >> I don't understand why we have that paragraph.
> >> An end point that terminates the Pledge (D)TLS connection and 
> acts as
> >> an RA *IS* a Join Registrar, not a Proxy.
> >>
> 
> > Thus is outside the BRSKI context, and thus a proxy with RA 
> (separate or not)
> 
> Let me delete "Join" from above sentence.
> 
> A device that terminates the DTLS security (CoAPS) and then talks to 
> the CA is a Registration Authority according to EST and RFC5280.  It's 
> not a proxy.
> (And it doesn't matter if it speaks HTTPS or CMS or CMP or 
> super-pigeon-telepathy to the CA)
> 
A http/coap proxy  is specified in RFC8075. It explains "how an HTTP request is 
mapped to
a CoAP request and how a CoAP response is mapped back to an HTTP
response".

In the est-coap draft DTLS and TLS connections are terminated in the http/coap 
proxy, and the proxy is therefore connected to an RA (possibly running on the 
same host as the proxy).

Where is my terminology going astray?

Peter



___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


Re: [Ace] draft-ietf-ace-coap-est-00

2018-03-15 Thread peter van der Stok



Michael Richardson schreef op 2018-03-15 09:00:

peter van der Stok  wrote:
>> >> DTLS connection is going to be required to act as an RA.  RAs
>> are required
>> >> to have the entire request for adding authentication as 
necessary.

>>
>> > This is visible in the figure of section 6, but needs 
elaboration in

>> the
>> > text.
>>
>> I don't understand why we have that paragraph.
>> An end point that terminates the Pledge (D)TLS connection and 
acts as

>> an RA *IS* a Join Registrar, not a Proxy.
>>

> Thus is outside the BRSKI context, and thus a proxy with RA
(separate or not)

Let me delete "Join" from above sentence.

A device that terminates the DTLS security (CoAPS) and then talks to 
the CA
is a Registration Authority according to EST and RFC5280.  It's not a 
proxy.

(And it doesn't matter if it speaks HTTPS or CMS or CMP or
super-pigeon-telepathy
to the CA)

A http/coap proxy  is specified in RFC8075. It explains "how an HTTP 
request is mapped to

   a CoAP request and how a CoAP response is mapped back to an HTTP
   response".

In the est-coap draft DTLS and TLS connections are terminated in the 
http/coap proxy, and the proxy is therefore connected to an RA (possibly 
running on the same host as the proxy).


Where is my terminology going astray?

Peter



___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


Re: [Ace] draft-ietf-ace-coap-est-00

2018-03-15 Thread Michael Richardson
Benjamin Kaduk  wrote:
>> Jim Schaad  wrote:
>> > In section 2 - There will be a problem in that the port format 
extension is
>> > being eliminated in TLS 1.3 - We may want to divide this into a 1.2 
and 1.3
>> > section for clarity.
>>
>> I don't understand what you are referring to.
>>
>> What is the "port format extension" you are referring to, and where in
>> section 2 do you think we are depending upon it?

> [...] DTLS
> implementations MUST use the Supported Elliptic Curves and Supported
> Point Formats Extensions [RFC4492]; the uncompressed point format
> MUST be supported; [RFC6090] can be used as an implementation method.

Ah, so s/port/point/

> The uncompressed point format only exists in (D)TLS 1.2 and lower.
> (TLS 1.3 does not separately negotiate point format, rather, the
> point format is determined by the group/curve to be used.)

I think we were just being overly specific, I'm not sure why.

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


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


Re: [Ace] draft-ietf-ace-coap-est-00

2018-03-15 Thread Michael Richardson

peter van der Stok  wrote:
>> >> DTLS connection is going to be required to act as an RA.  RAs
>> are required
>> >> to have the entire request for adding authentication as necessary.
>>
>> > This is visible in the figure of section 6, but needs elaboration in
>> the
>> > text.
>>
>> I don't understand why we have that paragraph.
>> An end point that terminates the Pledge (D)TLS connection and acts as
>> an RA *IS* a Join Registrar, not a Proxy.
>>

> Thus is outside the BRSKI context, and thus a proxy with RA (separate or 
not)

Let me delete "Join" from above sentence.

A device that terminates the DTLS security (CoAPS) and then talks to the CA
is a Registration Authority according to EST and RFC5280.  It's not a proxy.
(And it doesn't matter if it speaks HTTPS or CMS or CMP or 
super-pigeon-telepathy
to the CA)

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




--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


Re: [Ace] draft-ietf-ace-coap-est-00

2018-03-14 Thread peter van der Stok


>> * Should probably add a note in section 6 that any proxy that 
terminates

>> the
>> DTLS connection is going to be required to act as an RA.  RAs
are required
>> to have the entire request for adding authentication as 
necessary.


> This is visible in the figure of section 6, but needs elaboration 
in the

> text.

I don't understand why we have that paragraph.
An end point that terminates the Pledge (D)TLS connection and acts as
an RA *IS* a Join Registrar, not a Proxy.



Thus is outside the BRSKI context, and thus a proxy with RA (separate or 
not)


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


Re: [Ace] draft-ietf-ace-coap-est-00

2018-03-13 Thread Benjamin Kaduk
On Tue, Mar 13, 2018 at 09:44:37PM -0400, Michael Richardson wrote:
> 
> Jim Schaad  wrote:
> > In section 2 - There will be a problem in that the port format 
> extension is
> > being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and 
> 1.3
> > section for clarity.
> 
> I don't understand what you are referring to.
> 
> What is the "port format extension" you are referring to, and where in
> section 2 do you think we are depending upon it?

   [...] DTLS
   implementations MUST use the Supported Elliptic Curves and Supported
   Point Formats Extensions [RFC4492]; the uncompressed point format
   MUST be supported; [RFC6090] can be used as an implementation method.

The uncompressed point format only exists in (D)TLS 1.2 and lower.
(TLS 1.3 does not separately negotiate point format, rather, the
point format is determined by the group/curve to be used.)

I think the fix would just be something like "the uncompressed point
format MUST be supported for DTLS versions prior to 1.3".

-Ben


signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


Re: [Ace] draft-ietf-ace-coap-est-00

2018-03-13 Thread Michael Richardson

Jim Schaad  wrote:
> In section 2 - There will be a problem in that the port format extension 
is
> being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and 
1.3
> section for clarity.

I don't understand what you are referring to.

What is the "port format extension" you are referring to, and where in
section 2 do you think we are depending upon it?

I'm thinking that you are jumping to a conclusion based upon some poorly
written text on our part :-)

But, since I think all the authors are ignorant of that extension, we must be
misleading you unintentionally.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


Re: [Ace] draft-ietf-ace-coap-est-00

2018-03-13 Thread Michael Richardson

peter van der Stok  wrote:
>> *  In section 6- All proxies are required by CoAP blocking to re-assemble
>> the entire message at the proxy.  It can re-block things going to the 
next
>> proxy.  While there is no requirement that the proxy get the entire 
message
>> before sending on pieces, this should be common practice and would be
>> required for a CoAP/HTTP proxy.

> Agree fully, we need to clarify that.

If we are talking about CoAP->HTTP proxy, then clearly that's absolutely true.
How could it be any other way?  We can't do CoAP block mode over HTTP that
I know of :-)

There are other proxy types that we need to describe.


>> * Should probably add a note in section 6 that any proxy that terminates
>> the
>> DTLS connection is going to be required to act as an RA.  RAs are 
required
>> to have the entire request for adding authentication as necessary.

> This is visible in the figure of section 6, but needs elaboration in the
> text.

I don't understand why we have that paragraph.
An end point that terminates the Pledge (D)TLS connection and acts as
an RA *IS* a Join Registrar, not a Proxy.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


Re: [Ace] draft-ietf-ace-coap-est-00

2018-03-12 Thread Benjamin Kaduk
On Mon, Mar 12, 2018 at 09:08:05AM +0100, peter van der Stok wrote:
> Hi Jim,
> 
> thanks for the comments. See my reactions below.
> Jim Schaad schreef op 2018-03-10 22:15:
> > I agree with Hannes, this version of the document is much cleaner and 
> > much
> > clearer.  I think that it has solved most of the problems that I 
> > initially
> > had with the draft.  It is not ready to progress as there are still 
> > sections
> > that are marked as TODO.  But it is much closer to finishing that it 
> > was.
> 
> That sounds hopeful. Agree about the TODOs
> > 
> > I still have a couple of comments from a quick read through of the 
> > document.
> > 
> > In section 2 - There will be a problem in that the port format 
> > extension is
> > being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and 
> > 1.3
> > section for clarity.
> 
> You mean for backward compatibility?

For forwards compatibility, mostly, so we don't claim to require
something that does not exist in TLS 1.3.

-Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


Re: [Ace] draft-ietf-ace-coap-est-00

2018-03-12 Thread peter van der Stok

Hi Jim,

thanks for the comments. See my reactions below.
Jim Schaad schreef op 2018-03-10 22:15:
I agree with Hannes, this version of the document is much cleaner and 
much
clearer.  I think that it has solved most of the problems that I 
initially
had with the draft.  It is not ready to progress as there are still 
sections
that are marked as TODO.  But it is much closer to finishing that it 
was.


That sounds hopeful. Agree about the TODOs


I still have a couple of comments from a quick read through of the 
document.


In section 2 - There will be a problem in that the port format 
extension is
being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and 
1.3

section for clarity.


You mean for backward compatibility?



In section 3- Should we be looking at the use of COSE rather than CMS 
for

encryption of key services?


That is a question that needs some discussion by others.
In the recent draft-richardson-anima-ace-constrained-voucher-03, we 
encrypt the CBOR serialized voucher with either CMS or COSE, as signaled 
in the content format.
Also there is a new draft draft-selander-ace-coap-est-oscore-00 that 
discusses the use of OSCORE for est over coap
Introduction of COSE in est-coaps draft may need alignment with the 
other drafts.


You suggest to use COSE for server key generation only to better protect 
the keys, and all other services to be encrypted with CMS?




*  Do you have the option to additionally support the long name for the
service as well as the short name?  MUST have short name MAY have long 
name?


Agree, should work that out in more detail.


*  In section 6- All proxies are required by CoAP blocking to 
re-assemble
the entire message at the proxy.  It can re-block things going to the 
next
proxy.  While there is no requirement that the proxy get the entire 
message

before sending on pieces, this should be common practice and would be
required for a CoAP/HTTP proxy.


Agree fully, we need to clarify that.


* Should probably add a note in section 6 that any proxy that 
terminates the
DTLS connection is going to be required to act as an RA.  RAs are 
required

to have the entire request for adding authentication as necessary.


This is visible in the figure of section 6, but needs elaboration in the 
text.


Jim



Many thanks, this helps to get our text more concrete and complete.

Peter


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace