Re: [Ace] Charter discussion

[Panos Kampanakis (pkampana)]

I support the addition of draft-selander-ace-coap-est-oscore in the Charter
as it introduces OSCORE with its advantages in constrained environments for
EST which is already standardized in EST-coaps in ACE. 

 

As I have said before, I oppose the addition of CMPv2 over COAP in the
charter. Summarizing the reasons here again for brevity:

- we should not repeat the mistakes of the past and introduce multiple
protocols doing the same thing (cert enrollment or management) over COAP
unless there is a compelling reason. To answer your other question Daniel, I
don’t think we need a new certificate management protocol at this stage. 

- I am not convinced of the technical advantages of using CMPv2 over COAP in
constrained environments. 

- I have not seen overwhelming support for the draft in the list other than
Michael saying “why not” and Steffen and Hendrik (from Siemens) clearly
supporting it. Also, minutes from IETF-108 say “DM: Objections to doing this
work? No objections registered”. I was not there to oppose, but I would not
call that overwhelming active support either. 

- it is not clear who intends to use and implement the draft. If it is a one
or two vendor thing then I don’t think ACE should spend the cycles. I have
not seen many people chiming in that want to the draft and are willing to
review. 

 

Rgs,

Panos

 

 

From: Ace  On Behalf Of Göran Selander
Sent: Tuesday, November 03, 2020 5:06 AM
To: Daniel Migault ; Ace Wg 
Subject: Re: [Ace] Charter discussion

 

Hi Daniel, and all,

 

Some comments on the proposed charter and your mail, sorry for late
response.  

 

1.

”The Working Group is charged with maintenance of the framework and existing
profiles thereof, and may undertake work to specify profiles of the
framework for additional secure communications protocols”

 

I take it this text covers (should the WG want to adopt):

 

*   draft-tiloca-ace-group-oscore-profile
*   an ACE-EDHOC profile (i.e. the POST /token response and the access
token provision information to support authentication with EDHOC, e.g. raw
public key of the other party). Such a profile could provide good trust
management properties, potentially at the cost of a larger access token etc.

 

Right?

 

2.

”In particular the discussion might revive a discussion that happened in
2017 [2] - when I was not co-chair of ACE -and considered other expired work
such as [3]. Please make this discussion constructive on this thread.”

 

As I remember it, the outcome of this discussion was – in line with the
mindset of EST – that it is beneficial to re-use authentication and
communication security appropriate for actual use case. If coaps is suitable
for a particular use case, then it makes sense to protect also the enrolment
procedure with this protocol. But whereas the security protocol is coaps
instead of https, the enrolment functionality and semantics should reuse
that of EST, possibly profiled for the new setting: [4]. 

 

In the same spirit there was support at the meeting [2] to specify
protection of EST payloads profiled for use with OSCORE as communication
security protocol, together with a suitable AKE for authentication.
Following the adoption of EDHOC in LAKE this work has now been revived [5].
IMHO the reasoning above still makes sense.

 

With this in mind, and taking into account recent discussion on the list,
perhaps this part of the charter:

 

”The Working Group will standardize how to use Constrained Application
Protocol (CoAP) as a Transport Medium for the Certificate management
protocol version 2 (CMPv2).   ”

 

should be rephrased or complemented with the reasoning above, for example:

 

The scope of the Working Group includes profiles of the Enrolment over
Secure Transport (EST) transported with the Constrained Application Protocol
(CoAP)” 

 

Thanks

Göran

 

[4]  
https://tools.ietf.org/html/draft-ietf-ace-coap-est

[5] https://tools.ietf.org/html/draft-selander-ace-coap-est-oscore

 

 

 

 

On 2020-10-15, 19:50, "Ace" mailto:ace-boun...@ietf.org> > wrote:

Hi, 

I would like to start the charter discussion. Here is a draft of a proposed
charter [1]. 

 

It seems to be that additional discussion is needed with regard to the last
paragraph related certificate management. In particular the discussion might
revive a discussion that happened in 2017 [2] - when I was not co-chair of
ACE -and considered other expired work such as [3]. Please make this
discussion constructive on this thread. 

 

The fundamental question is whether we need certificate management at this
stage. If the answer is yes, and we have multiple proposals, it would be
good to clarify the position of the different proposals and evaluate whether
a selection is needed or not before validating the charter. 

 

Please provide your inputs on the mailing list before October 30. Of course
for minor edits, you may suggest them directly on the google doc.

 

Yours, 

Dan

Re: [Ace] Call for adoption draft-msahni-ace-cmpv2-coap-transport-01

[Panos Kampanakis (pkampana)]

I oppose adoption.

 

IETF in the past has come up with SCEP, CMP, CMC and EST, all of them for the 
most part doing the same thing with minor differences. I don’t think we need 
two enrollment protocols to run over COAP. We should not repeat mistakes of the 
past. 

 

In ACE we have EST-coaps which is done. We worked on it because EST was in IEC 
62351 and we needed a solution for some COAP usecases. Since then EST-coaps has 
been picked up by Fairhair and Thread. 

 

The argument about L7 protection in CMPv2 could also be satisfied by 
draft-selander-ace-coap-est-oscore. draft-selander-ace-coap-est-oscore was 
trying to secure EST over L7 encrypted COSE messages. 

 

Additionally, I would argue that L7 proof-of-identity is not a strong advantage 
in an (L)RA trust model for both EST-coaps and CMPv2-coaps. What is more, 
having the CA trust all potential manufacturer roots in order to do L7 proof of 
identity will not be trivial unless the CA is a private one. And in a private 
CA and (L)RA scenario I don’t know that end-to-end proof or identity is that 
important. 

 

I oppose adoption unless there is a compelling reason why. Also I am not sure 
where this draft would be implemented and used. If this is just for one or two 
vendors I don’t think ACE needs to spend the cycles. 

 

Thanks,

Panos

 

 

From: Ace  On Behalf Of Mohit Sahni
Sent: Monday, October 05, 2020 3:21 AM
To: Ace Wg 
Cc: stripa...@paloaltonetworks.com; saurabh.tripa...@gmail.com; Mohit Sahni 
; Brockhaus, Hendrik 

Subject: [Ace] Call for adoption draft-msahni-ace-cmpv2-coap-transport-01

 

Hello Ace WG,

I am presenting the draft-msahni-ace-cmpv2-coap-transport-01 to be adopted by 
ACE WG. This document supplements the "Lightweight CMP Profile" draft 
(https://tools.ietf.org/html/draft-brockhaus-lamps-lightweight-cmp-profile-03) 
which specify the modifications to the CMPv2 protocol for it to be used 
efficiently by the constrained devices for PKI operations. 

 

I discussed this draft in IETF-108 ACE session and the need for the recharter 
of ACE WG in order to adopt this draft, to which we had a consensus. Please 
state your opinion on whether this draft should be adopted by ACE WG. 

 

Link to the draft 
https://datatracker.ietf.org/doc/draft-msahni-ace-cmpv2-coap-transport/ 

 

Regards,

Mohit Sahni

 



smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault)

[Panos Kampanakis (pkampana)]

Hi Hendrik, 

Thank you. Understood about the end-to-end protection of CMP and POP. 

I would argue that establishing the end-to-end keys to offer the application
level protection functionality in a scalable way does not come easily. On
the other hand, even CMP allows for an RA trust model instead of end-to-end
POP like EST-coaps does. 

> I am uncertain if I understand your question correctly. Est-over-coaps
described EST transport and not CMP transport on top of CoAP.

I meant why do we need two enrollment protocols to run over COAP?
est-over-coaps took a long time and a lot of work. The reason we pursued it
is because we were getting requests from vendors that wanted to enroll certs
in constrained environments in the energy sector and industrial automation
and EST was standardized in IEC 62351. Is the cmp-over-coap argument that
you could run it over plan UDP and use out-of-band established, end-to-end
protection the sole motivating reason? 

Rgs, 
Panos


-Original Message-
From: Ace  On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, July 22, 2020 9:42 AM
To: Panos Kampanakis (pkampana) ; Benjamin Kaduk
; Michael Richardson 
Cc: Mohit Sahni ; steffen.fr...@siemens.com;
ace@ietf.org
Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel
Migault)

Hi Panos,

thnaks for you feedback.

> Von: Panos Kampanakis (pkampana) 
> 
> Hi,
> 
> > Looking into Mohits draft, cmp-over-coap is much simpler than
> est-over-coaps, as CMP does not need any binding to an underlying 
> (D)TLS handshake.
> 
> Not sure that is accurate. And EST does not bind to the tunnel 
> protocol either unless proof of possession is used. For now the 
> cmp-over-coap draft says
> 
>When the end to end secrecy is desired for CoAP transport, CoAP over
>DTLS [RFC6347] as a transport medium SHOULD be used.
> 
> COAP can run over DTLS or plain UDP and in rare cases TCP, TLS and 
> maybe Websockets. I am not sure someone would run cmp-over-coap over 
> TCP because then he could just run CMP natively without COAP in the 
> middle. Any application layer protocol (CMP etc) can run over any 
> transport but I am
not
> sure there are more transports than the usual ones for cmp-over-coap
anyway.

It is not needed to run CMP over CoAP over TCP. UDP as transport protocol is
fine. Actually CMP over CoAP also does not need DTLS underneath. But it also
does not hinder to have a second line of defense.
As I understand EST, proof-of-possession is purely provided by the
self-signature in PKCS#10. But EST provides the proof-of-identity of the
requesting party by the (D)TLS client authentication bound to the PKCS#10
(tls-unique copied in the P10 password filed). Is this correct?
Such binding is not required for CMP. CMP does not have any requirements in
this regard and provides prove-of-identity by signing the CMP messages. The
advantage is that this prove-of-identity can be end-to-end and not only on
the first hop to the (D)TLS server, like with EST.

> 
> 
> I agree that if this gets picked up it should be by ACE.
> 
> I would like to understand what gaps it is filling compared to 
> est-over-coaps which took a lot of work and where it will be used and 
> implemented in.

I am uncertain if I understand your question correctly. Est-over-coaps
described EST transport and not CMP transport on top of CoAP.
One prototypic implementation can be found on
github.com/siemens/embeddedCMP.

- Hendrik


smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault)

[Panos Kampanakis (pkampana)]

Hi, 

> Looking into Mohits draft, cmp-over-coap is much simpler than
est-over-coaps, as CMP does not need any binding to an underlying (D)TLS
handshake.

Not sure that is accurate. And EST does not bind to the tunnel protocol
either unless proof of possession is used. For now the cmp-over-coap draft
says 

   When the end to end secrecy is desired for CoAP transport, CoAP over
   DTLS [RFC6347] as a transport medium SHOULD be used.

COAP can run over DTLS or plain UDP and in rare cases TCP, TLS and maybe
Websockets. I am not sure someone would run cmp-over-coap over TCP because
then he could just run CMP natively without COAP in the middle. Any
application layer protocol (CMP etc) can run over any transport but I am not
sure there are more transports than the usual ones for cmp-over-coap anyway.


I agree that if this gets picked up it should be by ACE.

I would like to understand what gaps it is filling compared to
est-over-coaps which took a lot of work and where it will be used and
implemented in. 

Panos
 

-Original Message-
From: Ace  On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, July 22, 2020 3:51 AM
To: Benjamin Kaduk ; Michael Richardson

Cc: Mohit Sahni ; steffen.fr...@siemens.com;
ace@ietf.org
Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel
Migault)


> Von: Ace  Im Auftrag von Benjamin Kaduk
> 
> On Tue, Jul 21, 2020 at 04:31:05PM -0400, Michael Richardson wrote:
> >
> > Mohit Sahni  wrote:
> > > To give some background, this draft is an extension of Light
Weight CMP
> > > Profile (
> > >
>
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf
..
> org%2Fhtml%2Fdraft-ietf-lamps-lightweight-cmp-profile-
> 02&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cc3b352cdfd
> 174b0a7e2008d82dc1484f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C
> 0%7C637309655452109222&sdata=QWHu3IEwf4TIIpaW0cvKuMiGXixV1AX
> dws6g0vBQJPY%3D&reserved=0)
> > > draft currently under development in the LAMPS WG. We 
> > discussed the
> "CMPv2
> > > over CoAP" draft in the LAMPS WG and figured out that ACE WG 
> > is a
> more
> > > appropriate place for this draft. However, Jim suggested that 
> > we will
> need
> > > to modify the charter  of the ACE WG to adopt this draft.
> >
> > We did est-over-coaps [still in the queue], why shouldn't we do 
> > cmp-over-
> coap(s)?
> 
> It may just be that "est-over-coaps is so obviously us" that I didn't 
> check the charter carefully at that time.  But, at this point, we're 
> probably overdue for a recharter anyway, as the core framework is making
its way to the IESG.
> 

Steffen and I discussed this with Jim last year in Prague, if I remember
correctly, and he recommended to submit cmp-over-coap to ACE and not to
LAMPS.
As est-over-coaps was in scope of ACE, I also think it is quite obvious to
discuss cmp-over-coap in ACE.
Looking into Mohits draft, cmp-over-coap is much simpler than
est-over-coaps, as CMP does not need any binding to an underlying (D)TLS
handshake.
If you think this needs rechartering, we should go for it.

- Hendrik

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


smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt

[Panos Kampanakis (pkampana)]

Thank you for this Esko. Hmm, point taken.

I consider this a minor change and we will incorporate it in the AUTH48 phase. 
I am planning to rephrase to
   "[...] If the client had requested Content-
   Format TBD287 (application/pkix-cert), the
   server would respond with a single DER binary certificate.
   That certificate would be in a multipart-core container specifically
   in the case of a response to /est/skc query."

Let us know if you have any objections.

Rgs,
Panos

-Original Message-
From: Esko Dijk 
Sent: Monday, February 17, 2020 3:15 AM
To: Panos Kampanakis (pkampana) ; ace@ietf.org
Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt

Hello Panos,

I noticed one sentence in Appendix A that seems inconsistent with the rest of 
the I-D, or at least gives an incomplete view :

   If the client had requested Content-
   Format TBD287 (application/pkix-cert) by querying /est/skc, the
   server would respond with a single DER binary certificate in the
   multipart-core container.

The client here could also have POSTed to resource /est/sen with Accept:TBD287 
option, indicating it is requesting TBD287 for simple enrollment, and the 
server would respond with a single DER binary certificate 
(application/pkix-cert). So the current text might suggest that POSTing to 
/est/skc is the only way to request TBD287 format, which is not the case since 
/est/sen also may support it too.

Best regards
Esko


IoTconsultancy.nl  |  Email/Skype: esko.d...@iotconsultancy.nl

-Original Message-
From: Ace  On Behalf Of Panos Kampanakis (pkampana)
Sent: Monday, January 6, 2020 19:12
To: ace@ietf.org; i-d-annou...@ietf.org
Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt

Hello,

This iteration addresses all IESG reviews. More details on the feedback and 
how we addressed it are in the git issues here

Rgs,
Panos


-Original Message-
From: Ace  On Behalf Of internet-dra...@ietf.org
Sent: Monday, January 06, 2020 1:00 PM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : EST over secure CoAP (EST-coaps)
Authors : Peter van der Stok
  Panos Kampanakis
  Michael C. Richardson
  Shahid Raza
Filename: draft-ietf-ace-coap-est-18.txt
Pages   : 51
Date: 2020-01-06

Abstract:
   Enrollment over Secure Transport (EST) is used as a certificate
   provisioning protocol over HTTPS.  Low-resource devices often use the
   lightweight Constrained Application Protocol (CoAP) for message
   exchanges.  This document defines how to transport EST payloads over
   secure CoAP (EST-coaps), which allows constrained devices to use
   existing EST functionality for provisioning certificates.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-coap-est-18
https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-18


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt

[Panos Kampanakis (pkampana)]

Sorry, forgot the git link 
https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=is%3Aissue
+%22s+IESG%22 
 

-Original Message-
From: Ace  On Behalf Of Panos Kampanakis (pkampana)
Sent: Monday, January 06, 2020 1:12 PM
To: ace@ietf.org; i-d-annou...@ietf.org
Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt

Hello,

This iteration addresses all IESG reviews. More details on the feedback and
how we addressed it are in the git issues here 

Rgs,
Panos


-Original Message-
From: Ace  On Behalf Of internet-dra...@ietf.org
Sent: Monday, January 06, 2020 1:00 PM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Authentication and Authorization for
Constrained Environments WG of the IETF.

Title   : EST over secure CoAP (EST-coaps)
Authors : Peter van der Stok
  Panos Kampanakis
  Michael C. Richardson
  Shahid Raza
Filename: draft-ietf-ace-coap-est-18.txt
Pages   : 51
Date: 2020-01-06

Abstract:
   Enrollment over Secure Transport (EST) is used as a certificate
   provisioning protocol over HTTPS.  Low-resource devices often use the
   lightweight Constrained Application Protocol (CoAP) for message
   exchanges.  This document defines how to transport EST payloads over
   secure CoAP (EST-coaps), which allows constrained devices to use
   existing EST functionality for provisioning certificates.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-coap-est-18
https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-18


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt

[Panos Kampanakis (pkampana)]

Hello,

This iteration addresses all IESG reviews. More details on the feedback and
how we addressed it are in the git issues here 

Rgs,
Panos


-Original Message-
From: Ace  On Behalf Of internet-dra...@ietf.org
Sent: Monday, January 06, 2020 1:00 PM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Authentication and Authorization for
Constrained Environments WG of the IETF.

Title   : EST over secure CoAP (EST-coaps)
Authors : Peter van der Stok
  Panos Kampanakis
  Michael C. Richardson
  Shahid Raza
Filename: draft-ietf-ace-coap-est-18.txt
Pages   : 51
Date: 2020-01-06

Abstract:
   Enrollment over Secure Transport (EST) is used as a certificate
   provisioning protocol over HTTPS.  Low-resource devices often use the
   lightweight Constrained Application Protocol (CoAP) for message
   exchanges.  This document defines how to transport EST payloads over
   secure CoAP (EST-coaps), which allows constrained devices to use
   existing EST functionality for provisioning certificates.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-coap-est-18
https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-18


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Alexey Melnikov's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)

[Panos Kampanakis (pkampana)]

Hi Alexey, 

> Just to clarify: the original EST URIs are prohibited in COAP-EST?

No we don't forbid them in the draft. We do not make them MTI either though.
The long URIs can be supported and they would be a non-default EST-coaps
resource that a server could support and a client could do resource
discovery for. So we did not add text to say "MUST NOT implement the long
URIs". The mandatory to implement/support EST-coaps URIs are the short URIs
for EST-coaps though. 

Panos


-Original Message-
From: Ace  On Behalf Of Alexey Melnikov via
Datatracker
Sent: Monday, January 06, 2020 12:21 PM
To: The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com;
ace-cha...@ietf.org; ace@ietf.org
Subject: [Ace] Alexey Melnikov's No Objection on draft-ietf-ace-coap-est-17:
(with COMMENT)

Alexey Melnikov has entered the following ballot position for
draft-ietf-ace-coap-est-17: No Objection

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/



--
COMMENT:
--

Thank you for this well written document. And thank you for addressing my
points in github.

A remaining comment (which might or might not have been resolved):

5.1.  Discovery and URIs

   Clients and servers MUST support the short resource EST-coaps URIs.

Just to clarify: the original EST URIs are prohibited in COAP-EST?


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


smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

[Panos Kampanakis (pkampana)]

Hi Alexey, 

 

This commit 
https://github.com/SanKumar2015/EST-coaps/commit/77d65f0eb7a28282f363e5e48cd0d28970f9366e
 should address your feedback. The full discussion is in 
https://github.com/SanKumar2015/EST-coaps/issues/155 

 

Let us know if it does not make sense. 

 

Rgs,

Panos

 

From: Ace  On Behalf Of Alexey Melnikov
Sent: Monday, December 23, 2019 9:42 AM
To: consulta...@vanderstok.org; Carsten Bormann 
Cc: ace-cha...@ietf.org; Jim Schaad ; Benjamin Kaduk 
; Ace Wg ; The IESG ; 
draft-ietf-ace-coap-...@ietf.org; Klaus Hartke 
Subject: Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: 
(with DISCUSS and COMMENT)

 

Hi Peter,

 

On Mon, Dec 23, 2019, at 9:12 AM, Peter van der Stok wrote:

HI all,

 

We had this discussion about this specific text several times.

I like to keep at least some text for the following reason:

Implementers, new to coap without a photographic memory of RFC7252 text, are 
surprised by the absence of uri host in the examples, and tend to assume an 
error.

 

The curent text does not look like a "normative rephrasing" to me. 

Nevertheless, is the suggestion below acceptable to everyone?

 

OLD

 

The Uri-Host and Uri-Port Options can be omitted if they coincide

   with the transport protocol destination address and port

   respectively.  Explicit Uri-Host and Uri-Port Options are typically

   used when an endpoint hosts multiple virtual servers and uses the

   Options to route the requests accordingly.

 

NEW

Section 5.10.1 of RFC7252 specifies that the Uri-Host and Uri-Port Options can 
be omitted if they coincide

   with the transport protocol destination address and port

   respectively. 

 

Other suggestions are welcome.

Your suggested text is much better.

 

Thank you,

Alexey

Peter

Carsten Bormann schreef op 2019-12-20 18:16:

On Dec 20, 2019, at 17:34, Klaus Hartke mailto:har...@projectcool.de> > wrote: 

 

I would prefer if draft-ietf-ace-coap-est didn't say anything here,

since the Uri-Host and Uri-Port options and whether they should be

omitted or not is entirely specified by CoAP [RFC7252].*

 

Klaus has an important point here.

 

We need to be **much more** vigilant about specifications messing with their 
normative references.

Saying how they are used, yes, but re-stating (or, worse, re-interpreting) 
normative material from those references is prone to creating dialects that no 
longer interoperate with their unadulterated originals.  Unless these are 
hopelessly broken(*) and this is the only way to fix them, this is a MUST NOT.

 

Grüße, Carsten

 

(*) the normative reference EST has an example for that case: The use of 
content-transfer-encoding with HTTP, which is explicitly ruled out in Section 
19.4.5 of RFC 2616 (and now appendix A.5 of RFC 7231).  That was a count of RFC 
7030 messing with a normative reference, and in turn **needed** to be messed 
with in CoAP-EST (and eventually needs to be fixed in the parent specification, 
too).

 



smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)

[Panos Kampanakis (pkampana)]

Hi Barry, 

This commit 
https://github.com/SanKumar2015/EST-coaps/commit/01f7014e2348d09c0a1ff768eea7d53f4c5471f2
 tries to address your feedback. The full discussion is in 
https://github.com/SanKumar2015/EST-coaps/issues/153 

Let us know if it does not make sense. 

Rgs,
Panos

-Original Message-
From: Ace  On Behalf Of Panos Kampanakis (pkampana)
Sent: Saturday, December 21, 2019 10:49 PM
To: Barry Leiba ; The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; 
ace-cha...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: 
(with COMMENT)

Hi Barry,

Thank you for the thorough review. We are tracking your feedback and our 
responses in a git issue https://github.com/SanKumar2015/EST-coaps/issues/153 
We mostly confirm all your minor text changes and nit fixes. The TBD one we 
will not fix as we are waiting on IANA.

Let us know if something does not make sense. 

Rgs,
Panos


-Original Message-
From: Ace  On Behalf Of Barry Leiba via Datatracker
Sent: Monday, December 16, 2019 9:59 PM
To: The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; 
ace-cha...@ietf.org; ace@ietf.org
Subject: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: (with 
COMMENT)

Barry Leiba has entered the following ballot position for
draft-ietf-ace-coap-est-17: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/



--
COMMENT:
--

Thanks for this — a useful document.  I have a bunch of comments, but they’re 
all editorial.  Please consider them, but there’s not a need to give a detailed 
reply.

-- Section 4 --

  In that case, the
  server MAY want to authenticate a client certificate against its
  trust store although the certificate is expired (Section 10).

Total nit: Why "want to"?  Why not "server MAY authenticate"?

   As described in Section 2.1 of [RFC5272] proof-of-identity refers to
   a value that can be used to prove that the private key corresponding
   to the certified public key is in the possession of and can be used
   by an end-entity or client.

I find the passive voice to be quite awkward here, and suggest making it active:

NEW
   As described in Section 2.1 of [RFC5272], proof-of-identity refers
   to a value that can be used to prove that an end-entity or client is
   in possession of and can use the private key corresponding to the
   certified public key.
END

   the event of handshake message fragmentation, the Hash of the
   handshake messages used in the MAC calculation of the Finished
   message must be computed as if each handshake message had been sent
   as a single fragment (Section 4.2.6 of [RFC6347]).

I know this wording is directly from 6347, but I think it's unclear and would 
like to suggest an alternative.  The "as a single fragment" part is odd, 
because I think what it's really saying is that it's computed as if it had not 
been fragmented.  My suggestion is to change it thus (and similarly for the 
next paragraph after):

NEW
   the event of handshake message fragmentation, the Hash of the
   handshake messages used in the MAC calculation of the Finished
   message must be computed on each reassembled message, as if
   each handshake message had not been fragmented (Section 4.2.6
   of [RFC6347]).
END

If that's not correct, please take that as further evidence that it's unclear, 
and adjust accordingly.

   To alleviate this
   situation, an EST-coaps DTLS connection MAY remain open for
   sequential EST transactions which was not the case with [RFC7030].
   For example, an EST csrattrs request that is followed by a
   simpleenroll request can use the same authenticated DTLS connection.

Two total nits:
a. Comma before "which", please.
b. The "for example" needs some rewording to make it work:
NEW
   For example, if an EST csrattrs request is followed by a
   simpleenroll request, both can use the same authenticated
   DTLS connection.
END

-- Section 5.1 --

   EST-coaps is targeted for low-resource networks with small packets.
   Two types of installations are possible (1) rigid ones where the
   address and the supported functions of the EST server(s) are known,
   and (2) flexible one where the EST server and it supported functions
   need to be discovered.

This needs a colon (:) after "possible", a comma after "rig

Re: [Ace] Adam Roach's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

[Panos Kampanakis (pkampana)]

Hi Adam, 

This commit 
https://github.com/SanKumar2015/EST-coaps/commit/662752d2a725ee72a75af70c36a6379b5cc2d4ab
 tries to address your feedback. The full discussion is in 
https://github.com/SanKumar2015/EST-coaps/issues/156 

Let us know if it does not make sense. 

Rgs,
Panos

-Original Message-
From: Ace  On Behalf Of Panos Kampanakis (pkampana)
Sent: Saturday, December 21, 2019 11:37 PM
To: Adam Roach ; The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; 
ace-cha...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Adam Roach's Discuss on draft-ietf-ace-coap-est-17: (with 
DISCUSS and COMMENT)

Hi Adam,

Thank you for the feedback. For completeness, we are tracking it in a git issue 
https://github.com/SanKumar2015/EST-coaps/issues/156 

Good point about updating the Well-Known URIs to include [This RFC] 
additionally to RFC7030. We will make sure we add this in the IANA 
considerations.

We will also address the other three nits as well. 

Rgs,
Panos


-Original Message-
From: Ace  On Behalf Of Adam Roach via Datatracker
Sent: Tuesday, December 17, 2019 9:29 PM
To: The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; 
ace-cha...@ietf.org; ace@ietf.org
Subject: [Ace] Adam Roach's Discuss on draft-ietf-ace-coap-est-17: (with 
DISCUSS and COMMENT)

Adam Roach has entered the following ballot position for
draft-ietf-ace-coap-est-17: Discuss

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/



--
DISCUSS:
--


Thanks for the work that the authors and working group put into this document.
I have one DISCUSS-level comment that should be very easy to resolve, and a 
small number of editorial nits.

---

§9:

Since this specification is adding new endpoints under /.well-known/est, it 
needs to update the "Well-Known URIs" registry so that the entry for "est" 
indicates this document (in addition to RFC 7030).


--
COMMENT:
--


§5.3:

>  The Content-Format (HTTP Media-Type equivalent) of the CoAP message

HTTP doesn't have a "Media-Type" field. Presumably this intends to say 
"Content-Type"?

---

§5.3:

