Re: [Ace] Early media-type registration for EST over CoAP

[Michael Richardson]

Hannes Tschofenig  wrote:
> I don't have a strong opinion about option #2 appears to be slightly
> better.

Oh, I misread your options before.

Hannes Tschofenig  wrote:
>> (RTT for the lookup vs extra bytes in the URL)
>> Are you asking me about these two options:
>> Option #1 - going through /.well-known/core
>> REQ: GET /.well-known/core?rt=ace.est
>> RES: 2.05 Content ; rt="ace.est"


>> Option #2 - using a /.well-known/est URL
>> REQ: GET /.well-known/est
>> RES: 2.05 Content ; rt="ace.est"

Option 2 is not substituting /.well-known/core for /.well-known/est
(and doing resource discovery and then learn one uses /est-root/rv, etc.)
but rather not doing resource discovery, just go directly
to /.well-known/est/rv, which is what we do in RFC7030.

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





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

[Ace] CA generated keys (was Re: EST over CoAP)

[Michael Richardson]

Michael StJohns  wrote:
> Basically, the argument I'm hearing again is that we have to have
> common protocols that work with the least capable devices in the same
> way that they work with more capable devices.   Which then is taken to
> mean that we have to limit the security of said protocols to what's
> available with those most limited devices.

This is not really what's going on here.

The argument is whether device generate private keys should be supported
in the constrained version of EST.  The RA/CA (RFC5280 terms) side of things
in generally assumed not be seriously contrained.
(I expect to install a CA on an openwrt based Turris home router, but that's
equivalent to a 15 year old laptop, and hardly counts as constrained)

There is no reason why a RA/CA(%) can't support server-side key generation
according to RFC7030 section 4.4 as well as permitting capable devices to
generate their own keys.

Having the CA generate keys seemed to be all the rage at some point.
I was never clear if this was because desktop OSes couldn't be trusted
to do it properly, or because end-users wanted their private key as
part of their mobile profile, or because of the implicit escrow that it
permitted. (Remember splitting signing and encrypting keys...)

Panos' situation is, I understand, that he has customers with an extensive
deployment of devices in the field.  They currently use a proprietary
enrollment and key distribution system.  They want to "upgrade" to CoAP-EST,
but clearly there are some concerns about local key generation.  I don't know
why exactly, but I suspect it has to with the validation (FIPS140) of the
libraries available on that platform: perhaps they are not validated to
create their own keys...(yet?)

But they can be field upgraded in an unattended fashion to use a standard
protocol, as long as they don't have to do new crypto tricks *today*.

(%)- In smaller/self-contained systems, the Registration Authority (RA) is
 often co-located (part of, implemented by the same system) with the
 Certificate Authority.
 I actually don't know if the RA or CA generates the private key.

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





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

[Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Roman Danyliw]

Hello!

A reminder to the WG, draft-ietf-ace-cwt-proof-of-possession is in WGLC.  
Please send feedback to the mailing list by Wednesday, May 23.

Thanks,
Roman and Jim

> -Original Message-
> From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Roman Danyliw
> Sent: Tuesday, May 08, 2018 6:19 PM
> To: ace@ietf.org
> Subject: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
> 
> Hello!
> 
> Consistent with the feedback from the editor team at the London meeting,
> we are starting a working group last call (WGLC) for the "Proof-of-Possession
> Key Semantics for CBOR Web Tokens (CWTs)" draft:
> 
> ** draft-ietf-ace-cwt-proof-of-possession-02
> ** https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-02
> 
> Please send comments to the mailing list -- feedback on issues or needed
> changes; as well as endorsements that this draft is ready.
> 
> This WGLC will end on Wednesday, May 23, 2018.
> 
> Thanks,
> 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] Early media-type registration for EST over CoAP

[Hannes Tschofenig]

I don't have a strong opinion about option #2 appears to be slightly better.

I guess hard-cording URLs will not work

-Original Message-
From: Michael Richardson [mailto:mcr+i...@sandelman.ca]
Sent: 16 May 2018 14:16
To: Hannes Tschofenig
Cc: ace@ietf.org
Subject: Re: [Ace] Early media-type registration for EST over CoAP


