[Ace] draft-moskowitz-ecdsa-pki-10

[Hannes Tschofenig]

Hi Henk, Frank, Michael, Bob,

thanks for this document.

I have a question regarding the IEEE 802.1AR-based of the description.

Here is what I understand for use of certificates from 802.1AR (with my wording 
because RFC 2119 language is often missing in the 1AR spec):

* The DevID certificate subject field is always present, but can be empty. An 
IDevID certificate subject field MUST be non-null and SHOULD include a unique 
device serial number encoded as the serialNumber attribute. The subject field 
can contain information identifying the supplier or manufacturer of the device.
* IDevIDs SHOULD use the GeneralizedTime value 1231235959Z in the notAfter 
field.
* The subjectAltName extension MAY be present in both DevID certificates and 
DevID intermediate certificates. If a DevID certificate includes a 
subjectAltName, that field should include a HardwareModuleName. When a TPM is 
used to provide DevID module functionality the IDevID certificate contains a 
subjectAltName that uses a HardwareModuleName to identify the TPM, the hwType 
identifying the TPM Version and the hwSerialNum containing the TPM Serial 
Number.
* All certificates contain the authorityKeyIdentifier (as a non-critical 
extension).
* Intermediate certificates contain the subjectKeyIdentifier, as a non-critical 
extension. The subjectKeyIdentifier extension SHOULD NOT be included in DevID 
certificates.
* If a critical keyUsage extension is included in the IDevID, it MUST include 
digitalSignature. The keyUsage extension MAY include keyEncipherment.

Is my reading of IEEE 802.1AR correct?

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] Hackathon#112 Participation

[Hannes Tschofenig]

Hi all,

I just checked the IETF hackathon wiki and noticed a low participation from IoT 
groups.

At the IETF#11 hackathon several folks worked together (see summary 
presentation at 
https://github.com/IETF-Hackathon/ietf111-project-presentations/blob/main/hackathon-lwm2m.pdf)
 and we made some progress.

Let's continue this coding experience at the IETF#112 hackathon. If you are 
interested to work together at next hackathon, please drop me an email.

Arm is happy to support IoT hackathon participants with hardware*.

Ciao
Hannes

(*) Cortex M developer boards, to be more precise.
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] Correction

[Hannes Tschofenig]

Hi all,

I noticed room for a correction in Appendix E, which currently says:



   o  Access token retention -- in OAuth 2.0, the access token is sent

  with each request to the RS.  In this framework, the RS must be

  able to store these tokens for later use.  See Section 
5.10.1.

It is not correct to say that OAuth requires every request to contain the 
access token.

I have corrected this statement with this PR here:
https://github.com/ace-wg/ace-oauth/pull/195

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] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

[Hannes Tschofenig]

Hi Francesca,

CBOR is used in different places throughout the document. There are several 
different interfaces (C<->AS, C<->RS, RS<->AS and also the token encoding 
itself).

For which part does the document give you the impression that CBOR is mandatory?

Ciao
Hannes

PS: I will dig out discussion with the OAuth group on the issue of PoP tokens 
and how to request a PoP token with HTTP over the client-to-AS interface to 
then present it via a different transport to the RS.

-Original Message-
From: Francesca Palombini 
Sent: Thursday, March 25, 2021 3:59 PM
To: Cigdem Sengul ; Francesca Palombini 
; Hannes Tschofenig 

Cc: Seitz Ludwig ; The IESG ; 
ace-cha...@ietf.org; draft-ietf-ace-oauth-au...@ietf.org; ace@ietf.org; 
sec-...@ietf.org
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on 
draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

Hi Cigdem,

I just quickly scanned the MQTT profile, and noticed that for example the C-AS 
interaction defined in the MQTT-TLS profile (using a new media type 
"application/ace+json") do not map with what is currently defined in the ACE 
framework (which maps more closely to what OAuth 2.0 does, using 
"application/x-www-form-urlencoded" format with a character encoding of UTF-8 
in the HTTP request entity-body for example for the C-AS request).

My comment on point 13. is that: right now I read the framework as "it requires 
CBOR" for this exchange, and I agree with you this didn't seem to go with the 
rest of the specification - I was not requesting CBOR to be made mandatory, on 
the contrary I was pointing out an inconsistency within the document.

To re-iterate: I am ok with keeping a different encoding than CBOR in, but I do 
believe it needs clarification in the document. Also I did not suggest to 
remove HTTP from the specification.

Hannes - could you please remind me the substance of the discussion and the 
motivations for having this flexibility on encoding? Ludwig mentions "to allow 
legacy OAuth 2.0 equipment (i.e. not supporting ACE) to be used in ACE 
interactions on those legs of the communication where no constrained devices 
are involved." I feel like it would not be hard for OAuth2.0 ASes to support 
CBOR, they would need to support more processing defined by the Ace framework 
anyway.. Again, as I said several times, I am ok with stepping back, I just 
wanted to make sure I understood the motivation for a discussion which I 
haven't followed closely.

Francesca

On 25/03/2021, 15:10, "Cigdem Sengul"  wrote:

Hello,
I would like to add my two cents to this as the MQTT-TLS profile does use
HTTP/JSON for client-AS and rs-AS communication as similar already was
supported in MQTT implementations between an MQTT broker and external
servers (e.g., via auth plug-ins).

For points like 13: Making CBOR mandatory would break how it is implemented
for MQTT-TLS, which implements the AS creation hints as a User Property
inside an MQTT message.
"The User Property is a UTF-8 string pair, composed of a name and a value.
The name of the User Property MUST be set to
   "ace_as_hint".  The value of the user property is a UTF-8 encoded
   JSON string containing the mandatory "AS" parameter, and the optional
   parameters "audience", "kid", "cnonce", and "scope" as defined in
   Section 5.1.2 of the ACE framework"

Kind regards,
--Cigdem



On Thu, Mar 25, 2021 at 1:53 PM Francesca Palombini  wrote:

> Ludwig,
>
> Thank you for the quick reply, and for the useful background information.
>
> As I said, I think this document is important and should move forward
> asap, and it can do so without changing the main assumptions, with some
> additional clarifications in the text about CBOR vs "other" when HTTP is
> used (which in my opinions are necessary - see points 1, 8, 10, 11, 13, 
15,
> 17, 22, 23, 26, 28).
>
> What I wanted to highlight is that it would simplify the document a lot to
> just remove this flexibility, for which I don't understand the motivation,
> and say "CBOR is mandatory" even when HTTP is used. The flexibility could
> be added in a future document if needed. However, I understand that there
> is history in the working group, and I will step back and remove my 
DISCUSS
> if I am in the rough. Note however that in terms of work on the document I
> suspect that keeping this flexibility will require more work, not less.
>
> Looking forward to discussing this with Ben during the telechat.
> Francesca
>
> On 25/03/2021, 08:50, "iesg on behalf of Seitz Ludwig" <
> iesg-boun...@ietf.org on behalf of ludwig.se

Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

[Hannes Tschofenig]

Hi all,

what is the motivation for re-opening the discussion about this aspect? This 
was discussed in the working group before and we reached a conclusion about 
what we want to support.

The use of HTTP/JSON is extremely useful.

Ciao
Hannes

-Original Message-
From: Cigdem Sengul 
Sent: Thursday, March 25, 2021 3:10 PM
To: Francesca Palombini 
Cc: Seitz Ludwig ; The IESG ; 
art-...@ietf.org; ace-cha...@ietf.org; draft-ietf-ace-oauth-au...@ietf.org; 
ace@ietf.org
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on 
draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

Hello,
I would like to add my two cents to this as the MQTT-TLS profile does use 
HTTP/JSON for client-AS and rs-AS communication as similar already was 
supported in MQTT implementations between an MQTT broker and external servers 
(e.g., via auth plug-ins).

For points like 13: Making CBOR mandatory would break how it is implemented for 
MQTT-TLS, which implements the AS creation hints as a User Property inside an 
MQTT message.
"The User Property is a UTF-8 string pair, composed of a name and a value.
The name of the User Property MUST be set to
   "ace_as_hint".  The value of the user property is a UTF-8 encoded
   JSON string containing the mandatory "AS" parameter, and the optional
   parameters "audience", "kid", "cnonce", and "scope" as defined in
   Section 5.1.2 of the ACE framework"

Kind regards,
--Cigdem



On Thu, Mar 25, 2021 at 1:53 PM Francesca Palombini  wrote:

> Ludwig,
>
> Thank you for the quick reply, and for the useful background information.
>
> As I said, I think this document is important and should move forward
> asap, and it can do so without changing the main assumptions, with
> some additional clarifications in the text about CBOR vs "other" when
> HTTP is used (which in my opinions are necessary - see points 1, 8,
> 10, 11, 13, 15, 17, 22, 23, 26, 28).
>
> What I wanted to highlight is that it would simplify the document a
> lot to just remove this flexibility, for which I don't understand the
> motivation, and say "CBOR is mandatory" even when HTTP is used. The
> flexibility could be added in a future document if needed. However, I
> understand that there is history in the working group, and I will step
> back and remove my DISCUSS if I am in the rough. Note however that in
> terms of work on the document I suspect that keeping this flexibility will 
> require more work, not less.
>
> Looking forward to discussing this with Ben during the telechat.
> Francesca
>
> On 25/03/2021, 08:50, "iesg on behalf of Seitz Ludwig" <
> iesg-boun...@ietf.org on behalf of ludwig.se...@combitech.se> wrote:
>
> Hello Francesca,
>
> Thank you for your review. I will address your detailed comments
> separately, with regards to your DISCUSS:
>
> The option to allow both HTTP and JSON for any leg of the
> communication (client-AS, rs-AS, client-rs) was the result of long
> discussions in the WG. If I recall correctly the intent was to allow
> legacy OAuth 2.0 equipment (i.e. not supporting ACE) to be used in ACE
> interactions on those legs of the communication where no constrained
> devices are involved.
> I am reluctant to reopen these discussions at this point in time,
> and I suspect doing the necessary analysis to provide in-depth
> considerations on the choices between HTTP/CoAP and JSON/CBOR will
> significantly delay the progress of this document.
>
> @ace-chairs: What is your suggestion on how to best handle this?
> (Please note that I am unable to commit significant amounts of
> time to this work in the foreseeable future)
>
> Regards,
>
> Ludwig
>
>
> > -Original Message-
> > From: Ace  On Behalf Of Francesca
> Palombini via
> > Datatracker
> > Sent: den 24 mars 2021 15:50
> > To: The IESG 
> > Cc: art-...@ietf.org; ace-cha...@ietf.org; draft-ietf-ace-oauth-
> > au...@ietf.org; ace@ietf.org
> > Subject: [EXTERNAL] [Ace] Francesca Palombini's Discuss on
> draft-ietf-ace-
> > oauth-authz-38: (with DISCUSS and COMMENT)
> >
> > Francesca Palombini has entered the following ballot position for
> > draft-ietf-ace-oauth-authz-38: 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-oauth-authz/
> >
> >
> >
> >
> --
> > DISCUSS:
> >
> --
> >
> > Thank you for this document.

Re: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

[Hannes Tschofenig]

Hi all,

This is an interesting case.

CWT was created based on the work on ACE-OAuth. I would therefore agree with 
Ludwig that it should receive priority treatment with regards to the selection 
of the value encodings.

I do, however, also have sympathy for the argument Chuck mentioned regarding 
the scope encoded as a string. Of course, there is no need to encode the scope 
as a human-readable string.

The main question is whether we should argue about one byte.

Highly-paid ACE chairs: what is your opinion?

Ciao
Hannes


From: Jim Schaad 
Sent: Saturday, March 21, 2020 4:32 PM
To: 'Seitz Ludwig' ; 'Mike Jones' 
; 'Chuck Mortimore' ; 
Hannes Tschofenig 
Cc: chuck.mortim...@visa.com; cwt-reg-rev...@ietf.org; 
draft-ietf-ace-oauth-au...@ietf.org; drafts-expert-rev...@iana.org; ace@ietf.org
Subject: RE: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

No you should not need to make any changes in the document.  This will be taken 
care of by the RFC Editor.

Jim


From: Ace mailto:ace-boun...@ietf.org>> On Behalf Of 
Seitz Ludwig
Sent: Saturday, March 21, 2020 3:35 AM
To: Mike Jones 
mailto:michael.jo...@microsoft.com>>; Chuck 
Mortimore mailto:charliemortim...@gmail.com>>; 
hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>
Cc: chuck.mortim...@visa.com<mailto:chuck.mortim...@visa.com>; 
cwt-reg-rev...@ietf.org<mailto:cwt-reg-rev...@ietf.org>; 
draft-ietf-ace-oauth-au...@ietf.org<mailto:draft-ietf-ace-oauth-au...@ietf.org>;
 drafts-expert-rev...@iana.org<mailto:drafts-expert-rev...@iana.org>; 
ace@ietf.org<mailto:ace@ietf.org>
Subject: Re: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

Please disregard the last message (small keyboard, large fingers). What I 
intended to write was this:

Sorry for the delay, I’ve now looked into the changes necessary and it 
basically is this line in the draft:

8.13. CBOR Web Token Claims
[…]
Claim Key: TBD (suggested: 9) -> … suggested: 42)

I wonder if I need to make this change at all since the value is only suggested 
(and we now have a diverging decision by the designated experts). Can  IANA 
clarify this for me?

Thank you for your patience,


Ludwig


From: Seitz Ludwig mailto:ludwig.se...@combitech.se>>
Sent: den 21 mars 2020 11:26
To: Seitz Ludwig mailto:ludwig.se...@combitech.se>>; 
Mike Jones mailto:michael.jo...@microsoft.com>>; 
Chuck Mortimore 
mailto:charliemortim...@gmail.com>>; 
hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>
Cc: chuck.mortim...@visa.com<mailto:chuck.mortim...@visa.com>; 
ace@ietf.org<mailto:ace@ietf.org>; 
draft-ietf-ace-oauth-au...@ietf.org<mailto:draft-ietf-ace-oauth-au...@ietf.org>;
 drafts-expert-rev...@iana.org<mailto:drafts-expert-rev...@iana.org>; 