>  Media-Types specified in the HTTP Content-Type header (Section 3.2.2

Nit "...header field..."

---

§5.5:

>  HTTP response code 202 with a Retry-After header in [RFC7030] has no

Nit "...header field..."


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


smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Alissa Cooper's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)

[Panos Kampanakis (pkampana)]

Hi Alissa 

This commit
https://github.com/SanKumar2015/EST-coaps/commit/a45eda375f4b228b4bcb29e142e
393cddbaa4e6a tries to address your feedback. The full discussion is in
https://github.com/SanKumar2015/EST-coaps/issues/157 

Let us know if it does not make sense. 

Rgs,
Panos

-Original Message-
From: Ace  On Behalf Of Panos Kampanakis (pkampana)
Sent: Thursday, December 19, 2019 11:50 PM
To: Alissa Cooper ; The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com;
ace-cha...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Alissa Cooper's No Objection on
draft-ietf-ace-coap-est-17: (with COMMENT)

Hi Alissa, 

Thank you for the feedback. 

> "It is also RECOMMENDED that the Implicit Trust Anchor database used 
> for EST server authentication is carefully managed to reduce the 
> chance of a third-party CA with poor certification practices 
> jeopardizing authentication."
> 
> This strikes me as a slightly odd use of normative language (what are the
exception cases when the trust anchor database should not be carefully
managed?).
> 

The blurb is directly from RFC7030. We reiterate it here to point it out as
a best practice and then we present a potential deviation from it for
constrained environments. 

To avoid this confusion we can rephrase it as 

As discussed in Section 6 of [RFC7030], it is 
   "RECOMMENDED that the Implicit Trust Anchor database used
   for EST server authentication is carefully managed to reduce the
   chance of a third-party CA with poor certification practices
   jeopardizing authentication.  Disabling the Implicit Trust Anchor
   database after successfully receiving the Distribution of CA
   certificates response (Section 4.1.3 of [RFC7030]) limits any risk to
   the first DTLS exchange." [...]

Rgs,
Panos


-Original Message-
From: Ace  On Behalf Of Alissa Cooper via Datatracker
Sent: Tuesday, December 17, 2019 2:35 PM
To: The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com;
ace-cha...@ietf.org; ace@ietf.org
Subject: [Ace] Alissa Cooper's No Objection on draft-ietf-ace-coap-est-17:
(with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-ace-coap-est-17: No Objection

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/



--
COMMENT:
--

Section 10.1:

"It is also RECOMMENDED that the Implicit Trust Anchor database used
   for EST server authentication is carefully managed to reduce the
   chance of a third-party CA with poor certification practices
   jeopardizing authentication."

This strikes me as a slightly odd use of normative language (what are the
exception cases when the trust anchor database should not be carefully
managed?).


___
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


smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)

[Panos Kampanakis (pkampana)]

Hi Roman, 

This commit 
https://github.com/SanKumar2015/EST-coaps/commit/222879c5d8fab836a7cb1d35cb128821ca790370
 tries to address your feedback. The full discussion is in 
https://github.com/SanKumar2015/EST-coaps/issues/154 

Let us know if it does not make sense. 

Rgs,
Panos


-Original Message-
From: Ace  On Behalf Of Panos Kampanakis (pkampana)
Sent: Sunday, December 22, 2019 11:41 PM
To: Roman Danyliw ; The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; 
ace-cha...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: 
(with COMMENT)

Hi Roman,

Thank you for the thorough review. 

Please check the response to your feedback in 
https://github.com/SanKumar2015/EST-coaps/issues/154 There we include the fixes 
we will make and our thoughts on a couple of your comments. 

Please let us know if you have any further objections.

Panos


-Original Message-
From: Ace  On Behalf Of Roman Danyliw via Datatracker
Sent: Monday, December 16, 2019 5:02 PM
To: The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; 
ace-cha...@ietf.org; ace@ietf.org
Subject: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: 
(with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-ace-coap-est-17: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/



--
COMMENT:
--

* Section 4.  Per “the DTLS connections SHOULD only be kept alive for EST 
messages that are relatively close to each other”, I think the text means that 
some EST messages are more likely to occur one after another.  It would be 
worth being clearer what these would be.

* Section 5.1. Per “These URIs are shorter than the ones in [RFC7030]”, does 
Table 1 imply that when using EST-coaps the “longer names” from RFC7030 
wouldn’t be valid?

* Section 5.2  Per “The latter ones are deemed to expensive …”, was difficult 
to parse as the sentence prior has three things (instead of two).  Is this 
sentence referring to the “not specified functions” only?

* Section 5.3, Per “30% smaller payload for DER-encoded ASN.1”, if you can cite 
this metric, please do.

* Section 5.8.  Per “In summary, the symmetrically encrypted key is included in 
the encryptedKey attribute in a KEKRecipientInfo structure”, if this is done in 
a server-side key generation scenario, where is the client getting the key to 
decrypt the server computed key material?  Should the DecryptKeyIdentifier/ 
AsymmetricDecryptKeyIdentifier attributes be populated in the CSR per Sections
4.4.1.1/4.4.1.2 of RFC7030?

* Section 10.1.  Per “When server-side key generation is used, the constrained 
device depends on the server to generate the private key randomly, but it still 
needs locally generated random numbers for use in security protocols, as 
explained in Section 12 of [RFC7925].”, is the “security protocols” referenced 
here anything beyond DTLS?

* Section 10.1.  Per “In such occasions, checking the certificate revocation 
status or authorizing the client using another method is important for the 
server to ensure that the client is to be trusted.”

-- does this text suggest that expired+revoked certificates should not be used?

-- to word-smith:
s/for the server to ensure that the client is to be trusted/for the server to 
raise its confidence that the client can be trusted/

* Section 10.1.  Per “More information about recommendations of TLS and DTLS
are included in   [BCP195]”, thanks for referencing BCP195.  Could you please
clarify with normative language if these recommendations SHOULD/MUST be 
followed?

* Editorial
- Section 4.  Per “Authenticating and negotiating DTLS keys requires resources 
on low- end endpoints and consumes valuable bandwidth”, I’m not sure this 
sentence is needed.  Technically, “authenticating and negotiating DTLS keys 
requires resources” on any endpoint.

- Section 4.
OLD: Given that after a successful enrollment, it is more likely that a new EST 
transaction will take place after a significant amount of time, NEW: Given that 
after a successful enrollment, it is more likely that a new EST transaction 
will not take place for a significant amount of time,

- Section 5.5. Typo.  s/successfull/successful/

- Section 5.8.  s/Such scenarios could be when it is …/Such scenarios apply 
when it is …/

- Section 5.8.  s/ client, or when the resources/client, when the resources/

- Section 5

Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS)

[Panos Kampanakis (pkampana)]

Hi Magnus, 

This commit
https://github.com/SanKumar2015/EST-coaps/commit/37f6337a3b389632c18b77d3c4d
b8f28aabe9b63  tries to address your feedback. Let us know if it does not
make sense. 

Rgs,
Panos


-Original Message-
From: Ace  On Behalf Of Panos Kampanakis (pkampana)
Sent: Friday, December 20, 2019 12:19 PM
To: Magnus Westerlund ;
i...@ietf.org
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com;
ace-cha...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Magnus Westerlund's Discuss on
draft-ietf-ace-coap-est-17: (with DISCUSS)

Hi Magnus,

I see your point about the confusion the word "support" could cause. Our
intention was to make Block1 and Block2 MTI for the server, Block2 MTI for
the client and Block1 optional to implement for the client only if it needs
it. RFC7959 says " Implementation of either Block option is intended to be
optional. ". So, I think it makes more sense to replicate this language
instead of support. We will use "implement" in place of "support" in our
draft.

Regarding what happens if a client wants to send a large request and it has
not implemented Block 1, I don't think we should define that in our draft.
RFC7959 says when you see a Block message you MUST process it or reject the
message. It does not mandate what the sender application does if it has a
large message and does not have COAP Blocks implemented. The right behavior
in this case is to depend on the lower layer protocol. So if COAP does not
support it, then IP. I do not think we should interfere with that in our
draft, it falls in general TCP/IP layering.

Does the above sound reasonable?

Panos


-Original Message-
From: Ace  On Behalf Of Magnus Westerlund
Sent: Friday, December 20, 2019 4:34 AM
To: i...@ietf.org; Panos Kampanakis (pkampana) 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com;
ace-cha...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Magnus Westerlund's Discuss on
draft-ietf-ace-coap-est-17: (with DISCUSS)

Hi,


On Fri, 2019-12-20 at 05:01 +, Panos Kampanakis (pkampana) wrote:
> Thanks Magnus.
>
> > The EST-coaps client MUST support
> > Block1 only if it sends EST-coaps requests with an IP packet size 
> > that exceeds the Path MTU.
> >
> > I think the requirement for when Block1 is required to be supported 
> > in the above sentence is unclear. Is the intention to say: An 
> > EST-coaps MUST support
> > block1 to be capable to send requests that would otherwise result in 
> > the reliance on IP level fragmentation?
>
> Yes, that was the intention. We will rephrase it to say
>
>[...] The EST-coaps client MUST support
>Block1 only if it sends large EST-coaps requests that would
>otherwise result to IP layer fragmentation.
>

Is it support or use block1 when the request is to big? I think the
combination of support and only results in uncertainty towards what the
implementor. Based on this reformulation I have the impression you want to
make the implementation optional if the expected EST-coaps request size is
less than what the IP MTU can send without fragmentation. However, that
leads me to ask what is the behavior of a node that suddenly are faced with
a request that is larger. Refuse to send it with an error or still rely on
IP fragmentation? There is always the potential for a request being to large
unless implementation support of block1 is mandated.


Cheers

Magnus Westerlund


--
Networks, Ericsson Research
--
Ericsson AB | Phone  +46 10 7148287
Torshamnsgatan 23   | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerl...@ericsson.com
--


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


smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)

[Panos Kampanakis (pkampana)]

Hi Roman,

Thank you for the thorough review. 

Please check the response to your feedback in 
https://github.com/SanKumar2015/EST-coaps/issues/154 There we include the fixes 
we will make and our thoughts on a couple of your comments. 

Please let us know if you have any further objections.

Panos


-Original Message-
From: Ace  On Behalf Of Roman Danyliw via Datatracker
Sent: Monday, December 16, 2019 5:02 PM
To: The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; 
ace-cha...@ietf.org; ace@ietf.org
Subject: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: 
(with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-ace-coap-est-17: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/



--
COMMENT:
--

* Section 4.  Per “the DTLS connections SHOULD only be kept alive for EST 
messages that are relatively close to each other”, I think the text means that 
some EST messages are more likely to occur one after another.  It would be 
worth being clearer what these would be.

* Section 5.1. Per “These URIs are shorter than the ones in [RFC7030]”, does 
Table 1 imply that when using EST-coaps the “longer names” from RFC7030 
wouldn’t be valid?

* Section 5.2  Per “The latter ones are deemed to expensive …”, was difficult 
to parse as the sentence prior has three things (instead of two).  Is this 
sentence referring to the “not specified functions” only?

* Section 5.3, Per “30% smaller payload for DER-encoded ASN.1”, if you can cite 
this metric, please do.

* Section 5.8.  Per “In summary, the symmetrically encrypted key is included in 
the encryptedKey attribute in a KEKRecipientInfo structure”, if this is done in 
a server-side key generation scenario, where is the client getting the key to 
decrypt the server computed key material?  Should the DecryptKeyIdentifier/ 
AsymmetricDecryptKeyIdentifier attributes be populated in the CSR per Sections
4.4.1.1/4.4.1.2 of RFC7030?

* Section 10.1.  Per “When server-side key generation is used, the constrained 
device depends on the server to generate the private key randomly, but it still 
needs locally generated random numbers for use in security protocols, as 
explained in Section 12 of [RFC7925].”, is the “security protocols” referenced 
here anything beyond DTLS?

* Section 10.1.  Per “In such occasions, checking the certificate revocation 
status or authorizing the client using another method is important for the 
server to ensure that the client is to be trusted.”

-- does this text suggest that expired+revoked certificates should not be used?

-- to word-smith:
s/for the server to ensure that the client is to be trusted/for the server to 
raise its confidence that the client can be trusted/

* Section 10.1.  Per “More information about recommendations of TLS and DTLS
are included in   [BCP195]”, thanks for referencing BCP195.  Could you please
clarify with normative language if these recommendations SHOULD/MUST be 
followed?

* Editorial
- Section 4.  Per “Authenticating and negotiating DTLS keys requires resources 
on low- end endpoints and consumes valuable bandwidth”, I’m not sure this 
sentence is needed.  Technically, “authenticating and negotiating DTLS keys 
requires resources” on any endpoint.

- Section 4.
OLD: Given that after a successful enrollment, it is more likely that a new EST 
transaction will take place after a significant amount of time, NEW: Given that 
after a successful enrollment, it is more likely that a new EST transaction 
will not take place for a significant amount of time,

- Section 5.5. Typo.  s/successfull/successful/

- Section 5.8.  s/Such scenarios could be when it is …/Such scenarios apply 
when it is …/

- Section 5.8.  s/ client, or when the resources/client, when the resources/

- Section 5.8. s/Then the private key/The private key/


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


smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Adam Roach's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

[Panos Kampanakis (pkampana)]

Hi Adam,

Thank you for the feedback. For completeness, we are tracking it in a git issue 
https://github.com/SanKumar2015/EST-coaps/issues/156 

Good point about updating the Well-Known URIs to include [This RFC] 
additionally to RFC7030. We will make sure we add this in the IANA 
considerations.

We will also address the other three nits as well. 

Rgs,
Panos


-Original Message-
From: Ace  On Behalf Of Adam Roach via Datatracker
Sent: Tuesday, December 17, 2019 9:29 PM
To: The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; 
ace-cha...@ietf.org; ace@ietf.org
Subject: [Ace] Adam Roach's Discuss on draft-ietf-ace-coap-est-17: (with 
DISCUSS and COMMENT)

Adam Roach has entered the following ballot position for
draft-ietf-ace-coap-est-17: Discuss

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/



--
DISCUSS:
--


Thanks for the work that the authors and working group put into this document.
I have one DISCUSS-level comment that should be very easy to resolve, and a 
small number of editorial nits.

---

§9:

Since this specification is adding new endpoints under /.well-known/est, it 
needs to update the "Well-Known URIs" registry so that the entry for "est" 
indicates this document (in addition to RFC 7030).


--
COMMENT:
--


§5.3:

>  The Content-Format (HTTP Media-Type equivalent) of the CoAP message

HTTP doesn't have a "Media-Type" field. Presumably this intends to say 
"Content-Type"?

---

§5.3:

>  Media-Types specified in the HTTP Content-Type header (Section 3.2.2

Nit "...header field..."

---

§5.5:

>  HTTP response code 202 with a Retry-After header in [RFC7030] has no

Nit "...header field..."


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


smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)

[Panos Kampanakis (pkampana)]

Hi Barry,

Thank you for the thorough review. We are tracking your feedback and our 
responses in a git issue https://github.com/SanKumar2015/EST-coaps/issues/153 
We mostly confirm all your minor text changes and nit fixes. The TBD one we 
will not fix as we are waiting on IANA.

Let us know if something does not make sense. 

Rgs,
Panos


-Original Message-
From: Ace  On Behalf Of Barry Leiba via Datatracker
Sent: Monday, December 16, 2019 9:59 PM
To: The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; 
ace-cha...@ietf.org; ace@ietf.org
Subject: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: (with 
COMMENT)

Barry Leiba has entered the following ballot position for
draft-ietf-ace-coap-est-17: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/



--
COMMENT:
--

Thanks for this — a useful document.  I have a bunch of comments, but they’re 
all editorial.  Please consider them, but there’s not a need to give a detailed 
reply.

-- Section 4 --

  In that case, the
  server MAY want to authenticate a client certificate against its
  trust store although the certificate is expired (Section 10).

Total nit: Why "want to"?  Why not "server MAY authenticate"?

   As described in Section 2.1 of [RFC5272] proof-of-identity refers to
   a value that can be used to prove that the private key corresponding
   to the certified public key is in the possession of and can be used
   by an end-entity or client.

I find the passive voice to be quite awkward here, and suggest making it active:

NEW
   As described in Section 2.1 of [RFC5272], proof-of-identity refers
   to a value that can be used to prove that an end-entity or client is
   in possession of and can use the private key corresponding to the
   certified public key.
END

   the event of handshake message fragmentation, the Hash of the
   handshake messages used in the MAC calculation of the Finished
   message must be computed as if each handshake message had been sent
   as a single fragment (Section 4.2.6 of [RFC6347]).

I know this wording is directly from 6347, but I think it's unclear and would 
like to suggest an alternative.  The "as a single fragment" part is odd, 
because I think what it's really saying is that it's computed as if it had not 
been fragmented.  My suggestion is to change it thus (and similarly for the 
next paragraph after):

NEW
   the event of handshake message fragmentation, the Hash of the
   handshake messages used in the MAC calculation of the Finished
   message must be computed on each reassembled message, as if
   each handshake message had not been fragmented (Section 4.2.6
   of [RFC6347]).
END

If that's not correct, please take that as further evidence that it's unclear, 
and adjust accordingly.

   To alleviate this
   situation, an EST-coaps DTLS connection MAY remain open for
   sequential EST transactions which was not the case with [RFC7030].
   For example, an EST csrattrs request that is followed by a
   simpleenroll request can use the same authenticated DTLS connection.

Two total nits:
a. Comma before "which", please.
b. The "for example" needs some rewording to make it work:
NEW
   For example, if an EST csrattrs request is followed by a
   simpleenroll request, both can use the same authenticated
   DTLS connection.
END

-- Section 5.1 --

   EST-coaps is targeted for low-resource networks with small packets.
   Two types of installations are possible (1) rigid ones where the
   address and the supported functions of the EST server(s) are known,
   and (2) flexible one where the EST server and it supported functions
   need to be discovered.

This needs a colon (:) after "possible", a comma after "rigid ones", "a" before 
"flexible one", another comma after "flexible one", and make it "its supported".

-- Section 5.5 --

   Similarly, 2.04

   is used in successfull response to EST-coaps POST requests (/sen,
   /sren, /skg, /skc).

There's odd spacing here; please fix it.  And "successful" is misspelled.

-- Section 5.7 --

   If the server is very slow (i.e., minutes) in providing the response
   (i.e., when a manual intervention is needed),

I think you mean "e.g." for both of those, evidence for my general aversion to 
using Latin abbreviations that many people don't fully understand.  It also 
feels odd to have the two examples separated in this way.  I suggest this:

NEW
   If the server is very slow in providing th

Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

[Panos Kampanakis (pkampana)]

Hi Alexey, 

Thanks for the feedback. 

We are tracking all your 4 comments and discussion points in a git issue in
https://github.com/SanKumar2015/EST-coaps/issues/155 There are 4 comments in
the issue, one for each of your points. The comments include all exchanged
information in this thread with Ben K, Jim S., Carsten, and Peter. 

At the end of each comments in the git issue you will see the change we
intend to make in the draft to address the feedback. Let us know if any of
them does not make sense. 

Rgs,
Panos



-Original Message-
From: Ace  On Behalf Of Alexey Melnikov via
Datatracker
Sent: Wednesday, December 18, 2019 8:27 AM
To: The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com;
ace-cha...@ietf.org; ace@ietf.org
Subject: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17:
(with DISCUSS and COMMENT)

Alexey Melnikov has entered the following ballot position for
draft-ietf-ace-coap-est-17: Discuss

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/



--
DISCUSS:
--

Thank you for this well written document. I have a couple of small DISCUSS
points and a few minor comments/questions that I would like to discuss.

DISCUSS:

5.4.  Message Bindings

   o  The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content-
  Format, Block1, Block2, and Accept.  These CoAP Options are used
  to communicate the HTTP fields specified in the EST REST messages.
  The Uri-host and Uri-Port Options can be omitted from the COAP
  message sent on the wire.

The statement above

  When omitted, they are logically
  assumed to be the transport protocol destination address and port
  respectively.  Explicit Uri-Host and Uri-Port Options are
  typically used when an endpoint hosts multiple virtual servers and
  uses the Options to route the requests accordingly.

and the last quoted statement: How can the sender know whether or not it is
Ok to omit Uri-Host/Uri-Port?

7.  Parameters

   It is recommended, based on experiments,
   to follow the default CoAP configuration parameters ([RFC7252]).
   However, depending on the implementation scenario, retransmissions
   and timeouts can also occur on other networking layers, governed by
   other configuration parameters.  When a change in a server parameter
   has taken place, the parameter values in the communicating endpoints
   MUST be adjusted as necessary.

The last sentence: use of MUST with passive voice is really unhelpful here.
Adjusted by whom? How can this MUST be satisfied?


--
COMMENT:
--

Comment:

5.1.  Discovery and URIs

   Clients and servers MUST support the short resource EST-coaps URIs.

Just to clarify: the original EST URIs are prohibited in COAP-EST?

In 5.8:

   In the case where the asymmetric encryption key is suitable for
   transport key operations the generated private key is encrypted with
   a symmetric key which is encrypted by the client-defined (in the CSR)

I would break up this sentence into 2 to make it clearer, as I initially
read this as 2 encryption operations applying to the generated private key
itself.
So I suggest something like:

 In the case where the asymmetric encryption key is suitable for  transport
key operations the generated private key is encrypted with  a symmetric key.
The symmetric key itself is encrypted by the client-defined  (in the CSR)

   asymmetric public key and is carried in an encryptedKey attribute in
   a KeyTransRecipientInfo structure.

   Finally, if the asymmetric
   encryption key is suitable for key agreement, the generated private
   key is encrypted with a symmetric key which is encrypted by the
   client defined (in the CSR) asymmetric public key and is carried in
   an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo.

As above.


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


smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS)

[Panos Kampanakis (pkampana)]

Hi Magnus,

I see your point about the confusion the word "support" could cause. Our 
intention was to make Block1 and Block2 MTI for the server, Block2 MTI for the 
client and Block1 optional to implement for the client only if it needs it. 
RFC7959 says " Implementation of either Block option is intended to be 
optional. ". So, I think it makes more sense to replicate this language instead 
of support. We will use "implement" in place of "support" in our draft.

Regarding what happens if a client wants to send a large request and it has not 
implemented Block 1, I don't think we should define that in our draft. RFC7959 
says when you see a Block message you MUST process it or reject the message. It 
does not mandate what the sender application does if it has a large message and 
does not have COAP Blocks implemented. The right behavior in this case is to 
depend on the lower layer protocol. So if COAP does not support it, then IP. I 
do not think we should interfere with that in our draft, it falls in general 
TCP/IP layering.

Does the above sound reasonable?

Panos


-Original Message-
From: Ace  On Behalf Of Magnus Westerlund
Sent: Friday, December 20, 2019 4:34 AM
To: i...@ietf.org; Panos Kampanakis (pkampana) 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; 
ace-cha...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: 
(with DISCUSS)

Hi,


On Fri, 2019-12-20 at 05:01 +, Panos Kampanakis (pkampana) wrote:
> Thanks Magnus.
>
> > The EST-coaps client MUST support
> > Block1 only if it sends EST-coaps requests with an IP packet size
> > that exceeds the Path MTU.
> >
> > I think the requirement for when Block1 is required to be supported
> > in the above sentence is unclear. Is the intention to say: An
> > EST-coaps MUST support
> > block1 to be capable to send requests that would otherwise result in
> > the reliance on IP level fragmentation?
>
> Yes, that was the intention. We will rephrase it to say
>
>[...] The EST-coaps client MUST support
>Block1 only if it sends large EST-coaps requests that would
>otherwise result to IP layer fragmentation.
>

Is it support or use block1 when the request is to big? I think the combination 
of support and only results in uncertainty towards what the implementor. Based 
on this reformulation I have the impression you want to make the implementation 
optional if the expected EST-coaps request size is less than what the IP MTU 
can send without fragmentation. However, that leads me to ask what is the 
behavior of a node that suddenly are faced with a request that is larger. 
Refuse to send it with an error or still rely on IP fragmentation? There is 
always the potential for a request being to large unless implementation support 
of block1 is mandated.


Cheers

Magnus Westerlund


--
Networks, Ericsson Research
--
Ericsson AB | Phone  +46 10 7148287
Torshamnsgatan 23   | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerl...@ericsson.com
--


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

Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS)

[Panos Kampanakis (pkampana)]

Thanks Magnus. 

> The EST-coaps client MUST support
> Block1 only if it sends EST-coaps requests with an IP packet size
> that exceeds the Path MTU.
> 
> I think the requirement for when Block1 is required to be supported in the
> above sentence is unclear. Is the intention to say: An EST-coaps MUST support
> block1 to be capable to send requests that would otherwise result in the
> reliance on IP level fragmentation?

Yes, that was the intention. We will rephrase it to say

   [...] The EST-coaps client MUST support
   Block1 only if it sends large EST-coaps requests that would 
   otherwise result to IP layer fragmentation.

Rgs,
Panos


-Original Message-
From: Ace  On Behalf Of Magnus Westerlund via Datatracker
Sent: Thursday, December 19, 2019 7:54 AM
To: The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; 
ace-cha...@ietf.org; ace@ietf.org
Subject: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with 
DISCUSS)

Magnus Westerlund has entered the following ballot position for
draft-ietf-ace-coap-est-17: Discuss

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/



--
DISCUSS:
--

Section 5.6:

The EST-coaps client MUST support
   Block1 only if it sends EST-coaps requests with an IP packet size
   that exceeds the Path MTU.

I think the requirement for when Block1 is required to be supported in the 
above sentence is unclear. Is the intention to say: An EST-coaps MUST support
block1 to be capable to send requests that would otherwise result in the 
reliance on IP level fragmentation?




___
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] Alissa Cooper's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)

[Panos Kampanakis (pkampana)]

Hi Alissa, 

Thank you for the feedback. 

> "It is also RECOMMENDED that the Implicit Trust Anchor database used
> for EST server authentication is carefully managed to reduce the
> chance of a third-party CA with poor certification practices
> jeopardizing authentication."
> 
> This strikes me as a slightly odd use of normative language (what are the 
> exception cases when the trust anchor database should not be carefully 
> managed?).
> 

The blurb is directly from RFC7030. We reiterate it here to point it out as a 
best practice and then we present a potential deviation from it for constrained 
environments. 

To avoid this confusion we can rephrase it as 

As discussed in Section 6 of [RFC7030], it is 
   "RECOMMENDED that the Implicit Trust Anchor database used
   for EST server authentication is carefully managed to reduce the
   chance of a third-party CA with poor certification practices
   jeopardizing authentication.  Disabling the Implicit Trust Anchor
   database after successfully receiving the Distribution of CA
   certificates response (Section 4.1.3 of [RFC7030]) limits any risk to
   the first DTLS exchange." [...]

Rgs, 
Panos


-Original Message-
From: Ace  On Behalf Of Alissa Cooper via Datatracker
Sent: Tuesday, December 17, 2019 2:35 PM
To: The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; 
ace-cha...@ietf.org; ace@ietf.org
Subject: [Ace] Alissa Cooper's No Objection on draft-ietf-ace-coap-est-17: 
(with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-ace-coap-est-17: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/



--
COMMENT:
--

Section 10.1:

"It is also RECOMMENDED that the Implicit Trust Anchor database used
   for EST server authentication is carefully managed to reduce the
   chance of a third-party CA with poor certification practices
   jeopardizing authentication."

This strikes me as a slightly odd use of normative language (what are the 
exception cases when the trust anchor database should not be carefully 
managed?).


___
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] I-D Action: draft-ietf-ace-coap-est-17.txt

[Panos Kampanakis (pkampana)]

This version addresses Ben's recent feedback before it can go to IESG 
evaluation. 
Thanks Ben for keeping us honest. 
Panos


-Original Message-
From: Ace  On Behalf Of internet-dra...@ietf.org
Sent: Thursday, December 05, 2019 9:43 PM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-17.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : EST over secure CoAP (EST-coaps)
Authors : Peter van der Stok
  Panos Kampanakis
  Michael C. Richardson
  Shahid Raza
Filename: draft-ietf-ace-coap-est-17.txt
Pages   : 52
Date: 2019-12-05

Abstract:
   Enrollment over Secure Transport (EST) is used as a certificate
   provisioning protocol over HTTPS.  Low-resource devices often use the
   lightweight Constrained Application Protocol (CoAP) for message
   exchanges.  This document defines how to transport EST payloads over
   secure CoAP (EST-coaps), which allows constrained devices to use
   existing EST functionality for provisioning certificates.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-coap-est-17
https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-17


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] Secdir last call review of draft-ietf-ace-coap-est-15

[Panos Kampanakis (pkampana)]

Hi Ben,

Can you confirm if the diff 
https://github.com/SanKumar2015/EST-coaps/commit/53933bb9f9365795f2302baef2e39709ae05
 addresses your feedback? I will then re-upload it.  

Thanks,
Panos

-Original Message-
From: Ace  On Behalf Of Panos Kampanakis (pkampana)
Sent: Monday, November 18, 2019 2:07 PM
To: Benjamin Kaduk 
Cc: Yaron Sheffer ; 
draft-ietf-ace-coap-est@ietf.org; ace@ietf.org
Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15

Hi Ben,

All addressed, except for the last one. The diff is here 
https://github.com/SanKumar2015/EST-coaps/commit/53933bb9f9365795f2302baef2e39709ae05
 

My responses below in Pk> 

I will wait for your confirmation before I upload version 17.

Panos


-Original Message-
From: Benjamin Kaduk 
Sent: Tuesday, November 12, 2019 6:06 PM
To: Panos Kampanakis (pkampana) 
Cc: Yaron Sheffer ; 
draft-ietf-ace-coap-est@ietf.org; ace@ietf.org
Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15

Hi Panos,

On Wed, Oct 16, 2019 at 03:06:01PM +0000, Panos Kampanakis (pkampana) wrote:
> Hi Yaron,
> 
> Thank you for the thorough review and feedback. 
> 
> To make sure I don't miss any of your comments over an email thread, I track 
> all your feedback in git issue 152 
> https://github.com/SanKumar2015/EST-coaps/issues/152 There I tried to address 
> all your comments and question and clarify some points. 
> 
> I also pushed minor changes to fix a few of the issues you brought up. 
> The diff of the changes pushed is here 
> https://github.com/SanKumar2015/EST-coaps/commit/86d785f2122596f28674f
> e8e403d30467c98abfb
> 
> Please review the git issue and let us know if there are pending concerns. 
> Otherwise I am planning to reupload a new iteration next week. 

Thanks for uploading the -16, and thanks again to Yaron for the very thoughtful 
review.

Sadly, I seem to have not looked at the github diff closely enough/in a timely 
fashion, so I think we'll need to publish a -17 before I can move this into 
IESG evaluation.  Here's my remaining notes:

Section 4

   Private keys can be transported as responses to a server-side key
   generation request as described in Section 4.4 of [RFC7030] and
   discussed in Section 5.8 of this document.

I think that, since Yaron brought it up, we should say "Section 4.4 of 
[RFC7030] (and subsections)".

PK> Fixed. 

   curve.  After the standardization of [RFC7748], support for
   Curve25519 will likely be required in the future by (D)TLS Profiles
   for the Internet of Things [RFC7925].

Sorry I missed this before -- "standardization" is a bit of a bugbear (7748 is 
Informational, not even Standards-Track, let alone full Internet Standard).

Pk> Replaced "standardization" with "publication". 

   In a constrained CoAP environment, endpoints can't always afford to
   establish a DTLS connection for every EST transaction.
   Authenticating and negotiating DTLS keys requires resources on low-
   end endpoints and consumes valuable bandwidth.  To alleviate this
   situation, an EST-coaps DTLS connection MAY remain open for
   sequential EST transactions.  For example, an EST csrattrs request
   that is followed by a simpleenroll request can use the same
   authenticated DTLS connection.  However, when a cacerts request is

I think we can also clarify that this "MAY remain open" is changing 
expectations from RFC 7030, where the expectation was that the TLS connection 
did not remain open.

Pk> I added " which was not the case in [RFC7030]"