Hannes Tschofenig  wrote:
>> Hannes: do you have any opinion about the necessity of going through
>> /.well-known/core to get the short URL, vs just using a
>> /.well-known/est URL?

Yes, exactly.  Is option #1 useful enough to justify the code to parse links?  
Os is the code impact already paid for in your view?

> (RTT for the lookup vs extra bytes in the URL)
> Are you asking me about these two options:
> Option #1 - going through /.well-known/core
>  REQ: GET /.well-known/core?rt=ace.est
>  RES: 2.05 Content ; rt="ace.est"


> Option #2 - using a /.well-known/est URL
>  REQ: GET /.well-known/est
>  RES: 2.05 Content ; rt="ace.est"

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



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] Early media-type registration for EST over CoAP

[Hannes Tschofenig]

> Hannes: do you have any opinion about the necessity of going through 
> /.well-known/core to get the short URL, vs just using a /.well-known/est URL?
(RTT for the lookup vs extra bytes in the URL)

Are you asking me about these two options:

Option #1 - going through /.well-known/core

 REQ: GET /.well-known/core?rt=ace.est

 RES: 2.05 Content
   ; rt="ace.est"



Option #2 - using a /.well-known/est URL

 REQ: GET /.well-known/est

 RES: 2.05 Content
   ; rt="ace.est"



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] Early media-type registration for EST over CoAP

[Carsten Bormann]

I was thinking about media type parameters such as charset="utf-8". The RT 
value need to be registered separately, but we can be a bit lazy about that.. 

Sent from mobile

> On 16. May 2018, at 12:15, Hannes Tschofenig  
> wrote:
> 
> Hi Carsten,
> 
> Yes, I am talking about the Content-Format numbers for them.
> Would rt="ace.est" be the parameter you are talking about?
> 
> Ciao
> Hannes
> 
> -Original Message-
> From: Carsten Bormann [mailto:c...@tzi.org]
> Sent: 15 May 2018 11:45
> To: Hannes Tschofenig
> Cc: ace@ietf.org; core
> Subject: Re: [Ace] Early media-type registration for EST over CoAP
> 
>> On May 15, 2018, at 10:56, Hannes Tschofenig  
>> wrote:
>> 
>> I am curious whether it would be possible to ask for early media-type 
>> registration of at least these two types:
>> - application/pkcs7-mime
>> - application/pkcs10
> 
> There already are registered.
> 
> I think you are talking about getting Content-Format numbers for these?
> Do we need any parameters or content-codings with that?
> 
> Grüße, Carsten
> 
> 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] Early media-type registration for EST over CoAP

[Hannes Tschofenig]

Hi Carsten,

Yes, I am talking about the Content-Format numbers for them.
Would rt="ace.est" be the parameter you are talking about?

Ciao
Hannes

-Original Message-
From: Carsten Bormann [mailto:c...@tzi.org]
Sent: 15 May 2018 11:45
To: Hannes Tschofenig
Cc: ace@ietf.org; core
Subject: Re: [Ace] Early media-type registration for EST over CoAP

On May 15, 2018, at 10:56, Hannes Tschofenig  wrote:
>
> I am curious whether it would be possible to ask for early media-type 
> registration of at least these two types:
> - application/pkcs7-mime
> - application/pkcs10

There already are registered.

I think you are talking about getting Content-Format numbers for these?
Do we need any parameters or content-codings with that?

Grüße, Carsten

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

[Mohit Sethi]

Hi Panos,

I wonder what kind of devices you have in mind? On one hand, the devices 
are constrained enough not to have resources for generating 
cryptographic quality randomness. But they somehow have support for 
tamper-resistance identity protection? Is it cheaper to have 
tamper-resistance? And is it somehow more energy-efficient?


I understand that generating strong identities and storing them securely 
are different issues. But I would be interested to learn about IoT 
devices that have tamper-resistance storage but no possibility of 
generating cryptographic quality randomness. Also, what protocols do you 
think the devices would use for authenticating these identities?


--Mohit

On 05/15/2018 05:00 PM, Panos Kampanakis (pkampana) wrote:


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



___
Ace mailing list