cwt-reg-rev...@ietf.org<mailto:cwt-reg-rev...@ietf.org>
Subject: RE: [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

Hello all, soo

From: Ace mailto:ace-boun...@ietf.org>> On Behalf Of 
Seitz Ludwig
Sent: den 17 mars 2020 10:01
To: Mike Jones 
mailto:michael.jo...@microsoft.com>>; Chuck 
Mortimore mailto:charliemortim...@gmail.com>>; 
hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>
Cc: chuck.mortim...@visa.com<mailto:chuck.mortim...@visa.com>; 
ace@ietf.org<mailto:ace@ietf.org>; 
draft-ietf-ace-oauth-au...@ietf.org<mailto:draft-ietf-ace-oauth-au...@ietf.org>;
 drafts-expert-rev...@iana.org<mailto:drafts-expert-rev...@iana.org>; 
cwt-reg-rev...@ietf.org<mailto:cwt-reg-rev...@ietf.org>
Subject: Re: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

Fair enough, take my points as the author’s opinion only.  That leaves us with 
3 experts to make the decision. Your position is clear, Chuck hasn’t commented 
on the latest exchange but he was agreeing with you before. I propose we give 
Hannes another day and if he doesn’t comment we go ahead with your decision, is 
that acceptable for you?

/Ludwig


From: Mike Jones 
mailto:michael.jo...@microsoft.com>>
Sent: den 16 mars 2020 19:43
To: Seitz Ludwig mailto:ludwig.se...@combitech.se>>; 
Chuck Mortimore 
mailto:charliemortim...@gmail.com>>; 
hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>
Cc: drafts-expert-rev...@iana.org<mailto:drafts-expert-rev...@iana.org>; 
cwt-reg-rev...@ietf.org<mailto:cwt-reg-rev...@ietf.org>; 
chuck.mortim...@visa.com<mailto:chuck.mortim...@visa.com>; 
draft-ietf-ace-oauth-au...@ietf.org<mailto:draft-ietf-ace-oauth-au...@ietf.org>;
 ace@ietf.org<mailto:ace@ietf.org>
S

Re: [Ace] Using OAuth and ACE-OAuth with MQTT

[Hannes Tschofenig]

Ludwig, you are right. I missed that. I was incorrectly looking at 
draft-ietf-ace-oauth-params-12 where all the parameters are.
I will delete my PR.

Ciao
Hannes

-Original Message-
From: Seitz Ludwig 
Sent: Tuesday, March 17, 2020 12:41 PM
To: Hannes Tschofenig ; Jim Schaad 

Cc: 'Cigdem Sengul' ; 'Ace Wg' 
Subject: RE: Using OAuth and ACE-OAuth with MQTT

I'm sorry if I'm being daft here, but what is the difference to
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-8.5  ?

/Ludwig

-----Original Message-
From: Hannes Tschofenig 
Sent: den 17 mars 2020 12:38
To: Jim Schaad ; Seitz Ludwig 

Cc: 'Cigdem Sengul' ; 'Ace Wg' 
Subject: RE: Using OAuth and ACE-OAuth with MQTT

Hi Jim, Hi Ludwig,

I created a PR at https://github.com/hannestschofenig/ace-oauth-params/pull/1

I wasn't quite sure how to set two registry values, namely (a) Additional Token 
Endpoint Response Parameters and (b) HTTP Authentication Scheme(s).
For (a) I used "none" and for (b) I used "Bearer".

Ciao
Hannes

-Original Message-
From: Hannes Tschofenig
Sent: Wednesday, March 11, 2020 8:34 AM
To: Jim Schaad 
Cc: 'Cigdem Sengul' ; 'Ace Wg' 
Subject: RE: Using OAuth and ACE-OAuth with MQTT

Hi Jim,

I believe you are right that the functionality is supported. In retrospect it 
is good that Ludwig just imported the key transport necessary functionality 
with draft-ietf-ace-oauth-params-12. Hence, you can do pretty everything 
defined in draft-ietf-oauth-pop-key-distribution with the ACE-OAuth framework. 
Only one piece is missing in the IANA consideration section, namely the 
registration of "pop" in the "OAuth Access Token Types" registry. That needs to 
be added. Not a big deal though. I will send text to Ludwig.

I am happy.

Ciao
Hannes

PS: I am not sure whether the authentication mechanisms defined in 
draft-ietf-ace-mqtt-tls-profile are actually sound. Maybe I should do a formal 
analysis.

-Original Message-
From: Jim Schaad 
Sent: Wednesday, March 11, 2020 12:10 AM
To: Hannes Tschofenig 
Cc: 'Cigdem Sengul' ; 'Ace Wg' 
Subject: Using OAuth and ACE-OAuth with MQTT

Hannes,

This is going to be a long email and I hope that I do not get too many things 
wrong in the process of getting it written up.

So the question that you raised is can the current MQTT profile use the 
existing OAuth and ACE-OAuth protocols.  My assertion is that the answer is yes 
and I will walk through the two different protocols in order to demonstrate 
this.  For simplicilty I am only going to deal with one of the TLS 
configurations that the MQTT profile envisions.

For TLS authentication, the server is to be validated by using an X.509 
certificate and there is to be a method for the client to be able to associate 
the identifier in the certificate with the OAuth token request.
This I assume is a well understood problem in the OAuth WG.  The client is not 
authenticated to the server by TLS, this is deferred to MQTT protocol.
When using ACE-OAuth, this is generally going to be tied through the audience 
field in some method.

The format of the scope field is defined in the MQTT document and the AS will 
need to be able to parse that field and do the proper enforcement.  I think 
this different than what a normal OAuth AS does where the scope is a single 
value rather than a composite value.

The key which is placed in the token is going to be an asymmetric signing key.  
This is the standard thing for OAuth.  At some point in the future it might be 
nice to allow for symmetric keys to be sent out, but for now the ACE-OAuth is 
sufficient for dealing with that case.

Using OAuth

The client makes a request to an OAuth authorization server for a token.
The grant_type for the token is going to be "client_credentials", the scope is 
a text string defined by the MQTT profile document.  Authorization is needed 
for the connection.  My assumption is that this is now normally done by the use 
of HTTPS rather than something like basic authentication.

**

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&
scope=publish_topic1/topic2%2Epublish_topic3/+/stats%2Esubscribe_topic3/#

**

The AS response with a standard message

**

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

{
 "access_token":". JWT token ..",  "token_type":"bearer",
 "expires_in": 3600,
}

**

The client now connects to the MQTT server using TLS, validating the 
certificate of the server against it's trust anchors and the "known" name of 
the MQTT server.

The client now sends an MQTT CONNECT message to th

Re: [Ace] Using OAuth and ACE-OAuth with MQTT

[Hannes Tschofenig]

Hi Jim, Hi Ludwig,

I created a PR at https://github.com/hannestschofenig/ace-oauth-params/pull/1

I wasn't quite sure how to set two registry values, namely (a) Additional Token 
Endpoint Response Parameters and (b) HTTP Authentication Scheme(s).
For (a) I used "none" and for (b) I used "Bearer".

Ciao
Hannes

-Original Message-
From: Hannes Tschofenig
Sent: Wednesday, March 11, 2020 8:34 AM
To: Jim Schaad 
Cc: 'Cigdem Sengul' ; 'Ace Wg' 
Subject: RE: Using OAuth and ACE-OAuth with MQTT

Hi Jim,

I believe you are right that the functionality is supported. In retrospect it 
is good that Ludwig just imported the key transport necessary functionality 
with draft-ietf-ace-oauth-params-12. Hence, you can do pretty everything 
defined in draft-ietf-oauth-pop-key-distribution with the ACE-OAuth framework. 
Only one piece is missing in the IANA consideration section, namely the 
registration of "pop" in the "OAuth Access Token Types" registry. That needs to 
be added. Not a big deal though. I will send text to Ludwig.

I am happy.

Ciao
Hannes

PS: I am not sure whether the authentication mechanisms defined in 
draft-ietf-ace-mqtt-tls-profile are actually sound. Maybe I should do a formal 
analysis.

-Original Message-
From: Jim Schaad 
Sent: Wednesday, March 11, 2020 12:10 AM
To: Hannes Tschofenig 
Cc: 'Cigdem Sengul' ; 'Ace Wg' 
Subject: Using OAuth and ACE-OAuth with MQTT

Hannes,

This is going to be a long email and I hope that I do not get too many things 
wrong in the process of getting it written up.

So the question that you raised is can the current MQTT profile use the 
existing OAuth and ACE-OAuth protocols.  My assertion is that the answer is yes 
and I will walk through the two different protocols in order to demonstrate 
this.  For simplicilty I am only going to deal with one of the TLS 
configurations that the MQTT profile envisions.

For TLS authentication, the server is to be validated by using an X.509 
certificate and there is to be a method for the client to be able to associate 
the identifier in the certificate with the OAuth token request.
This I assume is a well understood problem in the OAuth WG.  The client is not 
authenticated to the server by TLS, this is deferred to MQTT protocol.
When using ACE-OAuth, this is generally going to be tied through the audience 
field in some method.

The format of the scope field is defined in the MQTT document and the AS will 
need to be able to parse that field and do the proper enforcement.  I think 
this different than what a normal OAuth AS does where the scope is a single 
value rather than a composite value.

The key which is placed in the token is going to be an asymmetric signing key.  
This is the standard thing for OAuth.  At some point in the future it might be 
nice to allow for symmetric keys to be sent out, but for now the ACE-OAuth is 
sufficient for dealing with that case.

Using OAuth

The client makes a request to an OAuth authorization server for a token.
The grant_type for the token is going to be "client_credentials", the scope is 
a text string defined by the MQTT profile document.  Authorization is needed 
for the connection.  My assumption is that this is now normally done by the use 
of HTTPS rather than something like basic authentication.

**

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&
scope=publish_topic1/topic2%2Epublish_topic3/+/stats%2Esubscribe_topic3/#

**

The AS response with a standard message

**

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

{
 "access_token":". JWT token ..",  "token_type":"bearer",
 "expires_in": 3600,
}

**

The client now connects to the MQTT server using TLS, validating the 
certificate of the server against it's trust anchors and the "known" name of 
the MQTT server.

The client now sends an MQTT CONNECT message to the server passing the JWT 
token in as part of the Authentication Data (section 2.2.4 of the MQTT 
document).




Using ACE-OAuth

***

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/ace+json

{
  "scope": "publish_topic1/topic2 publish_topic3/+/stats subscribe_topic3/#",
  "audience": "mqtts://mqtt.example.com"
}

**

For ACE-OAuth, the default value of grant_type is client_credentials so that 
parameter is omitted.


*

HTTP/1.1 200 OK
Content-Type: application/ace+json

{
 "access_token":". JWT token ..",
 "expires_in": 3600,
 "ace_profile" : "mqtt_tls"
}

Re: [Ace] Using OAuth and ACE-OAuth with MQTT

[Hannes Tschofenig]

Hi Jim,

I believe you are right that the functionality is supported. In retrospect it 
is good that Ludwig just imported the key transport necessary functionality 
with draft-ietf-ace-oauth-params-12. Hence, you can do pretty everything 
defined in draft-ietf-oauth-pop-key-distribution with the ACE-OAuth framework. 
Only one piece is missing in the IANA consideration section, namely the 
registration of "pop" in the "OAuth Access Token Types" registry. That needs to 
be added. Not a big deal though. I will send text to Ludwig.

I am happy.

Ciao
Hannes

PS: I am not sure whether the authentication mechanisms defined in 
draft-ietf-ace-mqtt-tls-profile are actually sound. Maybe I should do a formal 
analysis.

-Original Message-
From: Jim Schaad 
Sent: Wednesday, March 11, 2020 12:10 AM
To: Hannes Tschofenig 
Cc: 'Cigdem Sengul' ; 'Ace Wg' 
Subject: Using OAuth and ACE-OAuth with MQTT

Hannes,

This is going to be a long email and I hope that I do not get too many things 
wrong in the process of getting it written up.

So the question that you raised is can the current MQTT profile use the 
existing OAuth and ACE-OAuth protocols.  My assertion is that the answer is yes 
and I will walk through the two different protocols in order to demonstrate 
this.  For simplicilty I am only going to deal with one of the TLS 
configurations that the MQTT profile envisions.

For TLS authentication, the server is to be validated by using an X.509 
certificate and there is to be a method for the client to be able to associate 
the identifier in the certificate with the OAuth token request.
This I assume is a well understood problem in the OAuth WG.  The client is not 
authenticated to the server by TLS, this is deferred to MQTT protocol.
When using ACE-OAuth, this is generally going to be tied through the audience 
field in some method.

The format of the scope field is defined in the MQTT document and the AS will 
need to be able to parse that field and do the proper enforcement.  I think 
this different than what a normal OAuth AS does where the scope is a single 
value rather than a composite value.

The key which is placed in the token is going to be an asymmetric signing key.  
This is the standard thing for OAuth.  At some point in the future it might be 
nice to allow for symmetric keys to be sent out, but for now the ACE-OAuth is 
sufficient for dealing with that case.

Using OAuth

The client makes a request to an OAuth authorization server for a token.
The grant_type for the token is going to be "client_credentials", the scope is 
a text string defined by the MQTT profile document.  Authorization is needed 
for the connection.  My assumption is that this is now normally done by the use 
of HTTPS rather than something like basic authentication.

**

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&
scope=publish_topic1/topic2%2Epublish_topic3/+/stats%2Esubscribe_topic3/#

**

The AS response with a standard message

**

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

{
 "access_token":". JWT token ..",  "token_type":"bearer",
 "expires_in": 3600,
}

**

The client now connects to the MQTT server using TLS, validating the 
certificate of the server against it's trust anchors and the "known" name of 
the MQTT server.

The client now sends an MQTT CONNECT message to the server passing the JWT 
token in as part of the Authentication Data (section 2.2.4 of the MQTT 
document).




Using ACE-OAuth

***

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/ace+json

{
  "scope": "publish_topic1/topic2 publish_topic3/+/stats subscribe_topic3/#",
  "audience": "mqtts://mqtt.example.com"
}

**

For ACE-OAuth, the default value of grant_type is client_credentials so that 
parameter is omitted.


*

HTTP/1.1 200 OK
Content-Type: application/ace+json

{
 "access_token":". JWT token ..",
 "expires_in": 3600,
 "ace_profile" : "mqtt_tls"
}



As can be seen, there are only minimal differences between what is sent out 
between the Vanilla and the ACE version of OAuth.  In both cases it is assumed 
that the client is going to know which asymmetric key is going to be used.  
There are a couple of differences however:

1.  I have used the value of "bearer" for "token_type" in OAuth because that 
seemed to me to be the one which mapped to the usage in a better manner.
The OAuth-ACE framework however registers the value of "PoP" and specifies it 
as th

Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03

[Hannes Tschofenig]

Hi Cigdem,

Following the OAuth virtual interim meeting call today I wonder whether it 
makes sense to describe how the key transport with the PoP token using the 
communication between the client and the authorization server over the HTTP 
interface works.

Ciao
Hannes


From: Hannes Tschofenig
Sent: Friday, February 28, 2020 11:08 AM
To: Cigdem Sengul 
Cc: ace@ietf.org
Subject: RE: [Ace] draft-ietf-ace-mqtt-tls-profile-03


  *   I plan to join. I  have been aware of the issue, but could not follow how 
it was planned to be resolved.
  *   I was looking at this: draft-ietf-oauth-pop-key-distribution

Yes, that’s what the group wanted to do. Now, new ideas showed up on the radar 
that are incompatible with that approach that offer a much tighter integration 
with HTTP signing.

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-ietf-ace-mqtt-tls-profile-03

[Hannes Tschofenig]

  *   I plan to join. I  have been aware of the issue, but could not follow how 
it was planned to be resolved.
  *   I was looking at this: draft-ietf-oauth-pop-key-distribution

Yes, that’s what the group wanted to do. Now, new ideas showed up on the radar 
that are incompatible with that approach that offer a much tighter integration 
with HTTP signing.

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-ietf-ace-mqtt-tls-profile-03

[Hannes Tschofenig]

Hi Cigdem,

Thanks for your quick response.

From the text you cited regarding MQTT v5 it is not backwards compatible to 
version 3.1.1. The exact impact of working between two devices of different 
versions has not been described in the spec either. The follow sentence in your 
introduction can easily give readers the impression that the two versions are 
backwards compatible. Here is the sentence:

" It is expected that MQTT
   deployments will retain backward compatibility for MQTT v3.1.1
   clients, and therefore, this document also describes a reduced set of
   protocol interactions for MQTT v3.1.1 - the OASIS Standard
   [MQTT-OASIS-Standard].
"

Maybe you want to change the wording a little bit.  I think the reason why you 
want to describe a solution for v3.1.1 is that this is the widely deployed 
version.

Regarding the broker term: It is probably a matter of taste but I would refer 
to the terms used in the spec and would not replicate the terminology from the 
OASIS MQTT specs in the draft. Someone who implements the draft will have to 
become familiar with MQTT anyway. But that’s just me. For example, I often see 
people using the term “certificate authorities (CA)” in their write-ups. RFC 
5280 defines and uses the term “certification authority (CA)". While the two 
sound and look similar only one is actually correct.

I noticed you have put a normative dependency on 
[I-D.palombini-ace-coap-pubsub-profile]. I don't think it is necessary because 
it is not a requirement to implement the spec. You could use it on top of it -- 
or you could use something else as well. I would move it to the informative 
part. The added benefit of doing that is that you do not block your spec till 
that draft becomes RFC. On the other hand, RFC 6749, RFC 7800, and 
I-D.ietf-ace-cwt-proof-of-possession cannot be informative references when you 
use PoP tokens in your solution.

You might be interesting to hear that there is currently no way to obtain the 
keys for a PoP token over HTTP, which your solution requires. The virtual 
interim meeting in the OAuth group should probably be of interest to you.

Ciao
Hannes

From: Cigdem Sengul 
Sent: Tuesday, February 25, 2020 3:10 PM
To: Hannes Tschofenig 
Cc: ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03

Hello Hannes,

We used  broker as it is a widely accepted term in the MQTT Community for 
"server" e.g.,
majority of the provider would list also a broker implementation to refer to 
their server implementation.

With respect to whether 3.1,1 clients talking to v5, there may be some issues. 
This is what the spec says:

Non-normative Comment
If the Server distributes Application Messages to Clients at different protocol 
levels (such as MQTT V3.1.1) which do not support properties or other features 
provided by this specification, some information in the Application Message can 
be lost, and applications which depend on this information might not work 
correctly.

The spec also defines a protocol version error message:
If the [Client's] Protocol Version [in the CONNECT packet] is not 5 and the 
Server does not want to accept the CONNECT packet, the Server MAY send a 
CONNACK packet with Reason Code 0x84 (Unsupported Protocol Version) and then 
MUST close the Network Connection

So, whether a broker provides dual support would depend on the provider. E.g., 
the Mosquitto broker supports the different protocol versions.

Thanks,
--Cigdem

On Tue, Feb 25, 2020 at 10:01 AM Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com> wrote:
Hi Cigdem, Hi Anthony, Hi Paul,

Why are you using the term MQTT broker? My understanding of the MQTT spec is 
that there are only clients and servers - nothing more.

Is a MQTT v3.1.1 client able to talk to a MQTT v5 server? Would a MQTT v3.1.1 
client talk to a MQTT v5 client via a server that supports both v3.1.1 and v5?

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
mailto:Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
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] FW: Virtual Interim Meeting for the PoP Discussion

[Hannes Tschofenig]

This virtual interim meeting could be of interest to you if you care about 
getting access tokens using HTTP from the AS for use with some IoT protocol 
with the RS.

Some time ago we made the agreement that ACE would define the non-HTTP 
transports of information related to PoP tokens while OAuth focuses on the 
HTTP-based transport.

From: OAuth  On Behalf Of Hannes Tschofenig
Sent: Wednesday, February 26, 2020 6:22 PM
To: oauth 
Subject: [OAUTH-WG] Virtual Interim Meeting for the PoP Discussion


Hi all,



Here are the details for the virtual interim meeting to discuss the 
proof-of-possession tokens.



Date: March, 9th

Time: 6:00 PM - 7:30 PM Monday, (UTC+01:00) Amsterdam, Berlin, Bern, Rome, 
Stockholm, Vienna


Meeting number (access code): 641 458 628
Meeting password: BWsAF9rT



Webex link:

https://ietf.webex.com/ietf/j.php?MTID=m03e9c040f9cd66650e1663f1da17d294



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 
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.
BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Europe/Berlin
TZURL:http://tzurl.org/zoneinfo-outlook/Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T03
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20200226T170831Z
ATTENDEE;CN="";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:hannes.tschofe...@arm.com
ORGANIZER;CN="Web Authorization Protocol Working Group":MAILTO:oauth-cha...@ietf.org
DTSTART;TZID=Europe/Berlin:20200309T18
DTEND;TZID=Europe/Berlin:20200309T193000
LOCATION:https://ietf.webex.com/ietf/j.php?MTID=m03e9c040f9cd66650e1663f1da17d294
TRANSP:OPAQUE
SEQUENCE:1582736911
UID:2045d357-fe78-490a-b904-560dc7ae3602
DESCRIPTION:\n\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=m03e9c040f9cd66650e1663f1da17d294\nMeeting number (access code): 641 458 628\n\n\nMeeting password: BWsAF9rT\n\n\n\nJOIN BY PHONE\n1-650-479-3208 Call-in toll number (US/Canada)\nTap here to call (mobile phones only, hosts not supported): tel:%2B1-650-479-3208,,*01*641458628%23%23*01*\n\n\n\nJOIN FROM A VIDEO SYSTEM OR APPLICATION\nDial sip:641458...@ietf.webex.com\nYou can also dial 173.243.2.68 and enter your meeting number.\n\n\nJoin using Microsoft Lync or Microsoft Skype for Business\nDial sip:641458628.i...@lync.webex.com\n\n\n\nCan't join the meeting?\nhttps://collaborationhelp.cisco.com/article/WBX29055\n\n\nIMPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.\n
X-ALT-DESC;FMTTYPE=text/html:\n* {\npadding: 0;margin: 0;}\ntable {\n	border-collapse: separate; width =100%;	border: 0;	border-spacing: 0;}\n\ntr {\n	line-height: 18px;}\n\na, td {\n	font-size: 14px;	font-family: Arial;	color: #333;	word-wrap: break-word;	word-break: normal;	padding: 0;}\n\n.title {\n	font-size: 28px;}\n\n.image {\n	width: auto;	max-width: auto;}\n\n.footer {\n	width: 604px;}\n\n.main {\n\n}@media screen and (max-device-width: 800px) {\n	.title {\n		font-size: 22px !important;	}\n	.image {\n		width: auto !important;		max-width: 100% !important;	}\n	.footer {\n		width: 100% !important;		max-width: 604px !important\n	}\n	.main {\n		width: 100% !important;		max-width: 604px !important\n	}\n}\n\n\n\n	 \n	\n		\n			\n\n\n\n\n\n			\n\n	\n		When it's time, join the Webex meeting here.\n	\n\n \n\n	\n		Meeting number (access code): 641 458 628\n	\n\n			\n			\n			Meeting password:BWsAF9rT\n\n\n	 \n			\n\n	\n		\n			https://ietf.webex.com/ietf/j.php?MTID=m03e9c040f9cd66650e1663f1da17d294"; style="color:#FF; font-size:20px; text-decoration:none;">Join meeting\n		\n	\n\n			\n		\n\n \n  \n\n  Join by phone   1-650-479-3208 Call-in toll number (US/Canada)     \n\n \n\nJoin from a video system or applicationDial 641458...@ietf.webex.com  You can also dial 17

[Ace] draft-ietf-ace-mqtt-tls-profile-03

[Hannes Tschofenig]

Hi Cigdem, Hi Anthony, Hi Paul,

Why are you using the term MQTT broker? My understanding of the MQTT spec is 
that there are only clients and servers - nothing more.

Is a MQTT v3.1.1 client able to talk to a MQTT v5 server? Would a MQTT v3.1.1 
client talk to a MQTT v5 client via a server that supports both v3.1.1 and v5?

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] Transporting different types of cnf objects - CBOR vs JSON

[Hannes Tschofenig]

I believe the current approach is for the server to provide the symmetric key 
(rather than the client).

I have no idea when this topic gets resolved because folks keep changing their 
mind so quickly.

From: Cigdem Sengul 
Sent: Donnerstag, 3. Oktober 2019 12:37
To: Hannes Tschofenig 
Cc: Carsten Bormann ; Jim Schaad ; Ludwig 
Seitz ; ace@ietf.org
Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON

Hello,

Thank you for your responses.

Until this issue is resolved, is it OK just to point to RFC 7800, which says 
the client provides the symmetric PoP key?

For MQTT draft,  would like to explain that C-RS is MQTT - MQTT may carry 
JSON/CBOR encoding for the Data fields in the packets.

C-AS and RS-AS can be HTTPS/CoAP/MQTT - what we describe in the draft it is 
HTTPS; MQTT support needs more thought for request-response style communication.
For HTTPS/CoAP, application/ace+json or application/ace+cbor content formats.

Since this info is a bit muddled in the current draft, I would like to ensure 
there is a clear paragraph, which the workgroup would be fine with.

Thank you for your help.
Sincerely,
--Cigdem





On Thu, Oct 3, 2019 at 7:42 AM Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:
There is unfortunately a problem.

With proof-of-possession keys there is more than just conveying the CWT/JWT 
over another transport.
In the PK-case, the client has to provide the public key to the server and get 
it bound to the PoP token.
In the symmetric key case, the server has to provide the token along with the 
symmetric key that is also included although encrypted) in the PoP token.

We have standardized the transport of this additional information in ACE for 
use with CoAP but for HTTP we decided to do the work on OAuth, where it got 
stuck because the IoT-interested people are not there and the Web folks want 
something else.

Ciao
Hannes

-Original Message-
From: Ace mailto:ace-boun...@ietf.org>> On Behalf Of 
Carsten Bormann
Sent: Mittwoch, 2. Oktober 2019 15:05
To: Cigdem Sengul mailto:cigdem.sen...@gmail.com>>
Cc: Jim Schaad mailto:i...@augustcellars.com>>; Ludwig 
Seitz mailto:ludwig.se...@ri.se>>; 
ace@ietf.org<mailto:ace@ietf.org>
Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON

There is no strong interdependency between Web transfer protocol (HTTPS/CoAPS) 
and data format.
COSE works great over HTTPS, and if it must be, you can ship JOSE over CoAPS.

Grüße, Carsten


> On Oct 2, 2019, at 14:00, Cigdem Sengul 
> mailto:cigdem.sen...@gmail.com>> wrote:
>
> Hello all,
>
> I am trying to implement this discussion in the draft.  A point is raised 
> about COSE keys in JSON messages.
> Could it be possible to go with:
> (1) HTTPS - application/ace+json - jwt - jose - PoP for JWT or
> (2) CoAP - application/ace+cbor - cwt - cose - PoP for CWT without
> mixing anything?
>
> (1) we thought to describe by default in the document, and (2) we said MAY be 
> supported.
> Is there a problem with this approach?
>
> Thanks,
> --Cigdem
>
>
> On Tue, Jun 4, 2019 at 9:29 PM Cigdem Sengul 
> mailto:cigdem.sen...@gmail.com>> wrote:
> Hello,
> Yes, we thought supporting JSON option would be good, though indeed there is 
> no issue with transporting CBOR..
> If there are no other concerns, we can define the new media type in the MQTT 
> draft.
> Will add the issue to GitHub repo.
>
> --Cigdem
>
> On Tue, Jun 4, 2019 at 7:37 PM Jim Schaad 
> mailto:i...@augustcellars.com>> wrote:
>
>
> > -Original Message-
> > From: Ace mailto:ace-boun...@ietf.org>> On Behalf Of 
> > Ludwig Seitz
> > Sent: Monday, June 3, 2019 11:51 PM
> > To: ace@ietf.org<mailto:ace@ietf.org>
> > Subject: Re: [Ace] Transporting different types of cnf objects -
> > CBOR vs JSON
> >
> > On 01/06/2019 02:51, Jim Schaad wrote:
> > > Ludwig,
> > >
> > > I have been doing some adaptions of my codebase for dealing with
> > > the MQTT specification.  In the process of this, I have identified
> > > the following items that I think needs some discussion.  They may
> > > not need changes in any documents and maybe should get a new document.
> > >
> > > 1.  The MQTT document is using the content type "application/json"
> > > over HTTPS for transporting messages.  Does there need to be an
> > > "application/ace+json" defined as a media type, but not
> > > necessarily a CBOR media type?  I think the answer may be yes, but
> > > it could be a new
> > document.
> > >
> > I would argue that the first draft using such a media type would be
> > the right place to specify it. However I'm not sure using JSON is
&g

Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON

[Hannes Tschofenig]

There is unfortunately a problem.

With proof-of-possession keys there is more than just conveying the CWT/JWT 
over another transport.
In the PK-case, the client has to provide the public key to the server and get 
it bound to the PoP token.
In the symmetric key case, the server has to provide the token along with the 
symmetric key that is also included although encrypted) in the PoP token.

We have standardized the transport of this additional information in ACE for 
use with CoAP but for HTTP we decided to do the work on OAuth, where it got 
stuck because the IoT-interested people are not there and the Web folks want 
something else.

Ciao
Hannes

-Original Message-
From: Ace  On Behalf Of Carsten Bormann
Sent: Mittwoch, 2. Oktober 2019 15:05
To: Cigdem Sengul 
Cc: Jim Schaad ; Ludwig Seitz ; 
ace@ietf.org
Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON

There is no strong interdependency between Web transfer protocol (HTTPS/CoAPS) 
and data format.
COSE works great over HTTPS, and if it must be, you can ship JOSE over CoAPS.

Grüße, Carsten