Section 10.1

   the first DTLS exchange.  Alternatively, in a case where a /sen
   request immediately follows a /crts, a client MAY choose to keep the
   connection authenticated by the Implicit TA open for efficiency
   reasons (Section 4).  A client that interleaves EST-coaps /crts
   request with other requests in the same DTLS connection SHOULD
   revalidate the server certificate chain against the updated Explicit
   TA from the /crts response before proceeding with the subsequent
   requests.  If the server certificate chain does not authenticate
   against the database, the client SHOULD close the connection without
   completing the rest of the requests.  The updated Explicit TA MUST
   continue to be used in new DTLS connections.

I think Yaron was saying that "even if the optimization of keeping the DTLS 
connection open is useful in the general case, it is very risky and prone to 
misimplementation when combined with /crts".  So, if I can rephrase the propsal 
to be that we say something more like "even though in general the DTLS 
connection can remain open for efficiency (Section 4), after a /crts response, 
the client MUST close the DTLS connection and establish a new DTLS connection 
for subsequent EST exchanges", are there reasons that we shouldn't use that

Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15

[Panos Kampanakis (pkampana)]

Hi Ben,

All addressed, except for the last one. The diff is here 
https://github.com/SanKumar2015/EST-coaps/commit/53933bb9f9365795f2302baef2e39709ae05
 

My responses below in Pk> 

I will wait for your confirmation before I upload version 17.

Panos


-Original Message-
From: Benjamin Kaduk  
Sent: Tuesday, November 12, 2019 6:06 PM
To: Panos Kampanakis (pkampana) 
Cc: Yaron Sheffer ; 
draft-ietf-ace-coap-est@ietf.org; ace@ietf.org
Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15

Hi Panos,

On Wed, Oct 16, 2019 at 03:06:01PM +0000, Panos Kampanakis (pkampana) wrote:
> Hi Yaron,
> 
> Thank you for the thorough review and feedback. 
> 
> To make sure I don't miss any of your comments over an email thread, I track 
> all your feedback in git issue 152 
> https://github.com/SanKumar2015/EST-coaps/issues/152 There I tried to address 
> all your comments and question and clarify some points. 
> 
> I also pushed minor changes to fix a few of the issues you brought up. 
> The diff of the changes pushed is here 
> https://github.com/SanKumar2015/EST-coaps/commit/86d785f2122596f28674f
> e8e403d30467c98abfb
> 
> Please review the git issue and let us know if there are pending concerns. 
> Otherwise I am planning to reupload a new iteration next week. 

Thanks for uploading the -16, and thanks again to Yaron for the very thoughtful 
review.

Sadly, I seem to have not looked at the github diff closely enough/in a timely 
fashion, so I think we'll need to publish a -17 before I can move this into 
IESG evaluation.  Here's my remaining notes:

Section 4

   Private keys can be transported as responses to a server-side key
   generation request as described in Section 4.4 of [RFC7030] and
   discussed in Section 5.8 of this document.

I think that, since Yaron brought it up, we should say "Section 4.4 of 
[RFC7030] (and subsections)".

PK> Fixed. 

   curve.  After the standardization of [RFC7748], support for
   Curve25519 will likely be required in the future by (D)TLS Profiles
   for the Internet of Things [RFC7925].

Sorry I missed this before -- "standardization" is a bit of a bugbear (7748 is 
Informational, not even Standards-Track, let alone full Internet Standard).

Pk> Replaced "standardization" with "publication". 

   In a constrained CoAP environment, endpoints can't always afford to
   establish a DTLS connection for every EST transaction.
   Authenticating and negotiating DTLS keys requires resources on low-
   end endpoints and consumes valuable bandwidth.  To alleviate this
   situation, an EST-coaps DTLS connection MAY remain open for
   sequential EST transactions.  For example, an EST csrattrs request
   that is followed by a simpleenroll request can use the same
   authenticated DTLS connection.  However, when a cacerts request is

I think we can also clarify that this "MAY remain open" is changing 
expectations from RFC 7030, where the expectation was that the TLS connection 
did not remain open.

Pk> I added " which was not the case in [RFC7030]"

Section 10.1

   the first DTLS exchange.  Alternatively, in a case where a /sen
   request immediately follows a /crts, a client MAY choose to keep the
   connection authenticated by the Implicit TA open for efficiency
   reasons (Section 4).  A client that interleaves EST-coaps /crts
   request with other requests in the same DTLS connection SHOULD
   revalidate the server certificate chain against the updated Explicit
   TA from the /crts response before proceeding with the subsequent
   requests.  If the server certificate chain does not authenticate
   against the database, the client SHOULD close the connection without
   completing the rest of the requests.  The updated Explicit TA MUST
   continue to be used in new DTLS connections.

I think Yaron was saying that "even if the optimization of keeping the DTLS 
connection open is useful in the general case, it is very risky and prone to 
misimplementation when combined with /crts".  So, if I can rephrase the propsal 
to be that we say something more like "even though in general the DTLS 
connection can remain open for efficiency (Section 4), after a /crts response, 
the client MUST close the DTLS connection and establish a new DTLS connection 
for subsequent EST exchanges", are there reasons that we shouldn't use that 
behavior?

Pk> I am not sure it is worth to add more complexity specific to /crts. We 
would be adding more complexity for the client to track if this TLS connection 
is a cacerts connection then I need to close it, if it is any other connection 
then I can interleave requests. I am not convinced that the risk is that big 
either. A malicious user that was authenticated by the Implicit DB could easily 
craft a cacerts response that allows him to be authenticated by the Exp

Re: [Ace] I-D Action: draft-ietf-ace-coap-est-16.txt

[Panos Kampanakis (pkampana)]

Hi,

This iteration addresses Yaron's secdir review. Thank you for the thorough 
feedback Yaron. 
The summary of the fixes is here 
https://github.com/SanKumar2015/EST-coaps/issues/152  
The diff is here 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-16.txt 

Rgs, 
Panos

-Original Message-
From: Ace  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, October 22, 2019 10:12 PM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-16.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : EST over secure CoAP (EST-coaps)
Authors : Peter van der Stok
  Panos Kampanakis
  Michael C. Richardson
  Shahid Raza
Filename: draft-ietf-ace-coap-est-16.txt
Pages   : 50
Date: 2019-10-22

Abstract:
   Enrollment over Secure Transport (EST) is used as a certificate
   provisioning protocol over HTTPS.  Low-resource devices often use the
   lightweight Constrained Application Protocol (CoAP) for message
   exchanges.  This document defines how to transport EST payloads over
   secure CoAP (EST-coaps), which allows constrained devices to use
   existing EST functionality for provisioning certificates.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-coap-est-16
https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-16


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] Secdir last call review of draft-ietf-ace-coap-est-15

[Panos Kampanakis (pkampana)]

Hi Yaron,

I addressed the remaining issues from your responses in the git issue 
https://github.com/SanKumar2015/EST-coaps/issues/152#issuecomment-543315662 
Please check them out and let me know if you have more comments. 

Rgs, 
Panos


-Original Message-
From: Ace  On Behalf Of Panos Kampanakis (pkampana)
Sent: Wednesday, October 16, 2019 11:06 AM
To: Yaron Sheffer ; sec...@ietf.org
Cc: draft-ietf-ace-coap-est@ietf.org; i...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15

Hi Yaron,

Thank you for the thorough review and feedback. 

To make sure I don't miss any of your comments over an email thread, I track 
all your feedback in git issue 152 
https://github.com/SanKumar2015/EST-coaps/issues/152 There I tried to address 
all your comments and question and clarify some points. 

I also pushed minor changes to fix a few of the issues you brought up. The diff 
of the changes pushed is here 
https://github.com/SanKumar2015/EST-coaps/commit/86d785f2122596f28674fe8e403d30467c98abfb
 

Please review the git issue and let us know if there are pending concerns. 
Otherwise I am planning to reupload a new iteration next week. 

Rgs, 
Panos



-Original Message-
From: Ace  On Behalf Of Yaron Sheffer via Datatracker
Sent: Sunday, October 13, 2019 9:02 AM
To: sec...@ietf.org
Cc: draft-ietf-ace-coap-est@ietf.org; i...@ietf.org; ace@ietf.org
Subject: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15

Reviewer: Yaron Sheffer
Review result: Has Issues

This document defines a new profile for EST (simple certificate enrollment) for 
restricted devices, to be run on top of CoAP and DTLS, instead of the usual 
HTTP and TLS.

Overall, I tend to be suspicious of "restricted" profiles, and this is a case 
in point. An implementation of DTLS is no simpler than TLS and most would 
probably support both protocols. And basically anything supports HTTP. So why 
would it make sense to define a whole new profile just to avoid using TCP very 
rarely (say, for daily certificate enrollment), when this profile even needs to 
include its own fragmentation/buffering mechanisms because the ASN.1 payloads 
are too long? In other words, we are introducing new and additional complexity 
with little or no performance gain.

- 2. Only certificate-based client authentication is supported. Hopefully some 
time soon we'll be able to use PAKE here, to bootstrap the PKI.

- 4. "Crypto agility is important" - this statement is somewhat meaningless: do 
we require more than one cipher suite, which would ensure some level of agility?

- Also, when we say "Sec. 4.4 of RFC 7925" do we mean *only* Sec. 4.4 or also 
the subsections: 4.4.1 etc.

- "in DTLS 1.3 the Supported Elliptic Curves extension has been renamed to 
Supported Groups". This is probably true for an older version of the draft, I 
couldn't find anything to support it in -32.

- "the Finished message must be computed" - this whole paragraph is unclear.
Are we changing the Finished/MAC computation in DTLS (if so, this must be 
pointed out very clearly)? Or are we explaining a point about channel binding 
(if we are, this doesn't come across).

- Similarly for the following paragraph: is this a performance  optimization, 
or a change to DTLS? And by the way, why are standard session resumption 
mechanisms not used?

- I don't see value in the short EST URI paths given that most of the "weight"
is in ASN.1 data, and the paths are negligible in comparison. Moreover, if the 
paths are different, shouldn't this document formally UPDATE RFC 7030? I think 
it is no longer a profile.

- Non-default server port: the examples include an IPv6 address in addition to 
the port number. Is there a way to use relative URIs (omitting the IP address) 
but include a port number? The server may not know its own IP address (IPv4 
with NAT) or the address may be dynamic.

- The server MUST support the default /.well-known/est root resource, but then
in the next sentence we discuss non-default URIs. In the case of the server
having multiple "identities" (the main purpose of the "arbitrary label", 
AFAIU), the root resource is confusing - which identity is it associated with?
And then how is discovery managed for each identity, and is there a way to 
discover the identities?

- There is nowhere in this document a full formal definition of content type
TBD287 (a single cert).

- Content type negotiation: I can see how it works for enrollment. But in the 
case of /cacerts, if the server has a list of certs in its explicit TA store 
(e.g. to support rollover), how can TBD287 (a single cert) make sense?

- It is mighty confusing to denote "content format" by "ct" (presumably, this 
stands for "content type").

- "ASN.1 encoded in binary format" - I think this should be, "DER-

Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15

[Panos Kampanakis (pkampana)]

Hi Yaron,

Thank you for the thorough review and feedback. 

To make sure I don't miss any of your comments over an email thread, I track 
all your feedback in git issue 152 
https://github.com/SanKumar2015/EST-coaps/issues/152 There I tried to address 
all your comments and question and clarify some points. 

I also pushed minor changes to fix a few of the issues you brought up. The diff 
of the changes pushed is here 
https://github.com/SanKumar2015/EST-coaps/commit/86d785f2122596f28674fe8e403d30467c98abfb
 

Please review the git issue and let us know if there are pending concerns. 
Otherwise I am planning to reupload a new iteration next week. 

Rgs, 
Panos



-Original Message-
From: Ace  On Behalf Of Yaron Sheffer via Datatracker
Sent: Sunday, October 13, 2019 9:02 AM
To: sec...@ietf.org
Cc: draft-ietf-ace-coap-est@ietf.org; i...@ietf.org; ace@ietf.org
Subject: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15

Reviewer: Yaron Sheffer
Review result: Has Issues

This document defines a new profile for EST (simple certificate enrollment) for 
restricted devices, to be run on top of CoAP and DTLS, instead of the usual 
HTTP and TLS.

Overall, I tend to be suspicious of "restricted" profiles, and this is a case 
in point. An implementation of DTLS is no simpler than TLS and most would 
probably support both protocols. And basically anything supports HTTP. So why 
would it make sense to define a whole new profile just to avoid using TCP very 
rarely (say, for daily certificate enrollment), when this profile even needs to 
include its own fragmentation/buffering mechanisms because the ASN.1 payloads 
are too long? In other words, we are introducing new and additional complexity 
with little or no performance gain.

- 2. Only certificate-based client authentication is supported. Hopefully some 
time soon we'll be able to use PAKE here, to bootstrap the PKI.

- 4. "Crypto agility is important" - this statement is somewhat meaningless: do 
we require more than one cipher suite, which would ensure some level of agility?

- Also, when we say "Sec. 4.4 of RFC 7925" do we mean *only* Sec. 4.4 or also 
the subsections: 4.4.1 etc.

- "in DTLS 1.3 the Supported Elliptic Curves extension has been renamed to 
Supported Groups". This is probably true for an older version of the draft, I 
couldn't find anything to support it in -32.

- "the Finished message must be computed" - this whole paragraph is unclear.
Are we changing the Finished/MAC computation in DTLS (if so, this must be 
pointed out very clearly)? Or are we explaining a point about channel binding 
(if we are, this doesn't come across).

- Similarly for the following paragraph: is this a performance  optimization, 
or a change to DTLS? And by the way, why are standard session resumption 
mechanisms not used?

- I don't see value in the short EST URI paths given that most of the "weight"
is in ASN.1 data, and the paths are negligible in comparison. Moreover, if the 
paths are different, shouldn't this document formally UPDATE RFC 7030? I think 
it is no longer a profile.

- Non-default server port: the examples include an IPv6 address in addition to 
the port number. Is there a way to use relative URIs (omitting the IP address) 
but include a port number? The server may not know its own IP address (IPv4 
with NAT) or the address may be dynamic.

- The server MUST support the default /.well-known/est root resource, but then
in the next sentence we discuss non-default URIs. In the case of the server
having multiple "identities" (the main purpose of the "arbitrary label", 
AFAIU), the root resource is confusing - which identity is it associated with?
And then how is discovery managed for each identity, and is there a way to 
discover the identities?

- There is nowhere in this document a full formal definition of content type
TBD287 (a single cert).

- Content type negotiation: I can see how it works for enrollment. But in the 
case of /cacerts, if the server has a list of certs in its explicit TA store 
(e.g. to support rollover), how can TBD287 (a single cert) make sense?

- It is mighty confusing to denote "content format" by "ct" (presumably, this 
stands for "content type").

- "ASN.1 encoded in binary format" - I think this should be, "DER-encoded 
ASN.1, in its native binary form".

- Please don't use "he" and "she" for the server and the client. Both are 
merely "it".

- "The Registrar MUST authenticate and optionally authorize the client 
requests" - this statement is too weak. The Registrar must also ensure that 
clients only send CSRs that pertain to their authenticated identity (channel 
binding), even when POP-linking is not used. I think this is worthy of its own 
subsection, describing the validation required for each particular EST flow.

- The following paragraph is not clear: is PoP-linking 
useful/recommended/mandated in this scenario? IMO there should be some 2119 
word regarding server-side validation of the tls-uni

Re: [Ace] Genart last call review of draft-ietf-ace-coap-est-15

[Panos Kampanakis (pkampana)]

Thanks David. Done. I replaced the RFC7525 references with BCP195. 

Should I upload or will there be more Gen-ART reviews?


-Original Message-
From: Ace  On Behalf Of David Schinazi via Datatracker
Sent: Sunday, October 06, 2019 12:49 AM
To: gen-...@ietf.org
Cc: draft-ietf-ace-coap-est@ietf.org; i...@ietf.org; ace@ietf.org
Subject: [Ace] Genart last call review of draft-ietf-ace-coap-est-15

Reviewer: David Schinazi
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-ace-coap-est-??
Reviewer: David Schinazi
Review Date: 2019-10-05
IETF LC End Date: 2019-10-18
IESG Telechat date: Not scheduled for a telechat

Summary: Document is clear and well-written.

Major issues: None.

Minor issues: None.

Nits/editorial comments: I believe references to RFC7525 should instead refer 
to it as BCP195 to point to future revisions.


___
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] I-D Action: draft-ietf-ace-coap-est-15.txt

[Panos Kampanakis (pkampana)]

Hello, 

The v15 iteration addresses Ben K.'s latest feedback in response to the fixes 
that went in after his AD review. Thank you for the detailed feedback Ben. 
The diff from v14 is here 
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-15 

I think it could move to the next stage now. 

Thanks,
Panos


-Original Message-
From: Ace  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, October 01, 2019 11:17 AM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-15.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : EST over secure CoAP (EST-coaps)
Authors : Peter van der Stok
  Panos Kampanakis
  Michael C. Richardson
  Shahid Raza
Filename: draft-ietf-ace-coap-est-15.txt
Pages   : 50
Date: 2019-10-01

Abstract:
   Enrollment over Secure Transport (EST) is used as a certificate
   provisioning protocol over HTTPS.  Low-resource devices often use the
   lightweight Constrained Application Protocol (CoAP) for message
   exchanges.  This document defines how to transport EST payloads over
   secure CoAP (EST-coaps), which allows constrained devices to use
   existing EST functionality for provisioning certificates.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-coap-est-15
https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-15


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] AD review of draft-ietf-ace-coap-est-12 part 2

[Panos Kampanakis (pkampana)]

Hi Ben,

Thank you again for the additional feedback. 

The changes are summarized in the git issue 
https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-535065314 I 
mostly made all the suggested text changes, summarized our discussion about 
extended-master-secret. I also made a change in Fig 2 and Fig 3 to address the 
issue you caught with the /128 blocks. 

The diff is here 
https://github.com/SanKumar2015/EST-coaps/commit/d16c53d3360430b5587021dc1a2d31f668c0c0fe
 . And a minor nit fix in 
https://github.com/SanKumar2015/EST-coaps/commit/ff5b303781231e34571352cb07fb895d5ecab791
 

I will reupload early next week. Please check out the issue in case you have 
further comments. 

Panos


-Original Message-
From: Ace  On Behalf Of Benjamin Kaduk
Sent: Monday, September 23, 2019 6:48 PM
To: Panos Kampanakis (pkampana) 
Cc: Peter van der Stok ; Jim Schaad 
; draft-ietf-ace-coap-est@ietf.org; Michael 
Richardson ; ace@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Hi Panos,

Sorry for the slow response here -- I was in telechat-prep mode last week.

This is in pretty good shape, and I wanted to especially thank you for the 
presentation in the github issue -- that format was extremely helpful for me.

I think we will probably need to upload one more minor revision before I 
initiate the IETF LC; please seem my comments below.


In Section 4, I think we need to put the "for" back in "requests for a trusted 
certificate list".

Also, refresh my memory: did we decide that there's no need to explicitly 
mandate the use of the "extended_master_secret" TLS extension?

I'd also change the note about supported_groups vs. Supported Elliptic Curves 
to read "In addition, in DTLS 1.3 the Supported Elliptic Curves extension has 
been renamed to Supported Groups."

I think we can move /csrattrs to the bottom of Table 2 (thank you for changing 
Table 1!).

With the changes to the example in Figure 3, can you walk me through the 
block-size negotiation?  Quoting:

POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}-->
  |
   ... Immediate response when certificate is ready ...
  |
  <-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed){Cert resp (frag# 1)}
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128)   -->
  <-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp (frag# 2)}

So the ACK to the final fragment of the POST includes (2:0/1/256), or the first 
fragment of a 256-byte-fragmented version of the response.
The client then goes and asks for (2:1/0/128), which is the second fragment of 
a 128-byte-fragmented version of the response.  Is that just going to be the 
last 128 bytes of the thing it already got from the server?  If so, is that 
something it would actually do (e.g., if it had to drop part of the server's 
response due to a buffer-size limitation) or is it not possible to only have 
part of a fragment (so it would need to either ask for (2:0/0/128) or 
(2:2/0/128)?

It looks like you removed the text about "[the two representations] do not have 
to be in a particular order since each representation is preceded by its 
Content-Format ID" based on my remark about core-multipart-ct; that document 
has since been approved by the IESG and is explicitly confirming that there is 
no specific ordering requirement (in contrast to multipart/mixed), so we could 
put that clause back in this document if desired.

I consider it more likely than not that a directorate reviewer will want to 
tweak the added language at the end of Section 5.8 explaining our divergence 
from RFC 7030; if you want to preemptively reword, my suggestion would be 
"Although [RFC7030] strongly recommends that clients request the use of CMS 
encryption on top of the TLS channel's protection, this document does not make 
such a recommendation; CMS encryption can still be used when mandated by the 
use case."

Thanks!

-Ben


On Mon, Sep 16, 2019 at 05:38:59PM +, Panos Kampanakis (pkampana) wrote:
> Hi Ben,
> 
> I think we have now addressed all your feedback from the AD review. A big 
> chunk of the changes were agreed upon in the list emails threads. 
> 
> The iteration that we are planning to upload that includes all the 
> changes is at 
> https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-c
> oap-est.txt
> 
> The summary of all your comments and what went into the text is in the 
> git issue https://github.com/SanKumar2015/EST-coaps/issues/150 To 
> break it down
> - https://github.com/SanKumar2015/EST-coaps/issues/150#issue-489289217 has 
> most of the changes agreed on the list.
> -  
> https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-528001807 
> has an answer to your question about addressing the tls-unique issue in a new 
&

Re: [Ace] I-D Action: draft-ietf-ace-coap-est-14.txt

[Panos Kampanakis (pkampana)]

Hi everyone,

This iteration addresses comments we received from Ben's AD Review. Thanks Ben. 

The summary of all comments and what went into the text after the discussions 
in the list is in the git issue 
https://github.com/SanKumar2015/EST-coaps/issues/150 

Rgs,
Panos



-Original Message-
From: Ace  On Behalf Of internet-dra...@ietf.org
Sent: Friday, September 20, 2019 11:54 PM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-14.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : EST over secure CoAP (EST-coaps)
Authors : Peter van der Stok
  Panos Kampanakis
  Michael C. Richardson
  Shahid Raza
Filename: draft-ietf-ace-coap-est-14.txt
Pages   : 50
Date: 2019-09-20

Abstract:
   Enrollment over Secure Transport (EST) is used as a certificate
   provisioning protocol over HTTPS.  Low-resource devices often use the
   lightweight Constrained Application Protocol (CoAP) for message
   exchanges.  This document defines how to transport EST payloads over
   secure CoAP (EST-coaps), which allows constrained devices to use
   existing EST functionality for provisioning certificates.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-coap-est-14
https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-14


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] AD review of draft-ietf-ace-coap-est-12 part 2

[Panos Kampanakis (pkampana)]

Hi Ben,

I think we have now addressed all your feedback from the AD review. A big chunk 
of the changes were agreed upon in the list emails threads. 

The iteration that we are planning to upload that includes all the changes is 
at 
https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt
 

The summary of all your comments and what went into the text is in the git 
issue https://github.com/SanKumar2015/EST-coaps/issues/150 To break it down 
- https://github.com/SanKumar2015/EST-coaps/issues/150#issue-489289217 has most 
of the changes agreed on the list.
-  https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-528001807 
has an answer to your question about addressing the tls-unique issue in a new 
draft. 
- https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-531853281 
has the last changes in response to your feedback that went into the draft 
after Peter uploade the -13 iteration. 

Two places to pay attention to is that I removed the 
>   It is strongly RECOMMENDED that the clients request that the returned
>   private key be afforded the additional security of the Cryptographic
>   Message Syntax (CMS) EnvelopedData in addition to the TLS-provided
>   security to protect against unauthorized disclosure."
and the 
>   The corresponding longer URIs from [RFC7030] MAY be supported."
The rationale behind that is in the git issue. 

Please have a look and let us know if there is anything missing. Otherwise we 
will upload at the end of the week. 

Rgs,
Panos


-Original Message-
From: Ace  On Behalf Of Panos Kampanakis (pkampana)
Sent: Tuesday, September 10, 2019 12:18 AM
To: Jim Schaad ; 'Michael Richardson' 

Cc: draft-ietf-ace-coap-est@ietf.org; 'Benjamin Kaduk' ; 
ace@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Hi Jim,

We are tracking all of Ben's feedback here 
https://github.com/SanKumar2015/EST-coaps/issues/150 

The fixes that have gone in the draft so far are after each comment. There are 
still some that we still need to update after the threads converged. 

Panos


-Original Message-
From: Ace  On Behalf Of Jim Schaad
Sent: Monday, September 09, 2019 11:34 PM
To: 'Michael Richardson' 
Cc: draft-ietf-ace-coap-est@ietf.org; 'Benjamin Kaduk' ; 
ace@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Authors,

Are we ready to produce a new draft that addresses most, if not all, of Ben's 
comments?  Do we have a pull request to deal with this that we can point to?

Jim


-Original Message-
From: Jim Schaad 
Sent: Monday, September 9, 2019 1:17 PM
To: 'Michael Richardson' ; 'Benjamin Kaduk'

Cc: draft-ietf-ace-coap-est@ietf.org; ace@ietf.org
Subject: RE: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2



-Original Message-
From: Michael Richardson  
Sent: Monday, September 9, 2019 9:38 AM
To: Benjamin Kaduk 
Cc: draft-ietf-ace-coap-est@ietf.org; ace@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2


Benjamin Kaduk  wrote:
>> So, on a constrained device, I'd like to know what to expect (what to
>> code for).  While I do'nt particularly care for server-generated
keys,
>> it should probably be specified correctly.  I see that the complexity
>> of sorting this means that I think that Content-Format 284
>> (unprotected) will get used most often.

> Your constrained device is probably only going to implement one cipher
> [mode], too, right?  If it's an AEAD mode, you use AuthEnvelopedData;
> otherwise, classic EnvelopedData.

Yes, but each constrained device type might have a different set, and the
EST server for such an installation has to figure out how to send the right
thing.

[JLS] This is the function of section 4.4.1.1 in RFC 7030 which says that
the DecryptKeyIdentifier must be present.  This will provide the EST server
a method to identify the correct key and the correct symmetric encryption
algorithm.

>> I think that we could go to TLS Exporter right now, but it would take
>> some work.

> I'd rather have both classic-EST and coap-EST benefit than just
> coap-EST.

So you'd agree to deferring this to a document (maybe in LAMPS?) that would
Updates: 7030 and this document.

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

Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

[Panos Kampanakis (pkampana)]

Hi Jim,

We are tracking all of Ben's feedback here 
https://github.com/SanKumar2015/EST-coaps/issues/150 

The fixes that have gone in the draft so far are after each comment. There are 
still some that we still need to update after the threads converged. 

Panos


-Original Message-
From: Ace  On Behalf Of Jim Schaad
Sent: Monday, September 09, 2019 11:34 PM
To: 'Michael Richardson' 
Cc: draft-ietf-ace-coap-est@ietf.org; 'Benjamin Kaduk' ; 
ace@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Authors,

Are we ready to produce a new draft that addresses most, if not all, of Ben's 
comments?  Do we have a pull request to deal with this that we can point to?

Jim


-Original Message-
From: Jim Schaad 
Sent: Monday, September 9, 2019 1:17 PM
To: 'Michael Richardson' ; 'Benjamin Kaduk'

Cc: draft-ietf-ace-coap-est@ietf.org; ace@ietf.org
Subject: RE: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2



-Original Message-
From: Michael Richardson  
Sent: Monday, September 9, 2019 9:38 AM
To: Benjamin Kaduk 
Cc: draft-ietf-ace-coap-est@ietf.org; ace@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2


Benjamin Kaduk  wrote:
>> So, on a constrained device, I'd like to know what to expect (what to
>> code for).  While I do'nt particularly care for server-generated
keys,
>> it should probably be specified correctly.  I see that the complexity
>> of sorting this means that I think that Content-Format 284
>> (unprotected) will get used most often.

> Your constrained device is probably only going to implement one cipher
> [mode], too, right?  If it's an AEAD mode, you use AuthEnvelopedData;
> otherwise, classic EnvelopedData.

Yes, but each constrained device type might have a different set, and the
EST server for such an installation has to figure out how to send the right
thing.

[JLS] This is the function of section 4.4.1.1 in RFC 7030 which says that
the DecryptKeyIdentifier must be present.  This will provide the EST server
a method to identify the correct key and the correct symmetric encryption
algorithm.

>> I think that we could go to TLS Exporter right now, but it would take
>> some work.

> I'd rather have both classic-EST and coap-EST benefit than just
> coap-EST.

So you'd agree to deferring this to a document (maybe in LAMPS?) that would
Updates: 7030 and this document.

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

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

Re: [Ace] I-D Action: draft-ietf-ace-coap-est-12.txt

[Panos Kampanakis (pkampana)]

Hi all, 

This iteration fixes the nits and feedback provided by Esko in 5/21 and 5/28. 
The comments and their fixes are discussed in two git issues 
- https://github.com/SanKumar2015/EST-coaps/issues/145  
- https://github.com/SanKumar2015/EST-coaps/issues/146 

The diff from the previous version is here 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-12.txt 

Thanks to Esko for being persistent in trying to bring the doc to a state as 
perfect as possible. 

Rgs,
Panos


-Original Message-
From: Ace  On Behalf Of internet-dra...@ietf.org
Sent: Wednesday, June 05, 2019 10:49 AM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-12.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : EST over secure CoAP (EST-coaps)
Authors : Peter van der Stok
  Panos Kampanakis
  Michael C. Richardson
  Shahid Raza
Filename: draft-ietf-ace-coap-est-12.txt
Pages   : 49
Date: 2019-06-05

Abstract:
   Enrollment over Secure Transport (EST) is used as a certificate
   provisioning protocol over HTTPS.  Low-resource devices often use the
   lightweight Constrained Application Protocol (CoAP) for message
   exchanges.  This document defines how to transport EST payloads over
   secure CoAP (EST-coaps), which allows constrained devices to use
   existing EST functionality for provisioning certificates.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-coap-est-12
https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-12


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] I-D Action: draft-ietf-ace-coap-est-11.txt / additional review comments

[Panos Kampanakis (pkampana)]

Hi Esko,