> On Oct 2, 2019, at 14:00, Cigdem Sengul  wrote:
>
> Hello all,
>
> I am trying to implement this discussion in the draft.  A point is raised 
> about COSE keys in JSON messages.
> Could it be possible to go with:
> (1) HTTPS - application/ace+json - jwt - jose - PoP for JWT or
> (2) CoAP - application/ace+cbor - cwt - cose - PoP for CWT without
> mixing anything?
>
> (1) we thought to describe by default in the document, and (2) we said MAY be 
> supported.
> Is there a problem with this approach?
>
> Thanks,
> --Cigdem
>
>
> On Tue, Jun 4, 2019 at 9:29 PM Cigdem Sengul  wrote:
> Hello,
> Yes, we thought supporting JSON option would be good, though indeed there is 
> no issue with transporting CBOR..
> If there are no other concerns, we can define the new media type in the MQTT 
> draft.
> Will add the issue to GitHub repo.
>
> --Cigdem
>
> On Tue, Jun 4, 2019 at 7:37 PM Jim Schaad  wrote:
>
>
> > -Original Message-
> > From: Ace  On Behalf Of Ludwig Seitz
> > Sent: Monday, June 3, 2019 11:51 PM
> > To: ace@ietf.org
> > Subject: Re: [Ace] Transporting different types of cnf objects -
> > CBOR vs JSON
> >
> > On 01/06/2019 02:51, Jim Schaad wrote:
> > > Ludwig,
> > >
> > > I have been doing some adaptions of my codebase for dealing with
> > > the MQTT specification.  In the process of this, I have identified
> > > the following items that I think needs some discussion.  They may
> > > not need changes in any documents and maybe should get a new document.
> > >
> > > 1.  The MQTT document is using the content type "application/json"
> > > over HTTPS for transporting messages.  Does there need to be an
> > > "application/ace+json" defined as a media type, but not
> > > necessarily a CBOR media type?  I think the answer may be yes, but
> > > it could be a new
> > document.
> > >
> > I would argue that the first draft using such a media type would be
> > the right place to specify it. However I'm not sure using JSON is
> > the right approach for an ACE specification at all, aren't we
> > supposed to cater for the constrained world?
> > What is there to prevent us from transporting CBOR over HTTP?
>
> There would be no reason that one cannot transport CBOR over HTTP.  During 
> the discussions for these drafts Hannes was very explicit that he wanted to 
> be able to use JSON rather than CBOR with the protocol that was defined by 
> ACE.  This would mean that there needs to be an ability to use JSON with the 
> ACE framework document.
>
> I would have no problems with the statement that the MQTT document would be a 
> good place to define the new media type.
>
> >
> > > 2.  If I use a "COSE_Key" confirmation method inside of an
> > > application/ace+json message, there is a potential problem and it
> > > could be dealt with in a number of different ways.
> > > *  The JWT confirmation method is identified as "jwk".  The COSE
> > > key must be translated into JOSE even if there is no equivalent
> > > key in JOSE.  I.e. that is a fatal error
> > > *  This does not make sense and the confirmation method should be
> > > changed to "cwk" so that either key format could be used in either
> > encoding.
> > >
> >
> > If we use JSON messages mixing in COSE becomes awkward. If the use
> > case calls for JSON, I'd argue it should also use RFC7800 instead of
> > draft-ietf-ace- cwt-proof-of-possession.
>
> I would not have a problem with this, it was one of the options above.  I was 
> just expanding my code to allow for JSON to be used and ran into this.  I 
> just wanted to get a clear group decision on this before I put things into 
> stone.
>
> Jim
>
> >
> > > 3.  If the confirmation is changed, you would need to convert the
> > > COSE key to a binary string, base64 encoded it and pass as a
> > > string when occurring in a JSON encoding.  There is not any other
> > > valid way to do this (except see above of just converting the key

Re: [Ace] EST over CoAP: Randomness

[Hannes Tschofenig]

Hi Mike,

A few remarks inline.

On 5/14/2019 7:29 PM, Hannes Tschofenig wrote:
> 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),
"with and without RNG"?
> (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
Um... you usually need one or the other of these to do a good implementation of 
a DRBG and hardware versions tend to be less "costly"
energy wise than software ones.
> (d) cost and price of an MCU are different aspects.

That have no bearing on the protocol design past a certain set of
minimums.   I'm beginning to think its time for "minimum requirements
for internet hosts - 2020 edition" RFCs.  We seem to be back in the same
set of arguments  that ANYTHING should be able to be an internet device
albiet with even lower thresholds than we were a few years ago.  ACE is
pushing those boundaries, but we seem to be chasing "cost -> 0"

[Hannes] Good that you are supporting my argument. I believe this is the first 
time you agree with me.

All good points, but ignoring the fact that needs drive the protocols
which drive the MCU development.  NOT MCUs limit the protocols which
limit the needs.

[Hannes] You should join the EDHOC discussion where you can hear a lot about 
how MCUs and networks limit (security) protocols.

In other words, if the community (through protocol definitions) doesn't
require the RNG, then the MCU developers won't include it.

[Hannes] Luckily silicon vendors already include RNGs in MCUs. That mission got 
accomplished.

With respect to RNG energy costs - the argument that they are too
expensive energy wise is pretty bogus.

[Hannes] Completely agree with you.
Luckily that text part got changed in the latest version of the draft as a 
consequence of the recent mailing list discussion.

  RNGs generally have two parts -
a TRNG or entropy source, and a DRBG seeded from the entropy source.
The energy costs for the DRBG are microscopic. The energy costs for a
TRNG are related more to the time needed to initially fill the entropy
pool (e.g. getting the noisy diodes making noise, getting the ring
oscillators ringing etc) than to keeping it running to get a few
thousand bits.  Doing this say once a year to seed the DRBG isn't going
to kill the lifetime of a battery device.

[Hannes] Well said. I had hoped that someone would go into the details and you 
did.
Btw, did you watch my webinar about RNGs 
https://www.youtube.com/watch?v=xQF2U6AkSjI ?

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: Randomness

[Hannes Tschofenig]

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 
Sent: Dienstag, 14. Mai 2019 15:08
To: Hannes Tschofenig ; 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://www.ietf.org/mailman/listinfo/ace

Re: [Ace] EST over CoAP: Randomness

[Hannes Tschofenig]

Esko,

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

Ciao
Hannes

From: Esko Dijk 
Sent: Dienstag, 14. Mai 2019 11:57
To: Hannes Tschofenig ; Panos Kampanakis (pkampana) 
; 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 
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: Randomness

[Hannes Tschofenig]

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.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] EST over CoAP: Randomness

[Hannes Tschofenig]

Your text updates look good to me, Panos.

Thanks.
Hannes

From: Panos Kampanakis (pkampana) 
Sent: Freitag, 10. Mai 2019 13:06
To: Hannes Tschofenig ; ace@ietf.org
Subject: RE: [Ace] EST over CoAP: Randomness

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 
mailto:hannes.tschofe...@arm.com>>
Sent: Friday, May 10, 2019 4:58 AM
To: Panos Kampanakis (pkampana) 
mailto:pkamp...@cisco.com>>; 
ace@ietf.org<mailto: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 har

Re: [Ace] EST over CoAP: Randomness

[Hannes Tschofenig]

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.




-Original Message-
From: Panos Kampanakis (pkampana) 
Sent: Freitag, 10. Mai 2019 04:53
To: Hannes Tschofenig ; ace@ietf.org
Subject: RE: [Ace] EST over CoAP: Randomness

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
IMPORTANT NOTICE: The contents of this email and any attachments are 
c

[Ace] EST over CoAP: Randomness

[Hannes Tschofenig]

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] FW: Joint IETF/IRTF - OMA SpecWorks Meeting

[Hannes Tschofenig]

FYI: I am forwarding the meeting announcement also to ACE and CORE because 
there maybe interested parties in these groups as well.
Everyone is welcome to join!

From: T2TRG  On Behalf Of Hannes Tschofenig
Sent: Dienstag, 7. Mai 2019 14:39
To: t2...@irtf.org
Cc: Ari Keränen 
Subject: [T2TRG] Joint IETF/IRTF - OMA SpecWorks Meeting

Hi all,

as Ari mentioned already we are planning to hold a joint meeting between OMA 
SpecWorks (two groups, namely the device management & service enablement 
working group  and the IPSO working group) and interested participants of the 
IETF/IRTF. The meeting will take place Friday, July 19th - the Friday before 
the IETF Hackathon/IETF 105 meeting starts. Ericsson is kindly hosting this 
event in their Montreal office. The Ericsson office location is 8275 Route 
Transcanadienne, Saint-Laurent, Quebec H4S-0B6: 
https://www.ericsson.com/en/about-us/company-facts/ericsson-worldwide/canada

For logistical reason please let us know whether you are interested to 
participate in the joint IETF/IRTF-OMA meeting:
https://doodle.com/poll/z6e8kzeke9r9bdyh

The agenda will be very much like the one we put together for the joint 
IETF/OMA conference call earlier this year where we talked about IETF drafts 
that are utilized by LwM2M.  A detailed agenda will be distributed in time for 
the meeting.

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

[Hannes Tschofenig]

Hi John,

I have a slightly different perspective.

ECDHE-PSK is not used because those companies who want to use security on 
really low end IoT devices use PSKs only and there is a lot of overhead from 
the public key crypto. We have been offering different ciphersuites that use 
ECDHE-PSK for a while and the interest was pretty much zero.

RPK was a nice idea but it turns out that those who want to deploy IETF IoT 
security solutions either want to go totally minimalistic (=PSK) or they go for 
certificates because they have an installed base. That's what we are seeing. As 
a co-author of the RPK document I have been talking to our Mbed TLS team a lot 
and they keep telling me that there is no interest. People ask once in a while 
for it on Github but don’t want to allocate any resources implementing it. To 
me that's a pretty strong hint of what people want and do not want.

Ciao
Hannes


-Original Message-
From: John Mattsson 
Sent: Freitag, 22. Februar 2019 10:08
To: Hannes Tschofenig ; ace@ietf.org; l...@ietf.org; 
secdispa...@ietf.org
Cc: Benjamin Kaduk ; salvador@um.es
Subject: Re: [Ace] EDHOC standardization

Hi Hannes,

No wonder that ECDHE-PSK is not widely used in (D)TLS when the relevant 
ECDHE-PSK cipher suites TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 for TLS 1.2 
(and similarly ECDHE + PSK + TLS_AES_128_CCM_8_SHA256 for TLS 1.3) were 
standardized just a few months ago (RFC 8442 and RFC 8446). Luckily most, if 
not all TLS 1.3 implementations are likely to support ECDHE + PSK + 
TLS_AES_128_CCM_8_SHA256.

Similarly, PRK (RFC 7250) is not supported in many TLS implementations (e.g. it 
is not supported in mbed TLS). The main use case for RPK and self-signed 
certificates are not as a replacement for PKI, it's a replacement for 
symmetrical group keys.

My experience is that almost all IoT devices are capable of doing ECDH and 
doing so is very important as a way to get PFS. As required by RFC 725, IEFT 
protocols need to mitigate pervasive monitoring and one very effective way is 
to use PFS.

Looking at a lot of currently deployed IoT systems makes me sad, if security is 
used at all, it is often hop-by-hop and often not over the full path. The 
systems seldom provide PFS and in many cases use symmetrical group keys where 
they should not. A common reason that systems do not use PFS is because they 
think it’s an easy way to enable intercept.

IETF has a role to educate and guide people on what to use. I think that IETF 
should strongly recommend PFS in all use cases and recommend using RPK/ 
self-signed certificates instead of group keys where possible. A pre-requisite 
for doing so is to provide protocols that can be used even in very constrained 
systems.

Cheers,
John

-Original Message-----
From: Hannes Tschofenig 
Date: Wednesday, 21 November 2018 at 16:16
To: John Mattsson , "ace@ietf.org" , 
"l...@ietf.org" 
Cc: Benjamin Kaduk , "salvador@um.es" 
Subject: RE: [Ace] EDHOC standardization

Hi John,

From our experience neither PSK+ECDHE nor RPK usage is common in IoT 
deployments among the bigger IoT providers.
Today, most companies use certificate-based authentication in almost all cases. 
In some cases plain PSK is used for those cases where devices are particularly 
constraint.

Ciao
Hannes

-Original Message-
From: Ace  On Behalf Of John Mattsson
Sent: Wednesday, November 21, 2018 4:03 PM
To: ace@ietf.org; l...@ietf.org
Cc: Benjamin Kaduk ; salvador@um.es
Subject: Re: [Ace] EDHOC standardization

Hi all,

Inspired by the discussion in this thread, I did more detailed calculations of 
the number of bytes when DTLS 1.3 is used for typical IoT use cases (PSK, RPK, 
Connection ID). The plan is to add this information to 
draft-ietf-lwig-security-protocol-comparison as this has been requested by 
several people. I think some bytes were missing in the earlier estimates for 
TLS 1.3, and as Ben commented, DTLS 1.3 adds some bytes compared to TLS 1.3.

==
Flight#1 #2#3   Total
--
DTLS 1.3 RPK + ECDHE 149373   213735
DTLS 1.3 PSK + ECDHE 18619057433
DTLS 1.3 PSK 13615057343
--
EDHOCRPK + ECDHE  3812186245
EDHOCPSK + ECDHE  43 4712102
==
 Number of bytes

Assumptions:
- Minimum number of algorithms and cipher suites offered
- Curve25519, ECDSA with P-256, AES-CCM_8, SHA-256
- Length of key identifiers: 4 bytes
- Connection 

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

[Hannes Tschofenig]

Hi Göran,

I will obviously not be able to convince you to change your research strategy. 
So, I will not even try.
Anyway, thanks for the performance measurements your co-workers created in the 
Excel sheets. I will take a closer look at them.

One item worthwhile to respond is the choice of the MCU. You wrote:
[GS] Nice application of LwM2M. The showcased device didn't seem very 
constrained though, ARM Cortex M4?

The Cortex M4 offers a larger instruction set, including DSP/SIMD capabilities, 
compared to something like the M0+. You can see the differences at 
https://en.wikipedia.org/wiki/ARM_Cortex-M
In this blog post, see 
https://community.arm.com/processors/b/blog/posts/armv6-m-vs-armv7-m---unpacking-the-microcontrollers,
 Chris Shore shows the difference in the instruction set graphically.

Using these extra instructions code can be executed faster. This faster 
execution time is already ensured by compilers but if you additionally use 
hand-crafted Assembly code then you will get an extra performance improvement. 
My co-workers from the Mbed TLS team have written hand-crafted Assembly to 
speed up bignum computations, see 
https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/bn_mul.h#L645
https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/bn_mul.h#L582

Executing code faster gives the device the ability to enter a low power state 
quicker.

Additionally, if you use sensor fusion then having floating point support in 
hardware will make your life easier (and the code faster).

Ciao
Hannes

-Original Message-
From: Göran Selander 
Sent: Montag, 4. Februar 2019 18:41
To: Hannes Tschofenig ; secdispa...@ietf.org; 
ace@ietf.org
Subject: Re: [Secdispatch] FW: [secdir] EDHOC and Transports

Hi Hannes, secdispatch, and ace,

(It seems Hannes original mail only went to secdispatch.)

Apologies for a long mail, and late response. I had to ask some people for help 
with calculations, see end of this mail.

On 2019-01-25, 15:15, "Secdispatch on behalf of Hannes Tschofenig" 
 wrote:

Fwd to SecDispatch since it was only posted on the SecDir list

-Original Message-
    From: Hannes Tschofenig 
Sent: Freitag, 25. Januar 2019 14:07
To: Hannes Tschofenig ; Jim Schaad 
; sec...@ietf.org
Subject: RE: [secdir] EDHOC and Transports

A minor follow-up: I mentioned that I am aware of a company using the 
energy scavenging devices and it turns out that this information is actually 
public and there is even a short video on YouTube. The company we worked with 
is called Alphatronics and here is the video: 
https://www.youtube.com/watch?v=JHpJV_CPYb4

As you can hear in the video we have been using our Mbed OS together with 
our device management solution (LwM2M with DTLS and CoAP) for these types of 
devices.

[GS] Nice application of LwM2M. The showcased device didn't seem very 
constrained though, ARM Cortex M4?

-Original Message-
From: secdir  On Behalf Of Hannes Tschofenig
Sent: Freitag, 25. Januar 2019 13:52
To: Jim Schaad ; sec...@ietf.org
Subject: Re: [secdir] EDHOC and Transports


   [Hannes]  what we are doing here is making an optimization. For some 
(unknown reason) we have focused our attention to the over-the-wire 
transmission overhead (not code size, RAM utilization, or developer usability*).

[GS] Exactly my point, it is not enough with reducing transmission overhead. We 
should also look at additional memory, flash, and configuration effort. These 
parameters are of course implementation dependent but can to some extent be 
inferred by bulk of specification and what pre-existing code can be reused.

   [Hannes]  We are doing this optimization mostly based on information about 
what other people tell us rather than based on our experience. The problem is 
that we have too few people with hands-on knowledge and/or deployment 
experience and if they have that experience they may not like to talk about it. 
So, we are stepping around in the dark and mostly perceived problems.

[GS] I don't think this rhetoric is very helpful. Who are "us"? The co-workers 
you quote below, are they "us" or the "other people"? The people active in 
6tisch, lpwan or 6lo who are supporting the work on an optimized key exchange, 
are they "us" or the "other people"?


   [Hannes]  Having said that I would like to provide a few remarks to your 
list below:

  [Jim]   1.  Low-power devices that either are battery based or scavenge 
power, these devices pay a power penalty for every byte of data sent and thus 
have a desire for the smallest messages possible.

[Hannes] Low power is a very complex topic since it is a system issue and 
boiling it down to the transmission overhead of every byte is an 
oversimplification. You are making certain assumptions of how power consumption 
of radio technologies work, which will be hard to verify. I h

Re: [Ace] Resource, Audience, and req_aud

[Hannes Tschofenig]

Hi Jim,
Hi Ludwig,

> Do the chairs think that this would unduly delay the progress of
> draft-ietf- ace-oauth-params?

[Hannes] Do you think it was inappropriate to point out this inconsistency?

> It looks like the are about the same point as we are.  So no I don't think it 
> would slow things down to make this change.

[Hannes] Jim what are you suggesting?

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] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

[Hannes Tschofenig]

Hi George,

The IANA registry does not indicate in what context these parameters are 
supposed to be used. To me it feels totally normal to use the audience 
parameter instead of the resource parameter when I have a logical name.

Stuffing everything into a URI is possible but in certain scenarios may feel 
quite unnatural. It must have felt unnatural already to the group when working 
on the token exchange spec…

Ciao
Hannes

From: George Fletcher 
Sent: Donnerstag, 7. Februar 2019 17:06
To: Hannes Tschofenig ; Ludwig Seitz 
; ace@ietf.org; oa...@ietf.org
Subject: Re: [Ace] [OAUTH-WG] Shepherd write-up for 
draft-ietf-oauth-resource-indicators-01

This is true... however, to my knowledge there is no support for this parameter 
outside of the token-exchange spec. Just because it is documented as an OAuth 
parameter I don't consider it usable in other contexts unless spec'd to do so. 
If we want to use 'audience' for logical audience names when binding audiences 
to tokens, then we need a spec for that (or add it to the resource-indicators 
spec).

Personally, I see a lot of overlap even between the 'audience' and 'resource' 
parameters. I'd really prefer we just have one parameter that can be either 
logical or specific. As outlined in this thread, 'https://api.exampl.com' to me 
is a logical representation of the resource if the "real" endpoint(s) are 
"https://api.example.com/mail/user/inbox";<https://api.example.com/mail/user/inbox>,
 ...

Thanks,
George
On 2/7/19 10:16 AM, Hannes Tschofenig wrote:
Hi George,


  *   I believe that since the latest draft of the resource indicators spec [1] 
allows for abstract identifiers, and since a URN is also a URI, you could 
easily use a URN syntax to accomplish the use case outlined in your email.


After re-reading the token exchange draft I realized that we have already 
defined a separate parameter for “abstract”, or logical, names via the audience 
parameter. Here is the definition:

   audience
  OPTIONAL.  The logical name of the target service where the client
  intends to use the requested security token.  This serves a
  purpose similar to the "resource" parameter, but with the client
  providing a logical name rather than a location.  Interpretation
  of the name requires that the value be something that both the
  client and the authorization server understand.  An OAuth client
  identifier, a SAML entity identifier 
[OASIS.saml-core-2.0-os<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16#ref-OASIS.saml-core-2.0-os>],
 an
  OpenID Connect Issuer Identifier 
[OpenID.Core<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16#ref-OpenID.Core>],
 or a URI are
  examples of things that might be used as "audience" parameter
  values.  Multiple "audience" parameters may be used to indicate
  that the issued token is intended to be used at the multiple
  audiences listed.  The "audience" and "resource" parameters may be
  used together to indicate multiple target services with a mix of
  logical names and locations.

Ciao
Hannes


From: Ace <mailto:ace-boun...@ietf.org> On Behalf Of 
George Fletcher
Sent: Dienstag, 29. Januar 2019 14:15
To: Ludwig Seitz <mailto:ludwig.se...@ri.se>; 
ace@ietf.org<mailto:ace@ietf.org>; oa...@ietf.org<mailto:oa...@ietf.org>
Subject: Re: [Ace] [OAUTH-WG] Shepherd write-up for 
draft-ietf-oauth-resource-indicators-01

Thank you so much for the background!

I believe that since the latest draft of the resource indicators spec [1] 
allows for abstract identifiers, and since a URN is also a URI, you could 
easily use a URN syntax to accomplish the use case outlined in your email.

resource=urn:x-mydevices:temperatureSensorGroup4711

The spec currently outlines examples where the "resource identifier" is not a 
"single resource" in the context of a fully qualified API endpoint.

Another example, for an API like SCIM 
[RFC7644<https://tools.ietf.org/html/rfc7644>] that has

   multiple endpoints such as 
"https://apps.example.com/scim/Users";<https://apps.example.com/scim/Users>,

   
"https://apps.example.com/scim/Groups";<https://apps.example.com/scim/Groups>, 
and

   
"https://apps.example.com/scim/Schemas";<https://apps.example.com/scim/Schemas> 
The client would use

   "https://apps.example.com/scim/";<https://apps.example.com/scim/> as the 
resource so that the issued

   access token is valid for all the endpoints of the SCIM API.
Using "https://apps.example.com/scim";<https://apps.example.com/scim> is 
semantically equivalent to using "temperatureSensorGroup4711", at least to me:)

Thanks,
George

[1] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-0

Re: [Ace] Resource, Audience, and req_aud

[Hannes Tschofenig]

Hi Ludwig,

> What I understood from the feed-back is that using a parameter called "aud" 
> in a request to the token endpoint would be interpreted as a restriction on 
> the audience of authorization servers that are addressed by this request.

I am not talking about a parameter called 'aud'. Take a look at the token 
exchange spec -- the parameter is called 'audience'.
'aud' is the name of the claim.

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] [OAUTH-WG] Resource, Audience, and req_aud

[Hannes Tschofenig]

Since the authors of the token exchange draft have asked IANA for an early 
registration of the parameters I get the impression that the question is more “ 
does the resource indicator spec need to define the resource parameter (or 
rather reference the resource and audience parameters from the token exchange 
spec)”?

From: Filip Skokan 
Sent: Donnerstag, 7. Februar 2019 16:38
To: Hannes Tschofenig 
Cc: ace@ietf.org; oa...@ietf.org
Subject: Re: [OAUTH-WG] Resource, Audience, and req_aud

To add to that,

3. If a device uses HTTP Token Exchange it can use both resource and audience 
parameters.

With the recent discussion and changes to the language in the resource 
indicators draft, does the token exchange spec need a unique audience parameter?

S pozdravem,
Filip Skokan


On Thu, 7 Feb 2019 at 16:25, Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:
Hi all,

after re-reading token exchange, the resource indicator, and the 
ace-oauth-params drafts I am wondering whether it is really necessary to have 
different functionality in ACE vs. in OAuth for basic parameters.

Imagine I use an Authorization Server and I support devices that use CoAP and 
HTTP.


  1.  If a device uses CoAP then it has to use the req_aud parameter to 
indicate to the authorization server that it wants to talk to a specific 
resource server. It would either put a URI or a logical name there.
  2.  If a device uses HTTP then it has to use either the resource parameter to 
indicate to the authorization server that it wants to talk to a resource 
server, which is identified using a URI, or the audience parameter, if it uses 
a logical name.

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.
___
OAuth mailing list
oa...@ietf.org<mailto:oa...@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
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] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

[Hannes Tschofenig]

Hi Ludwig,

the issue is that folks in the OAuth group have defined two parameters, namely 
resource (for URIs) and audience (for logical names), and in ACE there is only 
one doing both.

To me this appears to be sub-optimal to have different ways to accomplish the 
same goal just based on the protocol the information is exchanged.

Which route is better? I don't care.

Ciao
Hannes



-Original Message-
From: Ludwig Seitz 
Sent: Donnerstag, 7. Februar 2019 16:29
To: Hannes Tschofenig ; ace@ietf.org; oa...@ietf.org
Subject: Re: [OAUTH-WG] [Ace] Shepherd write-up for 
draft-ietf-oauth-resource-indicators-01

On 07/02/2019 16:15, Hannes Tschofenig wrote:
> Hi Ludwig,
>
>> My interpretation of this is that "resource" refers to a single resource
>
> No. Here is the text from token exchange (see last sentence):
>
> resource
[...]
> Multiple "resource" parameters may be used to indicate
>that the issued token is intended to be used at the multiple
>resources listed.
>

Enumerating the audience is not the same as addressing it by a group name.

I agree that without too much stretching of the definition of the
resource parameter I could use URIs as group identifiers, however the
audience claim is defined to be "StringOrURI" so if someone defines an
audience identified by a String that is not an URI how does a client ask
for that with the resource parameter?

Or in short: Why don't you make your resource parameter mirror the "aud"
claim?

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

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] Resource, Audience, and req_aud

[Hannes Tschofenig]

Hi all,

after re-reading token exchange, the resource indicator, and the 
ace-oauth-params drafts I am wondering whether it is really necessary to have 
different functionality in ACE vs. in OAuth for basic parameters.

Imagine I use an Authorization Server and I support devices that use CoAP and 
HTTP.


  1.  If a device uses CoAP then it has to use the req_aud parameter to 
indicate to the authorization server that it wants to talk to a specific 
resource server. It would either put a URI or a logical name there.
  2.  If a device uses HTTP then it has to use either the resource parameter to 
indicate to the authorization server that it wants to talk to a resource 
server, which is identified using a URI, or the audience parameter, if it uses 
a logical name.

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] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

[Hannes Tschofenig]

Hi George,


  *   I believe that since the latest draft of the resource indicators spec [1] 
allows for abstract identifiers, and since a URN is also a URI, you could 
easily use a URN syntax to accomplish the use case outlined in your email.

After re-reading the token exchange draft I realized that we have already 
defined a separate parameter for “abstract”, or logical, names via the audience 
parameter. Here is the definition:

   audience
  OPTIONAL.  The logical name of the target service where the client
  intends to use the requested security token.  This serves a
  purpose similar to the "resource" parameter, but with the client
  providing a logical name rather than a location.  Interpretation
  of the name requires that the value be something that both the
  client and the authorization server understand.  An OAuth client
  identifier, a SAML entity identifier 
[OASIS.saml-core-2.0-os],
 an
  OpenID Connect Issuer Identifier 
[OpenID.Core],
 or a URI are
  examples of things that might be used as "audience" parameter
  values.  Multiple "audience" parameters may be used to indicate
  that the issued token is intended to be used at the multiple
  audiences listed.  The "audience" and "resource" parameters may be
  used together to indicate multiple target services with a mix of
  logical names and locations.

Ciao
Hannes


From: Ace  On Behalf Of George Fletcher
Sent: Dienstag, 29. Januar 2019 14:15
To: Ludwig Seitz ; ace@ietf.org; oa...@ietf.org
Subject: Re: [Ace] [OAUTH-WG] Shepherd write-up for 
draft-ietf-oauth-resource-indicators-01

Thank you so much for the background!

I believe that since the latest draft of the resource indicators spec [1] 
allows for abstract identifiers, and since a URN is also a URI, you could 
easily use a URN syntax to accomplish the use case outlined in your email.

resource=urn:x-mydevices:temperatureSensorGroup4711

The spec currently outlines examples where the "resource identifier" is not a 
"single resource" in the context of a fully qualified API endpoint.

Another example, for an API like SCIM 
[RFC7644] that has

   multiple endpoints such as 
"https://apps.example.com/scim/Users";,

   
"https://apps.example.com/scim/Groups";, 
and

   
"https://apps.example.com/scim/Schemas"; 
The client would use

   "https://apps.example.com/scim/"; as the 
resource so that the issued

   access token is valid for all the endpoints of the SCIM API.
Using "https://apps.example.com/scim"; is 
semantically equivalent to using "temperatureSensorGroup4711", at least to me:)

Thanks,
George

[1] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02
On 1/29/19 2:56 AM, Ludwig Seitz wrote:
On 28/01/2019 23:12, George Fletcher wrote:

I also don't know that this raises to the level of "concern" but I find the 
parameter name of "req_aud" odd. Given that the parameter in the 
resource-indicators spec is 'resource' why not use a parameter name of 
'audience'. That said, I have not read the thread on the ACE working group list 
so there could be very good reasons for the chosen name:)

I do think that there is a lot of overlap (in most cases) between 'resource' 
and 'audience' and having two parameters that cover a lot of the same semantics 
is going to be confusing for developers. When calling an API at a resource 
server, the 'audience' and the 'resource' are pretty equivalent. Maybe in other 
use cases they are distinctly separate?

To give you all the background of "req_aud" from ACE (sorry for the long text):

Originally in ACE we had defined the "aud" parameter for requests to the token 
endpoint with the semantics that the client was requesting a token for a 
certain audience (i.e. requesting that the AS copy the "aud" parameter value 
into the "aud" claim value of the token).
We were then told that this collided with a use of "aud" in OAuth, that 
specifies the intended audience of Authorization Servers (if I remember 
correctly), so we decided to rename our parameter to "req_aud" for "requested 
audience".
Mike Jones then made us aware of the work on resource indicators, but upon 
closer examination I found the "resource" parameter to be more limited than the 
"req_aud", since resource specifically states:

"Its value MUST be an absolute URI ... the "resource" parameter URI value is an 
identifier representing the identity of the resource"

My interpretation of this is that "resource" refers to a single resource, which 
is more constrained than the definition of the "aud" claim from 7519, which 
uses a StringOrURI value.  Fo

Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

[Hannes Tschofenig]

Hi Ludwig,

> My interpretation of this is that "resource" refers to a single resource

No. Here is the text from token exchange (see last sentence):

   resource
  OPTIONAL.  Indicates the location of the target service or
  resource where the client intends to use the requested security
  token.  This enables the authorization server to apply policy as
  appropriate for the target, such as determining the type and
  content of the token to be issued or if and how the token is to be
  encrypted.  In many cases, a client will not have knowledge of the
  logical organization of the systems with which it interacts and
  will only know the location of the service where it intends to use
  the token.  The "resource" parameter allows the client to indicate
  to the authorization server where it intends to use the issued
  token by providing the location, typically as an https URL, in the
  token exchange request in the same form that will be used to
  access that resource.  The authorization server will typically
  have the capability to map from a resource URI value to an
  appropriate policy.  The value of the "resource" parameter MUST be
  an absolute URI, as specified by Section 4.3 of [RFC3986], which
  MAY include a query component and MUST NOT include a fragment
  component.  Multiple "resource" parameters may be used to indicate
  that the issued token is intended to be used at the multiple
  resources listed.

Ciao
Hannes


-Original Message-
From: OAuth  On Behalf Of Ludwig Seitz
Sent: Dienstag, 29. Januar 2019 08:56
To: ace@ietf.org; oa...@ietf.org
Subject: Re: [OAUTH-WG] [Ace] Shepherd write-up for 
draft-ietf-oauth-resource-indicators-01

On 28/01/2019 23:12, George Fletcher wrote:
> I also don't know that this raises to the level of "concern" but I
> find the parameter name of "req_aud" odd. Given that the parameter in
> the resource-indicators spec is 'resource' why not use a parameter
> name of 'audience'. That said, I have not read the thread on the ACE
> working group list so there could be very good reasons for the chosen
> name:)
>
> I do think that there is a lot of overlap (in most cases) between
> 'resource' and 'audience' and having two parameters that cover a lot
> of the same semantics is going to be confusing for developers. When
> calling an API at a resource server, the 'audience' and the 'resource'
> are pretty equivalent. Maybe in other use cases they are distinctly separate?
>

To give you all the background of "req_aud" from ACE (sorry for the long
text):

Originally in ACE we had defined the "aud" parameter for requests to the token 
endpoint with the semantics that the client was requesting a token for a 
certain audience (i.e. requesting that the AS copy the "aud"
parameter value into the "aud" claim value of the token).
We were then told that this collided with a use of "aud" in OAuth, that 
specifies the intended audience of Authorization Servers (if I remember 
correctly), so we decided to rename our parameter to "req_aud" for "requested 
audience".
Mike Jones then made us aware of the work on resource indicators, but upon 
closer examination I found the "resource" parameter to be more limited than the 
"req_aud", since resource specifically states:

"Its value MUST be an absolute URI ... the "resource" parameter URI value is an 
identifier representing the identity of the resource"

My interpretation of this is that "resource" refers to a single resource, which 
is more constrained than the definition of the "aud"
claim from 7519, which uses a StringOrURI value.  For example my intent was to 
use "aud" and "req_aud" for group identifiers
("temperatureSensorGroup4711") and other non-uri strings (hash-of-public-key), 
which I cannot do with "resource".  We therefore decided to keep the "req_aud" 
parameter in draft-ietf-ace-oauth-params, even though is clearly overlaps with 
"resource".

Any comments and suggestions about that line of reasoning (especially from the 
OAuth point of view) are very welcome.

/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
OAuth mailing list
oa...@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
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] FW: [OAUTH-WG] OAuth Security Workshop Call for Proposals

[Hannes Tschofenig]

This workshop may be of interest to you, particularly if you work on ACE-Oauth 
specification.

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Torsten Lodderstedt
Sent: Freitag, 11. Januar 2019 21:32
To: oa...@ietf.org
Subject: [OAUTH-WG] OAuth Security Workshop Call for Proposals

Hi all,

the Call for Proposal for the 4th OAuth Security Workshop is out!

https://sec.uni-stuttgart.de/events/osw2019

Please propose a session!

kind regards,
Torsten.

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] ACE Implementation for Disadvantaged Environments

[Hannes Tschofenig]

Hi Sebastian,

Thanks for the details. How easy do you think would it be to port the code to 
some other OS? (or in other words: how tightly have you coupled it to Contiki?)

Is the COSE/CWT parsing library separable from the rest?

For the 300 Kb flash: does this contain the firmware update mechanism?

Ciao
Hannes

From: Sebastian Echeverria 
Sent: Montag, 28. Januar 2019 16:06
To: Hannes Tschofenig 
Cc: Grace A Lewis ; ace@ietf.org; Dan Klinedinst 

Subject: Re: ACE Implementation for Disadvantaged Environments

Hello,

Here is some more information about it:


  *   We used Contiki as the base/OS for the code. More specifically, we forked 
from the 6lbr project (https://github.com/cetic/6lbr), as that version already 
had some code for handling DTLS connections and AES encryption in it.
  *   We are using the TI CC2538dk board as our constrained target platform.
  *   The implementation has support for the DTLS profile, using pre-shared 
keys, as this was enough for our use case.
  *   The implementation handles CWT tokens.
  *   We modified the Erbium CoAP server in 6lbr to be able to simultaneously 
listen for CoAP and CoAPs connections (using TinyDTLS underneath).
  *   The implementation uses the cn-cbor library for decoding CBOR data.
  *   The implementation supports receiving tokens at the authz-info endpoint, 
and then giving access to a couple of sample resources based on the claims from 
the received tokens.
  *   The implementation has some additional optional features related to our 
disadvantaged network environments, such as bootstrapping of the PSK 
credentials, and detecting revoked tokens through introspection.
  *   The current binary is around 300 kb, which is good enough for the 512 kb 
flash on the TI boards, though it may be a bit too large for a class II device. 
We can probably make it a bit smaller. In terms of RAM, it fits in the 32 KB 
available on the TI boards.

Best,

---
Sebastian Echeverria
Tactical Technologies Group (TTG)
Software Engineering Institute
Carnegie Mellon University



From: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>
Date: Monday, January 28, 2019 at 5:05 AM
To: Grace Lewis mailto:gle...@sei.cmu.edu>>, 
"ace@ietf.org<mailto:ace@ietf.org>" mailto:ace@ietf.org>>
Subject: RE: ACE Implementation for Disadvantaged Environments

Congrats to the work. Could you say a little bit the (constrained) resource 
server implementation?

Ciao
Hannes

From: Ace mailto:ace-boun...@ietf.org>> On Behalf Of 
Grace A Lewis
Sent: Mittwoch, 23. Januar 2019 19:12
To: ace@ietf.org<mailto:ace@ietf.org>
Subject: [Ace] ACE Implementation for Disadvantaged Environments

Hello,

I just wanted to make the group aware of our ACE implementation (SEI-ACE), 
which includes an implementation for a resource-constrained server.

Details available in this news article: 
https://www.sei.cmu.edu/news-events/news/article.cfm?assetid=539184

Article includes the link to our Git repo.

Enjoy!

- Grace Lewis

__
Grace A. Lewis, Ph.D.
Principal Researcher and TTG Initiative Lead
Carnegie Mellon Software Engineering Institute
Software Solutions Division (SSD)
Tactical Technologies Group (TTG)

4500 Fifth Ave. #5412
Pittsburgh, PA 15213
Phone: (412) 268-5851
http://www.sei.cmu.edu/staff/glewis

“A change in perspective is worth 80 IQ points” --- Alan Kay
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 
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] ACE Implementation for Disadvantaged Environments

[Hannes Tschofenig]

Congrats to the work. Could you say a little bit the (constrained) resource 
server implementation?

Ciao
Hannes

From: Ace  On Behalf Of Grace A Lewis
Sent: Mittwoch, 23. Januar 2019 19:12
To: ace@ietf.org
Subject: [Ace] ACE Implementation for Disadvantaged Environments

Hello,

I just wanted to make the group aware of our ACE implementation (SEI-ACE), 
which includes an implementation for a resource-constrained server.

Details available in this news article: 
https://www.sei.cmu.edu/news-events/news/article.cfm?assetid=539184

Article includes the link to our Git repo.

Enjoy!

- Grace Lewis

__
Grace A. Lewis, Ph.D.
Principal Researcher and TTG Initiative Lead
Carnegie Mellon Software Engineering Institute
Software Solutions Division (SSD)
Tactical Technologies Group (TTG)

4500 Fifth Ave. #5412
Pittsburgh, PA 15213
Phone: (412) 268-5851
http://www.sei.cmu.edu/staff/glewis

“A change in perspective is worth 80 IQ points” --- Alan Kay
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] Security of the Communication Between C and RS

[Hannes Tschofenig]

Hi Ludwig, Hi Jim

A few remarks below:

-Original Message-
From: Ludwig Seitz 
Sent: Donnerstag, 20. Dezember 2018 08:40
To: Jim Schaad ; Hannes Tschofenig 
; 'Stefanie Gerdes' ; ace@ietf.org
Subject: Re: [Ace] Security of the Communication Between C and RS

On 19/12/2018 21:22, Jim Schaad wrote:
>

>>> In step (4) you tie the expiry of the token to the attacker getting
>>> hold of the key. What happens if the attacker gets hold of the pop
>>> key before the token expires?
>>
>> If it is detected the AS would revoke the token. Then the client
>> _could_ use client introspection to get that information. Note that
>> this is what the CMU people are looking at.
>
> I am having a real problem with the idea that we are going to start
> adding the idea of revocation to the entire system.   I would much
> rather make sure that both sides are given an idea of when things are
> going to expire and just make things expire relatively quickly.
>

It's quite unlike the revocation in PKI, it's just that an AS can mark a token 
as invalid, and this information would then be available to those who can do 
introspection.

[Hannes] I see revocation and expiry of credentials as two somewhat different 
concepts.
In OAuth, we have a spec that deals with a limited form of revocation but the 
best mitigation IMHO is to issue "short-lived" tokens (short lived in the 
context of the given application domain). The token introspection interface 
also provides additional capabilities for real-time checking the status of a 
token. Finally, it is worth mentioning the SecEvents work here as well.

In practice it is difficult to revoke tokens in a timely fashion since you have 
to find out that there has been a leakage in the first place, which (as media 
reports indicate) often takes months if not years for companies to notice.

Regarding expiry of the token, we have the ability for the AS to tell the 
client as well as the RS how long the token is valid. Do we want to mandate it? 
Even if I don't see the harm in not providing the info to the client I am 
saying "why not". I am just not sure whether mandatorily sending the expired_in 
parameter to the client will help to prevent any attacks.

>>
>>> Additionally, if you use DTLS/TLS just having the PoP key still
>>> requires the attacker to run a new DTLS/TLS handshake with the RS.
>>
>> If the pop-key was used as a basis for doing a DTLS-PSK handshake,
>> the attacker should be able to hijack the connection and impersonate
>> either party.
>
> This depends on the version of PSK that you are doing.  If you use
> PSK+ECDH then the attacker cannot hijack the connection.
>

Right of course. I suspect however that not all constrained devices would 
implement the PSK+ECDH handshake, or are the other PSK handshakes deprecated?

[Hannes] It really depends what assumptions you make about how the attacker 
managed to get access to the PoP key in the first place, which we haven't 
really gone into any level of detail.
>From my experience (as I mentioned to John  Mattsson in his DTLS/TLS vs. 
>OSCORE performance analysis) use of PSK+ECDH(E) is rather unlikely since you 
>are essentially dumping the positive effects of the PSK-based mechanism while 
>maintaining all the negative aspects of the long-term PSK credential.

>>
>>> It would also be useful to know where the attacker got the PoP key
>>> from and how you can even detect the compromise.
>>
>> That is a different story entirely. You could imagine the case of an
>> RS improperly deleting an expired token and the associated pop-key,
>> and then being subject to a physical attack that recovers that
>> information.
>
> It would be more reasonable to say that if you are doing a physical
> attack, then it would be easy to get an RPK and then you are the RS
> until such a time as the AS is told that the key is no longer trusted.
> In this case you will just continue getting tokens as a client which
> are still valid and none of this is helpful in any event.

Ok my example was perhaps not ideal, since it has an even bigger breach as 
precondition. So under what conditions would an attacker get access to a 
pop-key of an expired token? Steffi any ideas?

[Hannes] We definitely need some more details about the type of attack we would 
like to prevent. Maybe it is worthwhile to think about what information the 
attacker steals from whom at what point in time could be a way to progress the 
topic.

Ciao
Hannes


/Ludwig



--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
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] Security of the Communication Between C and RS

[Hannes Tschofenig]

Thanks, Ludwig. The list of steps below help me to understand the concern.




1.) C obtains token and pop-key from AS
2.) C transmits token to RS and sets up secure communication (e.g.
DTLS-PSK) using the pop-key
3.) C sends secure requests to the RS
4.) token expires, an attacker manages to get hold of the pop-key
5.) C continues to send requests containing sensitive information to the RS , 
attacker can now read the messages and spoof positive responses from the RS. C 
never notices that the token is invalid and that it is actually talking to the 
attacker.



In step (4) you tie the expiry of the token to the attacker getting hold of the 
key. What happens if the attacker gets hold of the pop key before the token 
expires?
Additionally, if you use DTLS/TLS just having the PoP key still requires the 
attacker to run a new DTLS/TLS handshake with the RS.
It would also be useful to know where the attacker got the PoP key from and how 
you can even detect the compromise.