I addressed all your responses to this thread. Check them out here 
https://github.com/SanKumar2015/EST-coaps/issues/145#issuecomment-497043624 

Practically all your nits and suggestions were addressed. 
Specifically for swapping 2.01 with 2.04 throughout will be painful for interop 
implementers of the draft. I wish we had caught it earlier, but I saw your 
point and I made the change. 

The diffs are here 
https://github.com/SanKumar2015/EST-coaps/commit/ace75414ac21d2652d93ad1ab663a65772696817?diff=unified
 

I am planning to submit a new version next Wednesday. 

Let me know if there is anything else. 

Panos



-Original Message-
From: Ace  On Behalf Of Esko Dijk
Sent: Tuesday, May 28, 2019 6:31 AM
To: Panos Kampanakis (pkampana) ; ace@ietf.org
Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt / additional 
review comments

Hello,

Thanks for the update! First, regarding the changes:

* 
   mapping of HTTP response codes to CoAP response codes.  The success
   code in response to an EST-coaps GET request (/cacerts, /csrattrs),
   is 2.05.  Similarly, 2.01 is used in response to EST-coaps POST
   requests (/simpleenroll, /simplereenroll, /serverkeygen).  Section 7
   of [RFC8075] maps 2.02 (Deleted) or 2.04 (Changed) to an HTTP 200 OK
   response, but 2.01 (Created) is more suitable for the creation of
   certificates in the context of EST-coaps.
-> 2.01 Created is now used as POST response.  While I agree that it sounds 
more logical to use 2.01 than 2.04 (since a certificate is created by the 
server, based on the CSR), there is the CoAP level expectation that when using 
2.01 the resource is created at the location of the request - that is, for 
example, at /sen. So if the client would do a GET /sen it would get the actual 
previously created certificate. (Which is not the case.) The text in RFC 7252 
that states this is "Otherwise, the resource was created at the request URI."   
So 2.01 is used to create new CoAP *resources* that can be found at the server 
using a subsequent GET request. And 2.04 is used to execute actions like 
'create x' , the result of which is returned in the response but otherwise not 
available anywhere on the server anymore. The latter is the case in the 
EST-coaps protocol flow as there's no way to GET the resulting certificate 
later on.
-> the resources in brackets should now be the short resource names, since we 
talk about EST-coaps resources not EST resources anymore. So "GET request 
(/crts, /att)" etc.

* "EST makes use of HTTP 204 responses when a resource is not available for the 
client."
-> EST states either 204 or 404 can be used; which in CoAP translates to 4.04 
Not Found  if the resource is not available to the client, i.e. does not exist. 
That seems the easiest translation here. Though the server could also send 2.05 
with an empty zero-length payload, to express that it has that function 
available but there is "nothing" there for the client.

* 2.04 SHOULD only be used in response to an EST-coaps
   POST when the response comes delayed in a separate (not Piggybacked)
   message after an empty 0.00 message (Section 5.7)
-> this seems strange, the response code remains the same whether separate 
response or piggybacked response is used. At this level of request/response, 
there's no need to try to detail this. I feel it only makes it more complex; 
the base CoAP protocol should handle piggybacked vs separate for both client 
and server. (Without impact on response codes).

* Table 3: the "4.xx" can be "4.xx / 5.xx" because the 5.xx failures can also 
occur in any CoAP server in principle.  I don't really see why 4.02 should be 
mentioned separately? It again is defined in the base CoAP spec and not really 
of interest for EST-coaps, nor used by any definitions or examples in the 
current specification.


Second, below a few more review comments on the -11 version:

* End of Section 6: "If necessary, the EST-coaps-to-HTTP Registrar will support 
resouce discovery according to the rules in Section 5.1."
-> what about (also added letter to 'resouce')
"The EST-coaps-to-HTTP Registrar MUST support resource discovery according to 
the rules in Section 5.1."
Because this Registrar operates to the CoAP client facing side exactly like a 
CoAP EST server. So it must support the same rules for discovery, or else it 
won't work (e.g. be not discoverable).

* Section 9.1: "These have been registered provisionally in the Expert Review 
range (0-255)"
-> "These have been registered provisionally in the IETF Review or IESG 
Approval range (256-)"

* Section 10.1: 
   A client that pipelines EST-coaps /crts request
   with other requests in the same DTLS connection SHOULD revalidate the
   server certificate chain against the updated Explicit TA from the
   /crts response b

Re: [Ace] Esko's review from 5/28/2019 (was RE: I-D Action: draft-ietf-ace-coap-est-11.txt / additional review comments)

[Panos Kampanakis (pkampana)]

Hi Esko,

Changing subject line to address your new review comments first. I will address 
your response to your previous review in the other thread.

Thanks again for finding these nits and for your suggestions. 

> -> I wonder why the client would trust a new Explicit TA, if the EST server 
> itself cannot be authenticated using that TA. It will disconnect and then 
> upon next DTLS connection to the same server the handshake will fail against 
> the new TA. And the client can't perform EST anymore until factory reset. Or 
> is the expectation that it somehow will use another EST server for a second 
> try?

As you are pointing out, this is not a likely scenario because the cacerts 
response better include the root cert to authenticate the EST-coaps server 
going forward or the clients will be dead in the water. This text is added to 
address the RFC7030 (Section 4.1.1) language that explicitly says that the very 
first time you go from an implicit to an explicit TA you are supposed to 
teardown the connection after you get the cacerts response and start using the 
new TA going forward.

In some usecases we don't want to renegotiate DTLS in constrained heavily 
utilized mediums and establish a new connection for enrollment after a cacerts 
request, so I added this text to say that it is OK to keep the same connection 
but make sure you check that the server cert in this connection still validates 
against the just received cacerts.

> Sections 5.1, 5.7, 10.2 : word "he" is used to refer to client or server. 
> Maybe this should become "it" (not a person).

I went and made the sentences throughout the draft referring to client as "she" 
and the server "he". Better to be able to distinguish like that because "it" 
can be confusing.

I fixed all the rest. 

More details in the github issue 
https://github.com/SanKumar2015/EST-coaps/issues/146 

The diff is here 
https://github.com/SanKumar2015/EST-coaps/commit/e536875b9c6560562553de4ce4000b4ce35c83c7?diff=split
 

Rgs,
Panos


-Original Message-
From: Ace  On Behalf Of Esko Dijk
Sent: Tuesday, May 28, 2019 6:31 AM
To: Panos Kampanakis (pkampana) ; ace@ietf.org
Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt / additional 
review comments

Hello,

Thanks for the update! First, regarding the changes:

* 
   mapping of HTTP response codes to CoAP response codes.  The success
   code in response to an EST-coaps GET request (/cacerts, /csrattrs),
   is 2.05.  Similarly, 2.01 is used in response to EST-coaps POST
   requests (/simpleenroll, /simplereenroll, /serverkeygen).  Section 7
   of [RFC8075] maps 2.02 (Deleted) or 2.04 (Changed) to an HTTP 200 OK
   response, but 2.01 (Created) is more suitable for the creation of
   certificates in the context of EST-coaps.
-> 2.01 Created is now used as POST response.  While I agree that it sounds 
more logical to use 2.01 than 2.04 (since a certificate is created by the 
server, based on the CSR), there is the CoAP level expectation that when using 
2.01 the resource is created at the location of the request - that is, for 
example, at /sen. So if the client would do a GET /sen it would get the actual 
previously created certificate. (Which is not the case.) The text in RFC 7252 
that states this is "Otherwise, the resource was created at the request URI."   
So 2.01 is used to create new CoAP *resources* that can be found at the server 
using a subsequent GET request. And 2.04 is used to execute actions like 
'create x' , the result of which is returned in the response but otherwise not 
available anywhere on the server anymore. The latter is the case in the 
EST-coaps protocol flow as there's no way to GET the resulting certificate 
later on.
-> the resources in brackets should now be the short resource names, since we 
talk about EST-coaps resources not EST resources anymore. So "GET request 
(/crts, /att)" etc.

* "EST makes use of HTTP 204 responses when a resource is not available for the 
client."
-> EST states either 204 or 404 can be used; which in CoAP translates to 4.04 
Not Found  if the resource is not available to the client, i.e. does not exist. 
That seems the easiest translation here. Though the server could also send 2.05 
with an empty zero-length payload, to express that it has that function 
available but there is "nothing" there for the client.

* 2.04 SHOULD only be used in response to an EST-coaps
   POST when the response comes delayed in a separate (not Piggybacked)
   message after an empty 0.00 message (Section 5.7)
-> this seems strange, the response code remains the same whether separate 
response or piggybacked response is used. At this level of request/response, 
there's no need to try to detail this. I feel it only makes it more complex; 
the base CoAP protocol should handle piggybacked vs separate for both c

Re: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

[Panos Kampanakis (pkampana)]

Hi Esko,

Thank you again. Again a very elaborate review and found some good nits in the 
Delayed responses section. To make it easier I logged the issues and fixes here 
https://github.com/SanKumar2015/EST-coaps/issues/145 

The updated doc is here 
https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt
 and the diffs are here 
https://github.com/SanKumar2015/EST-coaps/commit/4ad5210faf624c67e1998da75ea051de616e91b1#diff-3a712edb43f6eace7fb1667328d65307
  

Rgs
Panos

-Original Message-
From: Esko Dijk  
Sent: Tuesday, May 21, 2019 6:31 PM
To: Panos Kampanakis (pkampana) ; ace@ietf.org
Cc: draft-ietf-ace-coap-...@ietf.org
Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

Hello Panos,

For the draft text I have a couple of more review remarks:

* page 8 first bullet: a previously issues client certificate could also 
expire, in some cases even without the client knowing. If the client then 
performs simple re-enrollment -- using its previous operational cert as 
authentication, what would happen?  I would expect the server MAY also want to 
use this certificate to authenticate the client. Because the purpose of the 
client connecting again to the EST server is to do simple re-enrollment, to get 
a new certificate.   Suppose a case where the handshake to the EST server fails 
because the EST server rejects the expired operational cert:  what would the 
client do now? It could be a certificate_expired message.  RFC 7030 provides no 
guidance in this matter; would EST-coaps need to define this? E.g. client 
SHOULD retry using the bullet #2 certificate (e.g. IDevID)?

* page 8 middle: "CoAP and DTLS can provide proof-of-identity for EST-coaps 
clients and servers with simple PKI messages as described in Section 3.1 of 
[RFC5272] "
Looking up this section it says: "The Simple PKI Request MUST NOT be used if a 
proof-of-identity needs to be included."   This seems to say the opposite of 
the above text?  This requires at least some more explanation.

* page 8 middle: "Moreover, channel-binding information for linking 
proof-of-identity with connection-based proof-of-possession is OPTIONAL for 
EST-coaps"  -> is it OPTIONAL for client, server, or both? I would assume it is 
OPTIONAL for both. If the (light-weight) client does not implement it and if 
the server does mandate it, the client can not connect to that server if its 
policy is set to "linking POP/identity required".

* page 14 top bullet: "The CoAP Options used are  " 
  -> the item Block could be expanded to "Block1, Block2" to capture the actual 
Option names.
  -> Location-Path is never used in any of the CoAP interactions defined; 
should be removed.

* Page 14 first 5.5 paragraph: "Similarly, 2.01, 2.02 or 2.04 MUST be used in 
response to EST POST requests"
  -> 2.01 Created is like HTTP 201, which is not used in EST - so can be 
removed here.
  -> 2.02 Deleted has no HTTP equivalent, so is not used in EST. It should be 
removed here.
  -> that leaves only 2.04 responses. However the text should say this is for 
successful (HTTP 200 or 202 in EST) responses , so suggestion is to change 
above sentence to: "Similarly, 2.04 MUST be used in a response to a successful 
EST POST request"

* page 14 bottom: "EST makes use of HTTP 204 and 404 responses when a resource 
is not  available for the client.  The equivalent CoAP codes to use in an 
EST-coaps responses are 2.04 and 4.04.  "
  -> CoAP 2.04 can only be used in responses to POST or PUT requests, not for 
GET responses.
  -> so in CoAP the server could either return 2.05 with empty payload 
(equivalent to HTTP 204), or return 4.04 (equivalent to HTTP 404)

* page 15 bottom: "The EST-coaps client and server MUST support Block2.  Block1 
MUST be supported for EST-coaps enrollment requests that exceed the Path MTU."
  -> could be clarified better, I expect a EST-coaps server MUST support Block1 
because that server doesn't know in advance how big the client's request 
payload is going to be and whether that client will use Block1.
  -> e.g. "The EST-coaps client and server MUST support Block2.  The EST-coaps 
server MUST support Block1. The EST-coaps client MUST support Block1 if it 
sends EST-coaps requests with an IP packet size that exceeds the Path MTU."

* page 16 example: the payloads are not indicating that each "{CSR req}" 
payload is different. I.e., a different block. It would be more clear if that 
is shown e.g. "{CSR 1}", "{CSR 2}", ... up to "{CSR N1+1}". The "req" string is 
not needed since the R in CSR already stands for request.

* page 17 example: see above payloads remark; and the following:
  --> what I find strange here is that a blockwise POST request ends with a 
5.03 response, and then the same request after that gives a 2.01

Re: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

[Panos Kampanakis (pkampana)]

Thanks Esko. 

Addressed in 
https://github.com/SanKumar2015/EST-coaps/blob/84ce0c1d5e768d40e97184214bae404da21bd050/draft-ietf-ace-coap-est.xml
 Two comments: 

> page 11 bottom requirement: " The client SHOULD use resource discovery when 
> he is unaware of the available  EST-coaps resources." - when an EST server is 
> known, this requirement does not really apply since the server always 
> supports .well-known EST resources.  So I read it as doing an RD discovery or 
> multicast CoAP discovery if the client doesn't known the EST server address.  
> Hope this is clear enough in the text and intended?

There are optional resources like /att, /skg and /skc that the server does not 
have to support, so that is what this sentence was referring to. 

> page 11 bottom: " It is up to the implementation to choose its resource 
> paths” -> seems not really the case, because the root resource structure is 
> forced by the specification. It could have been designed as free choice 
> (because it can be discovered anyway) but it is not.

The text says that the server MUST support the default /.well-known/est root 
resource and it SHOULD support resource discovery for non-default URIs (like 
/est or /est/ArbitraryLabel) or ports. In the latter case it is up to the 
server to decide the paths he makes its resources available at. That is what 
this sentence was referring to. But you are right; I realized that this 
sentence is redundant so I only kept "Throughout this document the example root 
resource of /est is used."

Will reupload the next iteration in a few days. 

Rgs,
Panos


-Original Message-
From: Esko Dijk  
Sent: Monday, May 20, 2019 2:31 AM
To: Panos Kampanakis (pkampana) ; ace@ietf.org
Cc: draft-ietf-ace-coap-...@ietf.org
Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

Thanks,

A few comments I had still on the discovery section - sorry to be late 
post-WGLC with this:

- page 10 bottom mentions "management data" - should say "management 
resources", or "EST resources" perhaps?
- page 10 bottom: " Upon success, the return payload will contain the root 
resource of the EST resources." - this is not true, since only the individual 
supported resources are returned. The root (e.g. "/est" in the examples) can be 
deduced from the response but it is never returned as one link format entry.
- page 11 top: the example is only correct for a secure (coaps://) discovery 
GET request, I think this could be mentioned in text or indicated in the 
request line.
- page 11 bottom requirement: " The client SHOULD use resource discovery when 
he is unaware of the available  EST-coaps resources." - when an EST server is 
known, this requirement does not really apply since the server always supports 
.well-known EST resources.  So I read it as doing an RD discovery or multicast 
CoAP discovery if the client doesn't known the EST server address.  Hope this 
is clear enough in the text and intended?
- page 11 bottom: "he supports" -> "it supports"
- page 11 bottom: " It is up to the implementation to choose its resource 
paths” -> seems not really the case, because the root resource structure is 
forced by the specification. It could have been designed as free choice 
(because it can be discovered anyway) but it is not.

Best regards
Esko

-Original Message-
From: Ace  On Behalf Of Panos Kampanakis (pkampana)
Sent: Friday, May 17, 2019 17:36
To: ace@ietf.org
Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

Hi all, 

This latest update addresses feedback while in WGLC" 
- the comments by Hannes and Esko related to RNG and server-side key gen. It 
aims to prevent misunderstandings that random numbers are not needed any more 
if server-side key gen is used. 
- the nits with "/crt" instead of "/crts" pointed out by Esko. 

The diff is here 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-11.txt 

Thanks,
Panos

-Original Message-
From: Ace  On Behalf Of internet-dra...@ietf.org
Sent: Friday, May 17, 2019 11:31 AM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : EST over secure CoAP (EST-coaps)
Authors : Peter van der Stok
  Panos Kampanakis
  Michael C. Richardson
  Shahid Raza
Filename: draft-ietf-ace-coap-est-11.txt
Pages   : 48
Date: 2019-05-17

Abstract:
   Enrollment over Secure Transport (EST) is used as a certificate
   provisioning protocol over HTTPS.  Low-resource de

Re: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

[Panos Kampanakis (pkampana)]

Hi all, 

This latest update addresses feedback while in WGLC" 
- the comments by Hannes and Esko related to RNG and server-side key gen. It 
aims to prevent misunderstandings that random numbers are not needed any more 
if server-side key gen is used. 
- the nits with "/crt" instead of "/crts" pointed out by Esko. 

The diff is here 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-11.txt 

Thanks,
Panos

-Original Message-
From: Ace  On Behalf Of internet-dra...@ietf.org
Sent: Friday, May 17, 2019 11:31 AM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : EST over secure CoAP (EST-coaps)
Authors : Peter van der Stok
  Panos Kampanakis
  Michael C. Richardson
  Shahid Raza
Filename: draft-ietf-ace-coap-est-11.txt
Pages   : 48
Date: 2019-05-17

Abstract:
   Enrollment over Secure Transport (EST) is used as a certificate
   provisioning protocol over HTTPS.  Low-resource devices often use the
   lightweight Constrained Application Protocol (CoAP) for message
   exchanges.  This document defines how to transport EST payloads over
   secure CoAP (EST-coaps), which allows constrained devices to use
   existing EST functionality for provisioning certificates.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-coap-est-11
https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-11


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] Use of /crt vs /crts in draft-ietf-ace-coap-est

[Panos Kampanakis (pkampana)]

Good catch Esko. Thanks.
We had three leftover “/crt” that should have been “/crts”. Will be fixed in 
the iteration to be submitted tomorrow.


From: Ace  On Behalf Of Esko Dijk
Sent: Thursday, May 16, 2019 5:28 AM
To: ace@ietf.org; draft-ietf-ace-coap-...@ietf.org
Subject: [Ace] Use of /crt vs /crts in draft-ietf-ace-coap-est

Dear authors,

In the draft both the paths /crt and /crts are used – this appears to be 
incorrect. Should it /crts  always ?

Best regards
Esko

Esko Dijk IoT Consultancy |  Email/Skype: 
esko.d...@iotconsultancy.nl

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

Re: [Ace] EST over CoAP: Randomness

[Panos Kampanakis (pkampana)]

Agreed Hannes and Esko.

For completeness, here is how the updated text looks like. It should cover what 
we discussed in this thread.

~
5.8. Server-side Key Generation

In scenarios where it is desirable that the server generates the private key, 
server-side key generation should be used. Such scenarios could be when it is 
considered more secure to generate at the server the long-lived random private 
key that identifies the client, or when the resources spent to generate a 
random private key at the client are considered scarce, or when the security 
policy requires that the certificate public and corresponding private key are 
centrally generated and controlled. Of course, that does not eliminate the need 
for proper random numbers for various protocols like (D)TLS (Section 10.1).
[ … ]

10.1. EST server considerations
[ … ]
Modern security protocols require random numbers to be available during the 
protocol run, for example for nonces, ephemeral EC Diffie-Hellman key 
generation. This capability to generate random numbers is also needed when the 
constrained device generates the private key (that corresponds to the public 
key enrolled in the CSR). When server-side key generation is used, the 
constrained device depends on the server to generate the private key randomly, 
but it still needs locally generated random numbers for use in security 
protocols, as explained in Section 12 of [RFC7925]. Additionally, the transport 
of keys generated at the server is inherently risky. Analysis SHOULD be done to 
establish whether server-side key generation enhances or decreases the 
probability of identity stealing.

It is important to note that sources contributing to the randomness pool used 
to generate random numbers on laptops or desktop PCs are not available on many 
constrained devices, such as mouse movement, timing of keystrokes, air 
turbulence on the movement of hard drive heads, as pointed out in [PsQs]. Other 
sources have to be used or dedicated hardware has to be added. Selecting 
hardware for an IoT device that is capable of producing high-quality random 
numbers is therefore important.
[ … ]
~

I am planning to reupload by the end of the week.

Rgs,
Panos


From: Hannes Tschofenig 
Sent: Tuesday, May 14, 2019 3:28 PM
To: Esko Dijk ; Panos Kampanakis (pkampana) 
; ace@ietf.org
Subject: RE: [Ace] EST over CoAP: Randomness

Esko,

your line of thought makes sense to me. I leave it to Panos to enhance the text.

Ciao
Hannes

From: Esko Dijk 
mailto:esko.d...@iotconsultancy.nl>>
Sent: Dienstag, 14. Mai 2019 11:57
To: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>; Panos Kampanakis 
(pkampana) mailto:pkamp...@cisco.com>>; 
ace@ietf.org<mailto:ace@ietf.org>
Subject: RE: [Ace] EST over CoAP: Randomness

Hi Hannes,

Agree. The draft is already referencing RFC 7925, so it could additionally 
reference Section 12 (https://tools.ietf.org/html/rfc7925#section-12) which 
explains that randomness is also needed for all DTLS handshakes. What I mention 
about “being able to trust the randomness level” is then maybe a more 
psychological requirement rather than technical. A powerful server with RTC 
just sounds more capable to do private key generation than an IoT device, which 
is why server-side keygen may be preferred ;)

Esko

From: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>
Sent: Tuesday, May 14, 2019 18:46
To: Esko Dijk 
mailto:esko.d...@iotconsultancy.nl>>; Panos 
Kampanakis (pkampana) mailto:pkamp...@cisco.com>>; 
ace@ietf.org<mailto:ace@ietf.org>
Subject: RE: [Ace] EST over CoAP: Randomness

Hi Esko,

good to hear from you.


  *   Another reason for server-side keygen can be that an IT 
department/manager wants it that way. There could be a policy that the keypairs 
for all domain certificates must be created by the systems under direct control 
of the IT department. (E.g. to comply with other policies or to be able to 
trust the randomness level. Or just because that was the way it always has been 
when PCs were provisioned with certificates.)  This could be listed as an 
additional reason.

For readers interested in making informed decisions I believe it is worthwhile 
to point out that they need random number generation capabilities on IoT 
devices – not just for the private key generation in context of the EST 
exchange. I fear that some people, including IT managers, just glance over the 
details and focus on isolated aspects. I am sure you agree with me that this 
would be a too simplistic view.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidentia

Re: [Ace] [EXTERNAL] Re: EST over CoAP: Randomness

[Panos Kampanakis (pkampana)]

The draft is not recommending against RNGs in any way and hopefully there will 
be no room for such misunderstandings in the updated text.
Panos


From: Ace  On Behalf Of Damm, Benjamin
Sent: Wednesday, May 15, 2019 10:29 AM
To: Hannes Tschofenig ; Paul Duffy (paduffy) 
; ace@ietf.org
Subject: Re: [Ace] [EXTERNAL] Re: EST over CoAP: Randomness

Low-throughput RNG should be a must for IoT. Certainly in our environment 
devices that are unable to generate keys would be unacceptable. Hopefully we 
won't codify such an abomination in any protocol.
-Ben


Benjamin Damm
Cell: +1-415-297-5474
Web: https://Itron.com


From: Ace mailto:ace-boun...@ietf.org>> on behalf of 
Hannes Tschofenig mailto:hannes.tschofe...@arm.com>>
Sent: Tuesday, May 14, 2019 4:29 PM
To: Paul Duffy; ace@ietf.org
Subject: [EXTERNAL] Re: [Ace] EST over CoAP: Randomness

Hi Paul,

My understanding from reading the draft text was that the "cost" was actually 
talking about "energy cost" rather than "monetary cost".
The monetary cost may also be interesting.

It is difficult to judge the extra cost of a RNG in an MCU because
(a) you rarely find an MCU with and without MCU (keeping all other features the 
same),
(b) even if you find one there are other factors that impact the cost (such as 
popularity of a particular MCU),
(c) RNG features are often provided with other features (such as SHA256 and AES 
in hardware), and
(d) cost and price of an MCU are different aspects.

Ciao
Hannes

-Original Message-
From: Paul Duffy mailto:padu...@cisco.com>>
Sent: Dienstag, 14. Mai 2019 15:08
To: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>; 
ace@ietf.org
Subject: Re: [Ace] EST over CoAP: Randomness


On 5/9/2019 10:42 AM, Hannes Tschofenig wrote:
> I believe we should encourage developers to pick the correct hardware for the 
> task rather than making them believe we have come up with solutions that 
> allow them to get away without a hardware-based RNG.
>
> I also do not believe the statement that random number key generation is 
> costly. Can you give me some number?

Strong agreement. The added cost for hw based RNG is ever decreasing. Last time 
I checked it was on the order of 50 cents @ Q 10k? It has likely fallen since. 
Confirm with Atmel etc.

Cheers


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Ace mailing list
Ace@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ace&d=DwICAg&c=pqcuzKEN_84c78MOSc5_fw&r=GYGBKg0XeEBnyXmKSs4zZ6DBOYB5tLwwWSrFtYahCvs&m=dH_774yB0_IzrwFvyY1Iio9qthZz-eV34lbAEv3Y3kY&s=WChHRMoeN8IO06GYZPU1yk3uh76KEHoR7q9Hx7nhGcs&e=
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] EST over CoAP: Randomness

[Panos Kampanakis (pkampana)]

Hi Hannes,

> Hence, I believe it would be better to first shorten the following paragraph 
> to a single line:

Note that this paragraph was added from feedback in the review process just to 
motivate server-side keygen. Given that your proposed text below practically 
moves the points made in this paragraph in the Sec considerations section, I am 
all for shortening the paragraph. I was thinking something close to what you 
wrote, but just to keep a couple of phrases as motivation about the feature 
without creating an inaccurate sense of security:
~~
5.8.  Server-side Key Generation

  In scenarios where it is desirable that the server obtains access to the 
private key the server-side
  key generation should be used. Such scenarios could be when it is considered 
more secure to
  generate at the server a long-lived random private key that identifies the 
client or when the
  resources spent to generate a random private key at the client are considered 
scarce.
~~

> In the security consideration section I would add a new section somewhere 
> that talks about the random number generation.

I like your text. I will add it  with minor changes in orange.
~~
   Modern security protocols require random numbers to be available during
   the protocol run, for example for nonces, ephemeral EC Diffie-Hellman key
   generation. This capability to generate random numbers is also needed
   when the constrained device generates the private key (that corresponds
   to the public key enrolled in the CSR). When server-side key generation is
   used, the constrained device depends on the server to generate the
   private key randomly, but it still needs locally generated random numbers
   for use in security protocols, such as DTLS.

   It is important to note that sources contributing to the randomness
   pool used to generate random numbers on laptops or desktop PCs
   are not available on many constrained devices, such as mouse
   movement, timing of keystrokes, air turbulence on the
   movement of hard drive heads, as pointed out in [PsQs].  Other
   sources have to be used or dedicated hardware has to be added.
   Selecting hardware for an IoT device that is capable of producing
   high-quality random numbers is therefore important.
~~

I hope it makes sense.

Panos


-Original Message-
From: Hannes Tschofenig 
Sent: Friday, May 10, 2019 4:58 AM
To: Panos Kampanakis (pkampana) ; ace@ietf.org
Subject: RE: [Ace] EST over CoAP: Randomness

Hi Panos,

I had argued earlier that this feature shouldn't be in the draft but it seems 
that I will not get there.

Hence, I believe it would be better to first shorten the following paragraph to 
a single line:

FROM:

"
5.8.  Server-side Key Generation

   Constrained devices sometimes do not have the necessary hardware to
   generate statistically random numbers for private keys and DTLS
   ephemeral keys.  Past experience has also shown that low-resource
   endpoints sometimes generate numbers which could allow someone to
   decrypt the communication or guess the private key and impersonate as
   the device [PsQs] [RSAorig].  Additionally, random number key
   generation is costly, thus energy draining. Even though the random
   numbers that constitute the identity/cert do not get generated often,
   an endpoint may not want to spend time and energy generating
   keypairs, and just ask for one from the server.

   In these scenarios, server-side key generation can be used.
   
"

TO:

"
5.8.  Server-side Key Generation

  In scenarios where it is desirable that the server obtains access to the 
private key the server-side
  key generation should be used.
  
"

In the security consideration section I would add a new section somewhere that 
talks about the random number generation.

"
Random Number Generation

   Modern security protocol require random numbers to be available during
   the protocol run, for example for nonces, ephemeral Diffie-Hellman key
   generation. When the private key is generated by the IoT device then
   the capability to generate random numbers is also needed. When server-
   side key generation is used then the IoT device still needs random numbers
   for use in security protocols, such as DTLS.

   It is important to note that sources contributing to the randomness
   pool on laptops or desktop PCs are not available on many IoT devices,
   such as mouse movement, timing of keystrokes, air turbulence on the
   movement of hard drive heads, as pointed out in [PsQs].  Other
   sources have to be found or dedicated hardware has to be added.
   Selecting hardware for an IoT device that is capable of producing
   high-quality random numbers is therefore important.
"

Does this make sense?

Ciao
Hannes

PS: Note that I omitted the reference to RSA because ECC is so much more 
popular in the IoT space that there is no point in dealing with RSA these days.




--

Re: [Ace] EST over CoAP: Randomness

[Panos Kampanakis (pkampana)]

Thanks Hannes.
Before I try to address it, can you help me understand what you are proposing. 
To amend this paragraph maybe?

-Original Message-
From: Ace  On Behalf Of Hannes Tschofenig
Sent: Thursday, May 09, 2019 10:43 AM
To: ace@ietf.org
Subject: [Ace] EST over CoAP: Randomness