Additionally, there is the question why the RS wouldn't stop communicating if 
the token expired since it has that information. Normally, the idea is that the 
RS has a protected resource and the client wants to access it. That's why the 
RS is asking the client to send a token that gives it access.

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] Security of the Communication Between C and RS

[Hannes Tschofenig]

Hi Steffi,

Are you focused on token expiry or the case where a token + symmetric key has 
been leaked?

Is the threat you are describing the case where the client uses DTLS/TLS with 
the RS (potentially long after a token has been presented), or the case where 
the client contacts the RS and presents a token?

Ciao
Hannes

-Original Message-
From: Stefanie Gerdes 
Sent: Mittwoch, 19. Dezember 2018 12:26
To: Hannes Tschofenig ; Ludwig Seitz 
; Jim Schaad ; ace@ietf.org
Subject: Re: [Ace] Security of the Communication Between C and RS

Hi Hannes,

On 12/18/2018 04:26 PM, Hannes Tschofenig wrote:
> Hi Steffi,
>
>> In OAuth, the expires_in field is usually used to inform the client how long 
>> the access token is valid. If the client uses the access token in a request 
>> after the token expired, the RS will reject the request, which usually is 
>> not a big problem for the client.
>
>> In ACE, AS provides the client with keying material for the RS, which is a 
>> completely different situation. If the client does not know how long the 
>> keying material is valid, it may use outdated keying material to communicate 
>> with RS. The expires_in field can be used to inform the client how long the 
>> keying material for RS is valid, if the keying material is valid as long as 
>> the access token.
>
>> The main reason to change keying material from time to time is to avoid that 
>> it is compromised. I therefore think that it is necessary for the security 
>> of the solution that C knows how long the keying material is supposed to be 
>> valid.
>
> If a client uses either an old key or an old token then the request will 
> fail. I don't see much difference here between OAuth and ACE.

The difference is that C cannot authenticate RS with an outdated key.
And even if the correct RS rejects the request, the confidentiality of the 
request may already have been breached, i.e., the damage is already done. C 
therefore must know how long the keying material is valid.

Viele Grüße
Steffi
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] Security of the Communication Between C and RS

[Hannes Tschofenig]

Hi Steffi,

>> I also think that the client must be able to assume that RS' RPK that C 
>> receives from AS is also valid as long as the token, unless C has additional 
>> information.
>
> I would think that it is rather unlikely that the RS will change its 
> public/private key pair so quickly. Right?

> I don't really know what you mean with "quickly". Access tokens may be valid 
> for a long time, depending on the application scenario. Also, RS may already 
> have its RPK for a while at the time when AS generates the access token. RPKs 
> do not contain semantic information and C may not have additional information 
> about the RPK. Therefore, C must be able to assume that the RS' RPK is valid 
> as long as the access token.

>From an AS point of view it would make sense to make sure they hand out 
>information to client that actually works. If the token is still valid while 
>the information about the RPK of the RS isn't then there may indeed be a 
>failure case.
This isn't too bad since the client will then (hopefully) contact the AS again 
to get a new access token.

We could nevertheless add a note saying that the operator of the AS needs to 
consider these cases and that the client should contact the AS again in an 
error situation.

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] Security of the Communication Between C and RS

[Hannes Tschofenig]

Hi Steffi,

> In OAuth, the expires_in field is usually used to inform the client how long 
> the access token is valid. If the client uses the access token in a request 
> after the token expired, the RS will reject the request, which usually is not 
> a big problem for the client.

> In ACE, AS provides the client with keying material for the RS, which is a 
> completely different situation. If the client does not know how long the 
> keying material is valid, it may use outdated keying material to communicate 
> with RS. The expires_in field can be used to inform the client how long the 
> keying material for RS is valid, if the keying material is valid as long as 
> the access token.

> The main reason to change keying material from time to time is to avoid that 
> it is compromised. I therefore think that it is necessary for the security of 
> the solution that C knows how long the keying material is supposed to be 
> valid.

If a client uses either an old key or an old token then the request will fail. 
I don't see much difference here between OAuth and ACE.

Adding a note to recommend the use of the expires_in field appears still useful 
to me.

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] Security of the Communication Between C and RS

[Hannes Tschofenig]

Hi Steffi, Hi Ludwig,

~snip~

>> The access information optionally can contain an expires_in field.
>> It would help to prevent security breaches under the following
>> conditions:
> 1. the keying material is valid as long as the ticket, 2. the
> expires_in field is present in the access information that AS sends to
> C, 3. the client checks the expires_in field when it gets the access
> information from the AS, and 4. the client checks if the keying
> material is still valid each time before it sends a request to RS.
>
> These checks make sense to me.
>
Are you proposing we make the expires_in field mandatory? If so, why isn't it 
mandatory already in OAuth (currently only RECOMMENDED)?

[Hannes] I would do the check when the field is actually there. However, it is 
a good question why it is not mandatory in OAuth. Let me drop a mail to the 
list.


Now that I got a response from the OAuth working group (in the sense that I was 
thinking about the claims in the access token rather than the parameters in the 
response from the AS) I think checking the expires_in field has to be optional 
since
* the expires_in parameter is optional, and
* it only has an advisory nature.

It is useful to send the parameter so that the client can determine when to 
request a new access token (for example, via the refresh token) but it is not 
absolutely necessary for the protocol operation.

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] Security of the Communication Between C and RS

[Hannes Tschofenig]

Hi Ludwig,

A few remarks inline:

-Original Message-
From: Ludwig Seitz 
Sent: Dienstag, 18. Dezember 2018 09:27
To: Hannes Tschofenig ; Stefanie Gerdes 
; Jim Schaad ; ace@ietf.org
Subject: Re: [Ace] Security of the Communication Between C and RS

On 15/12/2018 16:04, Hannes Tschofenig wrote:
> Hi Steffi,
>
> ~snip~
>
>> I really think you should point out that symmetric keying material
>> that the AS provides to the client is valid as long as the token.
>
> I think that's a useful recommendation. I do, however, believe that we
> are not making the same assumption for an asymmetric key bound to the
> token.
>

Ok, I'll add text to the draft that says this.

Note that this can be trouble if a client asks the AS to bind an existing 
symmetric pop-key to another (new) token it is requesting.
Which one of the two tokens bound to that key is now steering the expiration of 
the key?

[Hannes] Normally, the client would only request a symmetric PoP token from the 
AS and the AS would create the symmetric key and return the PoP token + the 
symmetric key.
Hence, in the normal case this shouldn't be happen.

>> The access information optionally can contain an expires_in field.
>> It would help to prevent security breaches under the following
>> conditions:
> 1. the keying material is valid as long as the ticket, 2. the
> expires_in field is present in the access information that AS sends to
> C, 3. the client checks the expires_in field when it gets the access
> information from the AS, and 4. the client checks if the keying
> material is still valid each time before it sends a request to RS.
>
> These checks make sense to me.
>
Are you proposing we make the expires_in field mandatory? If so, why isn't it 
mandatory already in OAuth (currently only RECOMMENDED)?

[Hannes] I would do the check when the field is actually there. However, it is 
a good question why it is not mandatory in OAuth. Let me drop a mail to the 
list.

Ciao
Hannes

/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
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] Security of the Communication Between C and RS (was: Re: Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt)

[Hannes Tschofenig]

Hi Steffi,

~snip~

> I really think you should point out that symmetric keying material that the 
> AS provides to the client is valid as long as the token.

I think that's a useful recommendation. I do, however, believe that we are not 
making the same assumption for an asymmetric key bound to the token.


> I also think that the client must be able to assume that RS' RPK that C 
> receives from AS is also valid as long as the token, unless C has additional 
> information.

I would think that it is rather unlikely that the RS will change its 
public/private key pair so quickly. Right?

> The access information optionally can contain an expires_in field. It would 
> help to prevent security breaches under the following conditions:
1. the keying material is valid as long as the ticket, 2. the expires_in field 
is present in the access information that AS sends to C, 3. the client checks 
the expires_in field when it gets the access information from the AS, and 4. 
the client checks if the keying material is still valid each time before it 
sends a request to RS.

These checks make sense to me.


> Without these steps, the confidentiality of the request data that C sends to 
> RS may be breached, and C may communicate with the wrong RS using outdated 
> keying material.

Not sure how you came to this conclusion. Why is the request sent by the C to 
the RS revealed to an attacker when the token expires?

Ciao
Hannes


Viele Grüße
Steffi

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
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] Token (In)Security

[Hannes Tschofenig]

Hi Steffi

I checked the text and the text is indeed confusing.

I have made an attempt to update it to address your comment. Here is the pull 
request:
https://github.com/ace-wg/ace-oauth/pull/168

Let me know if you think I captured everything properly.

Ciao
Hannes

-Original Message-
From: Ace  On Behalf Of Hannes Tschofenig
Sent: Freitag, 14. Dezember 2018 17:18
To: Stefanie Gerdes ; Ludwig Seitz ; Jim 
Schaad ; ace@ietf.org
Subject: Re: [Ace] Token (In)Security

Hi Steffi,

I anticipate that the use of tokens with IoT devices works similar to OAuth 
deployments today. As such, if you distribute self-contained tokens then you 
sign or mac them.
We have registered the necessary claims already, which includes the expiry. As 
such, I expect it to be used as well.

If we forgot to mention explicitly that we follow the best current practices in 
OAuth then we should add that reference. I will check the text...

Ciao
Hannes

-Original Message-
From: Ace  On Behalf Of Stefanie Gerdes
Sent: Freitag, 14. Dezember 2018 16:15
To: Ludwig Seitz ; Jim Schaad ; 
ace@ietf.org
Subject: [Ace] Token (In)Security

Hi all,

as I understand the current proposal of the ACE framework, an attacker can send 
an access token to the RS that only contains a scope and is not signed or 
otherwise protected. Section 5.8.1.1 (titled verifying an access token) does 
not state that RS must check the authenticity of the token, therefore RS can 
accept it. Since the token does not contain an exp field, it is infinitely 
valid. The attacker thus gains infinite unconditional access. Is this really 
what we want from a security framework?

I would expect section 5.8.1.1 to provide information if and when RS must check 
that the token stems from an authorized AS to prevent this scenario.

Viele Grüße
Steffi

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
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
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] Token (In)Security

[Hannes Tschofenig]

Hi Steffi,

I anticipate that the use of tokens with IoT devices works similar to OAuth 
deployments today. As such, if you distribute self-contained tokens then you 
sign or mac them.
We have registered the necessary claims already, which includes the expiry. As 
such, I expect it to be used as well.

If we forgot to mention explicitly that we follow the best current practices in 
OAuth then we should add that reference. I will check the text...

Ciao
Hannes

-Original Message-
From: Ace  On Behalf Of Stefanie Gerdes
Sent: Freitag, 14. Dezember 2018 16:15
To: Ludwig Seitz ; Jim Schaad ; 
ace@ietf.org
Subject: [Ace] Token (In)Security

Hi all,

as I understand the current proposal of the ACE framework, an attacker can send 
an access token to the RS that only contains a scope and is not signed or 
otherwise protected. Section 5.8.1.1 (titled verifying an access token) does 
not state that RS must check the authenticity of the token, therefore RS can 
accept it. Since the token does not contain an exp field, it is infinitely 
valid. The attacker thus gains infinite unconditional access. Is this really 
what we want from a security framework?

I would expect section 5.8.1.1 to provide information if and when RS must check 
that the token stems from an authorized AS to prevent this scenario.

Viele Grüße
Steffi

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
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

[Hannes Tschofenig]

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] IPR Conformance check for draft-ietf-ace-cwt-proof-of-possession

[Hannes Tschofenig]

I am not aware of any IPRs regarding draft-ietf-ace-cwt-proof-of-possession

From: Ace  On Behalf Of Samuel Erdtman
Sent: Thursday, November 29, 2018 6:49 AM
To: Roman Danyliw 
Cc: ace 
Subject: Re: [Ace] IPR Conformance check for 
draft-ietf-ace-cwt-proof-of-possession

As a co-author, I don't hold any IPR nor am I aware of any related to this draft

On Tue, Nov 27, 2018 at 3:44 PM Roman Danyliw 
mailto:r...@cert.org>> wrote:
Hello draft-ietf-ace-cwt-proof-of-possession authors,
(Hi Mike, Ludwig, Goeran, Samuel and Hannes,)

As the shepherd for draft-ietf-ace-cwt-proof-of-possession, I'd like to confirm 
with the authors that all IPR disclosures have occurred per RFC6702:

--[ shepherd questions ]--

(7) Has each author confirmed that any and all appropriate IPR disclosures 
required for full conformance with the provisions of BCP 78 and BCP 79 have 
already been filed. If not, explain why?

--[end question]--

Can you please respond to the list answering this question (e.g., "As a 
co-author, I don't hold any IPR nor am I aware of any related to this draft").

Thanks,
Roman

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
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] EDHOC standardization

[Hannes Tschofenig]

John, could you also add the detailed data for EDHOC as well?
(And thanks for the details regarding the DTLS numbers.)

Ciao
Hannes

-Original Message-
From: Ace  On Behalf Of John Mattsson
Sent: Wednesday, November 21, 2018 4:03 PM
To: ace@ietf.org; l...@ietf.org
Cc: Benjamin Kaduk ; salvador@um.es
Subject: Re: [Ace] EDHOC standardization

Hi all,

Inspired by the discussion in this thread, I did more detailed calculations of 
the number of bytes when DTLS 1.3 is used for typical IoT use cases (PSK, RPK, 
Connection ID). The plan is to add this information to 
draft-ietf-lwig-security-protocol-comparison as this has been requested by 
several people. I think some bytes were missing in the earlier estimates for 
TLS 1.3, and as Ben commented, DTLS 1.3 adds some bytes compared to TLS 1.3.

==
Flight#1 #2#3   Total
--
DTLS 1.3 RPK + ECDHE 149373   213735
DTLS 1.3 PSK + ECDHE 18619057433
DTLS 1.3 PSK 13615057343
--
EDHOCRPK + ECDHE  3812186245
EDHOCPSK + ECDHE  43 4712102
==
 Number of bytes

Assumptions:
- Minimum number of algorithms and cipher suites offered
- Curve25519, ECDSA with P-256, AES-CCM_8, SHA-256
- Length of key identifiers: 4 bytes
- Connection identifiers: 1 byte
- The DTLS RPKs use point compression (saves 32 bytes)
- No DTLS handshake message fragmentation
- Only mandatory DTLS extentions, except for connection ID
- Version 30 https://tools.ietf.org/html/draft-ietf-tls-dtls13-30

(EDHOC numbers are for the soon to be published -11 version with cipher suites)

I hope this information is useful for people. Please comment if I missed 
something or if you have any suggestion of things to add or how to present 
things. I do not know currently how these numbers compare to DTLS 1.2.

Below is detailed information about where the byte in different flights as well 
as the RPKs (SubjectPublicKeyInfo). Most of the bytes should have the correct 
value, but most of the length fields are just written as LL LL LL. Below is 
also information about how resumption, cached information [RFC 7924], and not 
using Connection ID affects the number of bytes.


==
DTLS 1.3 Flight #1 RPK + ECDHE
==

Record Header - DTLSPlaintext (13 bytes)
16 fe fd EE EE SS SS SS SS SS SS LL LL

Handshake Header - Client Hello (10 bytes)
01 LL LL LL SS SS 00 00 00 LL LL LL

Legacy Version (2 bytes)
fe fd

Client Random (32 bytes)
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 
1a 1b 1c 1d 1e 1f

Legacy Session ID (1 bytes)
00

Cipher Suites (TLS_AES_128_CCM_8_SHA256) (4 bytes)
00 02 13 05

Compression Methods (null) (2 bytes)
01 00

Extensions Length (2 bytes)
LL LL

Extension - Supported Groups (x25519) (8 bytes)
00 0a 00 04 00 02 00 1d

Extension - Signature Algorithms (ecdsa_secp256r1_sha256) (8 bytes)
00 0d 00 04 00 02 08 07

Extension - Key Share (42 bytes)
00 33 00 26 00 24 00 1d 00 20
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 
1a 1b 1c 1d 1e 1f

Extension - Supported Versions (1.3) (7 bytes)
00 2b 00 03 02 03 04

Extension - Client Certificate Type (Raw Public Key) (6 bytes)
00 13 00 01 01 02

Extension - Server Certificate Type (Raw Public Key) (6 bytes)
00 14 00 01 01 02

Extension - Connection Identifier (43) (6 bytes)
XX XX 00 02 01 42

13 + 10 + 2 + 32 + 1 + 4 + 2 + 2 + 8 + 8 + 42 + 7 + 6 + 6 + 6 = 149 bytes

--
DTLS 1.3 Flight #1 PSK + ECDHE
--

Differences compared to RPK + ECDHE

+ Extension - PSK Key Exchange Modes (6 bytes)
  00 2d 00 02 01 01

+ Extension - Pre Shared Key (51 bytes)
  00 29 00 2F
  00 0a 00 04 ID ID ID ID 00 00 00 00
  00 21 20 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 
17 18 19 1a 1b 1c 1d 1e 1f

- Extension - Signature Algorithms (ecdsa_secp256r1_sha256) (8 bytes)

- Extension - Client Certificate Type (Raw Public Key) (6 bytes)

- Extension - Server Certificate Type (Raw Public Key) (6 bytes)

149 + 6 + 51 - 8 - 6 - 6 = 186 bytes

--
DTLS 1.3 Flight #1 PSK
--

Differences compared to PSK + ECDHE

- Extension - Supported Groups (x25519) (8 bytes)

- Extension - Key Share (42 bytes)

186 - 8 - 42 = 

Re: [Ace] EDHOC standardization

[Hannes Tschofenig]

Hi John,

From our experience neither PSK+ECDHE nor RPK usage is common in IoT 
deployments among the bigger IoT providers.
Today, most companies use certificate-based authentication in almost all cases. 
In some cases plain PSK is used for those cases where devices are particularly 
constraint.

Ciao
Hannes

-Original Message-
From: Ace  On Behalf Of John Mattsson
Sent: Wednesday, November 21, 2018 4:03 PM
To: ace@ietf.org; l...@ietf.org
Cc: Benjamin Kaduk ; salvador@um.es
Subject: Re: [Ace] EDHOC standardization

Hi all,

Inspired by the discussion in this thread, I did more detailed calculations of 
the number of bytes when DTLS 1.3 is used for typical IoT use cases (PSK, RPK, 
Connection ID). The plan is to add this information to 
draft-ietf-lwig-security-protocol-comparison as this has been requested by 
several people. I think some bytes were missing in the earlier estimates for 
TLS 1.3, and as Ben commented, DTLS 1.3 adds some bytes compared to TLS 1.3.

==
Flight#1 #2#3   Total
--
DTLS 1.3 RPK + ECDHE 149373   213735
DTLS 1.3 PSK + ECDHE 18619057433
DTLS 1.3 PSK 13615057343
--
EDHOCRPK + ECDHE  3812186245
EDHOCPSK + ECDHE  43 4712102
==
 Number of bytes

Assumptions:
- Minimum number of algorithms and cipher suites offered
- Curve25519, ECDSA with P-256, AES-CCM_8, SHA-256
- Length of key identifiers: 4 bytes
- Connection identifiers: 1 byte
- The DTLS RPKs use point compression (saves 32 bytes)
- No DTLS handshake message fragmentation
- Only mandatory DTLS extentions, except for connection ID
- Version 30 https://tools.ietf.org/html/draft-ietf-tls-dtls13-30

(EDHOC numbers are for the soon to be published -11 version with cipher suites)

I hope this information is useful for people. Please comment if I missed 
something or if you have any suggestion of things to add or how to present 
things. I do not know currently how these numbers compare to DTLS 1.2.

Below is detailed information about where the byte in different flights as well 
as the RPKs (SubjectPublicKeyInfo). Most of the bytes should have the correct 
value, but most of the length fields are just written as LL LL LL. Below is 
also information about how resumption, cached information [RFC 7924], and not 
using Connection ID affects the number of bytes.


==
DTLS 1.3 Flight #1 RPK + ECDHE
==

Record Header - DTLSPlaintext (13 bytes)
16 fe fd EE EE SS SS SS SS SS SS LL LL

Handshake Header - Client Hello (10 bytes)
01 LL LL LL SS SS 00 00 00 LL LL LL

Legacy Version (2 bytes)
fe fd

Client Random (32 bytes)
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 
1a 1b 1c 1d 1e 1f

Legacy Session ID (1 bytes)
00

Cipher Suites (TLS_AES_128_CCM_8_SHA256) (4 bytes)
00 02 13 05

Compression Methods (null) (2 bytes)
01 00

Extensions Length (2 bytes)
LL LL

Extension - Supported Groups (x25519) (8 bytes)
00 0a 00 04 00 02 00 1d

Extension - Signature Algorithms (ecdsa_secp256r1_sha256) (8 bytes)
00 0d 00 04 00 02 08 07

Extension - Key Share (42 bytes)
00 33 00 26 00 24 00 1d 00 20
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 
1a 1b 1c 1d 1e 1f

Extension - Supported Versions (1.3) (7 bytes)
00 2b 00 03 02 03 04

Extension - Client Certificate Type (Raw Public Key) (6 bytes)
00 13 00 01 01 02

Extension - Server Certificate Type (Raw Public Key) (6 bytes)
00 14 00 01 01 02

Extension - Connection Identifier (43) (6 bytes)
XX XX 00 02 01 42

13 + 10 + 2 + 32 + 1 + 4 + 2 + 2 + 8 + 8 + 42 + 7 + 6 + 6 + 6 = 149 bytes

--
DTLS 1.3 Flight #1 PSK + ECDHE
--

Differences compared to RPK + ECDHE

+ Extension - PSK Key Exchange Modes (6 bytes)
  00 2d 00 02 01 01

+ Extension - Pre Shared Key (51 bytes)
  00 29 00 2F
  00 0a 00 04 ID ID ID ID 00 00 00 00
  00 21 20 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 
17 18 19 1a 1b 1c 1d 1e 1f

- Extension - Signature Algorithms (ecdsa_secp256r1_sha256) (8 bytes)

- Extension - Client Certificate Type (Raw Public Key) (6 bytes)

- Extension - Server Certificate Type (Raw Public Key) (6 bytes)

149 + 6 + 51 - 8 - 6 - 6 = 186 bytes

--
DTLS 1.3 Flight #1 PSK
-

Re: [Ace] Minimizing overhead of certificates in constrained IoT

[Hannes Tschofenig]

Hi John,

I see CWT as a combination of Kerberos ticket (for the use of symmetric key) 
and a certificate format (for the asymmetric key usage) encoded in CBOR.
The claims in the CWT are essentially the attributes you carry in a certificate.

Ciao
Hannes

-Original Message-
From: Ace  On Behalf Of John Mattsson
Sent: Friday, November 2, 2018 12:31 PM
To: t2...@irtf.org; ace@ietf.org
Subject: [Ace] Minimizing overhead of certificates in constrained IoT

Hi,

We recently submitted 
https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-00, which build on 
research done by Research Institutes of Sweden, Royal Institute of Technology 
in Stockholm, and Nexus:

https://kth.diva-portal.org/smash/get/diva2:1153958/FULLTEXT01.pdf
https://doi.org/10.1007/978-3-319-93797-7_14

The mechanism in the draft aims to reduce message overhead with the approach to 
start with a heavily profiled X.509 certificate and encode it to CBOR, 
resulting in around 50% savings in message overhead and storage. A major reason 
for submitting this early draft is to start a discussion on how to minimize the 
overhead (message size, code size, memory, storage, processing, etc.) caused by 
certificates in IoT deployments.

Current X.509 certificates are demanding in several ways (message, code size, 
memory, processing, etc. and are not designed for constrained IoT environments. 
The quite large sizes of even well profiled X.509 certificates mean that they 
take up a large part of the total number of bytes when used in protocols. 
Transmitting, receiving, or even listening for radio is relatively expensive in 
terms of power consumption and as the radio resources are often constrained, 
large messages lead to interference and therefore more latency than just the 
message sizes would infer.

That fact that certificates are sent encrypted in new protocols (TLS 1.3, DTLS 
1.3, EDHOC) means that compression in intermediaries will not work in the 
future. TLS 1.3 and DTLS 1.3 are currently looking at certificate compression, 
but these mechanisms are not optimal for constrained IoT. The use of general 
lossless compression algorithms are quite heavy, and they do not compress 
things optimally.

With the submission of raft-raza-ace-cbor-certificates we would like to start a 
discussion on how to minimize the overhead caused by certificates.

- Which aspects do the community prioritise the most? i.e. message size, code 
size, memory, processing, etc. And how should trade-offs between these aspects 
look like?

- For how long time is people planning to use older protocols that do not 
encrypt certificates? Is it worth specifying gateway type of compression for 
these protocols?

draft-raza-ace-cbor-certificates does currently take the approached to start 
with a heavily profiled X.509 certificate and encode it to CBOR. Another 
approach is to not start with X.509 and do certificates in CBOR directly. This 
can be even more optimal from a theoretical point of view but may never 
deployed. Previous attempts to introduce new certificate types seem to have 
failed. On the other hand the current mechanism increases code size and 
processing for the part verifying the certificate.

- How should new IoT CBOR certificates be introduced in protocols? As a new 
type of certificate or a new compression/encoding algorithm for certificates? 
Is compression/encoding done inside the protocol or outside of the protocol?

- Is CBOR the correct choice if a new encoding is specified? We certainly think 
so.

- What are peoples’ opinions on general lossless compression algorithms?

- Which protocols would the IoT community want to use with new 
certificates/encoding/compression?

I think that a good place to start a discussion about these topics would be in 
T2TRG. If people find this interesting, I suggest having a quick introduction 
on the Friday plenary session and then further discussions in the security 
breakout.

Cheers,
John

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
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] FW: draft-ietf-oauth-pop-key-distribution-04

[Hannes Tschofenig]

I submitted an update of the PoP key distribution document to get it in sync 
with what is happening with the ACE OAuth framework.

Ciao
Hannes

From: Hannes Tschofenig
Sent: Tuesday, October 23, 2018 2:19 PM
To: oauth 
Subject: draft-ietf-oauth-pop-key-distribution-04

Hi all,

I refreshed the PoP key distribution document today, see 
https://tools.ietf..org/html/draft-ietf-oauth-pop-key-distribution-04, in an 
attempt to get the document inline with the agreements we made at the Montreal 
IETF meeting, the Resource Indicators draft, and the work happening in ACE.

Thanks to Mike for going through the draft with me and for spotting several 
copy-and-paste mistakes.

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] Review of draft-ietf-ace-oauth-params-00

[Hannes Tschofenig]

Hi all,

I read through draft-ietf-ace-oauth-params-00 and have a few comments.

1) I believe the document should explain in more detail about how it fits into 
the rest of the OAuth PoP token work.
The story essentially is that we have the HTTP-based transport in the OAuth WG 
and we have the CoAP-based transport
in ACE. draft-ietf-ace-oauth-params-00 is about registering the necessary 
parameters for use with CoAP only.

Neither the abstract nor the intro says this.

2) 'req_aud' parameter

At the last IETF OAuth meeting in Montreal we agreed to adopt a new document, 
called resource indicators, and it can be found here:
https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01

I believe the parameter name and semantics defined in 
draft-ietf-oauth-resource-indicators-01 should match what is defined in 
draft-ietf-ace-oauth-params-00.

The name of the parameter in draft-ietf-oauth-resource-indicators-01 is 
'resource' and it is defined as

   resource
  Indicates the location of the target service or resource where
  access is being requested.  Its value MUST be an absolute URI, as
  specified by Section 4.3 of [RFC3986], which MAY include a query
  component but MUST NOT include a fragment component.  Multiple
  "resource" parameters MAY be used to indicate that the requested
  token is intended to be used at multiple resources.

In a nutshell I believe you should do the following:
 a) rename the parameter to 'resource' to get it inline with 
draft-ietf-oauth-resource-indicators-01
b) use the same semantics as in draft-ietf-oauth-resource-indicators-01
c) find out what the encoding considerations are when using CoAP

3) 'req_cnf' parameter

Changing the name of the parameter name from the previous 'cnf' is good and 
that was also requested at the last IETF due to the potential confusion with 
the 'cnf' claim name. However, I believe the semantics is different to the 
semantics defined in draft-ietf-oauth-pop-key-distribution. Unless I 
misunderstand but the relevant text regarding the req_cnf parameter content is 
this:

   o  "req_cnf" in the token request C -> AS, OPTIONAL to indicate the
  client's raw public key, or the key-identifier of a previously
  established key between C and RS that the client wishes to use for
  proof-of-possession of the access token.

For example, in draft-ietf-oauth-pop-key-distribution there is no key 
identifier passed from the client to the server when making the request for a 
PoP token. Instead, the server just mints one (along with the symmetric key) 
and sends it to the client.


Ciao
Hannes

PS: Why was a standalone document written instead of leaving the parameters in 
the ACE-OAuth framework spec? I guess there are reasons (which I may have 
missed).


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] Progressing the HTTP parameter encoding for OAuth PoP Key Distribution

[Hannes Tschofenig]

Hi all,

after several discussions we believe that we now have a proposal for moving 
forward on this topic.
We plan to update the expired draft  
and
(1) remove the audience parameter and replace it with a separately-specified 
resource parameter,
(2) remove the alg parameter,
(3) update the procedures for requesting and obtaining keying material,
(4) Synchronize with the ACE and WebRTC work to make sure that their use cases 
are appropriately covered.

Regarding (1): The meeting participants have decided to standardize an 
audience-alike parameter (in the form of a requested resource identifier) at 
this weeks IETF OAuth meeting. For that purpose, working group adoption of 
draft-campbell-oauth-resource-indicators is under way.  Only a reference to 
that document will be needed.

Regarding (2): Removal of the alg parameter will simplify the document and does 
not appear to be necessary for the currently investigated use cases. This 
assumption will have to be verified.

Regarding (3): Currently, the ACE-OAuth document and the 
 use different parameter names. 
Furthermore, those parameter names may be in conflict with other, already 
standardized parameter names. Hence, some parameters may need to be renamed. 
The plan is to focus on the following, minimal functionality only: server-side 
symmetric key generation and client-side public key registration to the AS. 
Furthermore, the encoding of the key transport will have to take the different 
token formats and protocols into account.

This approach will allow the ACE and WebRTC work to reference the generic PoP 
key distribution document without having to specify their own duplicate 
functionality.

We are planning to update  next week 
to have something to review.

Ciao
Hannes & Rifaat
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] ACE - OAuth Synchronization

[Hannes Tschofenig]

Hi Ben, Hi Ekr,

We tried to find an agreement of which group defines parameters needed for ACE 
to support the PoP token functionality.
Unfortunately, we didn't manage to find an agreement in which group the work 
should be done.

The ACE working group wants to start a working group last call on 
draft-ietf-ace-oauth-authz in September. Hence, there is some urgency in making 
a decision.

We need your guidance to avoid having the topic bounce back and forth between 
the two groups.

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] FW: EAT Bar BOF Meeting Room -- Square Dorchester

[Hannes Tschofenig]

In context of the presentation Carsten gave at the ACE meeting today (see 
https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-resource-directory-permissions-part-2-00)
 I pointed the group to a Bar BOF about the work on attestation, as described 
in https://tools.ietf.org/html/draft-mandyam-eat-00. The meeting will take 
place later today, as described below, in the Square Dorchester room.

Ciao
Hannes

From: Hannes Tschofenig
Sent: 14 July 2018 17:09
To: e...@ietf.org
Subject: EAT Bar BOF Meeting Room -- Square Dorchester

Hi all,

the meeting room for our Bar BOF, which starts at 18:00 after the afternoon 
session and ends at 19:30, will be "Square Dorchester"

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

[Hannes Tschofenig]

Hi all,

As mentioned at the ACE meeting today in the context of "can IoT devices 
generate random number" I promised to send a pointer to a recent webinar about 
the use of hardware-based RNG functionality. The webinar recording can be found 
at http://www2.keil.com/mbed/mbedtls (look for part 3).

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] FW: PoP Key Distribution

[Hannes Tschofenig]

Note that I posted a mail to the OAuth list about the PoP key distribution, 
which also relates to the work on ACE-OAuth.
If you are interested in this topic please feel free to join the discussion on 
the OAuth mailing list.

From: Hannes Tschofenig
Sent: 03 July 2018 21:46
To: oa...@ietf.org
Subject: PoP Key Distribution

Hi all,

we have been working on an update for the draft-ietf-oauth-pop-key-distribution 
document in time for the deadline but we noticed several issues that are 
worthwhile to bring to your attention.

draft-ietf-oauth-pop-key-distribution defines a mechanism that allows the 
client to talk to the AS to request a PoP access token and associated keying 
material.

There are two other groups in the IETF where this concept is used.


· The guys working on RTCWEB is the first. Misi (Mészáros Mihály) has 
been helping us to understand their needs. They have defined their own token 
format, which has been posted on the OAuth group a while ago for review.


· The other group is ACE with their work on an OAuth-based profile for 
IoT.

Where should the parameters needed for PoP key distribution should be defined? 
Currently, they are defined in two places -- in 
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13 and also in 
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03. In 
particular, the audience and the token_type parameters are defined in both 
specs.

IMHO it appears that OAuth would be the best place to define the HTTP-based 
parameters. ACE could define the IoT-based protocols, such as CoAP, MQTT, and 
alike. Of course, this is subject for discussion, particularly if there is no 
interest in doing so in the OAuth working group.

There is also a misalignment in terms of the content. 
draft-ietf-oauth-pop-key-distribution defined an 'alg' parameter, which does 
not exist in the draft-ietf-ace-oauth-authz document. The 
draft-ietf-ace-oauth-authz document does, however, have a profile parameter, 
which does not exist in draft-ietf-oauth-pop-key-distribution. Some alignment 
is therefore needed. In the meanwhile the work on OAuth meta has been finalized 
and could potentially be re-used.

When the work on draft-ietf-oauth-pop-key-distribution was initially started 
there was only a single, standardized token format, namely the JWT. Hence, it 
appeared reasonable to use the JWT keying structure for delivering keying 
material from the AS to the client.

In the meanwhile two other formats have been standardized, namely RFC 7635 and 
the CWT. For use with those specs it appears less ideal to transport keys from 
the AS to the client using the JSON/JOSE-based format. It would be more 
appropriate to use whatever PoP token format is used instead. Currently, this 
hasn't been considered yet.

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] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

Samuel, Jim,

We have two cases in ACE-OAuth:


1)  Client provides a key (or a reference to a key) to the AS. It wants the 
AS to include that key into the PoP token. The key is the long version of the 
key id*.

2)  Client asks the AS to get a token. In this case the AS creates a key 
and places that key or key id in the PoP token.

We seem to be worried that these keys / key ids are not unique over the 
lifetime of the tokens.
The ACE-OAuth document should say that the AS has to make sure that keys and 
key ids are not re-used over the lifetime of a PoP token, unless this is a 
desired behaviour.
I don’t think that the CWT PoP token is the right place to discuss this topic.

Ciao
Hannes

*: Here is what the draft says:

“
The proof-of-possession key can also be identified by the use of a
   Key ID instead of communicating the actual key, provided the
   recipient is able to obtain the identified key using the Key ID.
“

From: Samuel Erdtman [mailto:erdt...@spotify.com]
Sent: 27 June 2018 08:18
To: Jim Schaad
Cc: Hannes Tschofenig; Benjamin Kaduk; Mike Jones; 
draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

Jim, are you saying that if the client can pick the key identifier and if it 
has seen a key identifier of another client it could request a PoP token with 
the observed key-id and the observed subject but with an new key.
I guess this is a potential scenario that could be worth mentioning in security 
considerations.

If we look at ACE-OAuth there are as far as I can tell a few things that makes 
this a hard attack to do.

When the client makes the token request it is authenticated.

And with the subject being the authenticated client cannot control what goes 
into the cwt as subject

Since the cwt with the PoP key is signed there is no way for the attacking 
client to retro-fit the token to suit its needs e.g. change subject or key-id.

Finally I think it is preferable if the server selects key identifier.

Best regards
//Samuel


On Tue, 26 Jun 2018 at 18:57, Jim Schaad 
mailto:i...@augustcellars.com>> wrote:
Hannes,

My worry is not about implementers getting this correct and picking random
key ids.  My worry is about an attacker seeing the key id of somebody and
trying to use it either with the same or a different AS and getting a key
and then getting permissions associated with the initial key that they
should not be doing.

This is about an attack not about getting things to generally work right.

Jim


> -Original Message-
> From: Hannes Tschofenig 
> mailto:hannes.tschofe...@arm.com>>
> Sent: Tuesday, June 26, 2018 6:09 PM
> To: Jim Schaad mailto:i...@augustcellars.com>>; 
> 'Benjamin Kaduk'
> mailto:ka...@mit.edu>>; 'Mike Jones' 
> mailto:michael.jo...@microsoft.com>>
> Cc: 
> draft-ietf-ace-cwt-proof-of-possess...@ietf.org<mailto:draft-ietf-ace-cwt-proof-of-possess...@ietf.org>;
>  ace@ietf.org<mailto:ace@ietf.org>
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
>
> Hi Jim,
>
> you are essentially proposing that we should not directly use the key id
that
> is in the CWT-PoP but rather use it as input in a key derivation function.
The
> details of that key derivation function are specified outside the CWT-POP
> document and most likely in the context of the various profiles.
> Your proposals below suggest to use, among other things, the session key
as
> input to that function. That sounds pretty straight forward but raises the
> question why we fail to trust the implementer to create random key ids but
> then still trust them to create random keys.
>
> That's fine for me nevertheless.
>
> Ciao
> Hannes
>
> -Original Message-
> From: Jim Schaad 
> [mailto:i...@augustcellars.com<mailto:i...@augustcellars.com>]
> Sent: 24 June 2018 10:15
> To: 'Benjamin Kaduk'; 'Mike Jones'
> Cc: Hannes Tschofenig; 
> draft-ietf-ace-cwt-proof-of-possess...@ietf.org<mailto:draft-ietf-ace-cwt-proof-of-possess...@ietf.org>;
> ace@ietf.org<mailto:ace@ietf.org>
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
>
> Thinking things through, I would be more comfortable with something like
> the
> following:
>
> 1.  Create a confirmation called 'computed key id'.  This has two basic
> values:  What is the computation method?  What is the proof value?  You
can
> optionally have an unprotected KID value used to filter the set of keys on
the
> RS down to a reasonable set to enumerate (hopefully one).
>
> 2.  For RPK and TLS:  Define a method called hash of SPKI which has a hash
> method as a parameter.  Given that this can be computed independently b

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

Hi Jim,

It sounds like we need some high bandwidth face-to-face time on this issue in 
Montreal.
This is an interesting issue and IMHO reaches outside the CWT PoP document.

Ciao
Hannes

-Original Message-
From: Jim Schaad [mailto:i...@augustcellars.com]
Sent: 26 June 2018 18:57
To: Hannes Tschofenig; 'Benjamin Kaduk'; 'Mike Jones'
Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
Subject: RE: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

Hannes,

My worry is not about implementers getting this correct and picking random
key ids.  My worry is about an attacker seeing the key id of somebody and
trying to use it either with the same or a different AS and getting a key
and then getting permissions associated with the initial key that they
should not be doing.

This is about an attack not about getting things to generally work right.

Jim


> -Original Message-
> From: Hannes Tschofenig 
> Sent: Tuesday, June 26, 2018 6:09 PM
> To: Jim Schaad ; 'Benjamin Kaduk'
> ; 'Mike Jones' 
> Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
>
> Hi Jim,
>
> you are essentially proposing that we should not directly use the key id
that
> is in the CWT-PoP but rather use it as input in a key derivation function.
The
> details of that key derivation function are specified outside the CWT-POP
> document and most likely in the context of the various profiles.
> Your proposals below suggest to use, among other things, the session key
as
> input to that function. That sounds pretty straight forward but raises the
> question why we fail to trust the implementer to create random key ids but
> then still trust them to create random keys.
>
> That's fine for me nevertheless.
>
> Ciao
> Hannes
>
> -Original Message-
> From: Jim Schaad [mailto:i...@augustcellars.com]
> Sent: 24 June 2018 10:15
> To: 'Benjamin Kaduk'; 'Mike Jones'
> Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possess...@ietf.org;
> ace@ietf.org
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
>
> Thinking things through, I would be more comfortable with something like
> the
> following:
>
> 1.  Create a confirmation called 'computed key id'.  This has two basic
> values:  What is the computation method?  What is the proof value?  You
can
> optionally have an unprotected KID value used to filter the set of keys on
the
> RS down to a reasonable set to enumerate (hopefully one).
>
> 2.  For RPK and TLS:  Define a method called hash of SPKI which has a hash
> method as a parameter.  Given that this can be computed independently by
> all entities based on a Public Key value and it will be unique then you
have a
> key identifier that will not have collisions independent of who issues the
> CWT.
>
> 3.  For PSK and TLS:  Define a method which takes some parameters
including
> the key value, the CWT issuer identity and perhaps some random string and
> compute a proof of possession value on the PSK.
>
> 4.  For PSK and OSCORE: Define a similar method the question would be what
> the key value is to be used but that can be defined as part of OSCORE
>
> When using the keys for TLS
>
> For RPK the key is carried in the handshake and the server/client can
> generate the computed key id and compare it to what the AS distributed.
> The server can identify which CWTs are applicable by either comparison of
> the RPKs or the computed key id.  This means you have a high probability
> that you will not make a mistake and match to the wrong key.
>
> For PSK the identifier is carried in the handshake which is used to look
up a
> key value and the handshake is performed.  By matching computed key ids
> with the secret value one can ensure to a high probably that only CWTs
that
> reference the same secret are going to be used for permissions even if
they
> come from different AS entities.
>
> For OSCORE it is similar, the identifier is used to look up a key value
and by
> decrypting the CWT the key value is proofed.  You then match computed key
> ids in the same manner.
>
> If you really want to have something that is not cryptographically
computed
> and point to something else, then it makes more sense to me to reference a
> CWT issued by the same entity and say "use the same conformation method
> as this CWT does".
>
> jim
>
> > -Original Message-
> > From: Benjamin Kaduk 
> > Sent: Saturday, June 23, 2018 11:30 PM
> > To: Mike Jones 
> > Cc: Hannes Tschofenig ; Jim Schaad
> > ;
> > draft-ietf-

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

Hi Ben,

You are right. We were talking about the key identifiers.

Let me still stick with the Kerberos example. In that context this would mean 
that the KDC stores multiple accounts in the database that point to the same 
principal name. Have you seen that happening?
Re-using the same principle name over time as identifier get recycle when users 
get retired or otherwise leave the system might be an option. Is this a more 
likely?

As you see I am trying to find some examples of vulnerabilities in existing 
systems and I am having a hard time.

Ciao
Hannes

-Original Message-
From: Benjamin Kaduk [mailto:ka...@mit.edu]
Sent: 26 June 2018 17:14
To: Hannes Tschofenig
Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; 
ace@ietf.org
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

I thought we were worried about collision of key *identifiers*, which were
not necessarily raw keys or hashes thereof.  But it's possible I was not
paying enough attention and got confused.

-Ben