Hi all,

I am still a bit unhappy about this paragraph:

"
   Constrained devices sometimes do not have the necessary hardware to
   generate statistically random numbers for private keys and DTLS
   ephemeral keys.  Past experience has also shown that low-resource
   endpoints sometimes generate numbers which could allow someone to
   decrypt the communication or guess the private key and impersonate as
   the device [PsQs] [RSAorig].  Additionally, random number key
   generation is costly, thus energy draining.
"

If you get hardware that does not have a hardware-based RNG then you are in 
trouble. The main security protocols we look into do not work without a source 
of randomness. Hence, getting the certificate & private key from the server 
will not get you too far.

I believe we should encourage developers to pick the correct hardware for the 
task rather than making them believe we have come up with solutions that allow 
them to get away without a hardware-based RNG.

I also do not believe the statement that random number key generation is 
costly. Can you give me some number?

The references to [PsQs] [RSAorig] are IMHO also not appropriate because they 
are conveying a different message (at least that's my understanding from 
reading them). The message is that you have to be careful with designing and 
using a random number generator on embedded systems because the sources of 
entropy may just not be there (like keyboards, harddisk drive, processing 
scheduling, etc.).

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
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] I-D Action: draft-ietf-ace-coap-est-10.txt

[Panos Kampanakis (pkampana)]

This iteration addresses the recent WGLC feedback from Klaus and Jim. A summary 
of the issues addressed can be found here 
https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=is%3Aissue+%22WGLC+review+2%2F27%2F2019%22
 

It should also cover all other feedback we have received as well.

Panos


-Original Message-
From: Ace  On Behalf Of internet-dra...@ietf.org
Sent: Friday, March 08, 2019 8:54 AM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-10.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : EST over secure CoAP (EST-coaps)
Authors : Peter van der Stok
  Panos Kampanakis
  Michael C. Richardson
  Shahid Raza
Filename: draft-ietf-ace-coap-est-10.txt
Pages   : 48
Date: 2019-03-08

Abstract:
   Enrollment over Secure Transport (EST) is used as a certificate
   provisioning protocol over HTTPS.  Low-resource devices often use the
   lightweight Constrained Application Protocol (CoAP) for message
   exchanges.  This document defines how to transport EST payloads over
   secure CoAP (EST-coaps), which allows constrained devices to use
   existing EST functionality for provisioning certificates.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-coap-est-10
https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-10


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] WGLC for draft-ietf-ace-coap-est

[Panos Kampanakis (pkampana)]

Thanks Klaus. 

OK about waiting for confirmation on ports returned in discovery and RFC6690.

> wouldn't it also be possible to configure the client with the whole URI 
> containing the three parts directly?

Yes, that is perfectly possible. I don't think the draft is forbidding the 
whole URL being configured instead of a host:port:ArbitraryLabel tuple. 

> I really don't see why the EST-coaps specification needs to provide examples 
> for basic CoAP features that don't play a crucial role in the application.

Understood what you meant. I removed the normative "MUST" and replaced the 
language to more explicitly state the "RECOMMENDED" for implementers. 

> Specifically on Uri-Host and Uri-Port: RFC 7252 notes that "If the value of 
> an option is intended to be this default value, the option SHOULD NOT be 
> included in the message." [1] So your example actually violates this 'SHOULD 
> NOT'...

For consistency we now use FQDNs in all our /crt examples, so I think the A.1 
is more justified. 

If you want to check the updated draft use 
https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt
 

Rgs,
Panos


-Original Message-----
From: Klaus Hartke  
Sent: Tuesday, March 05, 2019 8:45 AM
To: Panos Kampanakis (pkampana) 
Cc: ace@ietf.org; Jim Schaad 
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est

Panos Kampanakis wrote:
> > But can't the client just be configured out-of-band with the URIs directly?
>
> That is right. We could mandate only .well-known URIs. But I think we 
> ought to let a deployment use non-default URIs. [...]

I was aiming at something different, but, re-reading my question, my question 
wasn't very clear. Let me try again.

In draft-ietf-ace-coap-est-09, a client can do discovery. For that, it needs to 
know the host name (or IP address) and port number of a CoAP server. It then 
constructs the URI  and then gets a 
list of links to the EST resources. The host name and port number must come 
from somewhere -- e.g., from configuration or from some other discovery 
process. I'm quite happy with this.

Then you were saying that, in some cases, this discovery step is 
unnecessary/wasteful. A client would instead need to know the host name (or IP 
address) and port number of a CoAP server as well as an ArbitraryLabel. It 
would then construct the URI 
 and could 
immediately start interacting with that resource. Again, the host name, port 
number and ArbitraryLabel must come from somewhere. You were saying that they 
come from configuration.

My question is: If host name, port number and ArbitraryLabel can come from 
configuration, from which the client constructs 
, wouldn't it also 
be possible to configure the client with the whole URI containing the three 
parts directly?

> > 5.1 "Discoverable port numbers can be returned in the response payload." -- 
> > Now I'm wondering if that's actually permitted by RFC 6690...
>
> [...] but I think the example is OK to include the port.

I'm not sure. RFC 6690 is really weird. Let me get back to you on this.

> > 5.4 "All EST-coaps request messages expect an acknowledgement (with a 
> > response payload); EST-coaps requests are confirmable CON CoAP messages." 
> > -- This seems to be a matter of implementation quality and should not be a 
> > requirement for interoperability. I suggest to remove this.
>
> We want to make use of Delayed responses. There are cases where the CA takes 
> time to generate the cert/keypair, and in that case it needs to signal the 
> delay with a Max-Age or Empty ACK. That is why we use CON. The text 
> justification does not explain explicitly, but we didn't want to clutter the 
> wording, so we kept it simple.

You're mixing up protocol specification and implementation guidance.
On the protocol specification side, both clients and servers are free to choose 
if they want to use confirmable or non-confirmable messages.
And an application should not make any restrictions on that. On the 
implementation guidance side, I think it makes a lot of sense to choose delayed 
responses here. But implementation guidance should be clearly marked as such, 
as not to create the impression that implementations can only use certain 
messages types or can rely on only certain messages types being used.

> > A.1. "The Uri-Host and Uri-Port Options can be omitted" -- But they aren't 
> > in this example. Since it's not important for the example, maybe just 
> > remove Uri-Host and Uri-Port from the example and also this paragraph?
>
> I wanted to keep it in there. We explain that it can be assumed from DTLS if 
> omitted, but I think it is worth to show how the option would be included. I 
> had trouble finding a COAP Uri-H

Re: [Ace] WGLC for draft-ietf-ace-coap-est

[Panos Kampanakis (pkampana)]

Thanks again Klaus. 

We addressed your 2nd WGLC review comments in 
https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=%22Klaus+WGLC+review+2%2F27%2F2019%22
   I think that is all of them. The latest version of the text is 
https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt
 

We are planning to reupload this week, please let us know if there is more 
feedback. 

Below I am addressing the rest of your questions or things I didn't think 
needed an update in the draft. 

> But can't the client just be configured out-of-band with the URIs directly?

That is right. We could mandate only .well-known URIs. But I think we ought to 
let a deployment use non-default URIs. For example some usecase might not want 
to send the .well-known in the URI to save transmission bytes and thus use a 
custom short URI. If the URI change takes place after deployment client will 
find that out with a discovery. Similarly, a usecase might initially not 
support one of the optional requests like server-side keygen. If the server 
adds support sometime in the future, the client could find out using discovery. 
And we ought to let the client be able to recover in case the well-known 
request URI fails for some reason and he wants to see what is supported by the 
server.That is why we thought it is still worth to keep the .well-known URIs 
along with the discovery.  

> 5.1 "The first three lines of the discovery response above MUST be returned 
> if the server supports resource discovery." -- ...if it supports EST? I mean, 
> if a server has a /.well-known/core resource and implements a draft, is there 
> a reason why it wouldn't include the EST resources in the /.well-known/core 
> representation? If it doesn't want to offer two sets of paths, it can simply 
> return this:
>   ;rt="ace.est.crts",
>   ;rt="ace.est.sen",
>   ;rt="ace.est.sren",
>   ;rt="ace.est.att",
>   ;rt="ace.est.skg",
>   ;rt="ace.est.skc"

Yes. The point of the "MUST" is that since crts, sen and sren are mandatory you 
are supposed to give them out when you support resource discovery for 
EST-coaps. If you are asking why don't we just support discovery and not the 
default ./well-known path, the reason that there might be cases where discovery 
is wasteful in terms of transmission and client code to parse the responses. 
These cases will never discover anything, they will just use the well-known 
path. 

> 5.1 "Discoverable port numbers can be returned in the response payload." -- 
> Now I'm wondering if that's actually permitted by RFC 6690...

I saw 
<http://www.example.com/sensors/t123>;anchor="/sensors/temp";rel="describedby 
in a couple of examples in RFC6690. I also saw it in 
https://tools.ietf.org/html/draft-ietf-core-resource-directory that shows 
"Res: 2.05 Content
   ;rt="temperature";
  anchor="coap://[2001:db8:3::123]:61616"
Jim suggested the anchor is not needed, but I think the example is OK to 
include the port. 

> 5.4 "All EST-coaps request messages expect an acknowledgement (with a 
> response payload); EST-coaps requests are confirmable CON CoAP messages." -- 
> This seems to be a matter of implementation quality and should not be a 
> requirement for interoperability. I suggest to remove this.

We want to make use of Delayed responses. There are cases where the CA takes 
time to generate the cert/keypair, and in that case it needs to signal the 
delay with a Max-Age or Empty ACK. That is why we use CON. The text 
justification does not explain explicitly, but we didn't want to clutter the 
wording, so we kept it simple. 

> 7. "Parameters" -- This section should be a non-normative implementation note 
> or removed altogether.

Yes, we removed all normative language from this section. 

> A.1. "The Uri-Host and Uri-Port Options can be omitted" -- But they aren't in 
> this example. Since it's not important for the example, maybe just remove 
> Uri-Host and Uri-Port from the example and also this paragraph? 

I wanted to keep it in there. We explain that it can be assumed from DTLS if 
omitted, but I think it is worth to show how the option would be included. I 
had trouble finding a COAP Uri-Host and port example online when I was 
searching and thus this is useful as a reference as well. 

Rgs,
Panos 


-Original Message-
From: Klaus Hartke  
Sent: Wednesday, February 27, 2019 11:39 AM
To: Panos Kampanakis (pkampana) 
Cc: ace@ietf.org; Jim Schaad 
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est

Hi Panos,

thanks for addressing all issues so thoroughly. I've performed another quick 
review of draft-ietf-ace-coap-est-09.

5.1. The discovery looks much better now! I think you had

Re: [Ace] WGLC for draft-ietf-ace-coap-est

[Panos Kampanakis (pkampana)]

Thanks Ben.

I addressed your content-format order comment in the next iteration of the 
draft by saying 

>   The two representations (each consisting of two CBOR array items) do 
>   not have to be in a particular order since each representation is 
>   preceeded by its Content-Format ID.

Panos


-Original Message-
From: Benjamin Kaduk  
Sent: Sunday, February 24, 2019 7:08 PM
To: Panos Kampanakis (pkampana) 
Cc: Klaus Hartke ; Jim Schaad ; 
ace@ietf.org
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est

On Fri, Feb 22, 2019 at 09:00:05PM +0000, Panos Kampanakis (pkampana) wrote:
> Hi Klaus,
> 
> Thanks for the thorough review. 
> 
> All your issues identified are tracked here 
> https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=is%3
> Aissue+%22Klaus+WGLC%22 . We tried to address all of them. The fixes 
> we are putting in are spelled out in the github issues themselves. The 
> actual latest version of the draft is 
> https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-c
> oap-est.txt
> 
> After proof reading the draft one more time we will upload early next week. 
> 
> Below I am answering some of the questions you asked in your review. 
> 
> > 4. -- Is this section about the generated certificates or the DTLS 
> > connection between the client and the server? If the latter, this section 
> > is weird, because RFC 7252 already does define MTI cipher suites and 
> > extensions, and I see no reason why an application layered on top of CoAP 
> > needs to restate all of that.
> 
> This section describes how the (D)TLS profile defined in RFC7925 is used by 
> EST-coaps. It was asked by the original ACE co-chair to show conformance with 
> ACE profiles.  It touches on the client server authentication, the tunnel 
> ciphersuites. It explains how the EST-coaps data exchange is secured thereby 
> preventing eavesdropping, tampering, and message forgery. We wanted to spell 
> out for implementers which parts of RFC7925 they should take into 
> consideration instead of just pointing them to RFC7925 or RFC7252 etc. 
> 
> > 4. "The authentication of the EST-coaps client MUST be with a client 
> > certificate in the DTLS handshake." -- Why? Why can't a client communicate 
> > with a server using any other secure mechanism with client authentication? 
> > Or is this just the MTI mechansim?
> 
> The issue is that EST mandates HTTP Basic or Digest Auth and/or client cert 
> auth. HTTP Auth is not defined for COAP application as far as we know. So, 
> for EST-coaps, the only viable authentication method is mutual cert auth. 
> Other client auth methods could be defined, but are outside the scope of this 
> draft. 

I think there is enough flexibility in our specifying a "new transport for EST" 
that we do not need to be strictly bound to the EST-mandated authentication 
mechanisms.  That said, I'm not sure I have any other options handy than mutual 
cert auth...

> > 5.1. "Arbitrary Labels are usually defined and used by EST CAs in order to 
> > route client requests to the appropriate certificate profile." -- I assume 
> > that a client needs to construct URIs from the well-known path 
> > "/.well-known/est", the Arbitrary Label and one of the suffixes. How does a 
> > client determine which Arbitrary Label to use?
> 
> That is configured on the client out of band depending on the CA that 
> generates the certs. It is outside the scope of EST or EST-coaps. 
> 
> > 5.1. "The EST-coaps server URIs, obtained through discovery of the 
> > EST-coaps root resource(s) as shown below, are of the form:" -- If a client 
> > discovers the URIs from "/.well-known/core" (annotated with "ace.est.crts", 
> > "ace.est.sen", etc.), is this table 1 still needed? If not, I would 
> > recommend that only the 'rt'  values are standardized ("ace.est.crts", 
> > "ace.est.sen", etc.) and all paths are left to the implementation, in 
> > accordance with BCP 190.
> 
> We intend to require /.well-known URIs so that resource discovery is not 
> mandatory for pre-configured client deployments. Discovery is optional when 
> non-default URIs are needed to save URI space. Feel free to check the text in 
> https://github.com/SanKumar2015/EST-coaps/issues/123 where I edited the 
> resource discovery text to make it clearer. 
> 
> > 5.1. "Discoverable port numbers MAY be returned in the  of the 
> > payload [I-D.ietf-core-resource-directory]." -- What does this mean?
> > And what does Resource Directory have to do with EST?
> 
> We needed a way to be able tell the client that the resource is hoste

Re: [Ace] WGLC for draft-ietf-ace-coap-est

[Panos Kampanakis (pkampana)]

Hi Klaus,

Thanks for the thorough review. 

All your issues identified are tracked here 
https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=is%3Aissue+%22Klaus+WGLC%22
 . We tried to address all of them. The fixes we are putting in are spelled out 
in the github issues themselves. The actual latest version of the draft is 
https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt
 

After proof reading the draft one more time we will upload early next week. 

Below I am answering some of the questions you asked in your review. 

> 4. -- Is this section about the generated certificates or the DTLS connection 
> between the client and the server? If the latter, this section is weird, 
> because RFC 7252 already does define MTI cipher suites and extensions, and I 
> see no reason why an application layered on top of CoAP needs to restate all 
> of that.

This section describes how the (D)TLS profile defined in RFC7925 is used by 
EST-coaps. It was asked by the original ACE co-chair to show conformance with 
ACE profiles.  It touches on the client server authentication, the tunnel 
ciphersuites. It explains how the EST-coaps data exchange is secured thereby 
preventing eavesdropping, tampering, and message forgery. We wanted to spell 
out for implementers which parts of RFC7925 they should take into consideration 
instead of just pointing them to RFC7925 or RFC7252 etc. 

> 4. "The authentication of the EST-coaps client MUST be with a client 
> certificate in the DTLS handshake." -- Why? Why can't a client communicate 
> with a server using any other secure mechanism with client authentication? Or 
> is this just the MTI mechansim?

The issue is that EST mandates HTTP Basic or Digest Auth and/or client cert 
auth. HTTP Auth is not defined for COAP application as far as we know. So, for 
EST-coaps, the only viable authentication method is mutual cert auth. Other 
client auth methods could be defined, but are outside the scope of this draft. 
 
> 5.1. "Arbitrary Labels are usually defined and used by EST CAs in order to 
> route client requests to the appropriate certificate profile." -- I assume 
> that a client needs to construct URIs from the well-known path 
> "/.well-known/est", the Arbitrary Label and one of the suffixes. How does a 
> client determine which Arbitrary Label to use?

That is configured on the client out of band depending on the CA that generates 
the certs. It is outside the scope of EST or EST-coaps. 

> 5.1. "The EST-coaps server URIs, obtained through discovery of the EST-coaps 
> root resource(s) as shown below, are of the form:" -- If a client discovers 
> the URIs from "/.well-known/core" (annotated with "ace.est.crts", 
> "ace.est.sen", etc.), is this table 1 still needed? If not, I would recommend 
> that only the 'rt'  values are standardized ("ace.est.crts", "ace.est.sen", 
> etc.) and all paths are left to the implementation, in accordance with BCP 
> 190.

We intend to require /.well-known URIs so that resource discovery is not 
mandatory for pre-configured client deployments. Discovery is optional when 
non-default URIs are needed to save URI space. Feel free to check the text in 
https://github.com/SanKumar2015/EST-coaps/issues/123 where I edited the 
resource discovery text to make it clearer. 

> 5.1. "Discoverable port numbers MAY be returned in the  of the payload 
> [I-D.ietf-core-resource-directory]." -- What does this mean?
> And what does Resource Directory have to do with EST?

We needed a way to be able tell the client that the resource is hosted on 
another port but the reference to  I-D.ietf-core-resource-directory is removed 
after Jim last WGLC We no longer use anchors, just an href in the payload. 
Check out https://github.com/SanKumar2015/EST-coaps/issues/136  

> 5.2. "Table 2 specifies the mandatory-to-implement or optional implementation 
> of the est-coaps functions." -- How does a client discover which functions 
> are implemented?

Client pre-configuration or optionally resource discovery. We added a reference 
to the discovery section. 

> 5.3. "Content-Format TBD287 can be used in place of 281" -- It's a bit 
> difficult to see what TBD287 and 281 mean without scrolling all the way down 
> and scrolling back up. Maybe include the table here to make the section 
> easier to read?

I don't think that is necessary as we are stating that TBD287 and 281 "to carry 
a single certificate instead of a PKCS#7 container in a /crts, /sen, /sren or 
/skg response ". Also there is a reference to the IANA section in the paragraph 
above. 

> 5.7. "After a delay of Max-Age, the client SHOULD resend the identical CSR to 
> the server." -- Just for my understanding: Does the submission of a specific 
> CSR always lead to the same output, or can it happen (e.g., if the client 
> submits an identical CSR weeks or months later) that the client would get a 
> different output?

Submitting the same CSR will likely give the client a diff

Re: [Ace] Embedded Content Types

[Panos Kampanakis (pkampana)]

OK, I was clearly misunderstanding what you were proposing. 
I can see that second URI working fine without affecting existing systems. Will 
update the draft. 


-Original Message-
From: Jim Schaad  
Sent: Thursday, February 21, 2019 10:55 PM
To: Panos Kampanakis (pkampana) ; 'Carsten Bormann' 

Cc: 'ace' ; 'Klaus Hartke' 
Subject: RE: [Ace] Embedded Content Types

Panos,

Someplace you are not understanding what I am saying.  


> -----Original Message-
> From: Panos Kampanakis (pkampana) 
> Sent: Thursday, February 21, 2019 7:21 PM
> To: Jim Schaad ; 'Carsten Bormann' 
> 
> Cc: 'ace' ; 'Klaus Hartke' 
> Subject: RE: [Ace] Embedded Content Types
> 
> 
> That comes with a set of problems. A simplification needs to take 
> place. It is probably better to just mandate one content-type for cert 
> to get away without complicated combined content types. We don't need 
> to support
> TBD287 and 281 in the embedded responses. It makes more sense to not 
> do so.
> 
> As for why, there are a three reasons I can think of:
> 1) Two separate URIs means we are adding state tracking for the CA. 
> The CA now needs to support
> - EST that says "give me the key and a cert all at once and then 
> forget about it".
> - EST-coaps that says "give me a key. Remember this key/cert pair and 
> serve the certificate until I decide to come back and get it". Now 
> imagine I have
> 1 of endpoints enrolling. The server keeps state for all of them 
> and cannot forget them until he gets the equivalent requests. And 
> then, what happens if a cert is lost on the way back? The CA is 
> supposed to remember the key / cert for some time. There is a DoS vector 
> right there.

I don't see this as occurring because that is not what I am suggestion.  In my 
world view there is no difference between doing the following:

POST /est/skg/XXX
POST /est/skg?ct=XXX

In both cases the client posts the CSR to the CA and returns a multipart 
response.  The response contains the private key and the certificate.  I would 
say that the difference between /est/skg and /est/skgXXX is that the first 
returns the certificate as a PKCS#2 and the second returns it as a bare 
certificate.  In both cases how one wraps the key (encrypted or not) is going 
to be based on either an attribute in the CSR or a decision on the part of the 
CA.  (It could be either encrypt w/ the key just given or don't issue 
certificate because you did not give me the needed attribute.)

If the CA does not need to spend a long time doing the processing of the 
certificate creation, then there is no need for a cache.  Using this method 
means that an RA which is using a current CA would send the post to the normal 
location on the CA and then convert the certificate to from a PKCS#7 to a plain 
certificate for the second URI, just like what you are probably thinking for 
the query parameter.  

By the way - you still have this same potential DOS for the case of manual 
intervention where the CA needs to keep the approval of the CSR around and 
match it against the request the second time it comes in when you say - ask me 
again later.  The expectation is that there would be a "limited" number of 
requests kept or for a limited amount of time.

> 
> 2) One more challenge with two URIs is that the client needs to 
> somehow signal in the 2nd request to the server to tell him what 
> key/cert he is expecting to get, so there is one more new thing the client 
> now needs to do.

No, the client does not need to do this because the multipart always returns a 
single answer.

> 
> 3) Additionally, it sounds like we are doomed with the discovery. The 
> server cannot tell the client what embedded types he supports, thus 
> the client will just try asking different combinations until he gets a 
> response.

That is the reason for doing the second URI.  The second URI can be identified 
by name and thus the client can know which combination is going to work.

Jim


> 
> That is why I think two URIs are a bad idea. A query type may be OK, 
> but I can see Carsten and Klaus' point. We can just keep one cert 
> content type in the multipart, that simplifies it.
> 
> Rgs,
> Panos
> 
> -Original Message-
> From: Jim Schaad 
> Sent: Thursday, February 21, 2019 6:35 PM
> To: 'Carsten Bormann' 
> Cc: Panos Kampanakis (pkampana) ; 'ace'
> ; 'Klaus Hartke' ; 
> draft-ietf-ace- coap-...@ietf.org
> Subject: RE: [Ace] Embedded Content Types
> 
> It is true that the query parameters are part of the type.  However, 
> the use of two different URIs allows for the discovery to figure out 
> if both versions are supported rather than having either a failure 
> occur bec

Re: [Ace] Embedded Content Types

[Panos Kampanakis (pkampana)]

That comes with a set of problems. A simplification needs to take place. It is 
probably better to just mandate one content-type for cert to get away without 
complicated combined content types. We don't need to support TBD287 and 281 in 
the embedded responses. It makes more sense to not do so. 

As for why, there are a three reasons I can think of: 
1) Two separate URIs means we are adding state tracking for the CA. The CA now 
needs to support 
- EST that says "give me the key and a cert all at once and then forget about 
it".
- EST-coaps that says "give me a key. Remember this key/cert pair and serve the 
certificate until I decide to come back and get it". Now imagine I have 1 
of endpoints enrolling. The server keeps state for all of them and cannot 
forget them until he gets the equivalent requests. And then, what happens if a 
cert is lost on the way back? The CA is supposed to remember the key / cert for 
some time. There is a DoS vector right there. 

2) One more challenge with two URIs is that the client needs to somehow signal 
in the 2nd request to the server to tell him what key/cert he is expecting to 
get, so there is one more new thing the client now needs to do. 

3) Additionally, it sounds like we are doomed with the discovery. The server 
cannot tell the client what embedded types he supports, thus the client will 
just try asking different combinations until he gets a response.

That is why I think two URIs are a bad idea. A query type may be OK, but I can 
see Carsten and Klaus' point. We can just keep one cert content type in the 
multipart, that simplifies it. 

Rgs,
Panos

-Original Message-
From: Jim Schaad  
Sent: Thursday, February 21, 2019 6:35 PM
To: 'Carsten Bormann' 
Cc: Panos Kampanakis (pkampana) ; 'ace' ; 
'Klaus Hartke' ; draft-ietf-ace-coap-...@ietf.org
Subject: RE: [Ace] Embedded Content Types

It is true that the query parameters are part of the type.  However, the use of 
two different URIs allows for the discovery to figure out if both versions are 
supported rather than having either a failure occur because the query parameter 
is not supported or getting the wrong answer back because it is not looked for.

Jim


> -Original Message-
> From: Carsten Bormann 
> Sent: Thursday, February 21, 2019 2:52 PM
> To: Jim Schaad 
> Cc: Panos Kampanakis (pkampana) ; ace 
> ; Klaus Hartke ; 
> draft-ietf-ace-coap- e...@ietf.org
> Subject: Re: [Ace] Embedded Content Types
> 
> On Feb 21, 2019, at 23:31, Jim Schaad  wrote:
> >
> > I am thinking of two different URLs, that is not do the difference 
> > by a query
> parameter but by changing the URI.
> 
> Note that the query parameters are part of the URI, so fundamentally 
> there is no difference between putting the info there or in the path 
> part of the URI.
> 
> The path part can be slightly more concise.  We are more used to 
> “computing” the query part.  I don’t have a strong preference.
> 
> But in either case it is good if discovery can find the URI being 
> offered (including its query parameters, if those are used).
> 
> (And I agree that the “ct” target attribute really is for the top 
> level media type; of course we could invent a new target attribute 
> “ect” for embedded content formats [and fight against autocorrection 
> for the rest of our lives :-
> )].)
> 
> Grüße, Carsten


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

Re: [Ace] Embedded Content Types

[Panos Kampanakis (pkampana)]

> This is why I would prefer doing something like "/est/skg" and "/est/skg/yyy".

Not sure I am following. Are these two request URIs? Or in the discovery 
response?


-Original Message-
From: Jim Schaad  
Sent: Thursday, February 21, 2019 4:54 PM
To: Panos Kampanakis (pkampana) ; 'Carsten Bormann' 

Cc: ace@ietf.org; 'Klaus Hartke' ; 
draft-ietf-ace-coap-...@ietf.org
Subject: RE: [Ace] Embedded Content Types



> -Original Message-
> From: Panos Kampanakis (pkampana) 
> Sent: Thursday, February 21, 2019 1:32 PM
> To: Carsten Bormann 
> Cc: Jim Schaad ; ace@ietf.org; Klaus Hartke 
> ; draft-ietf-ace-coap-...@ietf.org
> Subject: RE: [Ace] Embedded Content Types
> 
> Thanks Carsten.
> 
> Let's say we use a query /skg?sk=xxx&spk=yyy. /skg/xxx,yyy is a 
> different URI imo, so it changes the EST spec and that introduces 
> changes that affect CAs that already implemented it. So let's say we do 
> /skg?sk=xxx&spk=yyy.
> When I am doing resource discovery and the server is returning the 
> content formats for skg, is he going to signal his supported formats 
> with
> ;rt="ace.est.skg";ct="62 xxx yyy"

This is why I would prefer doing something like "/est/skg" and "/est/skg/yyy".  
This does not change any existing servers other than getting the ct values 
corrected in discovery.


> 
> RFC5272 says
> > The Content-Format code "ct" attribute provides a hint about the 
> > Content-Formats this resource returns.  Note that this is only a 
> > hint, and it does not override the Content-Format Option of a CoAP 
> > response obtained by actually requesting the representation of the resource.
> > [...] The Content-Format code attribute MAY include a 
> > space-separated sequence of Content-Format codes, indicating that 
> > multiple content-formats are available.
> 
> So it looks tome that ct="62 280 284 281 TBD287" could hint to the 
> client that all the following formats are supported for the multipart.
> 
> I had a chat with Klaus where he mentioned that he assumed the ct="63 
> xxx yyy" returned attribute values are the accepted values by the 
> server in the "Accept" option.

I would agree with Klaus that this is a correct answer.

Jim

> 
> 
> -Original Message-----
> From: Carsten Bormann 
> Sent: Wednesday, February 20, 2019 8:11 PM
> To: Panos Kampanakis (pkampana) 
> Cc: Jim Schaad ; ace@ietf.org; Klaus Hartke 
> ; draft-ietf-ace-coap-...@ietf.org
> Subject: Re: [Ace] Embedded Content Types
> 
> On Feb 20, 2019, at 22:33, Panos Kampanakis (pkampana) 
>  wrote:
> >
> > If we broke the requests to different URIs, it means that a client 
> > needs to
> keep track of his transactions and on top of it he needs to correlate 
> the key and the cert he receives at a later time.
> 
> I think this is just a misunderstanding — the idea wasn’t to supply 
> the parts under different URIs, but to make up different URIs for 
> retrieving the different combinations coming in one multipart-core, in one 
> transaction.
> 
> As in
> 
> /skg?sk=284&spk=281
> 
> (Where sk is short for “secret key” and spk for “signed public key” — 
> substitute your own names.)
> 
> or, say
> 
> /skg/284,281
> 
> This provides full format agility while preserving the interaction model.
> 
> Grüße, Carsten


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

Re: [Ace] Embedded Content Types

[Panos Kampanakis (pkampana)]

Thanks Carsten. 

Let's say we use a query /skg?sk=xxx&spk=yyy. /skg/xxx,yyy is a different URI 
imo, so it changes the EST spec and that introduces changes that affect CAs 
that already implemented it. So let's say we do /skg?sk=xxx&spk=yyy. When I am 
doing resource discovery and the server is returning the content formats for 
skg, is he going to signal his supported formats with 
;rt="ace.est.skg";ct="62 xxx yyy"

RFC5272 says
> The Content-Format code "ct" attribute provides a hint about the 
> Content-Formats this resource returns.  Note that this is only a hint, 
> and it does not override the Content-Format Option of a CoAP response 
> obtained by actually requesting the representation of the resource. 
> [...] The Content-Format code attribute MAY include a space-separated 
> sequence of Content-Format codes, indicating that multiple 
> content-formats are available.

So it looks tome that ct="62 280 284 281 TBD287" could hint to the client that 
all the following formats are supported for the multipart. 

I had a chat with Klaus where he mentioned that he assumed the ct="63 xxx yyy" 
returned attribute values are the accepted values by the server in the "Accept" 
option. 


-Original Message-
From: Carsten Bormann  
Sent: Wednesday, February 20, 2019 8:11 PM
To: Panos Kampanakis (pkampana) 
Cc: Jim Schaad ; ace@ietf.org; Klaus Hartke 
; draft-ietf-ace-coap-...@ietf.org
Subject: Re: [Ace] Embedded Content Types

On Feb 20, 2019, at 22:33, Panos Kampanakis (pkampana)  
wrote:
> 
> If we broke the requests to different URIs, it means that a client needs to 
> keep track of his transactions and on top of it he needs to correlate the key 
> and the cert he receives at a later time.

I think this is just a misunderstanding — the idea wasn’t to supply the parts 
under different URIs, but to make up different URIs for retrieving the 
different combinations coming in one multipart-core, in one transaction.

As in

/skg?sk=284&spk=281

(Where sk is short for “secret key” and spk for “signed public key” — 
substitute your own names.)

or, say

/skg/284,281

This provides full format agility while preserving the interaction model.

Grüße, Carsten

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

Re: [Ace] Shepard comments draft-ietf-ace-coap-est-08

[Panos Kampanakis (pkampana)]

Thanks Jim. We have addressed all of them in the upcoming next iteration.

We also have addressed Klaus' feedbacks and will send a response to him this 
week.

The only issue left is the embedded content types which is being discussed as 
you know. 

Panos


-Original Message-
From: Ace  On Behalf Of Jim Schaad
Sent: Saturday, February 16, 2019 2:56 PM
To: draft-ietf-ace-coap-...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] Shepard comments draft-ietf-ace-coap-est-08

1.  In section 10.1 the last sentence of the first paragraph and the first 
sentence of the last paragraph duplicate each other.  This should be cleaned up.

2.  Correct the grammar in the first sentence of section 10.2 -  s/registers a 
new/registers new/

3.  The correct example DNS name is est-coaps.example.org not
est-coaps.example.ietf.org.   Please correct this.  (See RFC 2606)

4.  The query in section 5.1 to a resource directory is not correct.  It would 
not go to /.well-known/core but to /rd-lookup (or what ever name is
used by the RD).   If this is not intended to be an RD query, then the
sentence about it above can be omitted.  

5.  Please remove the "anchor" target attribute from the response from the RD.  
I believe that this is no longer required and it is just adding noise without 
adding value.  If this is intended to be from well-known then it is sufficient 
to have the anchor but not to  have the authority section in the href.  

;rt="ace.est";anchor="coaps://2001:db8::123]:61617"

6.  You have registered 282 and 283 as content types, however you also do not 
define anything that uses these types.  Either some text about the content 
types needs to exist or potentially the registrations should be abandoned.

7.  There is an outstanding review from Klaus that needs to be addressed.

8.  There is still an open issue dealing with content types.  I have requested 
that this be added to the agenda for the next CoRE interim meeting.

Jim



___
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] Embedded Content Types

[Panos Kampanakis (pkampana)]

Hi Jim,

Thank you. Sorry I couldn't make it to the CORE interim meeting. 

I see the challenge with content-format ID explosion in option c. So I agree 
that in the long run, there needs to be a long-term solution and option b seems 
the best for the general case.

There are challenges with option b and EST-coaps though. If we broke the 
requests to different URIs, it means that a client needs to keep track of his 
transactions and on top of it he needs to correlate the key and the cert he 
receives at a later time. So, after pulling the two URIs he has to 
cryptographically confirm the key is tied to the certificate. Additionally, 
this deviates from the logic of the EST protocol which we are trying to profile 
on. We are adding new APIs to the protocol. 

Because of these challenges, I would like to use option c in the ETS-coaps 
draft. It is not violating RFC7252 and it does not affect the long term plan 
(option b) either. There are only to content types we are talking about in 
EST-coaps, a key and a cert. A key can be encrypted or not. A cert can be in 
PKCS#7 or plain pkix-cert. That makes four combinations. The number cannot 
explode further, so we could live with it in this context.

Any strong objections?

Rgs,
Panos



-Original Message-
From: Ace  On Behalf Of Jim Schaad
Sent: Wednesday, February 20, 2019 12:59 PM
To: ace@ietf.org
Cc: draft-ietf-ace-coap-...@ietf.org
Subject: [Ace] Embedded Content Types

The CoRE working had an interesting virtual meeting this morning (my time) 
where the main topic of discussion was how to deal with embedded content types. 
 This is a current problem that needs to be addressed with the EST document 
which is currently trying to deal with last call comments.  The log from the 
meeting can be found at 
https://etherpad.tools.ietf.org/p/core-interim-2019-02-20.

The takeaway from this that I got was:
1.  There is a real problem and we need to figure out the best ways to try
and deal with this in a generic manner.   This is a problem not only here,
but it the Publish/Subscribe CoRE document and in many other cases that we can 
see.

2.  We are not going to get a general solution immediately so EST needs to look 
at  doing something now.

3.  A couple of different possibilities where discussed that could be used:
a)  Return a list of links rather than a multipart content and let the client 
sort through that list and download the things that they want.  This is a 
purely reactive solution.
b) Use a different URI to ask for the different options.  This could be done 
either by the use of a different URI path or by the use of a query parameter.
c) Register a different content type for each of the possible return values.

There was a general preference for the use of a different URI as being the 
solution that should be used today.  The idea of registering multiple content 
types was generally disliked as it does not really extend well.
There was no specific preference on whether the use of a different URI path or 
a query parameter would be preferred.  The use of a different URI would allow 
for better discovery of capabilities.  

The idea of listing nested content types in the 'ct' link type was also 
universally disliked.

The CoRE, T2TRG and other forums are expected to continue discussions on this 
topic in different contexts such as Pub-Sub and CoRAL. To come up with both 
proactive and reactive solutions to the more general problem.

Jim


___
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] Shepard comments draft-ietf-ace-coap-est-08

[Panos Kampanakis (pkampana)]

Hi Jim,

About 

> 4.  The query in section 5.1 to a resource directory is not correct.  It 
> would not go to /.well-known/core but to /rd-lookup (or what ever name is 
> used by the RD).   If this is not intended to be an RD query, then the 
> sentence about it above can be omitted.  

> 5.  Please remove the "anchor" target attribute from the response from the 
> RD.  I believe that this is no longer required and it is just adding noise 
> without adding value.  If this is intended to be from well-known then it is 
> sufficient to have the anchor but not to  have the authority section in the 
> href.   ;rt="ace.est";anchor="coaps://2001:db8::123]:61617"

The text will now read 
~~~
Discoverable port numbers can be returned in the payload An example response 
payload for non-default CoAPS server port 61617 follows below. Linefeeds were 
included only for readability.

  REQ: GET /.well-known/core?rt=ace.est*

  RES: 2.05 Content
;rt="ace.est", 
;rt="ace.est.crts"; ct="281 TBD287", 
;rt="ace.est.sen";ct="281 TBD287", 
;rt="ace.est.sren";ct="281 TBD287",
;rt="ace.est.att";ct="285",
;rt="ace.est.skg";ct="62 280 284 281 
TBD287"
~~~

What do you think? Does it address your two comments 4 and 5?

Rgs,
Panos

-Original Message-
From: Ace  On Behalf Of Jim Schaad
Sent: Saturday, February 16, 2019 2:56 PM
To: draft-ietf-ace-coap-...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] Shepard comments draft-ietf-ace-coap-est-08

1.  In section 10.1 the last sentence of the first paragraph and the first 
sentence of the last paragraph duplicate each other.  This should be cleaned up.

2.  Correct the grammar in the first sentence of section 10.2 -  s/registers a 
new/registers new/

3.  The correct example DNS name is est-coaps.example.org not
est-coaps.example.ietf.org.   Please correct this.  (See RFC 2606)

4.  The query in section 5.1 to a resource directory is not correct.  It would 
not go to /.well-known/core but to /rd-lookup (or what ever name is
used by the RD).   If this is not intended to be an RD query, then the
sentence about it above can be omitted.  

5.  Please remove the "anchor" target attribute from the response from the RD.  
I believe that this is no longer required and it is just adding noise without 
adding value.  If this is intended to be from well-known then it is sufficient 
to have the anchor but not to  have the authority section in the href.  

;rt="ace.est";anchor="coaps://2001:db8::123]:61617"

6.  You have registered 282 and 283 as content types, however you also do not 
define anything that uses these types.  Either some text about the content 
types needs to exist or potentially the registrations should be abandoned.

7.  There is an outstanding review from Klaus that needs to be addressed.

8.  There is still an open issue dealing with content types.  I have requested 
that this be added to the agenda for the next CoRE interim meeting.

Jim



___
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] ace-coap-est-08: using /skg with Accept Option set to TBD287

[Panos Kampanakis (pkampana)]

> CoAP is not aware that the representation happens to contain embedded 
> representations and therefore the content negotiation mechanism cannot be 
> used directly to negotiate the formats of those. 
> The value of the Accept option in the request needs to be registered in the 
> IANA registry and the value of the Content-Format option in the response must 
> be the same as Accept value.
> Of course, one possible solution is to drop the use of content format ID 62 
> entirely and just register one ID for each possible combination. (But then 
> the client can still only include at most one Accept option in its request.)

Hmm, that is a fair point. I don't think it is warranted to register four more 
content formats for all possible format combinations in the multipart response. 

It looks to me that your proposal of using Uri-Query in the request in order 
for the client to define the supported formats of the requested 
resource/response is a good one.




-Original Message-
From: Ace  On Behalf Of Klaus Hartke
Sent: Tuesday, February 12, 2019 4:36 PM
To: Panos Kampanakis (pkampana) 
Cc: Esko Dijk ; ace@ietf.org
Subject: Re: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287

Panos Kampanakis wrote:
> Well, RFC7252 refers to a singular content format. In our case we are talking 
> about a dual content format (286 or 281 and 280 or 284) returned in a 62 
> multipart-content. Would it be a violation of RFC7252, since RFC7252's text 
> had single content format responses in mind only?

>From the point of view of CoAP, there is just a representation with
content-format 62. A client can indicate that it accepts a representation with 
content-format 62; the server then is required to return either a 
representation with content-format 62 or an error.
CoAP is not aware that the representation happens to contain embedded 
representations and therefore the content negotiation mechanism cannot be used 
directly to negotiate the formats of those.

>>  Maybe the draft-ietf-core-multipart-ct should extend the semantics of 
>> "Accept" to cover this case?

A content format is not a protocol extension and cannot override the protocol 
definition.

> I think that is good idea. The simplest way to do that would be encode the 3 
> content formats (for example 62, 286 and 280) into a single CF included in 
> the Accept option which tells the server what combination of content formats 
> to send back. Would that violate RFC7252 because the Content-Formats needs to 
> be actual CFs defined in the IANA registry and not a combination of them?

The value of the Accept option in the request needs to be registered in the 
IANA registry and the value of the Content-Format option in the response must 
be the same as Accept value.

Of course, one possible solution is to drop the use of content format ID 62 
entirely and just register one ID for each possible combination.
(But then the client can still only include at most one Accept option in its 
request.)

> From a previous thread with Jim S., I was under the impression that In the 
> virtual CoAP WG meeting a month back we went through in some explicit detail 
> that both Content-Format and Max-Age have no meaning when appearing on a 
> request and therefore should not be there.

Max-Age doesn't have a meaning in requests and therefore must not be there. I'm 
not sure where that about the Content-Format option comes from. If a POST 
request has a payload, then the format of that payload is described by a 
Content-Format option. (A GET request doesn't have a payload and therefore must 
not include a Content-Format option.)

Klaus

___
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] ace-coap-est-08: using /skg with Accept Option set to TBD287

[Panos Kampanakis (pkampana)]

Thanks Klaus and Esko. 

>If the preferred Content-Format cannot be returned, then a 4.06 "Not 
> Acceptable" MUST be sent as a response, unless another error code takes 
> precedence for this response.

Well, RFC7252 refers to a singular content format. In our case we are talking 
about a dual content format (286 or 281 and 280 or 284) returned in a 62 
multipart-content. Would it be a violation of RFC7252, since RFC7252's text had 
single content format responses in mind only? 


>  Maybe the draft-ietf-core-multipart-ct should extend the semantics of 
> "Accept" to cover this case?

I think that is good idea. The simplest way to do that would be encode the 3 
content formats (for example 62, 286 and 280) into a single CF included in the 
Accept option which tells the server what combination of content formats to 
send back. Would that violate RFC7252 because the Content-Formats needs to be 
actual CFs defined in the IANA registry and not a combination of them?


Panos


>From a previous thread with Jim S., I was under the impression that In the 
>virtual CoAP WG meeting a month back we went through in some explicit detail 
>that both Content-Format and Max-Age have no meaning when appearing on a 
>request and therefore should not be there.


-Original Message-
From: Ace  On Behalf Of Klaus Hartke
Sent: Tuesday, February 12, 2019 10:19 AM
To: Esko Dijk 
Cc: ace@ietf.org
Subject: Re: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287

Esko Dijk wrote:
> So the client asks for 286, but gets 62 (which has 286 embedded in it 
> as one of the parts). At first sight this appears incompatible with 
> CoAP RFC7252 logic.
>
> A strict server implementation might return 4.06 Not Acceptable since 
> the server code has registered the response type to be 62; and the 
> client asks something different.

 RFC 7252 is quite strict about this:

   If the preferred Content-
   Format cannot be returned, then a 4.06 "Not Acceptable" MUST be sent
   as a response, unless another error code takes precedence for this
   response.

That's a MUST, not a SHOULD.

Since a client might actually support multiple formats, it might make sense to 
indicate all supported formats in order of preference e.g. as query parameters:

Client:
  POST /.well-known/est/skg?ct=TBD287&ct=281
Accept: 62
...

Server:
  2.04
  Content-Format: 62
  Payload: (multipart containing TBD287)

Klaus

___
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] WGLC for draft-ietf-ace-coap-est

[Panos Kampanakis (pkampana)]

Hi all, 

The -08 version of the draft 
https://tools.ietf.org/html/draft-ietf-ace-coap-est-08 addresses all comments 
we received so far in the WGLC. It also simplifies parts of the text to make 
easier to read, moves a couple of sections in more suitable order and fixes 
nits and typos. 

Thanks to everyone that provided feedback and mostly Jim and Esko for their 
thorough reviews.

For a summary of the issues received in WGLC and how they were addressed, refer 
to 
https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed+WGLC
 

Let us know if there is more feedback.

Rgs,
Panos


-Original Message-
From: Ace  On Behalf Of Jim Schaad
Sent: Tuesday, January 29, 2019 12:59 AM
To: ace@ietf.org
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est

This message concludes the last call for this document.  The authors are 
requested to create and post a new document addressing the issues that were 
raised.

Jim

> -Original Message-
> From: Ace  On Behalf Of Jim Schaad
> Sent: Sunday, January 13, 2019 8:03 PM
> To: ace@ietf.org
> Subject: [Ace] WGLC for draft-ietf-ace-coap-est
> 
> The chairs believe that the EST over CoAP draft is nearing the point 
> it
should
> be sent to the IESG for publication.  We are therefore going to have a 
> Working Group Last Call on this document.  WGLC will until 29th of 
> this month.  Please review the document and send comments both 
> positive and negative to the list about its state.
> 
> Jim & Roman
> 
> 
> ___
> 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

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

Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07

[Panos Kampanakis (pkampana)]

Thanks Jim 

> You say that the client should use the new explicit trust anchors right after 
> the cacerts request, but if you do not tear down the DTLS connection you are 
> not doing that.  You are still using the old implicit trust anchors. The MAY 
> in section 11.1 for me is overridden by the previous SHOULD unless this case 
> is specifically called out in section 7.  I cannot understand the logic that 
> says when you get a certificate a year from now the explicit TAs SHOULD be 
> used, but it does not matter when you get the first certificate.

In the draft we want to say that when you get the cacerts response start using 
those as your explicit trust anchor. But we also want to say that if you 
pipeline EST-coaps messages in the same connection then you MAY keep the DTLS 
connection open. That has implications on the trust anchor if one of the 
EST-coaps requests included a cacerts request. I am thinking that in order to 
make it clearer we can add text to say that "After a cacerts you are expected 
to use the new trust anchor. If pipelining is used you MAY keep the connection 
open, but the client SHOULD still authenticate the server identity received 
during the DTLS handshake against the new trust anchor receive in response to a 
cacerts in the same connection. " What do you think? I open to other text 
suggestion to convey the point as well. 

About the Examples we will address the Max-Age and Content Format in the 
examples. I created new github issues for those.

Panos



-Original Message-
From: Jim Schaad  
Sent: Monday, January 28, 2019 4:37 PM
To: Panos Kampanakis (pkampana) ; ace@ietf.org
Subject: RE: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07

Clipping out things which are not issues:


> -Original Message-----
> From: Ace  On Behalf Of Panos Kampanakis
> (pkampana)
> Sent: Friday, January 18, 2019 12:59 PM
> To: Jim Schaad ; ace@ietf.org
> Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
> 
> Hi Jim,
> 
> Again, thank you for your thorough reviews. We addressed all of them. 
> The new version of the draft is at 
> https://github.com/SanKumar2015/EST-
> coaps/blob/master/draft-ietf-ace-coap-est.txt
> 
> For a more easily consumable content, your latest feedback was tracked 
> and addressed here https://github.com/SanKumar2015/EST-
> coaps/issues?utf8=%E2%9C%93&q=is%3Aissue+draft-ietf-ace-coap-est-07
> 
> I also lay out the changes  below:
> 
> 
> - About the persistent DTLS connections (Sect 7), the last two 
> paragraphs
of
> section 7 explain why in some cases DTLS connections need to stay open 
> for a limited amount of time. They also point to the Section 11.1 
> about the caveats of a persistent connection and the implicit DB. I do 
> not think it
is up to
> this draft to tell the client that he should use the new cert after an 
> enrollment. The old cert might still be perfectly valid or the new 
> cert
may be
> generated for a non DTLS client auth use. So, I don't think we need to
state in
> this draft that the new cert needs to be used in new DTLS connections.
> 
> - About the DTLS connections (Sec 11.1), We have usecases where a 
> client does not want to spend the resources, time, performance 
> implications to do
> 3-5 DTLS connections back to back in order to update its trustanchor 
> and
do
> its enrollments for multiple certs. In this cases, explained in 
> section 7
last
> paragraphs will keep a persistent DTLS connection. That is what 
> section
11.1 is
> trying to explain. Please keep in mind that in there we state that it 
> is RECOMMENDED for the client to start using the new explicit DB right 
> after the cacerts request. We just add the MAY keep the authenticated 
> with implicit DB DTLS connection open in some cases, but then he MUST 
> use the new DB starting for the next DTLS connection.
> 
> So, I think our language in Sections 7 and 11.1 suffices when talking
about
> persistent TLS connections.

Any time that the set of trust anchors is changed, you have also changed the 
set of things that you are going to trust.  If you remove the trust anchor for 
the current connection, or restrict it in some manner, you may no longer have 
any trust in that connection.  This is the worry that I have.  I completely 
agree that doing multiple certificate requests (not sure why) or a query about 
the csr attributes followed by the certificate request is totally reasonable.  

You say that the client should use the new explicit trust anchors right after 
the cacerts request, but if you do not tear down the DTLS connection you are 
not doing that.  You are still using the old implicit trust anchors.
The MAY in section 11.1 for me is overridden by the previous SHOULD unless this 
case is specifically called out in secti

Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07

[Panos Kampanakis (pkampana)]

Hi Jim,

Again, thank you for your thorough reviews. We addressed all of them. The new 
version of the draft is at 
https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt
 

For a more easily consumable content, your latest feedback was tracked and 
addressed here 
https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=is%3Aissue+draft-ietf-ace-coap-est-07
 

I also lay out the changes  below: 


- We fixed all the nits. 

- About the Arbitrary Label, we added 
"Arbitrary Labels are usually defined and used by EST CAs in order to route 
client requests to the appropriate certificate profile."

- About guidance when discovery is necessary, we added 
"Discovery SHOULD NOT be chosen when the client is preconfigured to use the 
default /.well known/est server root resource and port 5684. If the default 
root resource requests fail, the client SHOULD fall back to doing a resource 
discovery. Resource discovery SHOULD be employed when non-default URIs (like 
/est or /est/ArbitraryLabel) or ports are supported by the server or when the 
client is unaware of what EST-coaps resources are available by the server."

- About CBOR in section 5.7 we added 
"The sever-side key generation response is returned with content
   format application/multipart-core [I-D.ietf-core-multipart-ct]
   containing a CBOR array with four items (Section 5.2.1).  "

- About tlsl-unique and TLS exporters, this was discussed before for TLS 1.3 
(https://mailarchive.ietf.org/arch/msg/tls/-8rDHLR6hiR7wsLsf6nVLtqCCmU ) but we 
can't really mandate using a TLS exporter for tls-unique as this is not 
standardized anywhere. If there was an 5929-bis to update the tls-unique in 
order to address the risk and use an exporter then this draft would 
automatically inherit it.

Note that the implications of 3SHAKE were significant to TLS because the 
clients were not checking the server cert after the renegotiation (Step 3 of 
the paper). The implication to POP linking that EST-coaps uses though is 
minimal because it does not expose anything private, it just deems channel 
binding useless.

To address the concern I added text in the Security Considerations
" What's more, POP linking uses tls-unique as it is defined in [RFC5929]. The 
3SHAKE attack [tripleshake] poses a risk by allowing a man-in-the-middle to 
leverage session resumption and renegotiation to inject himself between a 
client and server even when channel binding is in use. The attack was possible 
because of certain (D)TLS implementation imperfections. In the context of this 
specification, an attacker could invalidate the purpose of the POP linking 
ChallengePassword in the client request by resuming an EST-coaps connection. 
Even though the practical risk of such an attack to EST-coaps is not 
devastating, we would rather use a more secure channel binding mechanism. Such 
a mechanism could include an updated tls-unique value generation like the 
tls-unique-prf defined in [I-D.josefsson-sasl-tls-cb] by using a TLS exporter 
[RFC5705] in TLS 1.2 or TLS 1.3's updated exporter (Section 7.5 of [RFC8446]). 
Such mechanism has not been standardized yet. Adopting in this document a 
channel
  binding value generated from an exporter would break backwards compatibility. 
Thus, in this specification we still depend in the tls-unique mechansim defined 
in [RFC5929], especially since the practicallity of such an attack would not 
expose any messages exchanged with EST-coaps."

- About the persistent DTLS connections (Sect 7), the last two paragraphs of 
section 7 explain why in some cases DTLS connections need to stay open for a 
limited amount of time. They also point to the Section 11.1 about the caveats 
of a persistent connection and the implicit DB. I do not think it is up to this 
draft to tell the client that he should use the new cert after an enrollment. 
The old cert might still be perfectly valid or the new cert may be generated 
for a non DTLS client auth use. So, I don't think we need to state in this 
draft that the new cert needs to be used in new DTLS connections.

- About the DTLS connections (Sec 11.1), We have usecases where a client does 
not want to spend the resources, time, performance implications to do 3-5 DTLS 
connections back to back in order to update its trustanchor and do its 
enrollments for multiple certs. In this cases, explained in section 7 last 
paragraphs will keep a persistent DTLS connection. That is what section 11.1 is 
trying to explain. Please keep in mind that in there we state that it is 
RECOMMENDED for the client to start using the new explicit DB right after the 
cacerts request. We just add the MAY keep the authenticated with implicit DB 
DTLS connection open in some cases, but then he MUST use the new DB starting 
for the next DTLS connection. 

So, I think our language in Sections 7 and 11.1 suffices when talking about 
persistent TLS connections.
~~~

Re: [Ace] I-D Action: draft-ietf-ace-coap-est-07.txt

[Panos Kampanakis (pkampana)]

Hello, 

The -07 version of draft-ietf-ace-coap-est addresses all feedback we have 
received to date and updates all the examples to include more realistic 
constrained environment EST-coaps message transactions. 

It is ready for WGLC, as discussed in IETF-103. 

Rgs,
Panos

-Original Message-
From: Ace  On Behalf Of internet-dra...@ietf.org
Sent: Wednesday, January 09, 2019 12:05 PM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : EST over secure CoAP (EST-coaps)
Authors : Peter van der Stok
  Panos Kampanakis
  Michael C. Richardson
  Shahid Raza
Filename: draft-ietf-ace-coap-est-07.txt
Pages   : 46
Date: 2019-01-09

Abstract:
   Enrollment over Secure Transport (EST) is used as a certificate
   provisioning protocol over HTTPS.  Low-resource devices often use the
   lightweight Constrained Application Protocol (CoAP) for message
   exchanges.  This document defines how to transport EST payloads over
   secure CoAP (EST-coaps), which allows constrained devices to use
   existing EST functionality for provisioning certificates.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-coap-est-07
https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-07


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] est-coaps clarification on /att and /crts

[Panos Kampanakis (pkampana)]

Hi Hannes,
Michael was only asking if allowing any anonymous entity to get the cacerts 
(trusted root cert list) is worth it. RFC7030 allows for this. Of course an 
enrollment would still require authentication/authorization. 
I was making the case that it is not worth to even allow anonymous get cacerts. 
Panos


-Original Message-
From: Hannes Tschofenig  
Sent: Wednesday, December 12, 2018 11:01 AM
To: Panos Kampanakis (pkampana) ; Michael Richardson 
; ace@ietf.org; an...@ietf.org
Cc: Peter van der Stok ; Max Pritikin (pritikin) 

Subject: RE: est-coaps clarification on /att and /crts

Hi Panos, Hi Michael,

> We want all our clients to be authenticated by DTLS before they start loading 
> up our RF network.
> I'm not suggesting that the DTLS be skipped, I'm suggesting that the client 
> certificate presented might be meaningless to the EST server.

I am curious what security model you have in mind? If you don't do client 
authentication then you are essentially issuing certificates to an anonymous 
entity. This feels like a very bad idea, particularly since the CA is supposed 
to assert the identifier of the client via the certificate.

What am I missing here?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

Re: [Ace] est-coaps clarification on /att and /crts

[Panos Kampanakis (pkampana)]

Gotcha, so you are describing a provisional DTLS connection at the server. 

Just to give a bit more color, in a usecase we are working on right now the 
mesh network link rate <100Kbps. That network gets oversubscribed with legit 
cacert responses. I can only imagine how worse it would be if bad guys were 
allowed to send small /crt requests and trigger big cert responses. 

Just a 4.01 would not tell the client that he needs to send client certs for 
auth. In plain EST it would take an HTTP 401 with an 
WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge
header in the response. Unless we replicate that a generic 4.01 would not be 
enough for the client to know what to do. 

Another issue is EST-coaps request pipelining. A cacerts could precede an 
enrollment in the same DTLS connection (for really constrained devices that 
don't want to establish two connections). This could be opening room for 
unauthenticated enrollments when pipelining is used. 

I think it is a good idea to not repeat the EST behavior in regards to /crt and 
/att. Provisional TLS at the server could have value in 
Constrianed-BRSKI/voucher though, for some situations though. 

> So I think that we need to say something in EST-COAPS to explain that we do 
> not see a use case for replying to /crts and /att for clients which are not 
> recognized.  Is 401 (4.01) or 403 (4.03) more appropriate do you think? 

Currently we say that clients need to be authenticated in a DTLS connection 
before an EST-coaps request. Do you want to make it more explicit to say that 
even though EST allowed for it, EST-coaps does not allow unauthenticated /crt 
and /att? We can certainly add that. 

Rgs,
Panos


-Original Message-
From: Michael Richardson  
Sent: Tuesday, December 11, 2018 5:22 PM
To: Panos Kampanakis (pkampana) ; ace@ietf.org; 
an...@ietf.org
Cc: Peter van der Stok ; Max Pritikin (pritikin) 

Subject: Re: est-coaps clarification on /att and /crts

* PGP Signed by an unknown key


Panos Kampanakis (pkampana)  wrote:
> I thought about this for the EST-coaps draft. EST allowed for 
> unauthenticated /cacerts and /csrattrs (/crt and /att in EST-coaps) as 
> you are suggesting.

Exactly.

> It is not as simple in EST-coaps. Two reasons:

> 1) There are constrained networks where an easy amplification attack 
> could take place. For example the /crt request is very small and the 
> response can be big (a few KBs in the context of a constrained network 
> is big). If unauthenticated, then /crts could be an easy amplification 
> attack to saturate a constrained network. We don't want that to 
> happen. We want all our clients to be authenticated by DTLS before 
> they start loading up our RF network.

I'm not suggesting that the DTLS be skipped, I'm suggesting that the client 
certificate presented might be meaningless to the EST server.
As for amplication attacks, they usually depend upon forged source addresses, 
and in that case the DTLS wouldn't have completed.

> 2) Additionally, there is a practical challenge of COAPS. When the 
> DTLS handshake is taking place the server does not know what the 
> request will be. In EST the server would send an HTTP WWW-Authenticate 
> header to ask the client to authenticate. Such a mechanism does not 
> exist in COAP, so it would not be straightforward unless we introduced 
> a bunch of new things into COAP.

AFAIK, we don't support HTTP-level authentication in COAPS, only DTLS level 
authentication is specified in EST-COAPS.