On Tue, Jun 26, 2018 at 03:12:52PM +0000, Hannes Tschofenig wrote:
> It does answer my question, Ben.
>
> This begs the question why the collision of session keys is suddenly a 
> problem in the ACE context when it wasn't a problem so far. Something must 
> have changed.
>
> Ciao
> Hannes
>
>
> -Original Message-
> From: Benjamin Kaduk [mailto:ka...@mit.edu]
> Sent: 26 June 2018 17:00
> To: Hannes Tschofenig
> Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; 
> ace@ietf.org
> Subject: Re: [Ace] Key IDs ... RE: WGLC on 
> draft-ietf-ace-cwt-proof-of-possession-02
>
> On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote:
> > Ben,
> >
> > I was wondering whether the situation is any different in Kerberos. If the 
> > KDC creates tickets with a session key included then it needs to make sure 
> > that it does not create the same symmetric key for different usages.
> > The key in the Kerberos ticket is similar to the PoP key in our discussion.
> >
> > Are we aware of key collision in Kerberos?
>
> I don't believe key collision is an issue in Kerberos.  Long-term keys
> (which are not what we're talking about here) are identified by a principal
> name, encryption type, and version number.  Session keys that are contained
> within tickets (and returned to the client in the KDC-REP) are random, so
> even if we are only using the birthday bound we're still in pretty good
> shape.  The modern enctypes tend to use subsession keys generated by the
> client and/or server as well as the KDC-generated session key, which
> provides further binding to the current session.
>
> Does that answer your question?
>
> -Ben
> 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 
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] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

Hi Jim,

you are essentially proposing that we should not directly use the key id that 
is in the CWT-PoP but rather use it as input in a key derivation function. The 
details of that key derivation function are specified outside the CWT-POP 
document and most likely in the context of the various profiles.
Your proposals below suggest to use, among other things, the session key as 
input to that function. That sounds pretty straight forward but raises the 
question why we fail to trust the implementer to create random key ids but then 
still trust them to create random keys.

That's fine for me nevertheless.

Ciao
Hannes

-Original Message-
From: Jim Schaad [mailto:i...@augustcellars.com]
Sent: 24 June 2018 10:15
To: 'Benjamin Kaduk'; 'Mike Jones'
Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; 
ace@ietf.org
Subject: RE: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

Thinking things through, I would be more comfortable with something like the
following:

1.  Create a confirmation called 'computed key id'.  This has two basic
values:  What is the computation method?  What is the proof value?  You can
optionally have an unprotected KID value used to filter the set of keys on
the RS down to a reasonable set to enumerate (hopefully one).

2.  For RPK and TLS:  Define a method called hash of SPKI which has a hash
method as a parameter.  Given that this can be computed independently by all
entities based on a Public Key value and it will be unique then you have a
key identifier that will not have collisions independent of who issues the
CWT.

3.  For PSK and TLS:  Define a method which takes some parameters including
the key value, the CWT issuer identity and perhaps some random string and
compute a proof of possession value on the PSK.

4.  For PSK and OSCORE: Define a similar method the question would be what
the key value is to be used but that can be defined as part of OSCORE

When using the keys for TLS

For RPK the key is carried in the handshake and the server/client can
generate the computed key id and compare it to what the AS distributed.  The
server can identify which CWTs are applicable by either comparison of the
RPKs or the computed key id.  This means you have a high probability that
you will not make a mistake and match to the wrong key.

For PSK the identifier is carried in the handshake which is used to look up
a key value and the handshake is performed.  By matching computed key ids
with the secret value one can ensure to a high probably that only CWTs that
reference the same secret are going to be used for permissions even if they
come from different AS entities.

For OSCORE it is similar, the identifier is used to look up a key value and
by decrypting the CWT the key value is proofed.  You then match computed key
ids in the same manner.

If you really want to have something that is not cryptographically computed
and point to something else, then it makes more sense to me to reference a
CWT issued by the same entity and say "use the same conformation method as
this CWT does".

jim

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Saturday, June 23, 2018 11:30 PM
> To: Mike Jones 
> Cc: Hannes Tschofenig ; Jim Schaad
> ; draft-ietf-ace-cwt-proof-of-possess...@ietf.org;
> ace@ietf.org
> Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
>
> On Fri, Jun 22, 2018 at 08:48:35PM +, Mike Jones wrote:
> > See my note just now proposing this text to Jim:
> >
> > "Likewise, if PoP keys are used for multiple different kinds of CWTs in
an
> application and the PoP keys are identified by Key IDs, care must be taken
to
> keep the keys for the different kinds of CWTs segregated so that an
attacker
> cannot cause the wrong PoP key to be used by using a valid Key ID for the
> wrong kind of CWT."
> >
> > As long as the PoP keys for different contexts are kept segregated, Key
ID
> collisions or reuse cause no problems.
>
> If we trust everyone to implement things properly.  We should probably
only
> take that risk if we get some other benefit from it, though.  Jim
mentioned
> (off-list?) a scenario involving giving the same client additional
privileges, and
> of course we can gain some simplicity savings if we don't need to enforce
> global key-id uniqueness (for appropriate values of "global").  So this
may
> well be the right thing to do; I just don't think it's without tradeoffs
as your
> text seems to imply.
>
> -Ben

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] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

It does answer my question, Ben.

This begs the question why the collision of session keys is suddenly a problem 
in the ACE context when it wasn't a problem so far. Something must have changed.

Ciao
Hannes


-Original Message-
From: Benjamin Kaduk [mailto:ka...@mit.edu]
Sent: 26 June 2018 17:00
To: Hannes Tschofenig
Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; 
ace@ietf.org
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

On Tue, Jun 26, 2018 at 08:53:57AM +0000, Hannes Tschofenig wrote:
> Ben,
>
> I was wondering whether the situation is any different in Kerberos. If the 
> KDC creates tickets with a session key included then it needs to make sure 
> that it does not create the same symmetric key for different usages.
> The key in the Kerberos ticket is similar to the PoP key in our discussion.
>
> Are we aware of key collision in Kerberos?

I don't believe key collision is an issue in Kerberos.  Long-term keys
(which are not what we're talking about here) are identified by a principal
name, encryption type, and version number.  Session keys that are contained
within tickets (and returned to the client in the KDC-REP) are random, so
even if we are only using the birthday bound we're still in pretty good
shape.  The modern enctypes tend to use subsession keys generated by the
client and/or server as well as the KDC-generated session key, which
provides further binding to the current session.

Does that answer your question?

-Ben
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] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

Ben,

I was wondering whether the situation is any different in Kerberos. If the KDC 
creates tickets with a session key included then it needs to make sure that it 
does not create the same symmetric key for different usages.
The key in the Kerberos ticket is similar to the PoP key in our discussion.

Are we aware of key collision in Kerberos?

Ciao
Hannes

-Original Message-
From: Benjamin Kaduk [mailto:ka...@mit.edu]
Sent: 23 June 2018 23:30
To: Mike Jones
Cc: Hannes Tschofenig; Jim Schaad; 
draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

On Fri, Jun 22, 2018 at 08:48:35PM +, Mike Jones wrote:
> See my note just now proposing this text to Jim:
>
> "Likewise, if PoP keys are used for multiple different kinds of CWTs in an 
> application and the PoP keys are identified by Key IDs, care must be taken to 
> keep the keys for the different kinds of CWTs segregated so that an attacker 
> cannot cause the wrong PoP key to be used by using a valid Key ID for the 
> wrong kind of CWT."
>
> As long as the PoP keys for different contexts are kept segregated, Key ID 
> collisions or reuse cause no problems.

If we trust everyone to implement things properly.  We should probably only
take that risk if we get some other benefit from it, though.  Jim mentioned
(off-list?) a scenario involving giving the same client additional
privileges, and of course we can gain some simplicity savings if we don't
need to enforce global key-id uniqueness (for appropriate values of
"global").  So this may well be the right thing to do; I just don't think
it's without tradeoffs as your text seems to imply.

-Ben
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] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

Hi Jim,

I would like to comment on this issue.

-
> > 14.  I have real problems w/ the use of a KID for POP identification.  It
may
> identify the wrong key or, if used for granting access, may have problems
w/
> identity collisions.  These need to be spelt out someplace to help people
> tracking down questions of why can't I verify w/ this CWT, I know it's
right.
>
> The Key ID is a hint to help identify which PoP key to use.  Yes, if a Key
ID is
> sent that doesn't correspond to the right PoP key, failures may occur.  I
view
> that as usage bug - not a protocol problem.  If keys aren't consistently
known
> and identified by both parties, there are lots of things that can go
wrong, and
> this is only one such instance.  That said, I can try to say something
about the
> need for keys to be consistently and known by both parties, if you think
that
> would help.

> My problem is that if there are two different people with the same Key ID,
either intentionally or unintentionally, then using the key ID to identify
the key may allow the other person to masquerade as the first person.  I am
unworried about the instance of a failure to get a key based on a key id.
That is not the problem you are proposing to address.

-

I think we should document this issue. Here is some text proposal that could go 
into a
separate operational consideration section (or into the security consideration 
section instead).

"
- Operational Considerations

The use of CWTs with proof-of-possession keys requires additional information 
to be shared
between the involved parties in order to ensure correct processing. The 
recipient needs to be
able to use credentials to verify the authenticity, integrity and potentially 
the confidentiality of
the CWT and its content. This requires the recipient to know information about 
the issuer.
Like-wise there needs to be an upfront agreement between the issuer and the 
recipient about
the claims that need to be present and what degree of trust can be put into 
those.

When an issuer creates a CWT containing a key id claim, it needs to make sure 
that it does not
issue another CWT containing the same key id with a different content, or for a 
different subject,
within the lifetime of the CWTs, unless intentionally desired. Failure to do so 
may allow one party
to impersonate another party with the potential to gain additional privileges.
"


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] "sub" and "iss" ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

Hi Roman,

this is also a good question:

> (3) (Editorial) Page 4, Section 3.0, I read to the end of this section by 
> which point there has been discussion of "sub" or "iss".  I was left 
> wondering about how to interpret the case where both are present and none are.

Here is the text from the draft:

"
   The presenter can be identified in one of several ways by the CWT
   depending upon the application requirements.  If the CWT contains a
   "sub" (subject) claim [CWT], the presenter is normally the subject
   identified by the CWT.  (In some applications, the subject identifier
   will be relative to the issuer identified by the "iss" (issuer) claim
   [CWT].)  If the CWT contains no "sub" claim, the presenter is
   normally the issuer identified by the CWT using the "iss" claim.  The
   case in which the presenter is the subject of the CWT is analogous to
   Security Assertion Markup Language (SAML) 2.0
   [OASIS.saml-core-2.0-os] SubjectConfirmation usage.  At least one of
   the "sub" and "iss" claims is typically present in the CWT and some
   use cases may require that both be present.
"

The CWT PoP document does not define the subject or issuer claims.
The document also not mandate a specific set of claims to be included in a CWT 
since this is application profile specific.

Hence, I am wondering whether we could shorten the paragraph above, which is 
actually a bit confusing.

"
This specification adds a new claim to offer the proof-of-possession 
functionality.
There are various claims already defined and the IANA claims registry [REF] 
contains the most
up-to-date list of standardized claims. Application using the CWT functionality 
define
what claims have to be used.

  The presenter can, if necessary, be identified in one of several ways by the 
CWT
   depending upon the application requirements.  If the CWT contains a
   "sub" (subject) claim [CWT], the presenter is the subject
   identified by the CWT. In some cases, there CWT may not include a "sub"
   claim, which allows the presenter to remain anonymous.
"

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] Replay ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

Hi Roman,

Thanks for your review.

As I was re-reading the reviews I spotted this comment:

>  (14) (Editorial)  Page 8, Section 4, Per "Replay can also be avoided if a 
> sub-key is derived from a shared secret that is specific to the instance of 
> the PoP demonstration."  PoP is spelled out everywhere else in this draft but 
> here.  Yes, the acronym is defined, but for readability, I recommend against 
> it using it and consistently spelling it out here too.

I believe the current text is a bit confusing. Here is what it says:

Proof of possession via encrypted symmetric secrets is subject to replay 
attacks.
This attack can, for example, be avoided when a signed nonce or challenge is 
used
since the recipient can use a distinct nonce or challenge for each interaction.
Replay can also be avoided if a sub-key is derived from a shared secret
that is specific to the instance of the proof-of-possession demonstration.

This somehow gives the impression that replay attacks are only a concern for 
symmetric key techniques.
Of course, this is not true. Furthermore, the text gives the impression that 
this attack is actually
something that can be covered within the CWT-PoP token spec itself. This is 
also not the case.

For this reason I am suggesting to change the paragraph to:
"
CBOR Web Tokens with proof-of-possession keys are used in context of an 
architecture,
such as ACE-OAuth [REF], where protocols are used by a presenter to request 
these tokens and
to subsequently use them with recipients. To avoid replay attacks when the 
proof-of-possession tokens
are sent to presenters a security protocol, which uses nonces or timestamps, 
has to be utilized.
Note that a discussion of the architecture or specific protocols CWT 
proof-of-possession tokens
are used with are outside the scope of this specification. "

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] Standardizing Attestation Tokens

[Hannes Tschofenig]

Hi all,

I would like to make you aware of work that will be discussed on attestation on 
the EAT mailing list. Here is the link to the list:
https://www.ietf.org/mailman/listinfo/eat

Here is a document describing the idea:
https://tools.ietf.org/html/draft-mandyam-eat-00

The work is relevant for IoT and non-IoT devices.

Laurence and I are planning to organize a Bar BOF at the Montreal IETF meeting 
to entertain the idea.

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] CWT-PoP & Multiple PoP keys

[Hannes Tschofenig]

Hi Jim,

I had a chat with Mike about relaxing the CWT-PoP spec to allow multiple PoP 
keys in a single CWT token.

He is concerned about the departure from RFC 7800 and, after giving it a bit 
more thoughts, I believe there is an issue. Initially, when we started the work 
our promise was that this is really just an alternative encoding of RFC 7800. 
With changes like those we are obviously breaking that concept. Having multiple 
keys within a single CWT is a corner case and I am not sure anymore whether I 
indeed want to go into that direction. In our implementation we are also not 
using multiple keys in a single CWT either.

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

[Hannes Tschofenig]

Peter,

Did this registration attempt got concluded?

Ciao
Hannes

-Original Message-
From: peter van der Stok [mailto:stokc...@xs4all.nl]
Sent: 24 May 2018 15:55
To: Carsten Bormann
Cc: Hannes Tschofenig; core; ace@ietf.org
Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP

Ok, I will raise the experts to-morrow.

Peter

Carsten Bormann schreef op 2018-05-24 16:37:
> On May 24, 2018, at 16:15, Hannes Tschofenig
>  wrote:
>>
>> Hi all,
>>
>> Trying to finalize this discussion: Could we do an early registry of
>> the Content-Format numbers?
>
> Yes.
>
>> From the discussion so far I believe we concluded that the charset is
>> utf-8
>
> What charset?  I thought we don’t have parameters (see below).
>
>> and that there are no parameters. Is that correct?
>
> That is my understanding so far, but the point of me asking the
> question was to ask the actual experts about these media types.  Did
> we get that input?
>
> Next step: make a proposal and raise this on core-paramet...@ietf.org
> so we get the needed input from the designated expert.
>
> Grüße, Carsten
>
>
>>
>> Ciao
>> Hannes
>>
>> From: Carsten Bormann [mailto:c...@tzi.org]
>> Sent: 16 May 2018 12:30
>> To: Hannes Tschofenig
>> Cc: ace@ietf.org; core
>> Subject: Re: [Ace] Early media-type registration for EST over CoAP
>>
>> Forgot to add another example: the content-format numbers for COSE
>> have parameters.
>>
>> Sent from mobile
>>
>> On 16. May 2018, at 12:26, Carsten Bormann  wrote:
>>
>> 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.
>>
>>
>> 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
>
> ___
> core mailing list
> c...@ietf.org
> https://www.ietf.org/mailman/listinfo/core
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] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

Hi Jim,

I have made changes to the draft based on your review and the updated version 
of the document can be found at https://github.com/cwt-cnf/i-d/pull/13
However, I am not sure we have consensus on the changes.

Ciao
Hannes

-Original Message-
From: Jim Schaad [mailto:i...@augustcellars.com]
Sent: 17 June 2018 01:03
To: draft-ietf-ace-cwt-proof-of-possess...@ietf.org
Cc: ace@ietf.org
Subject: RE: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-02

We have seen a number of messages on this document, but we have not yet seen
an updated draft that addresses all of these issues.  When should we expect
a new version.  It would have been nice to have had two published before
Montreal but that does not seem likely at this point.

Jim


> -Original Message-
> From: Ace  On Behalf Of Roman Danyliw
> Sent: Wednesday, May 16, 2018 6:18 AM
> To: ace@ietf.org
> Subject: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-
> 02
>
> 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

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] How to specify DTLS MTI in COAP-EST

[Hannes Tschofenig]

Here are my thoughts:


·   This group or any other IoT group should not come up with their own 
algorithm recommendations. Reason: we already have a group working on these 
recommendations - CFRG

·   There is no need to talk about new algorithms recommendations. Reason: 
the recommendations have already been made by the CFRG and the TLS 1.3 spec 
lists them.

·   The pace of switching to new crypto algorithm seems to be much slower 
in the IoT world (for the discussed reasons). I feel there is very little most 
of us can do to influence the pace. Reason: very few folks work on 
implementations of crypto algorithms for IoT devices.

Ciao
Hannes

From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: 07 June 2018 22:21
To: Michael Richardson
Cc: Hannes Tschofenig; ace@ietf.org
Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST

TBH, I'm not a fan of SHOULD+, etc., and they're pretty alien to TLS, so you 
should just use words if you want to convey these points.

With that said, I don't really understand the objective here: we're generally 
moving towards the CFRG curves, so what's the reasoning for the P256 MUST and 
why do you think that will change.

-Ekr



On Thu, Jun 7, 2018 at 10:41 AM, Michael Richardson 
mailto:mcr+i...@sandelman.ca>> wrote:

Hannes Tschofenig mailto:hannes.tschofe...@arm.com>> 
wrote:
> why don't you just reference https://tools.ietf.org/html/rfc7925?

Ignorance :-)
Thank you, I think that we will reference it then;

Section 4.4 includes:

At the time of writing, the
recommended curve is secp256r1, and the use of uncompressed points
follows the recommendation in CoAP.  Note that standardization for
Curve25519 (for ECDHE) is ongoing (see [RFC7748]), and support for
this curve will likely be required in the future.

which is what we want to say anyway.

> I am not a big fan of making all sorts of different crypto
> recommendations in our specs that differ slightly.
--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca<mailto:m...@sandelman.ca>  http://www.sandelman.ca/ 
   |   ruby on rails[

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

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] How to specify DTLS MTI in COAP-EST

[Hannes Tschofenig]

In products crypto does not change that fast given the lifetime of IoT devices 
and the hardware support for it. Our customers are asking for NIST certified 
crypto.

Ciao
Hannes

-Original Message-
From: Carsten Bormann [mailto:c...@tzi.org]
Sent: 07 June 2018 18:40
To: Hannes Tschofenig
Cc: Russ Housley; Michael Richardson; ace@ietf.org
Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST

On Jun 7, 2018, at 18:30, Hannes Tschofenig  wrote:
>
> why don't you just reference https://tools.ietf.org/html/rfc7925?

That describes the status of mid-2016.

Can we do something forward-looking?

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] How to specify DTLS MTI in COAP-EST

[Hannes Tschofenig]

Hi Russ, Hi Michael,

why don't you just reference https://tools.ietf.org/html/rfc7925?

I am not a big fan of making all sorts of different crypto recommendations in 
our specs that differ slightly.

Ciao
Hannes

PS: Next time someone suggests the use of a new crypto algorithm I will demand 
that they also implement one themselves.

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Russ Housley
Sent: 07 June 2018 15:55
To: Michael Richardson
Cc: ace@ietf.org
Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST

Michael:

These words were first used by IPsec; see RFC 4307.  They have gained broader 
acceptance.  I see no problem just using them here.

Russ


> On Jun 6, 2018, at 7:32 PM, Michael Richardson  wrote:
>
>
> In draft-ietf-ace-coap-est, we would like to specify some mandatory to
> implement algorithms for DTLS.
>
> We write:
>   The mandatory cipher suite for DTLS in EST-coaps is
>   TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in [RFC7251] which is the
>   mandatory-to-implement cipher suite in CoAP.
>
>   Additionally, the curve secp256r1 MUST be supported [RFC4492]; this curve
>   is equivalent to the NIST P-256 curve.
>
> And this is fine for now, but we'd like to signal that Curve25519
> should be considered as an alternative, but we don't want to make it a
> MUST *today*, and we don't want to force implementations 15 years down
> the road that have it to include secp256r1.
>
> IPsec(ME) has published things like:
> https://datatracker.ietf.org/doc/rfc8247/
> which include language like:
>
>   SHOULD+   This term means the same as SHOULD.  However, it is likely
> that an algorithm marked as SHOULD+ will be promoted at
> some future time to be a MUST.
>
>   SHOULD-   This term means the same as SHOULD.  However, an algorithm
> marked as SHOULD- may be deprecated to a MAY in a future
> version of this document.
>
>   MUST- This term means the same as MUST.  However, it is expected
> at some point that this algorithm will no longer be a MUST
> in a future document.  Although its status will be
> determined at a later time, it is reasonable to expect that
> if a future revision of a document alters the status of a
> MUST- algorithm, it will remain at least a SHOULD or a
> SHOULD- level.
>
> I don't think TLS has done this... maybe TLS plans to.
> We think that we'd like to use SHOULD+ for Curve25519 and MUST- for
> secp256r1, but we aren't sure that the WG will like us to use so many
> words as IPsec to say so.
>
> --
> ]   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

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 all,

Trying to finalize this discussion: Could we do an early registry of the 
Content-Format numbers?

From the discussion so far I believe we concluded that the charset is utf-8 and 
that there are no parameters. Is that correct?

Ciao
Hannes

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

Forgot to add another example: the content-format numbers for COSE have 
parameters.
Sent from mobile

On 16. May 2018, at 12:26, Carsten Bormann mailto:c...@tzi.org>> 
wrote:
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 
mailto:hannes.tschofe...@arm.com>> 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<mailto:ace@ietf.org>; core
Subject: Re: [Ace] Early media-type registration for EST over CoAP

On May 15, 2018, at 10:56, Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> 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.

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] WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes Tschofenig]

Hi Jim,

A few remarks below.

-Original Message-
From: Jim Schaad [mailto:i...@augustcellars.com]
Sent: 09 May 2018 05:51
To: draft-ietf-ace-cwt-proof-of-possess...@ietf.org
Cc: ace@ietf.org
Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02

I'll pull out the list of comments that I wrote a month ago but didn't start 
that computer up recently.

1.  Are all of the authors necessary?  As a chair I need to justify a count of 
more than 5 to the IESG.

[Hannes] As mentioned by Mike already, this was the result of a draft merger. 
The text initially came from an OAuth document (since this work had its history 
in the OAuth WG).

2.  Is the last sentence in section 1 necessary?  Are you actually defining any 
strings that could be case-sensitive?

[Hannes] I think we could get rid of that sentence.

3.  Terminology: In the definition of Issuer please make 'its' clearer.  It is 
not clear whose claims are being bound.

[Hannes] How about:

   Issuer
  Party that creates the CWT and binds the claims to the proof-of-
  possession key.


4.  Terminology: I still think this is 'Presenter' is a very strange term to 
use for this definition.  I would really like to see it be made something that 
makes sense and then say the term is the same as this in JWT.  The term has a 
model of use with it that I do not believe can be sustained even for the ACE 
Oauth case but really not in other cases.

[Hannes] It is a strange term but we used it also in the OAuth JWT PoP document 
and hence it wouldn't make sense to change it now.

5.  Terminology: Recipient matches presenter, and it matches the OAuth model
and not a trust model world.   Relying party or service provider make far
more sense to me.

[Hannes] Same comment as above. I prefer to be in alignment with the OAuth work 
here. I am wondering whether we should also copy the figures from Section 1 of 
https://tools.ietf.org/html/rfc7800 to make the architecture clearer.

6.  Under what circumstances would a 'sub' claim be present and it is not the 
presenter?  I can see that a holder of the key may be implicitly (or
anonymously) named, but putting something in the subject field which is not 
identifying the presenter is something that I would reject without a good 
presentation of why in the document.

[Hannes] Mike provided his perspective on this issue already. CWT is similar to 
JWT a somewhat flexible building block. What claims should, must or may be 
included in a given deployment depends a bit on the use case. Not including the 
subject claim may be useful for privacy purposes, for example. In other cases 
you definitely want to convey that information.

7.  I would disagree with the claim that if the 'sub' claim is missing then it 
would normally be the issuer.  For the world of IoT, I would expect that the 
subject would not be present because there is no need to identify the subject 
to the recipient.  I.e. it is an anonymous subject.

[Hannes] I am not sure that this is always the case in an IoT deployment. For 
example, imagine if a technician accesses some industrial device then I want to 
have the information about the person accessing those devices in my audit trail.

8.  It is not clear to me that either of the sub and iss claims would normally 
be present.  They might be present but neither is needed.  The subject can be 
anonymous and the issuer is identified by the key used to validate the security 
on the CWT.

[Hannes] In many deployments they may well not be present. That's completely 
fine. Fewer claims can sometimes be better.

9.  In section 3.1 the first two sentences appear to be contradictory.
Members are used to identify the POP key.  Other things than a POP key can be 
used than a POP key.  If they are used to identify the POP key- why would they 
not deal with the POP key?  I think that you should do a separation and define 
the 'cnf' file which can hold any number of confirmation methods and then have 
a section on defining some POP cnf method field holders.

[Hannes] How does this sound:


Section 3.1.  Confirmation Claim


FROM:

   The "cnf" claim is used in the JWT to contain members used to
   identify the proof-of-possession key.  Other members of the "cnf"
   object may be defined because a proof-of-possession key may not be
   the only means of confirming the authenticity of the token.  This is
   analogous to the SAML 2.0 [OASIS.saml-core-2.0-os]
   SubjectConfirmation element in which a number of different subject
   confirmation methods can be included (including proof-of-possession
   key information).

TO:

The "cnf" claim in the JWT is used to carry confirmation methods, some of
them use proof-of-possession keys while others do not. This design is
analogous to the SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation
element in which a number of different subject confirmation methods can
be included (including proof-of-possession key information).




10.  In section 3.1 P1 - I am not sure wh

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

[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

[Hannes Tschofenig]

Ø  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.

[This is probably an issue unrelated to EST topic but worthwhile to talk about 
nevertheless.]

How do you expect companies to come up with reasonable IoT security?

Our (Arm) thinking was that working on building blocks that are then combined 
in complete IoT device management solutions (like LwM2M) and supplemented with 
security guidance that includes the implementation (software & hardware), as we 
do it with the Platform Security Architecture (see 
https://developer.arm.com/products/architecture/platform-security-architecture),
 is the only way to improve IoT security. If you just dump ideas and protocols 
with lots of options to OEMs and let them figure out the security story 
themselves then guess what the outcome will be.

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

[Hannes Tschofenig]

FWIW I would untangle the tamper resistance property from the lifetime of these 
keys.
You will want to issue new keys periodically anyway.

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Panos Kampanakis (pkampana)
Sent: 15 May 2018 16:01
To: Mohit Sethi; ace@ietf.org
Subject: Re: [Ace] EST over CoAP

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) 
mailto:pkamp...@cisco.com>>; Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>; 
ace@ietf.org<mailto: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<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<https://www.ietf.org/mailman/listinfo/ace>

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] EST over CoAP: Introduction

[Hannes Tschofenig]

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

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

[Hannes Tschofenig]

I get the impression that the EST over CoAP spec will not completed as soon as 
I had hoped.

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

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

[Hannes Tschofenig]

Hi Mike,

You are getting the story wrong.

First, the boundary between what is IoT and what isn't isn't that clear. One 
man's IoT is another man's data center.

Second, many of the problems we run into are fundamental to crypto rather than 
the protocol design. There is just no free lunch even if we would like it sooo 
much.

Ciao
Hannes

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael StJohns
Sent: 14 May 2018 22:50
To: ace@ietf.org
Subject: Re: [Ace] EST over CoAP

Hi Hannes -

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 seems to be a bad argument both for the big guys and for the small guys.  
And its really not about the hardware requirements for a specific device that 
should be the concern of the IETF, but about specifying the protocol 
requirements - said requirements being reasonable for the specific limited 
field of use.

E.g. The recommendation must be for a "good" RNG - that doesn't necessarily 
translate to a requirement for a hardware TRNG, but if that's what you need to 
get to "good", then that's what the builder should spec.

I'm wondering if its time to fork the Internet Standards path and create an IOT 
Standards RFC path that deals with these less capable devices, explains that 
these are not to be used for larger devices unless talking to the constrained 
devices, but which still gets the IETF standards process treatment?  RFC 7228 
may have done us a disservice by not explaining what the minimum capable 
security services were for each of the classes.

Mike



On 5/14/2018 2:49 PM, Hannes Tschofenig wrote:
> Here is my personal take on this: you have to do your threat assessment to 
> find out what attacks you care about. This will determine your hardware 
> requirements (not the other way around). At a minimum you will have to figure 
> out how to provide randomness in your design and that can come at a very low 
> cost. For example, if I use ST's MCU finder 
> http://www.st.com/en/development-tools/st-mcu-finder.html and search for 
> microcontrollers that have TRNG support then I get 410 results (only for STM 
> MCUs).
>
> If you aim for devices that also provide ECC/RSA crypto in hardware +
> tamper-resistant key storage then we will move past the RFC 7228-type
> of constrained IoT device classes. You have can a look of what this
> means in context of Arm IP:
> https://developer.arm.com/products/system-ip/trustzone-security-ip
>
> On a meta-level I have difficulties with the security design decisions made 
> in IETF IoT-related groups since they swing back and forth between the 
> extremes in pretty much no time. At the London IETF meeting I hear people 
> talking about drafting guidelines for the use of new crypto algorithms with 
> IoT devices since P256r1 and AES128-CCM is not good enough for them. At the 
> same time I am having a hard time convincing people that using an 
> unauthenticated identifier is not good for security.
>
> Ciao
> Hannes
>
> -Original Message-
> From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael
> Richardson
> Sent: 14 May 2018 16:54
> To: ace@ietf.org
> Subject: Re: [Ace] EST over CoAP
>
>
> Hannes Tschofenig  wrote:
>  > 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.
>
> I think that this is the future, and I very much agree with you.
>
> There seems to be a stock of older designs which have gone through other 
> kinds of validation (for instance, think about the engineering review of 
> physical cases and PCB design for electric metering).
>
> My impression is that there is a desire to significantly update the security 
> profile of these devices (some of which are in the field already).  What was 
> deployed had poor security, or had proprietary protocols and there is a 
> desire to move it up to "par".
>
> The other thing I hear is that the crypto libraries involved take some time 
> to get FIPS-140 certified and so the one that the devices were deployed with 
> do RSA only, and there is a desire to update them to ECDSA (or EdDSA), and 
> means new keys.
>
> I think that any device with any kind of TPM would rather generate it's own 
> keys.  Whether it's a physical TPM, or some kind of TrustZone,etc. version.
>
>  > In a nuts

Re: [Ace] EST over CoAP

[Hannes Tschofenig]

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

 

Re: [Ace] EST over CoAP

[Hannes Tschofenig]

Here is my personal take on this: you have to do your threat assessment to find 
out what attacks you care about. This will determine your hardware requirements 
(not the other way around). At a minimum you will have to figure out how to 
provide randomness in your design and that can come at a very low cost. For 
example, if I use ST's MCU finder 
http://www.st.com/en/development-tools/st-mcu-finder.html and search for 
microcontrollers that have TRNG support then I get 410 results (only for STM 
MCUs).

If you aim for devices that also provide ECC/RSA crypto in hardware + 
tamper-resistant key storage then we will move past the RFC 7228-type of 
constrained IoT device classes. You have can a look of what this means in 
context of Arm IP: 
https://developer.arm.com/products/system-ip/trustzone-security-ip

On a meta-level I have difficulties with the security design decisions made in 
IETF IoT-related groups since they swing back and forth between the extremes in 
pretty much no time. At the London IETF meeting I hear people talking about 
drafting guidelines for the use of new crypto algorithms with IoT devices since 
P256r1 and AES128-CCM is not good enough for them. At the same time I am having 
a hard time convincing people that using an unauthenticated identifier is not 
good for security.

Ciao
Hannes

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael Richardson
Sent: 14 May 2018 16:54
To: ace@ietf.org
Subject: Re: [Ace] EST over CoAP


Hannes Tschofenig  wrote:
> 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.

I think that this is the future, and I very much agree with you.

There seems to be a stock of older designs which have gone through other kinds 
of validation (for instance, think about the engineering review of physical 
cases and PCB design for electric metering).

My impression is that there is a desire to significantly update the security 
profile of these devices (some of which are in the field already).  What was 
deployed had poor security, or had proprietary protocols and there is a desire 
to move it up to "par".

The other thing I hear is that the crypto libraries involved take some time to 
get FIPS-140 certified and so the one that the devices were deployed with do 
RSA only, and there is a desire to update them to ECDSA (or EdDSA), and means 
new keys.

I think that any device with any kind of TPM would rather generate it's own 
keys.  Whether it's a physical TPM, or some kind of TrustZone,etc. version.

> In a nutshell, I think you are better of recommending OEMs to select
> the right hardware for the given task.

I'd like to find some text that acknowledges the past, while setting things up 
better for the future.

> PS: For the proxy work (in context of DTLS/TLS) you might want to reach
> out to your co-worker Owen Friel.

he's in other loops already, but he seems shy to post to lists.

> IMPORTANT NOTICE: The contents of this email and any attachments are

I wish your email system would omit this, as it's both meaningless and 
sometimes harmful.

--
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] EST over CoAP

[Hannes Tschofenig]

Hi Michael,


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


Hannes Tschofenig  wrote:
> Thanks for the feedback.

> Why do you think it takes so long to get this document finished? In the
> end, you are just carrying EST over CoAP instead of conveying it over
> HTTP.

It's not really just us, it's time to get people to do the reviews required :-) 
It's also constrained about getting other documents out.  RFC8366 spent 4 weeks 
in AUTH48 due to a small YANG correction discovered at the last minute.
(And we had to bikeshed the title)

[Hannes] Fully understand. I am just advocating that we keep things going at a 
reasonable pace. I have seen documents hanging around waiting for not further 
defined events.
Since we are implementing this functionality I want to make sure we don't see 
surprises last minute.

> PS: Regarding the use of DTLS/TLS for the proxy. There are obviously
> ways to get this accomplished but the question for me is whether this
> functionality should go into this version of the spec or rather a
> companion document.

I don't understand the use case.
EST requires a secure transport from requesting entity to Registrar.
A DTLS/TLS proxy represents a MITM, and I don't see a way for either party to
trust it.I have been pushing to better detail how people want this to work.

[Hannes] I guess we will speculate about it when that work gets started in 
another document.

Ciao
Hannes


--
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] EST over CoAP

[Hannes Tschofenig]

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

[Hannes Tschofenig]

Hi Michael,

Thanks for the feedback.

Why do you think it takes so long to get this document finished? In the end, 
you are just carrying EST over CoAP instead of conveying it over HTTP.

Ciao
Hannes

PS: Regarding the use of DTLS/TLS for the proxy. There are obviously ways to 
get this accomplished but the question for me is whether this functionality 
should go into this version of the spec or rather a companion document.

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


Hannes Tschofenig  wrote:
> 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.

Server side key generation is not the only way to use this, and I'm not 
interested in it myself.

I don't think we can do http/coap proxying in any meaningful way if we are 
using TLS/DTLS for the secure transport.  I have encouraged my co-authors to 
either take it out, or realize that they are confusing the EST link (over DTLS) 
with the Registration Authority<->Certificate Authority link (over HTTPS).

> So, do we have a plan for how to complete the document?

I am implementing at this time, with CoAP over DTLS using OpenSSL today,
and mbedTLS for the pledge side in a week or two.   I believe that we can
finish this document by the end of the summer.  I don't think we'd get to WGLC 
before IETF102, and as August is a dead zone for IETF work, having a WGLC 
before September 1 would seem pointless.

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

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] EST over CoAP

[Hannes Tschofenig]

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] Security and privacy for small memory microprocessor based IoT devices are still being invented

[Hannes Tschofenig]

Here is the article mentioned during the ACE meeting today:
https://www.networkworld.com/article/3223952/internet-of-things/5-reasons-why-device-makers-cannot-secure-the-iot-platform.html

As you can see that there are some misconceptions about our IETF work. It is 
easy to conclude that "Security and privacy for small memory microprocessor 
based IoT devices are still being invented" reading some IETF drafts.

This motivated  me to start a webinar series on "Securing IoT applications with 
Mbed TLS" to clarify topics raised in this article and other IoT security 
myths. The first part is available for download:
http://www2.keil.com/mbed/mbedtls

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

[Hannes Tschofenig]

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

[Ace] ACE-OAuth implementation

[Hannes Tschofenig]

As mentioned at the working group meeting today we, Arm, released a product 
feature with the name "Secure Device Access" for our Mbed Cloud product. It 
implements functionality of the ACE-OAuth framework. I talked about it during 
the OAuth security workshop last week, see 
http://st.fbk.eu/sites/st.fbk.eu/files/osw2018-hannestschofenig.pdf

I believe that this is the first product announcement concerning ACE-OAuth. A 
corresponding press release can be found at:
https://blog.mbed.com/post/mbed-cloud-secure-devices

My slides as well as the blog post explain what we have been doing and what 
functionality we cover.

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] Client Token Analysis

[Hannes Tschofenig]

Hi all,

as mentioned during the ACE working group meeting today the paper with the 
analysis of the Client Token functionality can be found at the paper published 
for the OAuth Security Workshop.

Here is the link to the paper
http://st.fbk.eu/sites/st.fbk.eu/files/osw2018-ace.pdf

There are also lots of papers worthwhile reading:
https://st.fbk.eu/osw2018/program

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] FW: [Atlas] ATLS side meeting

[Hannes Tschofenig]

FYI: Here is the info for the lunch meeting today to discuss application layer 
TLS.
Feel free to join us.

From: Atlas [mailto:atlas-boun...@ietf.org] On Behalf Of Richard Barnes
Sent: 14 March 2018 16:04
To: at...@ietf.org
Subject: [Atlas] ATLS side meeting

Hey all,

FYI, we have a room booked for a side meeting at the IETF meeting, during the 
lunch break on Monday.  The assigned room is Hilton Meeting Rooms 1-4.

There will not be catering, so lunch is BYO.

--Richard

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-oauth-authz-10.txt: Leaving implementers in the dark

[Hannes Tschofenig]

Hi Carsten,

OAuth defined something called "Dynamic Client Registration", which gives you 
an idea what type of information is typically needed. Here is the RFC: 
https://tools.ietf.org/html/rfc7591

Regarding "initial integration of a device into a network only" isn't this 
sometimes called "network access authentication"?

In any case, I agree with you that we should add some text about what 
information is assumed to be present.

Ciao
Hannes

-Original Message-
From: Carsten Bormann [mailto:c...@tzi.org]
Sent: 20 February 2018 19:05
To: Hannes Tschofenig
Cc: Michael Richardson; Ludwig Seitz; ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in 
the dark

On Feb 20, 2018, at 08:43, Hannes Tschofenig  wrote:
>
> IMHO the biggest problem with "onboarding" is that people create new terms 
> without specifying what they actually mean and thereby fail to see the 
> relationship with existing work.

Right.  I have no idea what client registration has to do with “onboarding”, 
but I use that term for the initial integration of a device into a network only.

I continue to believe that we need a clear understanding of what information is 
exchanged during client registration that is relevant to the ACE OAuth.  There 
definitely will also be other information (“business logic”, and you can call 
the exchange of that part of the registration info “onboarding” if you like), 
and that is where the vendor differentiation can set in, but we should have no 
trouble defining the ACE content of client registration.

If we don’t define that ACE content, there is no way to know whether ACE OAuth 
is secure.

Defining the ACE content of the client registration as a set of data structures 
also helps with achieving actual interoperability, even if additional business 
logic is required in a specific case.

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] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

[Hannes Tschofenig]

IMHO the biggest problem with "onboarding" is that people create new terms 
without specifying what they actually mean and thereby fail to see the 
relationship with existing work.

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael Richardson
Sent: 19 February 2018 19:21
To: Ludwig Seitz
Cc: ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in 
the dark


Ludwig Seitz  wrote:
> I agree that onboarding is a valid concern (which is why I wrote
> appendix B),
> but lets not delay draft-ietf-ace-oauth-authz any further by adding a 
whole
> new set of functionality in it.

Back at the beginning of ACE it was clear that onboarding was an entire project 
of itself.  That's why I argued to keep it out of the first charter.

Onboarding suffers from a tendancy to boil the ocean, combined with the
elephant/blind-men problem.The way to tackle onboarding is not with
a single unifying ocean boiling protocol, but rather by letting each interested 
party define small protocols, and over time find commonality.
I get the vision of:  https://en.wikipedia.org/wiki/Nibbler

So while it is unfortunate if some implementers feel to be "in the dark", 
before we could rectify that situation, we'd have to know which implementers we 
are worried about.

--
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] Working group adoption of draft-vanderstok-ace-est

[Hannes Tschofenig]

I support the adoption of this document. My concerns with earlier versions of 
the document have been addressed with the recent draft updates.

I have read the latest version of the draft and I believe it is even ready for 
a working group last call once adopted.

Ciao
Hannes

PS: Sorry for my late response.

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Jim Schaad
Sent: 30 January 2018 21:23
To: ace@ietf.org
Subject: [Ace] Working group adoption of draft-vanderstok-ace-est

This is the start of a two week call for input on the adoption of the WG of the 
document draft-vanderstok-ace-est.  The document has been presented at the last 
two meetings and has some significant recent updates to respond to feedback.  
There seemed to be support at the last F2F to adopt.

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 Feb 13
2018.

Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
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-oauth-authz-10.txt: Leaving implementers in the dark

[Hannes Tschofenig]

Hi Carsten

It seems that I have misunderstood you. If you are not talking about the 
initial provisioning then all we need to do is to clarify. Looking at Appendix 
B it appears that some text needs improvement.

Ciao
Hannes

-Original Message-
From: Carsten Bormann [mailto:c...@tzi.org]
Sent: 18 February 2018 18:15
To: Hannes Tschofenig
Cc: ace
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in 
the dark

On Feb 18, 2018, at 08:52, Hannes Tschofenig  wrote:
>
> Hi Carsten,
>
> The challenge is that there is not a single way used in deployments. Some of 
> the techniques fall outside the scope of the IETF (such as the 
> manufacturing-related interactions), link layer specific approaches (such as 
> a Blueooth Smart App), or Secure Element-based concepts.
>
> Note that related solutions, such as ZeroTouch, ANIMA, EST, also leave this 
> initial provisioning undefined.

But this is not about initial provisioning (CAM-C), this is about C talking to 
an RS.
If there are only intra-silo ways in ACE to get this going, we should clearly 
document this.
Also, we need to clearly state what we believe needs to be achieved in that 
intra-silo step so the ACE protocol can rely on the security properties 
achieved there.

> I am not saying that nothing should be standardized but it will be difficult 
> to recruit the appropriate expertise and to get the relevant companies to 
> participate.

The IETF is generally most successful when it works on building blocks that 
then can be picked up by implementers and other SDOs (that pickup process then 
serves as another layer of quality control for us).  I don’t know why we have 
to be shy about this specific area for building blocks.

Grüße, Carsten

>
> Ciao
> Hannes
>
> -Original Message-
> From: Carsten Bormann [mailto:c...@tzi.org]
> Sent: 18 February 2018 17:45
> To: Hannes Tschofenig
> Cc: ace
> Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in 
> the dark
>
> On Feb 18, 2018, at 08:35, Hannes Tschofenig  
> wrote:
>>
>> Hi Carsten,
>>
>> We should maybe add that this information is provisioned either during 
>> manufacturing, via a commissioning tool or some other mechanisms. Not sure 
>> whether this will indeed add more but it might be useful to know.
>
> For a protocol that is meant to be interoperable, there need to be standard 
> (if not MTI) ways of getting this done.
> At least we need to have a defined interface between CAM (“commissioning 
> tool”) and C for letting C know what was agreed about how to address AS and 
> which RSes it should be used for.
>
> 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.
>
>

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