> I think it is still right to authenticate clients even for /crt and 
> /att in the EST-coaps context. Maybe that is something to be revisited 
> in Constrained-BRSKI/voucher, but not taken lightly.

So I think that we need to say something in EST-COAPS to explain that we do not 
see a use case for replying to /crts and /att for clients which are not 
recognized.  Is 401 (4.01) or 403 (4.03) more appropriate do you think?

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



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




* Unknown Key
* 0xDDD0DD65

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

Re: [Ace] est-coaps clarification on /att and /crts

[Panos Kampanakis (pkampana)]

Hi Michael,

I thought about this for the EST-coaps draft. EST allowed for unauthenticated 
/cacerts and /csrattrs (/crt and /att in EST-coaps) as you are suggesting. It 
is not as simple in EST-coaps. Two reasons: 
1) There are constrained networks where an easy amplification attack could take 
place. For example the /crt request is very small and the response can be big 
(a few KBs in the context of a constrained network is big). If unauthenticated, 
then /crts could be an easy amplification attack to saturate a constrained 
network. We don't want that to happen. We want all our clients to be 
authenticated by DTLS before they start loading up our RF network.
2) Additionally, there is a practical challenge of COAPS. When the DTLS 
handshake is taking place the server does not know what the request will be. In 
EST the server would send an HTTP WWW-Authenticate header to ask the client to 
authenticate. Such a mechanism does not exist in COAP, so it would not be 
straightforward unless we introduced a bunch of new things into COAP.

I think it is still right to authenticate clients even for /crt and /att in the 
EST-coaps context. Maybe that is something to be revisited in 
Constrained-BRSKI/voucher, but not taken lightly. 

Rgs,
Panos



-Original Message-
From: Michael Richardson  
Sent: Tuesday, December 11, 2018 11:29 AM
To: ace@ietf.org; an...@ietf.org
Cc: Panos Kampanakis (pkampana) ; Peter van der Stok 
; Max Pritikin (pritikin) 
Subject: est-coaps clarification on /att and /crts

* PGP Signed by an unknown key


A clarification question from an implementor (me) in the context of constrained 
BRSKI state machine.

The /att and /crts requests do not do anything to change the state of client or 
server.  It would seem that it might be safe to permit clients which have not 
yet authenticated to do this operation.
(/att gets CSR attributes, and /crts gets the list of trust anchors)

When EST-COAPS is used on its own, there usually needs to be a manufacturer 
trust anchor installed on the Registrar before any connection will be permitted.

When EST-COAPS is used as step 2 of constrained-BRSKI, whether or not the 
Registrar will accept any (and all) connections depends upon configuration of 
the operator.  Some devices might not be doing BRSKI (not need to, they already 
trust the operator, but they might still have IDevID only.  This might happen 
during a transition)

If the Registrar is "open" to new manufacturers, should the Registrar permit 
/att and /crts actions to be done by clients that it does not
recognize?   The /att call on an ANIMA ACP network would reveal to the
client the ULA that would be used for that client (and perhaps other 
interesting things), and the /crts would show the name of the operator.
Note that the later info probably is revealed just by doing the TLS handshake.

I think that they should be restricted in general, but I'm concerned that there 
might be some situation I've missed.

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




* Unknown Key
* 0xDDD0DD65

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

Re: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm

[Panos Kampanakis (pkampana)]

+1. I think this is a problem that needs to be solved.

But I do think that the OAuth or PubSub requirement is a strong one. I would 
like to see if the MLS work could be used in these environments too 
https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/ Using the OAuth draft 
or the PubSub one for authorization and group join is fine, but there will be 
environments where that will not be possible, so I was wondering if 
https://tools.ietf.org/html/draft-ietf-mls-protocol-02 could be leveraged.

Rgs,
Panos

From: Ace  On Behalf Of Peter van der Stok
Sent: Thursday, December 06, 2018 4:39 AM
To: Roman Danyliw 
Cc: ace@ietf.org
Subject: Re: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm

I support the adoption of this draft.
It is the right solution to our secure group communication wishes.

Peter

Roman Danyliw schreef op 2018-11-30 22:58:
Hello!

This is the start of a two week call for input on the WG adoption of the 
document:

draft-palombini-ace-key-groupcomm
https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-02

The document has been presented and discussed at the last few meetings; and 
revisions have been made based on WG feedback.  At the IETF 103 meeting, there 
was support for adoption; and volunteers to review and implement the draft.

Please provide feedback to the list/chairs if you believe that this document 
should be adopted as a WG document.The adoption call will end on December 
14 2018.

Regards,
Roman and Jim

___
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] ace-coap-est: unclear definition of /.well-known/est URI

[Panos Kampanakis (pkampana)]

EST by default runs on port 443 over TLS. It does not have any special port. 
Discovery is not defined in 7030. It is defined in BRSKI. And it based on GRASP 
or mDNS service discovery.

I think it is not necessary to define a default port. The default COAPS UDP 
5684 suffices. Now if a server wants to advertise a different port then we 
would need the full URI with the port.

From: Peter van der Stok [mailto:stokc...@bbhmail.nl]
Sent: Monday, September 24, 2018 4:12 AM
To: Esko Dijk 
Cc: Michael Richardson ; Panos Kampanakis (pkampana) 
; consulta...@vanderstok.org; ace@ietf.org
Subject: Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI

Hi,

What do I read?
when you do GET coap://example.com/.well-known/core
The discovery is on port 5683.
When you do GET coaps://example.com/.well-known/core
the discovery port is 5684.

I agree that we did not assign a port to coaps://example.com/est for that 
matter,
and as such the example is incorrect. Will we make the port discoverable?

RFC 7030 does not ask a port number from IANA.
And a search through IANA port numbers on "est" does not yield anything.

Any suggestions? or improve my knowledge.

Peter

Esko Dijk schreef op 2018-09-21 10:24:
I've asked if discovery is always required, permitted, or encouraged.

Normally it is always encouraged to use discovery in favour of fixed URIs at 
the server, to avoid specs squatting the URI namespace. But in our case the 
/.well-known/est space is already assigned (RFC 7030) so we have to support it 
also in coaps-est and no additional squatting takes place. Besides support for 
the well-known URI location, discovery by a client is permitted to find 
"ace.est" type resources at other places e.g. to get shorter URIs or to get 
6lowpan-compressible port numbers, or both.


I.e. - can the client avoid the round trip to do the discovery?
 - does the server have to provide the discovery?
 -- if not, what does a client do that performs the discovery and fails?
I've been told it was required.

- So it can't be required for the client, is my opinion.
- The server must support it (being a good CoAP-citizen) in some way as in the 
previous email.
- If it fails, the client might try another time using the /.well-known/est 
resource, or retry the discovery later on. (There could be various 
implementation-specific tactics here. Maybe the IP address of the EST server 
was configured wrongly; and the process that lead to this IP address can be 
redone by the client.)

Esko


___
Ace mailing list
Ace@ietf.org<mailto: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] ace-coap-est: unclear definition of /.well-known/est URI

[Panos Kampanakis (pkampana)]

Hi Esko,
Good point. We made this change to ensure the text is clearer. You will see it 
in the next iteration.
Thank you, 
Panos

-Original Message-
From: Esko Dijk [mailto:esko.d...@iotconsultancy.nl] 
Sent: Saturday, September 15, 2018 10:30 AM
To: Panos Kampanakis (pkampana) ; ace@ietf.org
Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI

Hello Panos,

Thanks - it's clear now that the "ArbitraryLabel" needs to be supported for 
this use case. The unclarity in the current text comes from the fact that the 
default /.well-known/est/ is missing ; which should be supported 
also as in RFC 7030. Also the usage of the discoverable root URI is missing 
here.

So we could update the text in Section 5 as follows:

--
The individual EST-coaps well-known server URIs differ from the EST URI by 
replacing the scheme https by coaps and by specifying shorter resource path 
names:

   coaps://www.example.com/.well-known/est/
   coaps://www.example.com/.well-known/est/ArbitraryLabel/

The ArbitraryLabel Path-Segment, if used, SHOULD be of the shortest length 
possible.

The optional additional EST-coaps server URIs, obtained through discovery of 
the EST root resource(s), are of the form:

   coaps://www.example.com//
   coaps://www.example.com//ArbitraryLabel/

--

The suggestion by Peter to add references to the corresponding EST RFC 7030 
sections is also good.

Regards
Esko

From: Panos Kampanakis (pkampana) 
Sent: Wednesday, September 12, 2018 17:31
To: Esko Dijk ; ace@ietf.org
Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI

Hi Esko,

Thanks for the comment. 

Certificate authorities use the ArbitraryLabel in order to direct the CSR 
request and issue certificates based on a certain policy / cert profile. For 
example, if you are ClientX you get label ClientX198282 and when you hit the CA 
HTTP URI .well-known/est/ ClientX198282/sen the CA knows to use the policy for 
ClientX in order to issue a certificate. Of course, someone that has deployed 
an on-prem CA that has the same cert profile for all endpoints will not need an 
arbitrary label and the default EST namespace is enough.  

So, even though coaps://www.example..com/.well-known/est/ would work 
for many cases, we needed to keep the 
coaps://www.example..com/.well-known/est/ArbitraryLabel/ as well for 
cases where the client is getting a cert from a CA that serves more than on 
cert profiles. We may need to specify that the labl should be as short as 
possible, even though it is kind of self-explanatory. 

I hope it makes sense.

Panos


From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Esko Dijk
Sent: Wednesday, September 12, 2018 11:10 AM
To: mailto:ace@ietf.org
Subject: [Ace] ace-coap-est: unclear definition of /.well-known/est URI

Dear all/authors of ace-coap-est,

Section 5 of ace-coap-est-05 indicates URI discovery is possible to find the 
EST functions entry point URI. Also a well-known URI is defined:

coaps://www.example..com/.well-known/est/ArbitraryLabel/.

This URI seems more complicated than needed? What if we simply define an 
always-available well-known URI, usable without any discovery:

coaps://www.example..com/.well-known/est/

This re-uses the well-known EST namespace which is exactly defined to do EST 
functions. So using the short-est names within this namespace should be fine.
It is important that a well-known URI is available that is usable without 
discovery, just like EST RFC 7030 defines it for https.
The "ArbitraryLabel" only makes the URI longer.

best regards
Esko Dijk

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

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

[Panos Kampanakis (pkampana)]

Hi Jim,
We have now addressed all the issues you brought up in July. The fixes will be 
in the last iteration. 
We will still make some cosmetic updates and post a new version.
Thank you for the thorough review. 
Rgs,
Panos

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Jim Schaad
Sent: Sunday, July 01, 2018 9:34 AM
To: draft-ietf-ace-coap-...@ietf.org
Cc: 'ace' 
Subject: [Ace] Review draft-ietf-ace-coap-est

* In section 4.1 I have a question about what you are using for payload content 
encoding.  Part of this might just be a question of how you plan to move from 
ASN.1 to CBOR at some point in the future.  I think that it would necessitate 
doing new media-types in that event.  You appear to be doing a CBOR bstr 
wrapping on the ASN.1 encoding payload.  I don't believe that there is any 
reason for doing this.  I would expect that the payload would be the ASN.1 w/o 
any ASN.1.  It is highly possible that I am just mis-reading what the text says 
and this is what you say.

* In section 5.0 - As written, the example of doing a query against 
/.well-known/core does not match my understanding of what would be return.
It should only return those resources which have the rt field set on them.
I do not understand why you believe that the following lines MAY be returned.  
Clarification of why you think this is true would be appreciated.

* Section 6 - Is there a need to have all of this description around 
TLS-unique?  Do you have a reason to believe that people are going get this 
implemented wrong?

* Section 7 - I think the figure has an error associated w/ it.  The CA should 
be tied to the EST Server and not to the Registrar

* Section 7 - Your language is a bit sloppy around the terms of POP and POP 
linking.  Unless it is really badly behaved, POP should never be broken by an 
RA.  The POP is the signature on the request and not tied to the TLS channel.  
The POP linking is tied to the TLS channel and is broken by the changing of the 
TLS sessions (client <-> RA,  RA <-> CA) 

* Section 7 - It is not clear to me that the SHOULD on reassembly of 
fragmentation is not a MUST.  I doubt that any EST server is going to be able 
to deal with getting fragments of requests from a registrar in separate 
messages.  This would be compounded if the proxy is handling multiple sessions 
at the same time. 

* Section 7 - It should be possible that when doing key generation for the 
protection of the private key to be end-to-end and it should not be necessary 
for the Proxy to decrypt and then re-encrypt the private key.  It should not 
matter for this if one does either symmetric or asymmetric encryption of the 
private key.

* Section 7 - It is very possible that the private key generation function 
would be hosted on the proxy and not at the CA.  I think that you might want to 
describe this as a normal configuration.  (Just spotted this in the Security 
considerations.  I think it should be here as well.)

* Section 9.1 - application/multipart-core should not be in the table of items 
for IANA to register.  This is being done in a different document.  If you want 
this table as a whole then it needs to be moved out of IANA considerations.

* Section 9.2 - please expand this text some.  You might want to look at
https://tools.ietf.org/html/rfc7390#section-6.1 for a template.


Jim


___
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] Review draft-ietf-ace-coap-est

[Panos Kampanakis (pkampana)]

Hi Jim,

Trying to close on this one and update the draft if necessary.

> [JLS]  I do not believe that the wrapping of content with the CBOR binary 
> text wrapping is needed at this point.  If that is needed for the multi-part 
> wrapping, then it is the job of the multi-part wrapping to deal with this 
> problem.  Multipart needs to be able to say I have a multipart of  text, json> neither of which are CBOR objects.  Therefor there is no reason 
> for you to use a CBOR wrapper for this and not just use the binary value.
You are right. We don’t need the CBOR binary wrapping. Originally the multipart 
was not using CBOR either 
https://tools.ietf.org/html/draft-fossati-core-multipart-ct-03 It was just 
using the encoding the length and then included the encoded payload. The draft 
was updated https://tools.ietf.org/html/draft-ietf-core-multipart-ct and to be 
consistent with CBOR follow this new wrapping methodology that leverages CBOR. 
What you are saying is right, but we needed to point to a live draft.

The key and the cert payloads in the multipart conveyed here will be ASN.1 as 
you suggested, binary encoded. The CT ID for the key and cert are defined in 
EST-coaps as 280 and 281. We need to make sure we spell them out in the text 
though to make them clearer.

Does it make sense?

Panos


From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, July 04, 2018 9:30 AM
To: consulta...@vanderstok.org
Cc: draft-ietf-ace-coap-...@ietf.org; 'ace' 
Subject: Re: [Ace] Review draft-ietf-ace-coap-est



From: Peter van der Stok mailto:stokc...@bbhmail.nl>>
Sent: Wednesday, July 4, 2018 1:53 AM
To: Jim Schaad mailto:i...@augustcellars.com>>
Cc: draft-ietf-ace-coap-...@ietf.org; 
'ace' mailto:ace@ietf.org>>
Subject: Re: [Ace] Review draft-ietf-ace-coap-est


Hi Jim,

Many thanks for the review. See our answers below.

* In section 4.1 I have a question about what you are using for payload content 
encoding.  Part of this might just be a question of how you plan to move from 
ASN.1 to CBOR at some point in the future.  I think that it would necessitate 
doing new media-types in that event.  You appear to be doing a CBOR bstr 
wrapping on the ASN.1 encoding payload.  I don't believe that there is any 
reason for doing this.  I would expect that the payload would be the ASN.1 w/o 
any ASN.1.  It is highly possible that I am just mis-reading what the text says 
and this is what you say.



What I wanted to do, and did not express very well.

Keep the ASN.1 structure of the payload; (re-using code)

Use straight binary coding instead of the base64-encoded (30% payload reduction)

Wrap the binary in a CBOR major type 2 h’xxx’ notation. (compatibility with 
multipart)

Not sure if this needs a new media type, the http content-coding and 
transfer-coding registries were not very helpful.



[JLS]  I do not believe that the wrapping of content with the CBOR binary text 
wrapping is needed at this point.  If that is needed for the multi-part 
wrapping, then it is the job of the multi-part wrapping to deal with this 
problem.  Multipart needs to be able to say I have a multipart of  neither of which are CBOR objects.  Therefor there is no reason for you 
to use a CBOR wrapper for this and not just use the binary value.


* In section 5.0 - As written, the example of doing a query against 
/.well-known/core does not match my understanding of what would be return.
It should only return those resources which have the rt field set on them.
I do not understand why you believe that the following lines MAY be returned.  
Clarification of why you think this is true would be appreciated.



Thanks for your reaction, I hesitated between two choices.

  *   Provide every line with another rt=ace.est.crts; rt=ace.est.sen; etc.
  *   Make them all ace.est.

There are no structure guidelines on rt= value, which complicates things.

Looking forward to your (and others) opinion.



[JLS] This is probably a don’t ask me question because I am not a deployer of 
IoT objects.  I don’t know that there is a good answer for this.  This is 
probably a good question to toss at the CORE WG.

* Section 6 - Is there a need to have all of this description around 
TLS-unique?  Do you have a reason to believe that people are going get this 
implemented wrong?


This come from experience. The implementation we had done in the past did not 
implement it correctly, that is why we expanded on the TLS-unique. We will see 
about shrinking the text in the draft.



* Section 7 - I think the figure has an error associated w/ it.  The CA should 
be tied to the EST Server and not to the Registrar


Thank you, we will fix that in the next iteration.



* Section 7 - Your language is a bit sloppy around the terms of POP and POP 
linking.  Unless it is really badly behaved, POP should never be broken by an 
RA.  The POP is the signature on the request and not tied to the TLS channel.  
The POP linking

Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI

[Panos Kampanakis (pkampana)]

Hi Esko,

Thanks for the comment.

Certificate authorities use the ArbitraryLabel in order to direct the CSR 
request and issue certificates based on a certain policy / cert profile. For 
example, if you are ClientX you get label ClientX198282 and when you hit the CA 
HTTP URI .well-known/est/ ClientX198282/sen the CA knows to use the policy for 
ClientX in order to issue a certificate. Of course, someone that has deployed 
an on-prem CA that has the same cert profile for all endpoints will not need an 
arbitrary label and the default EST namespace is enough.

So, even though coaps://www.example..com/.well-known/est/ would work 
for many cases, we needed to keep the 
coaps://www.example..com/.well-known/est/ArbitraryLabel/ as well for 
cases where the client is getting a cert from a CA that serves more than on 
cert profiles. We may need to specify that the labl should be as short as 
possible, even though it is kind of self-explanatory.

I hope it makes sense.

Panos


From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Esko Dijk
Sent: Wednesday, September 12, 2018 11:10 AM
To: ace@ietf.org
Subject: [Ace] ace-coap-est: unclear definition of /.well-known/est URI

Dear all/authors of ace-coap-est,

Section 5 of ace-coap-est-05 indicates URI discovery is possible to find the 
EST functions entry point URI. Also a well-known URI is defined:

coaps://www.example..com/.well-known/est/ArbitraryLabel/.

This URI seems more complicated than needed? What if we simply define an 
always-available well-known URI, usable without any discovery:

coaps://www.example..com/.well-known/est/

This re-uses the well-known EST namespace which is exactly defined to do EST 
functions. So using the short-est names within this namespace should be fine.
It is important that a well-known URI is available that is usable without 
discovery, just like EST RFC 7030 defines it for https.
The "ArbitraryLabel" only makes the URI longer.

best regards
Esko Dijk

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

Re: [Ace] EST over CoAP: Introduction

[Panos Kampanakis (pkampana)]

Hi Hannes,
Thank you for the text. The 15.4 was only serving only as a motivation usecase. 
We revamped the Intro similar to what you suggested. It will be fixed  in the 
next iteration.
Panos


From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Tuesday, May 15, 2018 5:34 AM
To: ace@ietf.org
Subject: [Ace] EST over CoAP: Introduction

Here is a proposal to change the introduction to the relevant parts only and to 
avoid repetition.
(The current document still keeps talking about IEEE 802.15.4 when there are so 
many other radio technologies as well.
There is nothing in this spec that makes this 15.4 specific. I understand that 
some of the authors really like 15.4 but .)

Here is my proposal to replace Section 1 and Section 1.1:

-

1.  Introduction

   "Classical" Enrollment over Secure Transport (EST) [RFC7030] is used for
   authenticated/authorized endpoint certificate enrollment (and
   optionally key provisioning) through a Certificate Authority (CA) or
   Registration Authority (RA).  It uses HTTPS.

   This specification defines a new transport for EST based on the
   Constrained Application Protocol (CoAP) since some Internet of Things (IoT)
   devices use CoAP instead of HTTP. This specification therefore utilizes DTLS 
[RFC6347],
   CoAP [RFC7252], and UDP instead of TLS [RFC5246], HTTP [RFC7230] and TCP..

   This document also profiles EST and only supports certificate-based client
   Authentication. The results are:

  *  The EST-coaps client does not support HTTP Basic authentication
 (as described in Section 3.2.3 of [RFC7030]).

  *  The EST-coaps client does not support authentication at the
 application layer (as described in Section 3.2.3 of [RFC7030]).

   EST messages may be relatively large and for this reason this
   document re-uses CoAP Block-Wise Transfer [RFC7959] to
   offer a fragmentation mechanism of EST messages at the CoAP layer.

-

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] EST over CoAP

[Panos Kampanakis (pkampana)]

Agreed. I see your point. I had read your whitepaper sometime back I think. 
Indeed ACE-Oath, or LWM2M KDC, or OCF DOXS could provide address the credential 
management issue. But I don't think we can tell endpoints that they are on 
their own unless they get the right hardware or they comply with the ACE-OAuth 
model, or DOXS.

EST server-side key gen is free in a sense does not require new entities. We 
are not introducing a new concept. If your EST-coaps server supports it, you 
could use it. But you do not need to even implement the server-side EST URI 
unless you want to. And of course server-side key gen does not address the 
whole credential issue which includes token, certs, raw public keys. It just 
gets an identity/priv keypair to the device.

Your feedback brings up good points, which I think we ought to elaborate on in 
the relevant sections and in the Security Considerations.



From: Hannes Tschofenig [mailto:hannes.tschofe...@arm.com]
Sent: Tuesday, May 15, 2018 4:27 AM
To: Panos Kampanakis (pkampana) ; ace@ietf.org
Subject: RE: EST over CoAP

Hi Panos,

I would say forget class 1 devices when you want to use public key crypto.

https://factorable.net/paper.html (and 
https://jhalderm.com/pub/papers/https-imc13.pdf  since it revisits the earlier 
analysis) was a problem with understanding where the entropy comes from. If you 
take a regular desktop Linux and remove keyboard, mouse, disk drive, complex 
process scheduling etc. then the ordinary entropy sources are suddenly gone. 
That was the problem identified in that paper.

I am worried about keys across devices. For this reason we have standardized 
protocols to allow you to provision devices with new keys. Here is a whitepaper 
published not too long ago that discusses the issue, see 
https://www..omaspecworks.org/wp-content/uploads/2018/03/IPSO-IoT-Credential-Management_Final.pdf

I believe you would agree with me that there is a lot of value in the public 
key crypto since you don't have to expose the private key. If your design 
suddenly still requires this then you are losing some of the good properties of 
public key crypto systems.

Ciao
Hannes

From: Panos Kampanakis (pkampana) [mailto:pkamp...@cisco.com]
Sent: 14 May 2018 21:24
To: Hannes Tschofenig; ace@ietf.org<mailto:ace@ietf.org>
Subject: RE: EST over CoAP

Your recommendation about having the right hardware is valid and what everyone 
should do as much as possible. What about Class 1 OEMs that cannot add the 
hardware you are recommending? Or even the ones that will not comply with the 
recommendations for their own reasons? We can't forget about those.

Is the vulnerability that you were referring to that the RA or CA have to 
generate the key? Trust of these entities needs to be established or this model 
falls apart anyway. It is up to the admin to decide if it trusts the Registrar 
will not store and reveal the private keys or generate insecure keys on the 
device itself. I am more concerned about this vulnerability 
https://www.kb.cert.org/vuls/id/566724 where some thousands of devices have the 
same identity and now they can all impersonate each other in my network as 
shown in https://jhalderm.com/pub/papers/https-imc13.pdf and 
https://factorable.net/paper.html

We agree on the other ephemeral keys used in secure communications. Good 
hardware would solve these issues. Without secure hardware some of these 
communications could be decrypted assuming the right resources. Even though, 
decrypting some data per connection is a concern, I don't think that the risk 
is as high as a compromised identity. Also, the former concern does not mean we 
should not have an option to eliminate the latter.

About the Proxy section 6, I would like to see comments about in in the next 
iteration, as we have updated to try to address some of these comments.

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 10:14 AM
To: Panos Kampanakis (pkampana) 
mailto:pkamp...@cisco.com>>; 
ace@ietf.org<mailto:ace@ietf.org>
Subject: Re: [Ace] EST over CoAP

Hi Panos,

Thanks for sharing this info.

Regarding the randomness requirement and the energy consumption. We have been a 
bit advocate for adding hardware-based random numbers to devices since 
randomness is a basic requirement for most security protocols.
You do not only need to have access to random numbers during key generation but 
also later when you use nonces, a DH exchange, create session keys, and IVs, 
and potentially even for signature generation. If you use a protocol that is 
not based on nonces then you may use one that relies on timestamps, which may 
not make the story necessarily easier.

Random number key generation is also not necessarily costly either (neither in 
terms of energy cost nor in terms of hardware costs).

Hence, I think you should consider the server-side key generation very 
carefully since you are essentially destroying 

Re: [Ace] EST over CoAP

[Panos Kampanakis (pkampana)]

Hi Mohit,
These priv/public keypairs+cert are provisioned and used on the endpoint as 
identity for authentication. If tamper-resistance is not supported on the 
endpoint, the keypairs could be reprovisioned more often than the traditional 
cert lifetime as the server-side key gen transaction does not incur significant 
workload to the endpoint itself.
Rgs,
Panos

From: Mohit Sethi [mailto:mohit.m.se...@ericsson.com]
Sent: Tuesday, May 15, 2018 1:37 AM
To: Panos Kampanakis (pkampana) ; Hannes Tschofenig 
; ace@ietf.org
Subject: Re: [Ace] EST over CoAP


Hi Panos,

How do you intend to use these server generated keys once they are provisioned 
onto the device?

--Mohit

On 05/14/2018 04:58 PM, Panos Kampanakis (pkampana) wrote:
Hi Hannes,

To address your question about server-side key gen, below is the explanation we 
have put in the draft already and will be in the next iteration
~
   Constrained devices sometimes do not have the necessary hardware to
   generate statistically random numbers for private keys and DTLS
   ephemeral keys.  Past experience has shown that cheap endpoints
   sometimes generate numbers which could allow someone to decrypt the
   communication or guess the private key and impersonate as the device.
   Studies have shown that the same keys are generated by the same model
   devices deployed on-line.

   Additionally, random number key generation is costly, thus energy
   draining.  Even though the random numbers that constitute the
   identity/cert do not get generated often, an endpoint may not want to
   spend time and energy generating keypairs, and just ask for one from
   the server.

   In these scenarios, server-side key generation can be used.  The
   client asks for the server or proxy to generate the private key and
   the certificate which is transferred back to the client in the
   server-side key generation response.
~

This is a need that we have heard from customers at Cisco.

About the proxy-Registrar question, we already have made the change in the 
working copy of the draft as well. We no longer call this functionality 
proxying, but instead use the concept of the registrar that terminates the 
connection and establishes the next one.

We didn't add any new features in the doc after removing the BRSKI stuff.

If you want an early preview to comment on, we can share the repository with 
you.

Panos

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
To: ace@ietf.org<mailto:ace@ietf.org>
Subject: [Ace] EST over CoAP

Hi all,

At IETF#101 Peter presented a list of open issues with the EST over CoAP draft, 
see
https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-secure-coap-00


-Operational parameter values

-Server side key generation using simple multipart encoding

-Explain trust relations for http/coap proxying

I have challenged the usefulness of the server-side key generation during the 
meeting but in general I am curious where we are with the document. It would be 
great to get it finalized. It appears that we are adding new features and 
therefore will not be able to complete the work in any reasonable timeframe.

So, do we have a plan for how to complete the document?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged.. If you are not the intended 
recipient, please notify the sender immediately and do not disclose the 
contents to any other person, use it for any purpose, or store or copy the 
information in any medium. Thank you.




___

Ace mailing list

Ace@ietf.org<mailto: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] EST over CoAP

[Panos Kampanakis (pkampana)]

Your recommendation about having the right hardware is valid and what everyone 
should do as much as possible. What about Class 1 OEMs that cannot add the 
hardware you are recommending? Or even the ones that will not comply with the 
recommendations for their own reasons? We can't forget about those.

Is the vulnerability that you were referring to that the RA or CA have to 
generate the key? Trust of these entities needs to be established or this model 
falls apart anyway. It is up to the admin to decide if it trusts the Registrar 
will not store and reveal the private keys or generate insecure keys on the 
device itself. I am more concerned about this vulnerability 
https://www.kb.cert.org/vuls/id/566724 where some thousands of devices have the 
same identity and now they can all impersonate each other in my network as 
shown in https://jhalderm.com/pub/papers/https-imc13.pdf and 
https://factorable.net/paper.html

We agree on the other ephemeral keys used in secure communications. Good 
hardware would solve these issues. Without secure hardware some of these 
communications could be decrypted assuming the right resources. Even though, 
decrypting some data per connection is a concern, I don't think that the risk 
is as high as a compromised identity. Also, the former concern does not mean we 
should not have an option to eliminate the latter.

About the Proxy section 6, I would like to see comments about in in the next 
iteration, as we have updated to try to address some of these comments.

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 10:14 AM
To: Panos Kampanakis (pkampana) 
mailto:pkamp...@cisco.com>>; 
ace@ietf.org<mailto:ace@ietf.org>
Subject: Re: [Ace] EST over CoAP

Hi Panos,

Thanks for sharing this info.

Regarding the randomness requirement and the energy consumption. We have been a 
bit advocate for adding hardware-based random numbers to devices since 
randomness is a basic requirement for most security protocols.
You do not only need to have access to random numbers during key generation but 
also later when you use nonces, a DH exchange, create session keys, and IVs, 
and potentially even for signature generation. If you use a protocol that is 
not based on nonces then you may use one that relies on timestamps, which may 
not make the story necessarily easier.

Random number key generation is also not necessarily costly either (neither in 
terms of energy cost nor in terms of hardware costs).

Hence, I think you should consider the server-side key generation very 
carefully since you are essentially destroying the benefits of public key 
crypto and introduce a big vulnerability.

In a nutshell, I think you are better of recommending OEMs to select the right 
hardware for the given task.

Ciao
Hannes

PS: For the proxy work (in context of DTLS/TLS) you might want to reach out to 
your co-worker Owen Friel.

From: Panos Kampanakis (pkampana) [mailto:pkamp...@cisco.com]
Sent: 14 May 2018 15:58
To: Hannes Tschofenig; ace@ietf.org<mailto:ace@ietf.org>
Subject: RE: EST over CoAP

Hi Hannes,

To address your question about server-side key gen, below is the explanation we 
have put in the draft already and will be in the next iteration
~
   Constrained devices sometimes do not have the necessary hardware to
   generate statistically random numbers for private keys and DTLS
   ephemeral keys.  Past experience has shown that cheap endpoints
   sometimes generate numbers which could allow someone to decrypt the
   communication or guess the private key and impersonate as the device.
   Studies have shown that the same keys are generated by the same model
   devices deployed on-line.

   Additionally, random number key generation is costly, thus energy
   draining.  Even though the random numbers that constitute the
   identity/cert do not get generated often, an endpoint may not want to
   spend time and energy generating keypairs, and just ask for one from
   the server.

   In these scenarios, server-side key generation can be used.  The
   client asks for the server or proxy to generate the private key and
   the certificate which is transferred back to the client in the
   server-side key generation response.
~

This is a need that we have heard from customers at Cisco.

About the proxy-Registrar question, we already have made the change in the 
working copy of the draft as well. We no longer call this functionality 
proxying, but instead use the concept of the registrar that terminates the 
connection and establishes the next one.

We didn't add any new features in the doc after removing the BRSKI stuff.

If you want an early preview to comment on, we can share the repository with 
you.

Panos

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
To: ace@ietf.org<mailto:ace@ietf.org>
Subject: [Ace] EST over CoAP

Hi all,

At 

Re: [Ace] EST over CoAP

[Panos Kampanakis (pkampana)]

Hi Hannes,

To address your question about server-side key gen, below is the explanation we 
have put in the draft already and will be in the next iteration
~
   Constrained devices sometimes do not have the necessary hardware to
   generate statistically random numbers for private keys and DTLS
   ephemeral keys.  Past experience has shown that cheap endpoints
   sometimes generate numbers which could allow someone to decrypt the
   communication or guess the private key and impersonate as the device.
   Studies have shown that the same keys are generated by the same model
   devices deployed on-line.

   Additionally, random number key generation is costly, thus energy
   draining.  Even though the random numbers that constitute the
   identity/cert do not get generated often, an endpoint may not want to
   spend time and energy generating keypairs, and just ask for one from
   the server.

   In these scenarios, server-side key generation can be used.  The
   client asks for the server or proxy to generate the private key and
   the certificate which is transferred back to the client in the
   server-side key generation response.
~

This is a need that we have heard from customers at Cisco.

About the proxy-Registrar question, we already have made the change in the 
working copy of the draft as well. We no longer call this functionality 
proxying, but instead use the concept of the registrar that terminates the 
connection and establishes the next one.

We didn't add any new features in the doc after removing the BRSKI stuff.

If you want an early preview to comment on, we can share the repository with 
you.

Panos

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
To: ace@ietf.org
Subject: [Ace] EST over CoAP

Hi all,

At IETF#101 Peter presented a list of open issues with the EST over CoAP draft, 
see
https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-secure-coap-00


-Operational parameter values

-Server side key generation using simple multipart encoding

-Explain trust relations for http/coap proxying

I have challenged the usefulness of the server-side key generation during the 
meeting but in general I am curious where we are with the document. It would be 
great to get it finalized. It appears that we are adding new features and 
therefore will not be able to complete the work in any reasonable timeframe.

So, do we have a plan for how to complete the document?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Coordinated effort to produce updated profiles for the use of crypto algorithms in IoT

[Panos Kampanakis (pkampana)]

+1
Should consider analysis and recommendations by NIST’s LWC project too 
https://www.nist.gov/programs-projects/lightweight-cryptography
Panos

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, March 19, 2018 7:15 AM
To: John Mattsson ; ace@ietf.org
Subject: Re: [Ace] Coordinated effort to produce updated profiles for the use 
of crypto algorithms in IoT

Here is a relevant document: 
https://tools.ietf.org/html/draft-tschofenig-uta-tls13-profile-00


From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of John Mattsson
Sent: 19 March 2018 11:11
To: ace@ietf.org
Subject: [Ace] Coordinated effort to produce updated profiles for the use of 
crypto algorithms in IoT

I strongly support Carsten’s suggestion to have a coordinated effort to produce 
updated profiles for the use of crypto algorithms in IoT. I think the work 
should include at least TLS, DTLS, COSE, and X.509 and take into consideration 
the hardware acceleration available in (future) devices. Should also look if 
there is a need to update X.509 profile in RFC 7925, any new IoT profile should 
be applicable to both TLS and COSE.

How do we get this started in a way that applies to all IETF groups using 
crypto? I would be happy to help with this work.

Some quick thoughts:

- Curve25519 is already implemented a lot, but needs to be differentiated from 
Ed25519 which is not implemented as much (yet) and may require CA support for 
certificate based deployments. Curve25519 and Ed25519 has a strong potential to 
lower latency, storage, memory, and battery consumptions in IoT devices. There 
was earlier vendors stating that curves with a cofactor caused problems for 
older hardware. My understanding is that this has now changed, at least the 
UICC vendors in 3GPP has stated that curve25519 works on their current hardware.

- ChaCha20-Poly1305 is only standardized with 128-bit tags and therefore not 
very well suited for IoT. Like GCM, Poly1305 is not very well suited for 
truncated tags. AES_128_OCB_8 only requires half the amount of AES operations, 
but AES is not drawing much power compared to transmitting, listening, and 
receiving radio, so any update from AES_128_CCM_8 might not be worth it. I 
think 64 bit tags is a good compromised between overhead and security for IoT.

-  PRF. TLS 1.3 used HMAC with SHA-256, RFC8247 specifies PRF_AES128_XCBC for 
devices not having SHA.

- Hash algorithms, Ed25519 is as far as I known standardized with SHA-512/256. 
IoT deployments of TLS and DTLS typically use SHA-256.

Cheers,
John
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[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  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 =-



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

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

[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 
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  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] Application Layer TLS

[Panos Kampanakis (pkampana)]

Someone had pointed it out on the mic in ACE @ IETF99, I think. Redefining well 
established protocol functionality like (D)TLS' to secure communications of 
other unencrypted application protocols comes with the risks of lack of vetting 
and scrutiny, test of time and mistakes though. 

I am not against this work, but I have seen many new secure protection channel 
establishment protocols and I am not sure there are no issues  which we don't 
see now that will manifest themselves later. 



-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael Richardson
Sent: Tuesday, November 21, 2017 1:48 PM
To: ace@ietf.org
Cc: Derek Atkins 
Subject: Re: [Ace] Application Layer TLS


Derek Atkins  wrote:
>> based on the recent email discussion about the DTLS proxy I thought it 
might
>> be useful that there was some thinking about how to run TLS/DTLS at the
>> application layer.

> I don't understand this statement.  The whole point of TLS/DTLS is that
> it runs at the Application Layer (as opposed to at the network layer,

DTLS has to provide many of the services of the Transport and Network layer 
(various amounts of reliability, fragmentation/segmentation) and there is 
overhead in that.  When running over things like CoAP, which *ALSO* provides 
those services, and in a more constrained network happy way, DTLS is way less 
appealing.

> Perhaps we need a better naming scheme here.

In my opinion, the ISO layer naming system has always been better as 
documentation, rather than architecture :-)

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



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

Re: [Ace] Early warning: Rewrite of vanderstok-ace-coap-est

[Panos Kampanakis (pkampana)]

Hi Hannes,
I think the current draft offers that. The BRSKI EST APIs are not mandatory to 
implement by any means. The bindings of just the EST (RFC7030) APIs explained 
in the doc would suffice. If you are saying that the current doc is too 
complicated, may that is something that can be addressed. If you are saying 
that there need to be two docs, one for pure EST and one for the BRSKI EST 
messages, maybe it makes sense. The list can chime in on that.
Looking forward to your draft.
Panos


From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Sunday, November 12, 2017 9:55 PM
To: ace@ietf.org
Subject: [Ace] Early warning: Rewrite of vanderstok-ace-coap-est

Hi all,

I had provided comments on the EST over CoAP document in the past. 
Unfortunately, my recommendations have been ignored and instead the document 
went into the other direction getting more complex with every draft version.

I need something that just allows me to run EST over CoAP - nothing more. As a 
result, I don't want profiling, don't want normative dependency to the ANIMA 
work, and don't want any relationship to IEEE 802.15.4. EST over CoAP should be 
able to run in a variety of context and over a number of networks.

For this purpose I am planning to write a new draft during this week that 
covers only one thing, namely carrying EST over CoAP without any profiling and 
without any new functionality.
If someone is interested in collaborating with me please drop me a note.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-selander-ace-eals vs. draft-vanderstok-ace-coap-est

[Panos Kampanakis (pkampana)]

Sorry for responding to this late. 

Full disclosure, I am also one of the authors of draft-vanderstok-ace-coap-est. 

draft-vanderstok-ace-coap-est uses well established DTLS to secure the COAP 
channel at the transport layer in order to carry the cert provisioning messages 
of EST. EST is a protocol that has certain advantages and has been seeing 
adoption for some time now. Some examples include Digicert 
https://www.digicert.com/news/2017-02-06-digicert-launches-auto-provisioning-for-iot-devices
 , Entrust 
https://www.entrustdatacard.com/blog/2017/may/certificate-management-to-client-or-not-to-client
 , Java Bouncy Castle https://www.bouncycastle.org/ , EJBCA 
https://sourceforge.net/p/ejbca/discussion/132019/thread/1d749923 , Cisco 
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_pki/configuration/xe-3s/sec-pki-xe-3s-book/sec-est-client-supp-pki.html
 , Samsung https://www.samsungknox.com/en/article/est-cmc-change-notes Of 
course DTLS, COAP are also well adopted and implemented. We have seen a few 
vendors asking EST run over COAP over DTLS specifically in lighting and IoT 
verticals in order to
  be bootstrapped and provisioned an identity. EALS on the other hand uses CMC 
messages over COAP by defining new URIs and new uses OSCOAP/EDHOC to secure the 
messages at the application layer. The CMC messages are similar to EST's and 
thus I don't see these as competing, but the new eals APIs are replicating 
functionality already existing in EST. Though, securing the messages at the 
application layer is a significant difference. There might be certain usecases 
for application layer security with OSCOAP like code size, but as already 
brought up in an earlier meeting the OSCOAP protections replicate the 
protections in DTLS at the transport layer. In other words, 
draft-vanderstok-ace-coap-est is based on established and trusted protocols 
that are already implemented and we have seen demand in the industry for this 
solution, thus the draft. EALS introduces newer protection mechanisms that 
could well have some usecases in the industry. 

I see the two drafts as defining two separate secure channels of securing the 
same COAP messages. I would suggest that the new protection mechanism offered 
in EALS could be a separate draft of protecting the EST-coap messages instead 
of DTLS, in order to reap the fruits of oscoap, but I would like to see the 
EST-coap message bindings be common without separate CMC messages. That way the 
BRSKI messages do not need to be redefined for bootstrapping over COAP either. 

I think these will be discussed in one of the upcoming interims, but I wanted 
to bring the points to prepare the discussion. 

Rgs,
Panos


-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, September 13, 2017 11:43 AM
To: Ace@ietf.org
Subject: [Ace] draft-selander-ace-eals vs. draft-vanderstok-ace-coap-est

Hi all,

in previous IETF meetings we had presentations on these two documents and it 
appears that there is an overlap. So far we haven't had a lot of discussions on 
these proposals on the list but since there seems to be interest from the folks 
attending the IETF meetings I am recommending to have a discussion about the 
direction we should go with this work.

Any thoughts?

Ciao
Hannes

___
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] Asymmetric signature performance

[Panos Kampanakis (pkampana)]

Not sure why you mentioned that factoring only applies to DH. As you know in 
RSA n=p*q and pubk*prk=1 mod (totient(n))=1 mod (p-1)(q-1). Thus, if an 
attacker could factor n (find p and q in this case) and solve for prk. So, 
factoring big numbers (n in this case) equals to breaking RSA. 

It is right that the primes in the paper were special and good SFNS targets. My 
argument was not that all 1024-bit RSA can be broken in 2 months. What I was 
saying was what the paper points out which is that there are weak 1024-bit n 
have been deployed and still exist which makes them good SNFS targets. If 
someone chose to keep deploying 1024 RSA, he is opening himself up for trouble. 

I am sorry, if security is the goal here, I could never agree that weak 
security with 1024-bit RSA can be considered security. Instead ECDSA and EdDSA 
are the secure and efficient options.

+1 on WalnutDSA. Needs further analysis as it is pretty new. 



-Original Message-
From: Derek Atkins [mailto:de...@ihtfp.com] 
Sent: Thursday, February 09, 2017 12:38 PM
To: Panos Kampanakis (pkampana) 
Cc: Derek Atkins ; ace@ietf.org
Subject: RE: [Ace] Asymmetric signature performance

Hi,

On Thu, February 9, 2017 12:20 pm, Panos Kampanakis (pkampana) wrote:
>
> About factoring 1024-bits,
> https://hal.inria.fr/hal-01376934/file/paper.pdf shows that a special 
> 1024-bit p was factored in 2 months. Also it explains that it is 
> possible to factor some primes used on the internet today. Going to 
> 1024 gives a false sense of security. Endorsing it in a standard to be 
> used for some years down the road makes me uncomfortable. 256-bit 
> ECDSA or EdDSA are more sufficient with good performance compared to RSA1024.

Please do not mix up 1024-bit Diffie-Hellman and 1024-bit RSA. They are 
different mechanisms and depend on different underlying math.  Everything you 
say above is about DH, which just does not apply when we're discussing RSA.  
You cannot "Factor a Prime"; by definition a prime's factors are 1 and itself 
(e.g. 11).

Yes, it is possible to create a DH-prime that allows easy solutions to the 
discrete-log problem.  And yes, it's easy to create an RSA key that's easily 
factored.  However, factoring a "good" 1024-bit RSA key is not "2 months" of 
effort.  c.f. https://en.wikipedia.org/wiki/RSA_numbers for a list of numbers 
and references to their factoring efforts over the years.

Yes, 256-bit ECC is more secure than 1024-bit RSA (128-bit security vs 80-bit 
security).  I cannot comment on the performance difference; I've been focusing 
on WalnutDSA which verifies orders of magnitude faster than either RSA or ECDSA.

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

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

Re: [Ace] Asymmetric signature performance

[Panos Kampanakis (pkampana)]

About factoring 1024-bits, https://hal.inria.fr/hal-01376934/file/paper.pdf 
shows that a special 1024-bit p was factored in 2 months. Also it explains that 
it is possible to factor some primes used on the internet today. Going to 1024 
gives a false sense of security. Endorsing it in a standard to be used for some 
years down the road makes me uncomfortable. 256-bit ECDSA or EdDSA are more 
sufficient with good performance compared to RSA1024.



-Original Message-
From: Derek Atkins [mailto:de...@ihtfp.com] 
Sent: Thursday, February 09, 2017 10:55 AM
To: Eliot Lear 
Cc: Panos Kampanakis (pkampana) ; Michael StJohns 
; ace@ietf.org
Subject: Re: [Ace] Asymmetric signature performance


On Thu, February 9, 2017 10:49 am, Eliot Lear wrote:
>
>
> On 2/9/17 4:45 PM, Derek Atkins wrote:
>> Hi,
>>
>> "Panos Kampanakis (pkampana)"  writes:
>>
>>> I am not saying symmetric keys are better than public key auth.
>>> I am saying that applying an 80-bit security level (RSA/DSA1024) 
>>> today offers a false sense of security. You might as well not 
>>> authenticate the messages.
>> I disagree.  I think in many cases an 80-bit asymmetric signature is 
>> better than a 128 (or even 256-bit) group-symmetric scheme, precisely 
>> because with the symmetric scheme you only need to acquire the group 
>> key from one node, which means you can attack ANY node, whereas with 
>> the asymmetric scheme you MUST attack the signing node (which can 
>> have better defenses).
>
> It can, Derek, but it might not.   Think light switch or doorbell button.

Sure, but it's still a single point of attack versus attacking *any member of 
the group*.  I.e., you have to direct the attack at the signing entity, which, 
as we seem to agree, *could* have better/stronger protections than the 
*weakest* member of the group.

This isn't perfect, but it's still IMHO a step in the right direction. 
"The Perfect is the enemy of the Good Enough"

> Eliot

-derek
-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

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

Re: [Ace] Asymmetric signature performance

[Panos Kampanakis (pkampana)]

I am not saying symmetric keys are better than public key auth. 
I am saying that applying an 80-bit security level (RSA/DSA1024) today offers a 
false sense of security. You might as well not authenticate the messages. 



-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael StJohns
Sent: Wednesday, February 08, 2017 5:48 PM
To: ace@ietf.org
Subject: Re: [Ace] Asymmetric signature performance

On 2/8/2017 10:56 AM, Panos Kampanakis (pkampana) wrote:
> One correction: 1024-bit RSA/DSA is not the same security level as 256-bit 
> curve ECDSA or Ed25519.

But neither is a group symmetric key of any sized used for 
authentication/authorization.

The point is that weaker but good enough security on the asymmetric side is 
going to be a better solution than ANY group symmetric key.

NIST et al have given some guidance about key strengths and their uses with 
respect to the broadest set of threats and following the guidance is pretty 
much good engineering.  But, looking at something like RSA
1024 bit (or the ECDSA equivalent of about 166 bits - I think that's the right 
number), and looking at the threat environment for the target application, and 
noting that it's trivial (protocol wise) to change out the size of the key 
(e.g. scale it) in higher threat environments,
1024/166 bits may not be a bad choice for minimum security for non-man rated 
IOT control things.

Mike



> To compare apples to apples you would need 3072-bit RSA/DSA sigs which ends 
> up being far worse in terms of sig size and performance.
>
> Agreed that symmetric group key auth has plenty of limitations.
>
> Panos
>
>
>
> -Original Message-
> From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael StJohns
> Sent: Tuesday, February 07, 2017 9:55 PM
> To: ace@ietf.org
> Subject: [Ace] Asymmetric signature performance
>
> Hi -
>
> This is sort of non-obvious, but one or two articles I read suggest that RSA 
> 1024 performance may be better than the ECDSA equivalent.
>
> The tradeoff here is obviously the size of the signature and the transmission 
> thereof, but...
>
> While 1024 bits isn't an ideal security strength for RSA, using any 
> asymmetric key system for source authentication in group systems is going to 
> be much better than trying to pretend that symmetric group key systems have 
> any authentication properties at all.
>
> I saw a PPT presentation by Hannes that  didn't include any RSA performance 
> numbers for the ARM processors even though the key sizes were compared. My 
> guess is that someone has numbers for 1024 RSA signatures on the tiny ARM 
> processors that might be useful to throw into the mix.
>
> https://www.cryptopp.com/benchmarks.html has comparison values for a specific 
> library.
>
> What I'm suggesting is that we figure out how to meet the "can't cost 
> anything" requirement with weaker asymmetric keys rather than accepting a low 
> end fantasy of symmetric key multicast authentication.
>
> Mike
>
>
>
>
> ___
> 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


___
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] Asymmetric signature performance

[Panos Kampanakis (pkampana)]

One correction: 1024-bit RSA/DSA is not the same security level as 256-bit 
curve ECDSA or Ed25519. To compare apples to apples you would need 3072-bit 
RSA/DSA sigs which ends up being far worse in terms of sig size and performance.

Agreed that symmetric group key auth has plenty of limitations. 

Panos



-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael StJohns
Sent: Tuesday, February 07, 2017 9:55 PM
To: ace@ietf.org
Subject: [Ace] Asymmetric signature performance

Hi -

This is sort of non-obvious, but one or two articles I read suggest that RSA 
1024 performance may be better than the ECDSA equivalent.

The tradeoff here is obviously the size of the signature and the transmission 
thereof, but...

While 1024 bits isn't an ideal security strength for RSA, using any asymmetric 
key system for source authentication in group systems is going to be much 
better than trying to pretend that symmetric group key systems have any 
authentication properties at all.

I saw a PPT presentation by Hannes that  didn't include any RSA performance 
numbers for the ARM processors even though the key sizes were compared. My 
guess is that someone has numbers for 1024 RSA signatures on the tiny ARM 
processors that might be useful to throw into the mix.

https://www.cryptopp.com/benchmarks.html has comparison values for a specific 
library.

What I'm suggesting is that we figure out how to meet the "can't cost anything" 
requirement with weaker asymmetric keys rather than accepting a low end fantasy 
of symmetric key multicast authentication.

Mike




___
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-vanderstok-core-coap-est-00

[Panos Kampanakis (pkampana)]

Hi Hannes,

Thank you. Let me try to address some of your questions.

> This sounds like a lot of constraints and I wonder whether this focus is just 
> a result of your personal interest or whether you believe this 
work cannot just be a new transport for EST.

EST is used in ANIMA's BRSKI used for bootstrapping endpoints. We have a few 
usecases that call for running EST/BRSKI over COAP as an consistent common 
protocol in some constrained environments. So that is how this draft was 
started.


> Do you believe that those two features are the ones that should be mandatory 
> to implement or is there less? Is there more?

cacerts, enroll, reenroll and ANIMA BRSKI's voucherrequest, voucher_status are 
probably going to be the MTI.


> How much text from other RFCs should be replicated in this document, 
> particularly from the EST RFC?

Good point. We should clean up repetitions from other drafts.


> Wouldn't it be useful to refer to RFC 7925 instead of writing new text for 
> the use of DTLS security?

Good point. There will be some more EST related DTLS explanations (for example 
POP) in the next iteration, but leveraging RFC7925 and clean up overlapping 
text is also important


> Do you have some early implementation experience with the suggested approach?

Indeed. The Nexus Group and SICS have an initial implementation.


Rgs,
Panos



-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, January 23, 2017 3:10 AM
To: Ace@ietf.org
Subject: [Ace] draft-vanderstok-core-coap-est-00

Hi Peter, Hi Sandeep,

thanks for putting this document together.

I read through it and have some high-level questions regarding the envisioned 
scope and purpose of the document.

The abstract, the introduction and the references suggest that the proposed 
mechanism is suitable for an IEEE 802.15.4 mesh network using 6lowpan in 
context of ANIMA using public key-based crypto only.

This sounds like a lot of constraints and I wonder whether this focus is just a 
result of your personal interest or whether you believe this work cannot just 
be a new transport for EST.

EST itself makes many of the features of the protocol optional already and 
there are essentially only two functions that really have to be implemented, 
namely

 * Simple PKI messages (using PKCS#10)
 * CA certificate retrieval

Do you believe that those two features are the onces that should be mandatory 
to implement or is there less? Is there more?


How much text from other RFCs should be replicated in this document, 
particularly from the EST RFC?

Wouldn't it be useful to refer to RFC 7925 instead of writing new text for the 
use of DTLS security?

Do you have some early implementation experience with the suggested approach?

Ciao
Hannes

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

Re: [Ace] App-layer security for CoAP using (D)TLS record layer

[Panos Kampanakis (pkampana)]

Hi Dan,
So if I understand this correctly, the intention of this draft is to describe 
how COAP header fields, options and data can be protected with DTLS (hence DTLS 
record) regardless of the key exchange mechanism. Is it intended as an 
alternative to OSCOAP/EDHOC?
Thanks,
Panos


-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Dan García Carrillo
Sent: Monday, January 16, 2017 6:00 PM
To: c...@ietf.org; ace@ietf.org
Cc: Dan García Carrillo 
Subject: [Ace] App-layer security for CoAP using (D)TLS record layer

Hello all: 

We submitted some time ago an I-D proposing the use of an active (D)TLS Record  
(e.g. running DTLS over CoAP or presenting a token with crypto material that is 
used to create the required keys for the DTLS record) to provide application 
level security for CoAP. 


https://tools.ietf.org/html/draft-garcia-core-app-layer-sec-with-dtls-record-00


The idea is to use an active (D)TLS record to protect part of the CoAP message 
following the rules established for OSCOAP:
 - The content to protect of a CoAP message (code, version, options to protect 
and payload if any) is fed to the (D)TLS record. 
 - The output is the CoAP content to protect with a (D)TLS record header 
prepended.
 - That would be set into the payload of a modified version of the original 
CoAP message (before it is protected) that only contains options that do not 
need to be protected.

We think this could add to an interesting discussion to the subject of Security 
for CoAP at application layer. 

Comments are welcome, 
Best Regards.
___
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] [Anima-bootstrap] EST over CoAP in ACE wg

[Panos Kampanakis (pkampana)]

Hi Michael,

This are interesting good points.

IMO, draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est do not 
necessarily need to define one transport mechanism. COAPS (over DTLS) is one 
obvious option but running over OSCOAP with EDHOC is another. One of the goals 
of these drafts (would need to be merged) is the binding between COAP messages 
and BRSKI / EST APIs for all the bootstrapping and cert enrollment transactions 
defined in the anima-bootstrapping-keyinfra doc and RFC7030. 
draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est address DTLS as 
transport mechanism right now, but could be expanded to define more than one 
transports. If the WG finds that as a better idea, normative language would 
need to be carefully of course and maybe an MTI option would need to be chosen.

I am curious about your workflow in 
https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html You are 
envisioning for the JCE to initiate the bootstrapping to the pledge, but 
wouldn't that better be defined in the anima-bootstrapping-keyinfra doc?

About 'simple system that can be used with PSKs as authentication', I was 
curious. Did you have TLS-PSK, or TLS-SRP or OSCOAP message auth with 
PSK/RPK/Cert? Anything more detail about these usecases?

A nit in " <--- CoAP POST /cert- [PKCS7 Certificate] ". That message 
would require the private key to be included with the cert since the pledge did 
not generate it by himself. EST defines CMS for this message. PKCS12 could 
suffice here as well with the challenge if the passphrase provisioning being 
the problem.

Rgs,
Panos

-Original Message-
From: Anima-bootstrap [mailto:anima-bootstrap-boun...@ietf.org] On Behalf Of 
Michael Richardson
Sent: Wednesday, December 07, 2016 2:38 PM
To: ace@ietf.org; 6ti...@ietf.org; 6tisch-secur...@ietf.org; 
anima-bootst...@ietf.org
Subject: Re: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg


I have read:
draft-pritikin-coap-bootstrap
and draft-vanderstock-core-coap-est

and over in the 6tisch security design team we have been trying to adapt the 
ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the 6tisch 
environment as a zero-touch enrollment process.
(Yes, I am an author involved in both WGs)

Peter (one of the authors of draft-vanderstock-core-coap-est) and Max (author 
of draft-pritikin-coap-bootstrap) are involved.

Both documents have good content, and we could combine them easily and wind up 
with a relatively straight forward description of how to run EST over COAPS.
But I don't think that this really solves the problems that we have.

However, the movement in
 draft-vucinic-6tisch-minimal-security (as phase 2, and one-touch)
and   draft-richardson-6tisch-dtsecurity-secure-join (as phase 1, zero-touch)
[both of which are being considered for adoption]

is to move away from DTLS and towards OSCOAP and EDHOC.

As such, what we would really like is an EST-like mechanism which runs over 
OSCOAP with EDHOC keying.  Ideally, it would also permit the process to be 
managed/initiated from the new device (the pledge), or from the JCE (Registrar, 
which might also be the AS in ACE terminology).

We want to initiate from the JCE so that we can:
  a) simplify the constrained device.
  b) manage the order and priority of join activities to avoid
 network congestion in constrained (mesh) networks.

On the other hand, some want a really simple system that can be used with PSKs 
as authentication, with the new nodes initiating.

I wrote this email last week to explain some of what I have in mind.
  https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html

I don't know if the EST work fits into ACE's charter, but given that ACE is 
where OSCOAP and EDHOC seem to be, I'm happy to work on a document here.

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



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

Re: [Ace] EST over CoAP in ACE wg

[Panos Kampanakis (pkampana)]

+1 on ACE taking up this work.

From: Kumar, Sandeep [mailto:sandeep.ku...@philips.com]
Sent: Monday, November 21, 2016 9:00 AM
To: ace@ietf.org
Cc: 'consulta...@vanderstok.org' ; Panos Kampanakis 
(pkampana) ; Shahid Raza 
Subject: EST over CoAP in ACE wg

Dear ACE members

Peter van Stok gave a short overview during the ACE f2f meeting on the work 
related to EST (RFC 7030) over DTLS secured CoAP 
(draft-vanderstok-core-coap-est-00<https://tools.ietf.org/html/draft-vanderstok-core-coap-est-00>).
 In the meeting there was general interest among the audience for the work and 
ACE as the preferred WG for this item. There are additional drafts and work on 
the same topic like the 
draft-pritikin-coap-bootstrap-01<https://tools.ietf.org/html/draft-pritikin-coap-bootstrap-01>
 and the email from Shahid 
https://www.ietf.org/mail-archive/web/ace/current/msg02029.html
The idea is to merge these into a single draft (already discussed among us).

We would like to get feedback on the mailing list if indeed ACE would be a 
right place to continue this work as was perceived during the f2f meeting. 
Please respond if you support (or not) the activity going forward in ACE wg.

Kind Regards
Sandeep




The information contained in this message may be confidential and legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified 
that any use, forwarding, dissemination, or reproduction of this message is 
strictly prohibited and may be unlawful. If you are not the intended recipient, 
please contact the sender by return e-mail and destroy all copies of the 
original message.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace