Re: [Ace] [Anima] Proposing document draft-amsuess-ace-brski-ace-00
Carsten Bormann wrote: >> the manufacturer has all the golden values (the endorsements). > The manufacturer may have the reference measurements. Whether anyone > whose statements you are willing to base your authorization on is > willing to endorse the manufacturer’s claims is one of the > authorization questions hidden in attestation… If your point is that other entities may have reference measurements/endorsements then I agree. But so what? RFC9334 says that the RP (the Registrar) needs a policy as to whose Attestation Results to trust, so that needs to be considered. If you want a choice in verifier, you have it. There is some latent fear among some people that the *Manufacturer* can only be the factory in Shenzhou, and we can't trust them. Of course, we went to some effort to say, MASA, not Manufacturer. But, I wonder if there are some linguistic thing occuring with the word Manufacturer that gets it confused with "factory". iPhones are manufacturered by Apple, even if the Factory is Foxcon. OEM = Original Equipment Manufacturer, which to my mind, is the entity that holds the private key corresponding to the firmware signing trust anchor. Anyway, *A* reason that I haven't written up an EAT-in-Voucher ID is that I've been convinced that devices need continuous assurance, and it makes no sense to me to run a remote attestation once in BRSKI, and then again in a continuous form. I think just run the continuous assurance protocol, but OTH, it would be nice to do this before the device is accepting onto the network. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Proposing document draft-amsuess-ace-brski-ace-00
Christian =?iso-8859-1?Q?Ams=FCss?= wrote:
> On Thu, Jul 20, 2023 at 02:35:09PM -0400, Michael Richardson wrote:
>> So draft-ietf-anima-constrained-voucher, has some optimizations that
>> can sometimes let the pledge skip the /crts, but why is that
>> interaction so expensive? Note that in lake-authz, the voucher isn't
>> actually sent, rather just the signature on what we expected to see in
>> the voucher so extensions to the voucher would be difficult to do.
> My impression was that this was not just an optimization that saves an
> initial request, but that the voucher (in all its augmentation that it
> gets when the registrar turns the PVR into an RVR) could serve as the
> one way the credentials are provisioned through. Packing everything
There are some things which quite reasonably could go into the
PVR/RVR+voucher. One example is remote attestation: the pledge is the
Attester, the Registrar is the RP, and the MASA is the Verifier. This makes
sense because the manufacturer has all the golden values (the endorsements).
> So in a sketch, we'd do just as in authz+CoJP, and in the msg_3 request
> (or even a later regular OSCORE request if we use CoJP too) ask the
> registrar for the relevant AS data.
Yes.
> I'll try to estavblish that as a new baseline. (Not sure yet whether
> that'd better be a -01, or an ace-est-ace as it's not really depending
> on BRSKI any more). An upside of that scenario is that it has a
Agreed: it's not BRSKI, just ... start with a secure channel.
> In such a scenario I'd only come back to PRM if there's good reason to
> actually do PRM (i.e. there are stairs, not just because it looks
> suitable), or when that rollover is AS initialized.
PRM has some innovation that allows the CSR to be created at the same time as
the voucher, and then some cross-checking.
> That handover gets me thinking: In authz-for-CoJP, the authenticator
> plays the role of the JRC (I figure it'll play reverse proxy for the
> actual one). Does that mean that the authenticator needs to stay around
> (and keep its EDHOC created OSCORE session / roll it over as described
> in CoJP), or can it ever hand the device off to a JRC directly?
If the OSCORE session can be moved, then I think yes, it could hand it off.
In particular on 802.15.4 (6tisch/CoJP) networks, then network rekeys have to
be handled carefully, and can take some time to get done.
> That was supposed to be an either-or; I don't suppose I'd have a device
> that takes both. (Should actually have been cert/AS data). But having
> the registar serve both JRC data and AS details sounds realistic to me.
Ah, yes. Agreed. The registrar has to cope with it all.
>> pick a "morning" in gather.town. I'm also remote. Maybe Wednesday
>> before ANIMA.
> Wednesday before at gather.town sounds great, looking forward to it!
Table "A" for Anima.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Proposing document draft-amsuess-ace-brski-ace-00
Christian Amsüss wrote:
> On Wed, Jul 12, 2023 at 05:52:30PM -0400, Michael Richardson wrote:
>> IN section 1.1, without having given a picture of what you are doing
>> you start to say: "The alternative to this constraint is to declare
>> this a blob" and this is really distracting to understanding what you
>> *ARE* doing.
> I think it's important, when limiting a reader's options, to point them
> at what else they could do. I've created issue [1] for the time being
> to not lose this, for I want to both resolve it for smooth reading and
> keep all the pointers around.
All I'm saying is that it's an objection/diversion of thought essentially
mid-sentence.
I'm not saying to remove it, I'm saying that is seriously distracts the reader.
> [1]: https://gitlab.com/chrysn/brski-ace/-/issues/1
>> "the pledge initiates EDHOC to the lake-authz.arpa anycast address,
>> sending an encrypted identifier for its MASA (party W) in EAD_1."
>>
>> This sounds like it's a new thing, but I think it's just the
>> lake-authz step one, right?
> It is; a wording enhancement will be in the editor's copy soon.
Good.
> If this is pursued in its YANG form (even partially), then I suppose
> that the draft would only serve as a staging ground for the extra YANG
> statements, with hopes to be sufficiently mature in time to be merged
> into constrained-voucher before the batch is through. (No clue how
> realistic that is right now).
Basically what I get from OPSAWG's publication of YANG modules is that they
go into a new RFC, with *JUST* the YANG module and when we need to revise the
YANG in anyway, a new RFC is published.
For instance https://datatracker.ietf.org/doc/rfc9418/ and RFC9417.
>> My impression is that you don't really want the *MANUFACTURER*
>> (authorized) to send down some ACE keying material. That is, Volvo
>> shouldn't be sending your car a key to open your building garage door,
>> rather, your building owner should be.
>>
>> So, augmenting the voucher, which comes from the Manufacuter (MASA,
>> aka W) to your pledge is wrong. You want the ACE Authorization
>> Server, aka V, to actually send the right keys.
>>
>> I think that either you want to use the new V/W relationship that
>> EDHOC, lake-authz setup to send the keys in message 4, or you want to
>> do a new FETCH on some some new resource to get them.
> My hope has been that like with BRSKI where a domain CA public key can
> be shipped right with the voucher, so I hoped to replicate the same
> slimness here. IIUC, a device can use BRSKI to enroll DTLS credentials
> without the need to do GETs to the registrar's /crts and the /s(r)en
> interactions.
So draft-ietf-anima-constrained-voucher, has some optimizations that can
sometimes let the pledge skip the /crts, but why is that interaction so
expensive?
Note that in lake-authz, the voucher isn't actually sent, rather just the
signature on what we expected to see in the voucher so extensions to the
voucher would be difficult to do.
> Revisiting what cBRSKI can do, maybe I was wrong, and only the /crts
> (and not the /s(r)en) part has an equivalence in BRSKI. Is that an
> equivalence (between /crts and pinned-domain-cert)? And if so: Why can
> the registrar not take a certificate request in the PVR and send the
> result of /sen on to the pledge through the RVR?
So if I understand you, you'd like to avoid additional round trips by
stacking the certificate request with the PVR. BRSKI-PRM does *exactly*
that, because in the store-and-forward ("DTN") nature of PRM, round trips
involve people walking up/down stairs.
In PRM we assume HTTP(S), and TCP and networks without much in the way of
challenge. So transfering a few tens of kilobytes shouldn't be a concern,
and of course it will take multiple TCP segments.
In a challenged network I don't understand making any step of the transaction
bigger than 1200, or even close to that, rather than just doing a second
transaction. Block mode seems less reliable from a state machine point of
view than a second transaction.
> Or did I get things so wrong that everything in the voucher was only to
> establish the first secure connection, and getting /crts etc is a
> necessary next step anyway?
Yes, in general, that's the case.
https://www.sandelman.ca/SSW/talks/brski/brski-animation.pdf
slide 117. Screencasts linked from https://brski.org/brski-impls.html
> But then, looking at CoJP-over-authz, how does the pledge learn any
> further keys and identities? Would it follow up the message_3 CoJP
> request and the CoJP respon
Re: [Ace] Proposed document: draft-amsuess-t2trg-raytime-01
Christian Amsüss wrote: >> We wrote something similiar for RFC8366 or 8995, but I think we ripped >> most of it out. For instance, if a device had a valid IDevID with a >> notBefore of 2021-02-01, and the RTC said 1980-01-01 [good old DOS >> epoch], then one could be sure it was at least 2021-02-01! > Does either of those have a versioned history? Without a change log in > them, and no mention of the example DOS epoch discoverable in either, I > couldn't find what was there. Yes, DT and github.com/anima-wg/bootstrap. I looked back a bunch coming up with: https://github.com/anima-wg/anima-bootstrap/blob/5f2527381c291af12f4f9df3c26feb1d079bda20/dtbootstrap-anima-keyinfra.txt section 2.6.1... but thtat's really the same text as in the RFC. Let' try git blame... https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-18#section-2.6.1 This might not be the last version that had this more complex text. It seemed like it was riff for distracting review comments, and didn't really help our primary focus, so it go removed sometime later. Unfortunate that the version buttons on the right don't retain the section number. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Proposed document: draft-amsuess-t2trg-raytime-01
Christian Amsüss wrote:
> Hello T2TRG (because of its researchy character), hello ACE (because
> this is applied to your ecosystem),
I don't think this belongs in t2trg, but I don't object.
maybe it goes into ACE or IOTOPS.
> motivated by project requirements, I've written a draft[1] on how
> devices without reliable Internet connectivity (and thus time source)
> can deal with time limited tokens.
I like your document.
We wrote something similiar for RFC8366 or 8995, but I think we ripped most
of it out. For instance, if a device had a valid IDevID with a notBefore of
2021-02-01, and the RTC said 1980-01-01 [good old DOS epoch], then one could
be sure it was at least 2021-02-01!
You are just advancing the raytime based upon verified information from the
AS. I definitely like that.
{There is a Doctor Who and/or Blakes Seven and/or Stargate plot here though.}
> The concept and trade-offs will not be surprising to many, but to my
> knowledge they have not been written up. In addition, this document
> lists the mechanisms a device can use to reject outdated tokens on a
> best effort base.
> I'd appreciate the group's input on the document, in particular in the
> area of previous work there.
I opened an issue in your gitlab.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Proposing document draft-amsuess-ace-brski-ace-00
Hi Christian, I'm excited by your document.
First some editorial suggestions. IN section 1.1, without having given a
picture of what you are doing you start to say:
"The alternative to this constraint is to declare this a blob"
and this is really distracting to understanding what you *ARE* doing.
"the pledge initiates EDHOC to the lake-authz.arpa anycast address, sending
an encrypted identifier for its MASA (party W) in EAD_1."
This sounds like it's a new thing, but I think it's just the lake-authz step
one, right?
You did a bunch of YANG:
uses "vch:voucher-artifact-grouping" {
augment "voucher" {
And I really wish that it worked that way.
But, it just doesn't.
https://play.conf.meetecho.com/Playout/?session=IETF116-NETMOD-20230331-0030
Start at 1:53:00.
My repo of examples is at: https://github.com/mcr/yang-augment-test
I can chase down the ML posts about this if it helpful.
--- on to your problem.
My impression is that you don't really want the *MANUFACTURER* (authorized)
to send down some ACE keying material. That is, Volvo shouldn't be sending
your car a key to open your building garage door, rather, your building owner
should be.
So, augmenting the voucher, which comes from the Manufacuter (MASA, aka W) to
your pledge is wrong. You want the ACE Authorization Server, aka V, to
actually send the right keys.
I think that either you want to use the new V/W relationship that EDHOC,
lake-authz setup to send the keys in message 4, or you want to do a new FETCH
on some some new resource to get them.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Anima] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)
Russ Housley wrote: >>> Is that identity now an LDevID (even though it has a completely >>> different shape than the IDevID), or is a certificate based LDevID >>> still created as part of the process, or can the device happily >>> complete the ANIMA processes without an LDevID? >> >> I wouldn't call it an LDevID. >> You don't need to do EST and ask for an LDevID. > I do not see this being prohibited. It would require: > - CA recognizes the trust anchor associated with the IDevID, > - CA can issue the LDevID, > - Client can authenticate the EST server based on something configured at the factory. I think you are speaking at cross-purposes. Christian wants to know if ANIMA/BRSKI can "complete" without asking for an LDevID. (yes) Alternatively, if some OSCORE context with a symmetric key can count. You have latched onto getting an LDevID without using EST. Agreed: you don't need EST, you can use any other enrollment protocol you want, and the BRSKI-AE document is about using CMP, for instance. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Anima] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)
Christian Amsüss wrote: > Yes, that's the way I'd hope they could be used. For example, if a > device were onboarded into an ACE domain with three AS that's using the > ACE-OSCORE profile with the devices, they'd obtain three symmetric keys > with a key identifier h'00', h'01' and h'02' respectively, so that when > the device receives a token, it'll try the one key and not any. No, that part does not make sense. The voucher is authenticating the (public key) identity of the Registrar (aka AS) to the Pledge. If you want to do further key derivations, then you'd have to some PRFs and/or DH (for PFS). >> It makes me nervous, but just because of the normal shared-key threat >> model. > That'd make me nervous too, but see above -- with shared keys, it'd be > at least my expectation that there's a key for every AS. > ... which also means that there'd be a need to update data that > originally came in on an ANIMA voucher, and I don't know whether that's > better done through ANIMA again or through ACE. Has to be done through OSCORE/EDHOC. > The identity a device (after onboarding onto an AS through ANIMA means) > will have as its operational identity the (AS-URI, audience) tuple, > confirmed by the shared key(s) it has obtained. It would not receive > any certificate, and not use the IDevID unless onboarding is started > anew. Yes, but the shared key comes from the EDHOC operation. > Is that identity now an LDevID (even though it has a completely > different shape than the IDevID), or is a certificate based LDevID > still created as part of the process, or can the device happily > complete the ANIMA processes without an LDevID? I wouldn't call it an LDevID. You don't need to do EST and ask for an LDevID. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)
Benjamin Kaduk wrote:
> On Mon, May 01, 2023 at 12:09:03PM +0200, Christian Amsüss wrote:
>> Hi Michael, (CC'ing ACE list because what I think will be the larger
>> part of the thread is hopefully relevant)
>>
>> > > there a generalization of the IEEE identifiers that also makes > >
>> sense for constrained but more general-purpose-oriented devices, > >
>> for which the ANIMA products can still be used?
>> >
>> > Yes, I agree: replacing the IDevID makes a lot of sense if the
>> control over > the software-update trust anchor changes.
>>
>> When talking about such processes, can we still use the IDevID term
>> (even though an IDevID is "stored in a way that protects it from
>> modification"), or is the use of the term OK because we're not
>> modifying but replacing it, or do we need to use a more general term,
>> or do we not care?
> I don't have much of an opinion on this at the moment but could
> probably be convinced that using IDevID is ok.
I wanted to wait for other opinions.
I begin to wonder if we should do our own 802.1AR. The document is 90%
references to IETF RFCs, many of them old or vague. Another half is a
pseudo-API, which nobody uses.
I don't really understand the concerns that Ben and Christian have raised.
>> * Does pinned-domain-pubk work also for COSE keys as used for signed
>> CWTs? (If so, is there a key identifier to go with it?)
> COSE key identifiers ('kid') are not exactly what you would typically
> call a "key identifier" in unconstrained spaces. In particular, they
> are just for optimizing lookup over trial decryption, and you have to
> associate your authorization data with the full key entry, not with the
> 'kid'. COSE 'kid' are not globally unique, and you might run into a
> lot of places using kid of '0' and relying on context to infer which
> one is meant.
pinned-domain-pubk pins a specific public key, in the case of "pubk", but
*value* the COSE kid is not really involved *at all*
pinned-domain-pubk-sha256 pins by SHA256 hash, but for 256-bit ECDSA keys, that
might
not be much of an actual savings.
>> * Some ACE profiles (eg. ACE-OSCORE, RFC9203) are typically used with
>> a symmetric key shared between AS and RS (and that may be the only key
>> material). Is it fine from an ANIMA PoV to only have such key
>> material? (When such a key is used, it obviously needs to be
>> encrypted; at least some methods of ANIMA, eg. EST, can do that).
> It makes me nervous, but just because of the normal shared-key threat
> model. (It is the group-shared threat model since you may have more
> than one instance of AS for ANIMA purposes, but it's probably okay to
> have "AS1 attacks AS2" as out of scope since the AS is assumed to be
> trusted.)
symmetric keys could be used with constrained vouchers, from the MASA to the
Pledge. They couldn't be used in the other direction, where the Registrar,
having no relationship with the Pledge, needs to validate the IDevID.
I wouldn't want to do this though, and I see no advantage, only extreme risk.
>> * (At least) When AS is used with asymmetric tokens, the RS needs to
>> be told its audience identifier; I'd guess that'd be a new leaf. *
>> Once onboarding onto ACE has completed, all the device's identity
>> would be ACE (except for the IDevID that's left in place for a factory
>> reset). Is that fine with an ANIMA setup?
> Without the full context of the preceding thread, it's hard to be sure
> I understand properly, but I think yes, ANIMA expects LDevID for
> onboarded devices, so if you're building ACP using ACE crypto it should
> be fine.
I see no reason the (provisional)[D}TLS connection between Pledge and Registrar
can't be used to initialize a symmetric key for OSCORE. Apply a suitable key
exporter.
The Registrar becomes (or communicates with) the AS.
If you are using EDHOC, then a suitable key was already created by EDHOC.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-moskowitz-ecdsa-pki-10
Michael Richardson wrote: >> * 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. > This turns out to be a complete distraction. > We had text about this in early BRSKI drafts, but the thing is that this is > about identifying the TPM device itself, which is really not the IDevID. > I'd have to look back in five year old emails to explain what it really was > about, but the short of it is that you should just pretend you never read > this part, as it really does help you. It really does *NOT* help anyone. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-moskowitz-ecdsa-pki-10
Hannes Tschofenig wrote: > 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): I found 1AR very difficult/obtuse. I had some communications with authors at one point that provided some history as to why. It would be nice to revise it within the IETF. > * 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. Yes. To clarify for archives, we are talking about the X520SerialNumber attribute. Section 2.3.1 of RFC8995 tried to be definitive hear. > * IDevIDs SHOULD use the GeneralizedTime value 1231235959Z in the notAfter field. Yes, identified as the "does not expire" entry. Of course, the notAfter field of the CA that signed the certificate might expire much sooner, but it could get resigned over time. The real limitation on IDevID longevity is really the cryptographic strength of the algorithms involved. > * 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. This turns out to be a complete distraction. We had text about this in early BRSKI drafts, but the thing is that this is about identifying the TPM device itself, which is really not the IDevID. I'd have to look back in five year old emails to explain what it really was about, but the short of it is that you should just pretend you never read this part, as it really does help you. > * All certificates contain the authorityKeyIdentifier (as a non-critical extension). Yes, because identifying the CA by the SubjectDN alone is a losing proposition over the time scales involved. > * Intermediate certificates contain the subjectKeyIdentifier, as a > non-critical extension. The subjectKeyIdentifier extension SHOULD NOT > be included in DevID certificates. s/Intermediate/Subordinate/ > * If a critical keyUsage extension is included in the IDevID, it MUST > include digitalSignature. The keyUsage extension MAY include > keyEncipherment. In general, IDevID should be maximally useful, so any KU or EKU should be AVOIDED. > Is my reading of IEEE 802.1AR correct? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] ace-ake-auth updates for latest EDHOC principles
The authors of draft-selander-ace-ake-auth have been discussing how to update
this draft to reflect some of the changes in EDHOC. Specifically, there is a
concern that ace-ake-auth reveals too much in message_1, things which EDHOC
has worked hard to keep private.
For those that don't know ace-ake-auth, it fits into the "Ultra-constrained"
onboarding column for the diagram that was part of
https://datatracker.ietf.org/doc/html/draft-richardson-enrollment-roadmap-03
(and was in the IoT-Dir wiki, which needs to be resurrected. The diagram is
also visible at:
https://github.com/anima-wg/enrollment-roadmap/blob/master/technology-components.svg
)
The ACE connection is that the backend (aka "BRSKI-MASA" protocol equivalent)
was leveraged against the ACE mechanism. There is now some reconsideration
here. Fundamentally, it would be nice to know where the document adoption is
going so that we'd know where to have public discussions about the trade-offs.
(please note reply-to)
The location of the MASA (aka "W" in the document) is provided in the clear
during message_1, with the actual device serial number encrypted to W using a
static DH key that the pledge ("U") has been provisioned with.
It would be nice to move some of this from message_1 to message_3, which
would guard better against on-path attacks that impersonate V. The URL
provided during message_1 is visible to any observers, and since this is
onboarding, any network privacy is not yet applicable.
OTH, the authorization step needs to complete before message_2 can properly
be formed, as it contains enough of the RFC8366 constrained-voucher semantics
that it allows the pledge (U) to authenticate V.
Knowing the identity of the MASA may tell you a lot about the device in
question. This is a place where having many MASA outsourced to a big MASA
helps with privacy. It's also a place where perhaps oblivious-HTTP might
help.
There is a question about what the security policy of W is.
Is it TOFU-ish, aka promiscious MASA, or does *it* know which device has been
sold to whom?
Also, the URL for the MASA is ideally very very short :-)
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
[Ace] ace-ake-authz --- Re: interim-2022-ace-01 interim approved
Göran Selander wrote: > We would like to present the new EDHOC-OSCORE profile of ACE that was > submitted for IETF 114: > https://datatracker.ietf.org/doc/html/draft-selander-ace-edhoc-oscore-profile > In brief, the idea is the following: Whereas in the OSCORE profile the > access token is bound to a symmetric key used with OSCORE, in this > profile the access token is bound to a public key credential used to > authenticate with EDHOC and establish a shared symmetric key which is > used with OSCORE. There is also some renewed interest in draft-selander-ace-ake-authz. It would be good to understand if this fits into the ACE charter, or not. I think that Göran has presented about it at some pre-pandemic point. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] AUTH48 changes to draft-ietf-ace-coap-est-18.txt
Hi, draft-ietf-ace-coap-est-18 finished the author interaction and approval a couple of weeks ago. One of the things that came up at the last minute was the way in which "tls-unique" from TLS 1.2 is replaced with a key exporter in TLS 1.3. This is explained in draft-ietf-kitten-tls-channel-bindings-for-tls13, and we added an informative to reference to that document. This was suggested by the Area Director, and the authors were completely in agreement. Basically, we inserted this paragraph in section 3. For (D)TLS 1.3, Appendix C.5 of [RFC8446] describes lack of channel bindings similar to tls-unique. [TLS13-CHANNEL-BINDINGS] can be used instead to derive a 32-byte tls-exporter binding from the (D)TLS 1.3 master secret by using a PRF negotiated in the (D)TLS 1.3 handshake, "EXPORTER-Channel-Binding" with no terminating NUL as the label, the ClientHello.random and ServerHello.random, and a zero- length context string. When proof-of-possession is desired, the client adds the tls-exporter value as a challengePassword in the attributes section of following the algorithm described PKCS #10 CertificationRequest [RFC5967] to prove that the client is indeed control the private key at the time of the (D)TLS session establishment. This email is something we meant to send at the time, but we didn't assign someone to do that. I was cleaning up my inbox... I think the RFC itself will emerge from RPC any minute now. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AD review of draft-ietf-ace-cmpv2-coap-transport-04
Benjamin Kaduk wrote: > A brief look into the history of RFC 7030 reveals that several > reviewers took objection to the usage of "arbitrary labels" under > /.well-known/est in question here, including a DISCUSS ballot from > Stephen Farrell. Unfortunately, (in my assessment) it seems that that > position was converted to a COMMENT prematurely, as only the question > of "how would this even work at all" was resolved, and the question of > "why does this need to be well-known" was not. Yes, as a deep reader of RFC7030, these labels always seemed like a solution looking for a problem. > In particular, if you have out-of-band between client and server about > what "arbitrary label" to use, then there is by assumption a channel > that could be used to coordinate what URI to use, so the server could > just assign a regular URI out of the portion of the URI namespace that > is wholly under its control (i.e., just the toplevel /arbitraryLabel1 I always assumed that the arbitrary label was something that the manufacturer provisioned. A device that needed multiple certificates for, "email", "https" and "xmpp" would know that, it would use that kind of thing there. THe different labels would be patched through a front-end to different CAs in the backend. But that this was entirely a local thing. I actually always thought that /.well-known was excessive for EST, period. I can't imagine a situation where an EST Registrar would do anything else. There is a big operational difference between EST vs securitytxt, which might be on any server. But, what mattered is that we pick a common place to put the EST stuff, and the established part of the dance floor that the IETF has marked off is /.well-known, so EST is there. It makes sense to put CMP there too. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Protocol Action: 'Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)' to Proposed Standard (draft-ietf-ace-dtls-authoriz
We are really some years away from *DTLS* from being ubiquitously available in libraries. Even for those that have some of it, it doesn't all work that well. And it might not be available in FIPS certified libraries yet. In RFC8995, we wrote (section 5.1) after IESG review: Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED on the pledge side. Encourage 1.3. Tolerate 1.2. This does cause some policy bifuration because of the different ways in which ciphers are named/negotiated, but that should not be a problem in practice. The CCM-8/MTI for CoAPS is really the bigger problem that we need to resolve. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] EAT document (was Re: [Rats] CDDL for CWT, JWT, UCCS and UJCS)
Laurence, I took a look through eat-11 just now. It's 70 pages to the appendix (17 pages of appendix), of which 28 pages (10 through 28) are about claims. 11 pages (section 8) is the CDDL. So let's say, not really 70 but 59 pages of content that requires human attention. 15 pages for privacy and security considerations. Section 7 concerns me. It's a profile for writing profiles. I wonder if section 3 (Claims) shouldn't come after section 6, before 7. section 6, which is about keys, maybe even should be earlier. To me, the document looks done to me. I think that there are wording fixes that would make it a little easier to read, but it sure looks finished to me. If there are still problems with some of the claims, maybe we could move those claims to another document. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Anima] Certification Authority renewal/rollover and intra-device communication
Brian E Carpenter wrote:
>> Brian E Carpenter wrote:
>> > I *really* don't understand this stuff, but how long could the rollover
>> > take, for a reasonably large IoT network (presumably thousands of
>> > devices)? Are we talking about a few seconds when no new sessions could
>> > start, or what?
>>
>> For sleepy IoT devices that wake up once a day, and run on a slow
network?
>> Could be a few weeks, easily.
>>
>> But, on such networks, the devices mostly don't talk to each other at
all.
> What, no networks of cooperating sensors ("I've detected smoke, did you
> detect smoke too?")
yeah, but since both sensors are sleeping, the coordination would be in the
central point.
>> Industrial situations like factories aren't doing a lot of device2device
>> communication (i.e. without involving the control system), but if they
did,
>> then they'd want to schedule the certificate renewal/rollover at a
specific time.
> Agreed, that would be normal procedure in control systems of all kinds.
> It's less clear in what are euphemistically called tactical networks; a
> certificate rollover on a battlefield could be a big deal.
the scene is the back of a truck (or sparse fuselage: think Edge of
Tomorrow), with 10 soldiers on each side: "Marines! Drop in five. Synchronize
your trust anchors!"
>> I think that we could do this by issuing new certificates with a
notBefore
>> date in the future, but to date, I don't think we have a clear
specification
>> that says this.
> Ack.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Anima] Certification Authority renewal/rollover and intra-device communication
Brian E Carpenter wrote: > I *really* don't understand this stuff, but how long could the rollover > take, for a reasonably large IoT network (presumably thousands of > devices)? Are we talking about a few seconds when no new sessions could > start, or what? For sleepy IoT devices that wake up once a day, and run on a slow network? Could be a few weeks, easily. But, on such networks, the devices mostly don't talk to each other at all. Industrial situations like factories aren't doing a lot of device2device communication (i.e. without involving the control system), but if they did, then they'd want to schedule the certificate renewal/rollover at a specific time. I think that we could do this by issuing new certificates with a notBefore date in the future, but to date, I don't think we have a clear specification that says this. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Certification Authority renewal/rollover and intra-device communication
In:
https://github.com/anima-wg/constrained-voucher/pull/177/files
We make a compromise on the CA rollover protocol defined RFC4210.
Specifically, during the period when devices are renewing their certificates,
we do not support communication between devices with different certificates.
For instance two devices creating a new DTLS session between them, or even
IKEv2 or EDHOC using certificates.
Existing connections could continue, including rekeying, but new ones would
not be possible to create if the devices are in different states.
It's not clear to the design team how RFC7030 would have supported this
anyway: when would the OldWithNew and NewWithOld certificates have been
transfered, and at what point would devices learn that they no longer need to
include those in the certificate chains that are exchanged inband.
Given IoT networks that are primarily M2MP, we think that it *is* reasonable
that a non-constrained data collection system could have all the right
certificates (OldWithNew, NewWithOld) to operate. But, we don't know how
that system got them.
{You might argue that this is really ace-est-coaps^WRFC9148 matter, and
probably you'd be right. But that document is past AUTH48, waiting for DTLS13}
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Fwd: New Version Notification for draft-tiloca-ace-revoked-token-notification-04.txt
Marco Tiloca wrote:
> We have recently submitted an updated version of
> draft-tiloca-ace-revoked-token-notification
> https://tools.ietf.org/html/draft-tiloca-ace-revoked-token-notification-04
I hadn't noticed this document before.
I will say that I'm skeptical about the use cases.
I took a quick read through section 1.
{If I had to make allusions to PKIX, I wonder if isn't more like an
"OCSP"-staple than a CRL}
> For a Client to
>access the Resource Server, the Client must present the issued Access
> Token at the Resource Server, which then validates and stores it.
I guess the "stores it" seems surprising to me.
I think that it might be worth clarifying that it's the RS that would be
subscribed to the TRL on the AS. I think that the Intro should discuss
Client vs RS code, and if there is a goal to require code changes at both
ends or not.
Your protocol looks (at a quick scan) is very well worked out, but I don't
know enough about when this would be used to understand what tradeoff you have
made.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] call for adoption for draft-marin-ace-wg-coap-eap
Eduardo Inglés (IMT) wrote: > Regarding the writing of the draft, I agree with Michael Richardson > that it can be improved to facilitate the understanding of some > concepts. For example, I would rewrite this sentence to understand it > on a first reading: "EAP requests go always from the EAP authenticator > and the EAP peer and the EAP responses from the EAP peer to the EAP > authenticator." And perhaps it is convenient to clarify in the > abstract that this draft is a lower layer EAP to avoid confusion with > the EAP methods. However, I do agree with the authors on the usefulness > of the protocol. Could you please explain to me a use case? Did you use an EAP method to key OSCORE? Did you do this without a TLS method within the EAP? If you did use a TLS method within EAP, then did you compare: (1) IP/UDP/CoAP/EAP/TLS to: (2) IP/UDP/DTLS/CoAP What was your EAP peer to AAA server communication transported? Was it EAP over RADIUS? If so, how did you setup the RADIUS key? Or did you use DTLS or TLS for the RADIUS? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] call for adoption for draft-marin-ace-wg-coap-eap
Dan Garcia Carrillo wrote: > I hope the last email answered your questions. Are you talking about this answer: > - Well known protocol thas provides flexible authentication with diffrent > methods and counting. > - It integrates well with AAA. > - It has a standard and very well known Key Management Framework. because it continues to not be answer. These are all features of EAP. How does EAP-over-CoAP benefit? EAP can be used inside (D)TLS (and maybe even cTLS) without CoAP having to carry EAP. I guess you want to be able to key OSCORE. So, I would guess that this must involve not using EAP-TLS* (or TEAP, or TTLS, etc.), so I think that reduces to some kind of EAP-PAKE situation, or EAP-SIM/AKA. Do both peer talk to the same AAA server? In that case, then they must have already established a secure relationship with the AAA server. (Because, radius demands it). If you have that, then you can just use the ACE framework to get OSCORE keys, treating the AAA server as the AS or RS. If they don't talk to the same AAA server, then how are the AAA servers related? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] call for adoption for draft-marin-ace-wg-coap-eap
Mohit Sethi M wrote: > Is your concern only in the context of IoT or do you think in general > we are better off using protocols directly without the EAP framework > overhead? EAP is designed to be used within a protocol, to interact with AAA infrastructure. Use within 802.1X, and IKEv2 has been great. The purpose of which is to authenticate a relationship, and provide keying material. This document claims to be useful between two peers, then goes on to acknowledge that there are more entities involved. 1) If we aren't talking about IoT, why would we be talking about CoAP? 2) I haven't seen a use case for this yet. 3) If you are trying to produce keying material for OSCORE, and EDHOC is not to your liking, and you want *TLS* involved, then just use DTLS or ATLAS or cTLS. You can run your favourite EAP methods within TLS if you want to. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] call for adoption for draft-marin-ace-wg-coap-eap
I reviewed the document before, and my concerns were not really answered. I can not understand what the applicability is. The document starts off with: The goal of this document is to describe an authentication service that uses the Extensible Authentication Protocol (EAP) [RFC3748]. The authentication service is built on top of the Constrained Application Protocol (CoAP) [RFC7252] and ALLOWS AUTHENTICATING TWO CoAP endpoints by using EAP without the need of ADDITIONAL PROTOCOLS TO BOOTSTRAP A SECURITY ASSOCIATION BETWEEN THEM. ... The assumption is that the EAP method transported in CoAP MUST generate cryptographic material [RFC5247] This implies use of one of the many EAP-TLS modes, some EAP PAKE mode, or maybe, in theory some EAP-SIM/AKA mode. 1) TLS modes could just use TLS, or DTLS and omit the extra EAP bytes. If saving those bytes are not important, then the use of PANA seems to do the same thing. 2) The EAP PAKE modes could just TLS with some PSK or PAKE authentication. 3) The EAP-SIM/AKA modes are not realistic, as they generally depend upon being able to talk to a database of SIM/AKA secrets. So, which modes that generate cryptographic material are envisioned? The document goes on to say: The CoAP client MAY contact with a backend AAA infrastructure to complete the EAP negotiation as described in the EAP specification [RFC3748]. which is a third party, when the intro told me that no third party was required. Even figure 1 show three parties. And section 5 says there might be five parties, again including an AAA server. I believe that this entire proposal goes against the ACE architecture, and should not be adopted by this WG. This work seems to duplicate the work in LAKE, as well as cTLS, while not bringing any clear advantage over existing protocols. If adopted, I don't review the document. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)
Dan Garcia wrote: > EAP can be used in the context of IoT for authentication. But, to what end? 1) If it is onboarding a new device, then there is no connectivity until after authentication. so you can't use CoAP, you have to use 802.1x, or some equivalent, or create a system such as draft-ietf-6tisch-minimal-security. Which does use CoAP and OSCORE already. 2) If it for application authentication, then you need to use EAP to setup MSK for later use by a context. We do this in IKEv2, (D)TLS already. So the only left would be OSCORE, yet you write "could", as if it was an afterthought. Tell me what is your application? What will be impossible if we don't do this work? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)
Could someone point to a use case for "EAP over CoAP" please? Is the goal to key an OSCORE context, or what? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Charter discussion
<#secure method=pgpmime mode=sign> Göran Selander wrote: > In the same spirit there was support at the meeting [2] to specify > protection of EST payloads profiled for use with OSCORE as > communication security protocol, together with a suitable AKE for > authentication. Following the adoption of EDHOC in LAKE this work has > now been revived [5]. IMHO the reasoning above still makes sense. > With this in mind, and taking into account recent discussion on the > list, perhaps this part of the charter: > ”The Working Group will standardize how to use Constrained Application > Protocol (CoAP) as a Transport Medium for the Certificate management > protocol version 2 (CMPv2). ” Note that CMPv2 is being revised in LAMPS, and that the ANIMA brski-async-enroll is specifying CMPv2 as an alternative for EST in an onboarding flow. I further expect to propose text to brski-async-enroll to do CMPv2 via CoAP multicast + CORECONF. I'd rather do this work in the proposed IOTOPS WG, but I don't really understand how that is working out yet. As such, there is no need to find another place for to do CMPv2/over CoAP. > should be rephrased or complemented with the reasoning above, for example: > The scope of the Working Group includes profiles of the Enrolment over Secure Transport (EST) transported with the Constrained Application Protocol (CoAP)” Is this a re-interpretation of the charter, or a proposed charter change? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Call for adoption draft-msahni-ace-cmpv2-coap-transport-01
Hi, I've read draft-msahni-ace-cmpv2-coap-transport-01. I think that the major reason to use CMP instead of EST is avoid the need for DTLS on the constrained client. As such, use of coaps seems far less interesting. In particular, I think that section 4.2, on CoAPs to HTTPS proxy is just wrong. I don't see why we need any kind of end to end trust assertions given that it is CMP. MITM trust for anchors seems a rather unwanted thing. Why can't the EE just be configured to speak to a CoAPS enabled RA (using it's name), and then transported to the CA via HTTPS. It is not like having the TLS MITM proxy is reducing crypto effort for any entity. I have no fundamental objection to this work, and I think that it should be adopted. But, I think that it is worth doing more than just s/http/coap/. I think that end points should be specified, as well as resource discovery. I was writing some text (not yet pushed) for BRSKI-ASYNC-ENROLL about how to do CMP for the "Delay Tolerant Networks" that AE envisions. On constrained networks, there are some significant tussles between allowing certificate renewal to be driven by a state machine on the client device vs by the network itself. Client devices know when they are awake and can receive renewals, but they don't know if the network has capacity at that time. On the other hand, the network knows when it has bandwidth, and it can manage things. My approach to CMP would be define a set of resources and then use CORECONF to access/update them. I think that: https://www.ietf.org/id/draft-ietf-netconf-trust-anchors-13.html https://www.ietf.org/id/draft-ietf-netconf-keystore-20.html The later offers a CSR leaf that a RA could *retrieve*, and then when a certificate is available, could push into the keystore. This also deals with what the trust anchors are. It could be that some additional leafs are needed to implement some of the additional CMP specific functionality. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Benjamin Kaduk wrote: >> > The requirement "the client MUST be able to determine whether an AS has >> > the authority to issue access tokens for a certain RS. This can for >> > example be done through pre-configured lists, or through an online >> > lookup mechanism that in turn also must be secured." indicates that C >> > is required to have another mechanism to determine the AS for a >> > specific RS and that the unauthorized AS address is completely >> > redundant. >> >> This is a hard problem. >> Q: "Who are you?" >> A: "Depends upon who is asking! Who are you?" >> A: "Depends upon who is asking! Who are you?" >> ... >> >> The DNS-SD WG produced rfc8882, but as I understand it, >> https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-privacy-05 >> was abandonned because the WG did not see implementation/energy. >> I can't seem to find the thread discussing that state. > Interestingly, the corresponding requirements document was just published > recently as RFC 8882. > "A problem with no solution is a hard problem"... I thought Christian Huitema's solution, which I think is three or four years old, was reasonable. The WG just couldn't get reviews or people interested in implementing. Maybe ACE cares enough now. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
sg> A compromised RS may use the hints for attempting to trick a client sg> into contacting an AS that is not supposed to be in charge of that RS. sg> Therefore, C must not communicate with an AS if it cannot determine sg> that this AS has the authority to issue access tokens for this sg> RS. Otherwise, a compromised RS may use this to perform a denial of sg> service against a specific AS, by redirecting a large number of client sg> requests to that AS. Jim Schaad wrote: > [JLS] I do not know how C is supposed to be able to determine if AS has > the authority to issue access tokens for a specific RS. If it had the > ability to do that then it can go directly to the AS in question > without ever needing to use this mechanism. This mechanism is designed > to be used for the case where C does not have a priori knowledge about > which AS it will talk to get the token for RS. I was going to ask the same thing. This is variation of the onboarding problem, but also it ignores how devices got network access in the first place. If C and RS share some trust in some nearby third party, then that party could vouch. I say "nearby", because having them both trust google or azure or amazon doesn't help, because that anchor has no real knowledge about whether RS or RS' is actually nearby. RS' could be legitimately onboarded with "cloud", but just happens to be a device "next door". Or could it? yes, in theory, but the question arises about how C and RS are communicating? If one assumes that they are on the same L2, or different L2's managed by the same L3, then there is a local third party. In most cases, if RS' can spoof a response, it's because it is on the same L2, having the same L2 security as C. If C and RS are distant (you try to turn on your blood pressure sensor across the Internet) then yes, it could wind up with the wrong sensor. >>>> - That RS shares the AS address with anybody that asks can be a >>>> severe privacy problem. If RS is a medical device, the AS address >>>> can reveal sensitive information. If RS is a blood pressure sensor >>>> it could e.g. be “AS address = >>>> coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” > [JLS] My first hope is that this RS would never return an AS address to > a client. Sending information which has secure privacy problems > amounts to a case where the rule should be: If C does not know what AS > to talk to, it has no business talking to me (RS). At which point, I wonder what the point of the AS is. > [JLS] This is the type of situation where that information itself is > going to be information to which access is to be restricted and where > you need to talk to an AS to get permissions to get that information. > In this type of situation I would expect that the information would > only be available either throw an already secure channel or from a DS > with the, not yet defined, AS attributes. So, RS could answer with some less specific AS, that deals with who C is? The, as it were, cloudflare of IoT? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
John Mattsson wrote: > - That RS shares the AS address with anybody that asks can be a severe > privacy problem. If RS is a medical device, the AS address can reveal > sensitive information. If RS is a blood pressure sensor it could > e.g. be “AS address = > coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” > The requirement "the client MUST be able to determine whether an AS has > the authority to issue access tokens for a certain RS. This can for > example be done through pre-configured lists, or through an online > lookup mechanism that in turn also must be secured." indicates that C > is required to have another mechanism to determine the AS for a > specific RS and that the unauthorized AS address is completely > redundant. This is a hard problem. Q: "Who are you?" A: "Depends upon who is asking! Who are you?" A: "Depends upon who is asking! Who are you?" ... The DNS-SD WG produced rfc8882, but as I understand it, https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-privacy-05 was abandonned because the WG did not see implementation/energy. I can't seem to find the thread discussing that state. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] bringing draft-selander-ace-ake-authz to ACE?
Göran Selander wrote: > We have been working on lightweight procedures for an IoT device to > join a network. The join process may include a number of components > such as authentication, remote attestation, authorization, enrolment of > locally significant certificate, etc. Much of current standards are > based on doing things in sequence, one thing at a time. This may be a > good idea but it introduces some redundancies. One way to reduce > overhead is to reuse elements from the authentication protocol in the > authorization or certificate enrolment processes. So, instead of > passing public keys and signatures multiple times between the same > endpoints over constrained links during different phases of the joining > procedure, we try to make more use of the authentication protocol while > ensuring that the security properties are as expected. ... > The link: Generic Animation of BRSKI - Bootstrapping Remote Secure > Key Infrastructure (ODP) (screencast) (enterprise/IoT screencast) > points to: https://www.youtube.com/watch?v=Mtbh_GN0Ce4 which is only 5 > minutes long. > I should redo this for ACE-AKE-AUTHZ, aka Ultra-Constrained > enrollment. Thinking a day later, I think that presenting a well animated view of ACE-AKE-AUTHZ at an ACE virtual interim and listening to feedback about what fits into ACE and what does not, would help out small design team clarify/debug our message, should we go to secdispatch, or whatever. [Jim: does that answer your question better?] I mean, we could also just hold our own virtual meeting too :-) I am personally more interested in writing code than wrangling documents from WG to WG in the next ~4 months. I think that some other things in the IETF will sort themselves out in that timeframe, and a path forward will become clear. In the meantime, explaining things to others helps me get it right. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] bringing draft-selander-ace-ake-authz to ACE?
I'm sorry that I missed today's meeting. I guess this wasn't on the agenda in the end? Göran Selander wrote: > But you are right that the draft is not just a new ACE profile. The > voucher concept fits into ANIMA, but is carried as an ACE access > token. It also makes use of the auxiliary data and other elements of > EDHOC. But neither ANIMA nor LAKE seems to be the right working > groups. ANIMA is not using the ACE framework, and LAKE is for the > nearest future only concerned with the basic AKE. ANIMA BRSKI is not using the ACE framework, but that's because I don't think it was clear when we started the work that vouchers were semantically similar to JWT/CWT. Well, I tried to move things that way, but it was just too soon. When we started, I thought that the thing that the AS (W) returns to V is an RFC8366 semantic voucher (encoded to CBOR a la draft-ietf-anima-constrained-voucher). However, in the document it has taken on it's own life. I think that we tried to make it close to an ACE token. This is where the connection comes in. Jim: jim> I have been sitting this to try and make a decision and figure out jim> what my feelings are with this draft. I did a fast read through the jim> document, too fast to actually understand what it is trying to do, and jim> I immediately ran into the question of why this document would be part jim> of ACE. It is using the concepts of a voucher, which is not currently jim> an ACE concept, as one of the fundamental concepts. That combined with jim> the use of an AKE makes me very wary of this document. (I have not jim> spent enough time embedded in the ECIES and HPKE world to understand jim> this well.) I think that the ECIES and HPKE part is not particularly significant. There are some links at: https://www.sandelman.ca/SSW/ietf/brski-links/ The link: Generic Animation of BRSKI - Bootstrapping Remote Secure Key Infrastructure (ODP) (screencast) (enterprise/IoT screencast) points to: https://www.youtube.com/watch?v=Mtbh_GN0Ce4 which is only 5 minutes long. I should redo this for ACE-AKE-AUTHZ, aka Ultra-Constrained enrollment. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault)
Mohit Sahni wrote: > To give some background, this draft is an extension of Light Weight CMP > Profile ( > https://tools.ietf.org/html/draft-ietf-lamps-lightweight-cmp-profile-02) > draft currently under development in the LAMPS WG. We discussed the "CMPv2 > over CoAP" draft in the LAMPS WG and figured out that ACE WG is a more > appropriate place for this draft. However, Jim suggested that we will need > to modify the charter of the ACE WG to adopt this draft. We did est-over-coaps [still in the queue], why shouldn't we do cmp-over-coap(s)? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Update of access rights
Francesca Palombini wrote: mcr> Is there an assumption that the access rights(T2) >= access mcr> rights(T1)? > FP: No. But at the same time if access rights(T2) is a subset of access > rights(T1), then there is no point in the client requesting T2 from the > AS... These could be a disjoint sets of access rights. There are some cases here. T2 is a superset of T1. Everything makes sense. T2 is a subset of T1.I to think about this. T2 is complete disjoint of T1. T2 is the union of a subnet of T1, and some new set of rights T2B. That is, partial overlap, but T2 not superset of T1. > FP: As currently defined in the document, yes, Sec1 ends up being > deleted as soon as Sec2 is validated (i.e. a request is correctly > decrypted by the receiving endpoint using Sec2). If T1 and T2 do > different things and the client wants to (and is allowed to - T1 is not > expired or revoked for some reason) keep T1 alive, then we are not in > the case of "update of access rights", i.e. the case where T2 replaces > T1. My "Final point" was to cover exactly the case you mention, where > T1 and T2 are used to derive 2 different security contexts, where the > RS does not realize they come from the same Client. It is up to the AS > to make sure that T1 and T2 are disjoints: why would the AS even send 2 > different tokens that cover part of or the entire same scope at the > same RS to the same client? By the way, if it is not already in there, > I think that that is another excellent consideration point for the Ace > framework. Client could be vaguely "multi-tenant", having a common security substrate. That's why there could be 2 different tokens. Think intelligent speakers that can learn "skills". One skill operates the stereo, and wants to adjust living room lighting for appropriate mood. (/me deletes off-colour joke about South Park) The other skill is the sleep aid, and just wants to dim all lights to near darkness, but should not operate stereo. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz
Carsten Bormann wrote: >> I don't see how the four-corner model solves the issue that I >> highlighted. If the client does not have a key for any local AS, then >> nothing helps. The four-corner model deals with the issue of the >> client and the RS not trusting the same AS, but the different AS >> entities trust each other on the back side. >> >> Getting trust in a local AS seems to be a bootstrapping problem. > If you only have one security domain, there is no benefit. But in > general is it much easier to bootstrap a device once into its own > security domain, instead of having to do the bootstrapping again and > again for each server that device needs to access. That was my understanding. The four corner removes the problem of how C trusts RS to a problem of how does C ask CAS whether it can trust RS. Which could involve significant layers of PKI or human override (or pixie dust). -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz
Jim Schaad wrote: > I have much the same problem. While a client could find an AS which > would authenticate the client, I don't know how the client would > establish any degree of trust in the AS which is going to give it > tokens. Is your question that you don't know how to trust that the AS is the correct AS for RS-foo? > If you have already put a local public key for the AS into the > client, then you might as well put in a name for the AS as well. I > suppose you could get by with a shared secret but that does not seem to > be a good way to build up the system. Maybe there are redundant instances of the AS, or maybe there are multiple ways (thus different IP addresses) by which to reach the AS. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Update of access rights
Francesca Palombini wrote:
> 7. Client wants to update its access rights: retrieves T2 from AS. Note
> that this T2 has different authorization info, but does not contain
> input keying material ("osc"), only a reference to identify Sec1 ("kid"
Is there an assumption that the access rights(T2) >= access rights(T1)?
> Moreover, while comparing with DTLS profile, we realized there is no
> reason for which 8. should be sent unprotected. In fact, doing so opens
> up to possible attacks where an old update (token non expired) is
> re-injected to the RS by an adversary:
I agree and I see your point.
Thank you for explaining it so well.
My question is whether step 8 results in Sec Ctx sec1 being deleted?
Could Client want to keep it alive in the case that T1 and T2 actually do
different things?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
{ I found Jim's very interesting email very hard to read without good
quoting, I'm repeating the important part }
henk> 2.) go to ACE and ask for an "unsigned token" option, or
Jim Schaad wrote:
jls> I don't have a problem with this, I am not sure that I see any
jls> reason for it however. See below.
henk> 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e.,
henk> that are not signed).
jls> I don't see any difference between this and option #2
jls> 4.) Just write your CWT code in a sensible manner.
jls> My CWT code base does not make any assumptions about the number or
jls> order of COSE security wrapping layers on a token. It thus looks
jls> like
jls> while (true) {
jls> if input has a COSE_Encrypt tag { decrypt it; set input to the
content; save the encryption information if needed e.g. shared key
authentication; continue; }
jls> if input has a COSE_MAC tag { validate it; set input to the content;
save the MAC information if needed e.g. shared key authentication; continue;}
jls> if input has a COSE_Signature tag { validate it; set input to the
content; save the signer information; continue }
jls> if input is a map - return input as the set of claims;
jls> throw an exception because it is not the correct format.
jls> }
jls> This does not require a tag for a naked set of claims and would
jls> allow that set of claims to be pass in the same place as a CWT can
jls> be passed. What you are suggesting would require extra code to
jls> exist someplace that is going to check for an additional tag.
jls> IT IS
jls> ALSO GOING TO LEAD TO PEOPLE THINKING THAT THIS NEW TAG SHOULD BE
jls> LEGAL TO PLACE INSIDE OF A CWT. After all it makes more sense to
jls> always include it than to just sometimes include it.
Emphasis mine.
So your suggestion is to do nothing.
I also wondered why that wouldn't work, but I hadn't written enough code to
ask the question intelligently.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Jim's Proposal on legal requestor
clarifying question. Jim Schaad wrote: > I do not seem to have been doing a good job of explaining the issue > that I am raising here, so I am going to go scenario based for a > description. > (1) I get an access token from an AS with a scope of [ > "coap://multicast-01", ["responder"]] > (2) I join the group associated > with that address > (3) I then decide to send the message below out > encrypted with the group symmetric key and signed with the public key I > registered during the join >GET coap://multicast-01/resource1 (I numbered the steps) I believe that (1) was intended to allow you to become a responder for this resource. > It then processes the get request > because it does not know that this is a violation of the scope assigned > to me by the AS. ! > The only way that I know for the server TimeX to enforce the allowable > operations is for that information to be propagated along with the > signature public key from the KDC to the server. One can create a > similar scenario on the other side where a client sends a response when > it is only authorized as a "requester". It seems to me that if the access control to the group is a group-shared symmetric key + asymmetric signature, that each responder requires the list of valid signers. Or, we need LAKE to turn the group key into 1:1. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
Benjamin Kaduk wrote: >> So, on a constrained device, I'd like to know what to expect (what to >> code for). While I do'nt particularly care for server-generated keys, >> it should probably be specified correctly. I see that the complexity >> of sorting this means that I think that Content-Format 284 >> (unprotected) will get used most often. > Your constrained device is probably only going to implement one cipher > [mode], too, right? If it's an AEAD mode, you use AuthEnvelopedData; > otherwise, classic EnvelopedData. Yes, but each constrained device type might have a different set, and the EST server for such an installation has to figure out how to send the right thing. >> 2) You are saying that we should replace tls-unique (RFC5929) with a >> TLS Exporter. But RFC7030 didn't reference RFC5705. You are >> suggesting that we update ourselves to use RFC5705. That would seem >> to require that we change some PKIX things in CSR. > From a crypto perspective, we should do that. From a > protocol-specification perspective, we should retain parity with > classic EST and only update when it does. So we should probably mostly > ignore this other than trying to kick off work on classic EST, and > mandating extended-master-secret. okay, good. >> 3) I'm wondering if we need to have a clear response/error code for >> the case where the tls-unique does not match. At least, from the >> HTTPS-EST server to the COAPS-EST "proxy" that might be valuable, even >> if the code it not sent back to the client. > [I didn't think much about whether this would give an attacker leverage > from which to execute new attacks] An HTTPS-EST server that responses to the COAPS-EST with such an error is probably mis-configured for that end point. It probably does not believe that the CoAPS-EST proxy is authorized to speak for the end point. Both are already trusted. The end point is probably already also trusted btw. The major use case that we had for server-generating keys is for updating keys for existing installations. Such as moving from 10yr old 1024RSA keys that were manually deployed (at the factory) to 256bit ECDSA keys, etc. >> +--+---++ >> | HTTP Media-Type | ID | Reference | >> +--+---++ >> | application/pkcs7-mime; | 280 | [THISDOCUMENT] | | >> smime-type=server-generated- | | | | key | | | | >> application/pkcs7-mime; | 281 | [THISDOCUMENT] | | >> smime-type=certs-only | | | | application/pkcs8 | 284 | [THISDOCUMENT] >> - | >> | | || >> | application/csrattrs | 285 | [THISDOCUMENT] | | application/pkcs10 | >> 286 | [THISDOCUMENT] | >> | | || >> | application/pkix-cert | TBD28 | [THISDOCUMENT] | | | 7 | | >> +--+---++ > No, I was thinking we should add "[THISDOCUMENT]" to the existing > entries, not replace them. got it. >> I think that 3SHAKE requires session resumption to be supported. I'm >> not sure that using session resumption is the best thing in a >> constrained client system. I think that whenever we get to doing a >> new operation, that we actually need a new session setup at that point >> anyway. > Hmm, but we perhaps cannot guarantee that this will hold universally > for all devices implementing coap-est. I do think that we can mandate > other aspects that make 3SHAKE impossible (like > extended-master-secret), though. okay. >> I think that we could go to TLS Exporter right now, but it would take >> some work. > I'd rather have both classic-EST and coap-EST benefit than just > coap-EST. So you'd agree to deferring this to a document (maybe in LAMPS?) that would Updates: 7030 and this document. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
| +--+---++ | application/pkcs7-mime; | 280 | [THISDOCUMENT] | | smime-type=server-generated- | || | key | || | application/pkcs7-mime; | 281 | [THISDOCUMENT] | | smime-type=certs-only| || | application/pkcs8| 284 | [THISDOCUMENT] - | | | || | application/csrattrs | 285 | [THISDOCUMENT] | | application/pkcs10 | 286 | [THISDOCUMENT] | | | || | application/pkix-cert| TBD28 | [THISDOCUMENT] | | | 7 || +--+---++ And I guess rfc5751-bis is now RFC8551. > So I have to wonder if I'm messing something up, somewhere. I see that Peter has posted new examples. > In the key-agreement case, the symmetric key-encryption key is the > result of the key-agreement operation, no? In which case it is not > itself encrypted, but rather the server's ephemeral public value is > sent. > > In RFC7030 the text says: the EnvelopedData content is encrypted using > a randomly > generated symmetric encryption key (that means ephemeral I assume). The > cryptographic strength of > the symmetric encryption key SHOULD be equivalent to the > clientspecified > asymmetric key. > However, I see no explicit relation with the ephemeral public value. pvds> I don't know what to do here; probably insert the 7030 text. I not understand the question here. >What's more, POP linking uses tls-unique as it is defined in > [RFC5929]. The 3SHAKE attack [tripleshake] poses a risk by allowing > nit: "such POP linking" or "the CMC POP linking" > CMC POP >a man-in-the-middle to leverage session resumption and renegotiation > to inject himself between a client and server even when channel binding > is in use. The attack was possible because of certain (D)TLS > implementation imperfections. In the context of this specification, > I don't think we can solely blame the attacks on implementation > imperfections (though they were certainly compounding factors). Does > this sentence really add any value to the current document? > > Leave this to my co-authors > I think that 3SHAKE requires session resumption to be supported. I'm not sure that using session resumption is the best thing in a constrained client system. I think that whenever we get to doing a new operation, that we actually need a new session setup at that point anyway. >binding mechanism. Such a mechanism could include an updated tls- > unique value generation like the tls-unique-prf defined in > [I-D.josefsson-sasl-tls-cb] by using a TLS exporter [RFC5705] in TLS > 1.2 or TLS 1.3's updated exporter (Section 7.5 of [RFC8446]). Such > mechanism has not been standardized yet. Adopting a channel binding > We probably should be explicit about "using a TLS Exporter value in > place of the tls-unique value in the CSR", just from a writing clarity > perspective. > > Leave to my co-authors from here to section 10.2 > I think that we could go to TLS Exporter right now, but it would take some work. > Do we want to say anything about the IDevID in the CSR/cert? I note > that the breakdown in Appendix C.2 (looks like openssl output) does not > decode the otherName (though asn1parse can be convinced to do so). > > What do you suggest for IDevID? > Actually openssl was used extensively for generating the examples. > Will be happy to learn about otherName > there is a whole bunch of othername not supported. asn1parse isn't terribly informative here, in my opinion. -- ] 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[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] EST over CoAP: Randomness
My understanding of the use case for server generated keys is for existing, deployed systems where the system can easily get a firmware update, but the hardware TPM itself is unable/unwilling to generate new keys, and can't be upgraded, but keys can be loaded. Systems like Hannes' company produces, where the TPM is really a TEE don't suffer from the upgrade problem, but there are many other systems out there based upon older designs. And, it's an optional part of the protocol; one I don't intend to support. I don't see why it should bother anyone. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est
Panos Kampanakis (pkampana) wrote: >> But can't the client just be configured out-of-band with the URIs directly? > That is right. We could mandate only .well-known URIs. But I think we > ought to let a deployment use non-default URIs. For example some > usecase might not want to send the .well-known in the URI to save > transmission bytes and thus use a custom short URI. If the URI change > takes place after deployment client will find that out with a > discovery. Similarly, a usecase might initially not support one of the > optional requests like server-side keygen. If the server adds support > sometime in the future, the client could find out using discovery. And > we ought to let the client be able to recover in case the well-known > request URI fails for some reason and he wants to see what is supported > by the server.That is why we thought it is still worth to keep the > .well-known URIs along with the discovery. also, EST-COAP is a building block for draft-ietf-anima-constrained-voucher (containing constrained BRSKI) so preconfiguration won't work. While constrained BRSKI can operate on .well-known the LDevID renewal might occur with a different server, and so discovery might be worthwhile. There are two reasons for doing the resource discovery: 1) to get a multicast response when looking for a registrar. 2) to get a shorter name to save some bytes. I think that (2) contributes negatively to code-complexity, and so if not for (1), I'd prefer to live on /.well-known only. But, I don't object to having shorter URLs available for those that want to spend the code. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Embedded Content Types
Carsten Bormann wrote: >> I am thinking of two different URLs, that is not do the difference by >> a query parameter but by changing the URI. > Note that the query parameters are part of the URI, so fundamentally > there is no difference between putting the info there or in the path > part of the URI. Really? Aren't there caching differences? (Not that these things should ever be cached) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Embedded Content Types
Carsten Bormann wrote: > I think this is just a misunderstanding — the idea wasn’t to supply the > parts under different URIs, but to make up different URIs for > retrieving the different combinations coming in one multipart-core, in > one transaction. > or, say > /skg/284,281 > This provides full format agility while preserving the interaction model. I sure prefer this over other hacks. Would the client say Accept: 62 to indicate it's willingness to receive a multipart? It seems that multiple Accept: option headers may be allowed. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Valery Smyslov wrote: >> Current version of EDHOC is 3-pass to allow traffic data after one round trip, >> which reduces latency in many applications. >> A 4-pass version has also been discussed: >> https://mailarchive.ietf.org/arch/msg/ace/ZDHYEhvI0PenU6nGrhGlULIz0oQ >> >> When EDHOC is used as key exchange for OSCORE, and also in other settings, >> EDHOC will commonly run on top of CoAP. For example, in 6tisch the join >> protocol relies on CoAP proxy functionality. CoAP is defined for reliable >> transport (RFC 8323) as well as UDP (RFC 7252), the latter handles >> retransmissions by client and server. An example of using EDHOC with CoAP is >> given in appendix D.1: >> https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-11#appendix-D.1 >> >> It sounds like we should add some considerations for the setting you outline. >> Do you have an example or pointer explaining the specific problem in more >> detail? > In the current EDHOC draft the initiators sends the last (third) message of AKE and then > immediately starts sending encrypted data (note, that he has almost > always something to send, When done over CoAP, the message would be sent with CONfirmable, so it would be ACK'ed. I would make the first message CONfirmable too. That makes it much like IKEv2 is, where all messages are ACKed and the initiator is responsible for all retransmits. If someone wants to run EDHOC over another transport, then they would need to take this into account. > So, unless you rely on a reliable transport that preserves packets ordering, > having odd number of messages significantly complicates implementations. CoAP is reliable, and it does preserve packet ordering if asked to. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Richard Barnes wrote: > Finally, to be totally honest, I find the EDHOC spec pretty inscrutable. A > little more prose to explain what's going on would go a long way toward > helping this discussion be productive. Sure. Find a WG to adopt it, and we can make the text beautiful. The packets are all there, and the references pretty much explain all the crypto. This stuff is not any newer than IKEv2. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287
CORE people, the thread is here: https://mailarchive.ietf.org/arch/msg/ace/L1QPw1zHAj15nsKMe8AFDu6dcmI Esko Dijk wrote: > Using a query is a good solution here; I would propose a query argument > as short as possible because we deal with constrained networks and we > want to avoid needless parsing in this case - the server only needs to > select between two format choices here, returning X.509 cert or PKCS#7 > with cert. Using a query really seems broken to me... > So to request PKCS#7 format , the default: > POST /est/skg > And to request X.509 format, the alternative that the server MAY support: > POST /est/skg?x Why not just use: POST /est/skx It's even shorter, and it's much more obvious if it is not supported. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287
Panos Kampanakis (pkampana) wrote: > Hmm, that is a fair point. I don't think it is warranted to register > four more content formats for all possible format combinations in the > multipart response. > It looks to me that your proposal of using Uri-Query in the request in > order for the client to define the supported formats of the requested > resource/response is a good one. It seems a totally adhoc way that totally subverts the content-type system. It really seems like we need to take this to CORE. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices
Jim Schaad wrote: > Of anybody on the mailing list believes that the document should not > add a new CoAP content type for "application/pkix-cert" please speak up > before next Monday. Can we go ahead with this request now? :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
https://goo.gl/LT4HYh is a diff from -06 to current. Panos has done a great job updating this according to the issues raised during the WGLC. Thank you I have re-read diffs to catch up, and have these minor author tweaks/questions. > Client authentication via DTLS Client Certificate is mandatory. I wonder if this should go into it's own section so that one can more easily say, "Please see section x.y.z" s/enrolment/enrollment/ <- use American spelling, I guess. We had both. section 6: REQ: GET /.well-known/core?rt=ace.est* I didn't know the trailing "*" was a thing. ; rt="ace.est", I guess I have to re-read the Core Link resource discovery document. Can a server respond with ; ?? it's shorter, and I think would be valid? > If >the default root resource requests fail, the client > SHOULD fall back >to doing a resource discovery. Resource discovery > SHOULD be employed >when non-default URIs (like /est or > /est/ArbitraryLabel) or ports are > supported by the server or when the > client is unaware of what EST- >coaps resources are available by the server. This implies that a server is not required to support /.well-known/est We are not clear about this. I would prefer that the server ALWAYS supports the well-known names, such that the client can skip doing resource discovery if it thinks that the extra bytes in the URL matter less than additional round trip to do discovery. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices
Esko Dijk wrote: > So to reduce code size for embedded implementations it would be very > beneficial if the EST Server would support an additional content > format: > application/pkix-cert (see RFC 5280) So, to implement this in the specification, we need an additional Content-Type value to be allocated. If we have WG Consensus to add this, then we can spin the document and ask for another early allocation. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices
Esko Dijk wrote: > My main comment on this draft is based on recent experience with an > embedded implementation. In the draft, the content format > "application/pkcs7-mime;smime-type=certs-only" is used to transport a > single certificate back to the client. However, in the embedded > implementation crypto library there is no support for parsing this > format, but there is support for parsing X.509v3 > (application/pkix-cert). See > e.g. https://tls.mbed.org/api/group__x509__module.html for an embedded > API that can parse CSR and certs, but not PKCS#7. > Therefore the X.509 format seems better to use; also given that > 1) the signing of data that the PKCS#7 S/MIME envelope provides is useless because the DTLS session is already end-to-end protected and the certificate is already signed; and > 2) RFC 7030 requires that only one certificate, the generated one, is > carried in the /simple(re)enroll response so that a container format > for multiple certificates is not really needed here. > So to reduce code size for embedded implementations it would be very > beneficial if the EST Server would support an additional content > format: > application/pkix-cert (see RFC 5280) I think that this is a reasonable thing to do. The client can easily say what it wants and I think the two formats are relatively easy to swap. What about if we went further, and went to: Concise Identities draft-birkholz-core-coid-01 -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC comments draft-ietf-ace-coap-est-07
Jim Schaad wrote: > The question I was asking was more about the original enrollment rather > than renewal although it could come into question there as well. > - I have the implicit trust anchors and get a EST server URL. > - Call /cacerts > - I now have the explicit trust anchors but potentially have the same EST > server URL. > - Given that I have a NEW trust anchor, what do I do with the current DTLS > session? > - I now do an enrollment with the EST server to get a certificate. > One can say it is fine to use the implicit TA for that enrollment, but one > could also say that as the certificate chain is now different then the > DTLS session should be released and a new one established. I think that the purpose of calling /cacerts is to get context for living within the network. I think that one continues with enrollment with the same connection. Restarting it might not actually work. The resulting certificate should validate with the set of trust anchors provided, and the anchors should let the client validate other clients. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC comments draft-ietf-ace-coap-est-07
Jim Schaad wrote: > Section 11.1 - When changing from the implicit trust anchor to explicit > trust anchors, do you expect that the est server that you are going to > be talking to is generally going to change? I think that it should > probably be recommended that the DTLS connection NOT be persistent > across a change in the trust anchors if they are different. I'm trying to understand the question better. To be clear: - implicit trust anchors -- what the device was built with. - explicit trust anchors -- what is returned from /cacerts|/crts So after calling /cacerts, the client now can authenticate an EST server with the domain registrar. Beforehand, it has to use something built-in. I think you are asking about whether or not the server identification (certificate) is different in the two cases? If we could be sure that a different EST server would be used for renewals of the certificate (LDevID), then that EST server could have a locally anchored certificate. I don't think we want to force this change of servers so the we must be prepared for a single EST server to do both initial enrollment and also renewal. @Hannes, it would be good to have your opinion here. This problem can be solved with correct use of SNI extension in DTLS, but it is unclear how much detail we need to be explicit about. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] est-coaps clarification on /att and /crts
Max Pritikin (pritikin) wrote: > Jim Schaad wrote: > jim> Clarification requested - exactly what element is the Registrar? mcr> It's an EST RFC7030 term, but essentially it's the server that mcr> connects to (or is) the CA. max> The Registrar terminology is from the Anima working group and is closely max> analogous to the “Registration Authority” we know and love from the PKI max> space. Oh, right. I forgot that Registration Authority (RA) is not the same word as "Registrar". I wonder if we should have aligned that more, or aligned it less. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Anima] est-coaps clarification on /att and /crts
Hannes Tschofenig wrote: > > 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. Clients which are not **yet** authenticatable. The client shows up, does a DTLS connection. We let the DTLS connection succeed, because we want to record the particulars of the client, so we can ask a human. Much like happens when you ssh to a new host: it stops to ask if you you agree with the key. You don't know, so you hit ^C. So, that's all. We don't intend to issue certificates... yet. I'm also asking if there is some use case where the client might legitimate need the list of trust anchors (/cacerts request) in order so that it can...? (I couldn't think of a use case) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] est-coaps clarification on /att and /crts
Panos Kampanakis (pkampana) wrote: > Gotcha, so you are describing a provisional DTLS connection at the server. I'm thinking about a Registrar that might be serving both provisional connections and ones that are just renewing LDevIDs, and maybe ones that also serve selected factory installed IDevIDs (a use case which est-coaps caters directly to). > Currently we say that clients need to be authenticated in a DTLS connection > before an EST-coaps request. Do you want to make it more explicit to say > that even though EST allowed for it, EST-coaps does not allow > unauthenticated /crt and /att? We can certainly add that. I'd like to add this. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] est-coaps clarification on /att and /crts
Panos Kampanakis (pkampana) wrote: > I thought about this for the EST-coaps draft. EST allowed for > unauthenticated /cacerts and /csrattrs (/crt and /att in EST-coaps) as you > are suggesting. Exactly. > It is not as simple in EST-coaps. Two reasons: > 1) There are constrained networks where an easy amplification attack could > take place. For example the /crt request is very small and the response can > be big (a few KBs in the context of a constrained network is big). If > unauthenticated, then /crts could be an easy amplification attack to > saturate a constrained network. We don't want that to happen. We want all > our clients to be authenticated by DTLS before they start loading up our RF > network. I'm not suggesting that the DTLS be skipped, I'm suggesting that the client certificate presented might be meaningless to the EST server. As for amplication attacks, they usually depend upon forged source addresses, and in that case the DTLS wouldn't have completed. > 2) Additionally, there is a practical challenge of COAPS. When the DTLS > handshake is taking place the server does not know what the request will > be. In EST the server would send an HTTP WWW-Authenticate header to ask the > client to authenticate. Such a mechanism does not exist in COAP, so it > would not be straightforward unless we introduced a bunch of new things > into COAP. AFAIK, we don't support HTTP-level authentication in COAPS, only DTLS level authentication is specified in EST-COAPS. > I think it is still right to authenticate clients even for /crt and /att in > the EST-coaps context. Maybe that is something to be revisited in > Constrained-BRSKI/voucher, but not taken lightly. So I think that we need to say something in EST-COAPS to explain that we do not see a use case for replying to /crts and /att for clients which are not recognized. Is 401 (4.01) or 403 (4.03) more appropriate do you think? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] est-coaps clarification on /att and /crts
Jim Schaad wrote: > Clarification requested - exactly what element is the Registrar? It's an EST RFC7030 term, but essentially it's the server that connects to (or is) the CA. > The one item that I can generally think of that might be a problem is that > the answers to /att and /crts may differ based on the entity that is asking > the question. In this case not having the entity being validated means that > the "wrong" answer may be returned or different answers would be returned > before and after validation. Yes, I agree: it should be restricted. I think that it should be restricted. Partly, I'm just not sure where the text should go, or if it needs to be said at all. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] est-coaps clarification on /att and /crts
A clarification question from an implementor (me) in the context of constrained BRSKI state machine. The /att and /crts requests do not do anything to change the state of client or server. It would seem that it might be safe to permit clients which have not yet authenticated to do this operation. (/att gets CSR attributes, and /crts gets the list of trust anchors) When EST-COAPS is used on its own, there usually needs to be a manufacturer trust anchor installed on the Registrar before any connection will be permitted. When EST-COAPS is used as step 2 of constrained-BRSKI, whether or not the Registrar will accept any (and all) connections depends upon configuration of the operator. Some devices might not be doing BRSKI (not need to, they already trust the operator, but they might still have IDevID only. This might happen during a transition) If the Registrar is "open" to new manufacturers, should the Registrar permit /att and /crts actions to be done by clients that it does not recognize? The /att call on an ANIMA ACP network would reveal to the client the ULA that would be used for that client (and perhaps other interesting things), and the /crts would show the name of the operator. Note that the later info probably is revealed just by doing the TLS handshake. I think that they should be restricted in general, but I'm concerned that there might be some situation I've missed. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ACE Framework Review
Thanks for this amazing analysis. It languished in my inbox because it was not bikeshed material, and I had to think about things :-) Stefanie Gerdes wrote: > The minimal security requirements for the communication between two > communication partners should be listed (C-AS, RS-AS, C-RS, > respectively). Which pieces of information do they require prior to the > communication? How must the communication be secured? Which keying > material do they need to use? The framework should point out that all > claims that influence the security must stem from claimants that were > approved by the respective human being that is responsible for the > device, i.e., the requesting party for the client and the resource > owner for the AS and RS. Otherwise the solution is not secure. It seems that the answers should start with "which keying material do they need to use" and then move upwards. > Management of the authz-info resource: * The authz-info resource is > vulnerable to DoS attacks: clients may (with or without intention) send > large numbers of access tokens to RS. A constrained RS may soon run out > of memory/storage space if it needs to store large numbers of This seems like a really serious issue, and it seems that we need an additional RTT to really fix it. -- ] 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[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] EDHOC standardization
Benjamin Kaduk wrote: >> > Are you proposing that the management of the 0/1-to-algorithm mapping >> > be managed on a per-deployment basis or by the IETF? >> >> I think that the existing proposal was that 0 means "negotiated out-of-band", >> which implies that it's a per-deployment basis. >> >> I'm proposing that instead of having 0 mean "some local default", >> I'm suggesting that 0 mean, "some local default 0" and 1 mean, "some other >> local default 1", which lets the default be updated without a flag day. > That feels like a potentially awkward provisioning problem. I guess the > idea is that any given node is only going to do 1 or 0 and not both? Maybe > that helps. I don't think you get it if you think it's awkward! Any firmware implements 0 or 1, correct. [I'm not a fan of such a system. I also don't think it is small enough for LoRAWAN either] When a new choice is hard coded into that closed vertical system (via "out-of-band"), this choice would be baked in at the next firmware update. (There are many ways to do this of course. Throw dip switches if you like) Having both 0 and 1 lets the firmware be incrementally updated, otherwise the operator either has a flag day, or has to keep track of the parameters on an per-device basis. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] EDHOC standardization
Benjamin Kaduk wrote: >> John Mattsson wrote: > of negotiation is >> still needed. The current plan for the next version > is to introduce >> cipher suites and to let the cipher suite with value 0 > indicate that >> algorithms have been negotiated out-of-band. >> >> I agree with the idea that some common default should be very easy to >> refer to, but I don't like the idea that the gateway has to remember >> what the out-of-band "default" is on a per-device basis. I would say >> that we need at least 0/1, so that we can say that it's the current vs >> the "new" default. >> >> If you consider the case where the sensor is on very low bandwidth >> connection (I would say LoRaWAN, but I am not well qualified in that >> space). The sensor gets visited every two or three years by a >> technician (if only to make sure that the sensor is still where it is >> supposed to be). While there new firmware updates are applied, and as >> a result the algorithm defaults are updated. During the cycle, some >> devices are updated and some are still old. > Are you proposing that the management of the 0/1-to-algorithm mapping > be managed on a per-deployment basis or by the IETF? I think that the existing proposal was that 0 means "negotiated out-of-band", which implies that it's a per-deployment basis. I'm proposing that instead of having 0 mean "some local default", I'm suggesting that 0 mean, "some local default 0" and 1 mean, "some other local default 1", which lets the default be updated without a flag day. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] EDHOC standardization
Salvador Pérez wrote: > we have implemented a previous version of EDHOC > (draft-selander-ace-cose-ecdhe) and want to share some experiences. That's very cool. Some questions for you! > Our work so far has focused on implementation and evaluation of version > -08 of EDHOC over CoAP using real IoT hardware. The obtained results > show a significant performance improvement compared to other key > establishment protocols, such as DTLS handshake (version 1.2), > especially with respect to length and number of exchanged messages. What did you use for authentication? RSA? ECDSA? EDDSA? PSK? Were they raw public keys, or was it in a certificate? Did you try a certificate in one direction and a raw public key in the other? Did you offer more than 1 algorithm when you negotiated? > We have reviewed version -10 and noted the reduction of message > length. Based on our experience, we propose that also removing the > overhead due to security parameter negotiation could be an important > optimization, and relevant in many use cases where these parameters are > available through an out-of-band process. If the list of valid algorithms is available securely by out-of-band processes, then couldn't use this mechanism to do key agreement instead, saving 100% of the bytes on the wire? :-) We need to do security parameter negotiation in order to be agile against future algorithm attacks, and there will be algorithm attacks in the 20 to 40 year lifespans that we expect... and we need to leave space for replacing the DH process with some QMDH process. The CBOR encoding is really really very nice for this, and I wish we had CBOR when we did IKEv2. > Accordingly and taking into account that EDHOC provides a basic > security functionality for any context where security needs to be > enabled, we are currently considering the application of this protocol > in different IoT deployments, such as LoRaWAN networks, OSCORE-enabled > scenarios or its integration with capabilities. We therefore would like > to see the progress of EDHOC in standardization. I don't see how LORaWAN has enough bytes available for even EDHOC. I think that LoRaWAN needs a key agreement protocol that can be run once while the sensor is attached to the installer's smartphone. The important thing is that one is able to use the key agrement protocol over IPs A<->B, in order to setup a context that can be used between IPs C<-->D. -- ] 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[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] JWT + OAuth Request
Jim Schaad wrote: > The OAuth group discovered a problem with some the names of our new > OAuth fields that was caused by the fact that they have an ID that is > someplace between the IESG and the RFC Editor which introduced the Took a moment to realize that ID = Internet Draft, rather than being a reference a hash key id :-) (Which document is this?) > Why option 1 might be acceptable: > B. If a CWT version is this is really needed, perhaps we can get a > different design to be used. Specifically, create two new CWT claims: > "oauth_req", "oauth_resp" and then place the OAuth parameters in those > fields and not make them CWT claims. I am sure that there would be > complaints about this, but much as COSE fixed problems that it saw as > being wrong, the WG could do the same thing. I prefer this solution, but I feel unsufficiently informed about how the above ID might come back to bite us. (I can live with combining registries) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
Peter van der Stok wrote: > What do I read? when you do GET coap://example.com/.well-known/core > The discovery is on port 5683. When you do GET > coaps://example.com/.well-known/core the discovery port is 5684. yes, the question is, when you ask: coap://example.com/.well-known/core?rt=ace.est do you expect to get back a pointer to: coaps://example.com/est > RFC 7030 does not ask a port number from IANA. And a search through > IANA port numbers on "est" does not yield anything. It does not. a) it doesn't do discovery, but just uses /.well-known directly. b) it assumes https:// -- ] 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[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
Esko Dijk wrote: > @Michael: > Since the EST resource is always present on the fixed port 5684 on URI > /.well-known/est - if a fixed port is needed e.g. for a join proxy, use > 5684 and the well-known URI. No discovery needed. I've asked if discovery is always required, permitted, or encouraged. I.e. - can the client avoid the round trip to do the discovery? - does the server have to provide the discovery? -- if not, what does a client do that performs the discovery and fails? I've been told it was required. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
Esko Dijk wrote: > Indeed, and the ace-coap-est examples use port 61616 mostly. The > discovery Link Format is quite inefficient when returning results on > *different* endpoints. Example: > REQ: GET coap://[2001:db8::2:1]/.well-known/core?rt=ace.est > RES: 2.05 Content > ;rt="ace.est" I understand. > Although in above case the server could shorten the response payload by > returning its IP address ( [2001:db8::2:1]:61616/est>;rt="ace.est"). But still it’s a waste of > bytes. It could have multiple addresses!!! I've seen it just return , but I guess if you want to return the port number, you have to return the hostname... <:61616/est> won't do? > The current example in Section 5 of ace-coap-est is problematic, > because discovery is on port 5683 and the hosted EST endpoint is on the > secure port 5684. So the following won’t work according to RFC 7252 / So I've assumed that discovery happens on 5684, under DTLS. You are suggesting that we need to run an unencrypted CoAP to offer the discovery option as well. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
Esko Dijk wrote: > To be fully complete the URIs that can be discovered should also > include a port number, as they could be hosted at 5684 or any available > UDP port - other than 5683. >coaps://www.example.com:// > coaps://www.example.com://ArbitraryLabel/ I didn't think that CoAP resource discovery supports port numbers, does it? There are some issues with this, specifically because it interacts poorly with the join proxy mechanism. (The proxy always forwards to a single port, and only listens on a single port) I supppose that's okay, for that usage can be banned for the zero-touch join mechanisms that use a join proxy. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [core] Early media-type registration for EST over CoAP
Jim Schaad wrote: > That sounds like a good plan forward. Are you also going to need an early > registration on the multipart-core draft as well? yes, it would be nice, ... we think that it's CORE's problem to adopt the draft and ask for that. The multipart response is only need for systems where the private key will be generated on the EST server: and a number of implementers are keen *not* to do that, so the multipart is not urgent to as many people. > From: Peter van der Stok > Sent: Wednesday, June 20, 2018 3:07 AM > To: Carsten Bormann > Cc: Hannes Tschofenig ; core ; > ace@ietf.org; Jim Schaad ; r...@cert.org > Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP > HI Carsten, Jim > Just to get this clear. > We will update the the est-coaps draft by referring to > draft-fossati-core-multipart-ct-05 for the wanted early registration of the > content formats specified in est-coaps. > Once done, we direct a request for early registration of the content-format > values to the ACE chairs. > Although the corresponding media formats have not been allocated yet for > multipart-ct draft, the corresponding content-format numbers can be allocated > already. > Is that the approved plan? > Please confirm or specify the conditions on multipart-ct draft. > Many thanks for your understanding, > Peter > Carsten Bormann schreef op 2018-06-19 14:22: > On Jun 19, 2018, at 14:11, Carsten Bormann wrote: > Since the registry that we are registering into does not fulfill the > preconditions of RFC 7120 Section 2 point (a), > (Sorry, wasn't awake enough. If we go for the 256- space, of course > it does. And we probably do.) > So we'll have to follow the process according to Section 3 of RFC 7120. > Starting with point (1) of Section 3.1: > 1. The authors (editors) of the document submit a request for early > allocation to the Working Group chairs, specifying which code > points require early allocation and to which document they should > be assigned. > Grüße, Carsten > ___ > core mailing list > c...@ietf.org > https://www.ietf.org/mailman/listinfo/core > > Alternatives: > > _______ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [core] Early media-type registration for EST over CoAP
Carsten Bormann wrote: > On Jun 19, 2018, at 14:11, Carsten Bormann wrote: >> >> Since the registry that we are registering into does not fulfill the >> preconditions of RFC 7120 Section 2 point (a), > (Sorry, wasn’t awake enough. If we go for the 256- space, of > course it does. And we probably do.) yes, we were perfectly happy with that space. > So we’ll have to follow the process according to Section 3 of RFC 7120. > Starting with point (1) of Section 3.1: >1. The authors (editors) of the document submit a request for early > allocation to the Working Group chairs, specifying which code points > require early allocation and to which document they should be assigned. I thought ACE co-chairs already gave consent, but looking in the archives, I see that this isn't actually so. Jim? Roman? DO YOU CONSENT? We have already had some round trips and document changes thanks to Klaus Hartke. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] How to specify DTLS MTI in COAP-EST
We have written: + + As per section 3.3 and section 4.4, the + mandatory cipher suite for DTLS in EST-coaps is + TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in , + and the the curve secp256r1 MUST + be supported ; this curve is equivalent to the + NIST P-256 curve. Crypto agility is important, and the + recommendations in section 4.4 and any + updates to RFC7925 concerning Curve25519 and other CFRG curves also applies. https://github.com/SanKumar2015/EST-coaps/commit/94812c98492b6a6b0440155025357fa0b58ca017?diff=split We had a discussion about whether section 4.2 (PSK) and 4.3 (RPK) also applies, and in general they do, but we don't understand the use cases that would result in that usage. (Is it PSK, or EAP-SIM for for instance?) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] How to specify DTLS MTI in COAP-EST
Eric Rescorla wrote: > 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. Because current generation of hardware and TPM modules has definite support for P256, and while some of the hardware assist out there can accelerate CFRG curves as well or better: a) it's not universally true. b) it takes time to get the new code through a FIPS process. So, we want to say, P256 is if you must, and CFRG if you can on the constrained device. On a non-constrained CA side, P256 becomes a MUST because one needs to support the old devices, and CFRG becomes a MUST just as soon as one can get the code through the right processes. In any case, 7925 says EXACTLY this, so we are happy, and do not want to repeat things. > wrote: >> >> Hannes Tschofenig 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 http://www.sandelman.ca/| ruby on >> rails[ >> >> >> ___ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> >> > > Alternatives: > -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] How to specify DTLS MTI in COAP-EST
Hannes Tschofenig 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 http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] How to specify DTLS MTI in COAP-EST
Russ Housley wrote: > These words were first used by IPsec; see RFC 4307. They have gained > broader acceptance. I see no problem just using them here. Yes, but they aren't in an RFC2119-like document that we can simply cite, and I'm not sure if the TLS reviewers will like them. Ben doesn't like them for instance. I would probably just write: SHOULD+/SHOULD-/MUST- are used in the same way as in RFC8247 >> 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 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] How to specify DTLS MTI in COAP-EST
Olaf Bergmann wrote: > Michael Richardson writes: >> Curve25519 should be considered as an alternative > As we had this discussion at IETF-101 regarding the profile coap_dtls: > What where your reasoning for Curve25519? (Especially vs. Ed25519?) AFAIK, Curve25519 is about the PFS/key-agreement. Ed25519 is about authentication of the end-points, and depends upon what's in the certificates (if any are used) to validate the end points. CoAP-EST does not say anything actually about authentication; i.e. how we get the Secure Transport. It's out of scope for this document. (But, in scope for draft-ietf-6tisch-dtsecure-zerotouch-join ) -- ] 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[ signature.asc Description: PGP signature ___ 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.tschofe...@arm.com> wrote: > I don't have a strong opinion about option #2 appears to be slightly > better. Oh, I misread your options before. Hannes Tschofenig <hannes.tschofe...@arm.com> wrote: >> (RTT for the lookup vs extra bytes in the URL) >> Are you asking me about these two options: >> Option #1 - going through /.well-known/core >> REQ: GET /.well-known/core?rt=ace.est >> RES: 2.05 Content ; rt="ace.est" >> Option #2 - using a /.well-known/est URL >> REQ: GET /.well-known/est >> RES: 2.05 Content ; rt="ace.est" Option 2 is not substituting /.well-known/core for /.well-known/est (and doing resource discovery and then learn one uses /est-root/rv, etc.) but rather not doing resource discovery, just go directly to /.well-known/est/rv, which is what we do in RFC7030. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] CA generated keys (was Re: EST over CoAP)
Michael StJohns <mstjo...@comcast.net> wrote: > Basically, the argument I'm hearing again is that we have to have > common protocols that work with the least capable devices in the same > way that they work with more capable devices. Which then is taken to > mean that we have to limit the security of said protocols to what's > available with those most limited devices. This is not really what's going on here. The argument is whether device generate private keys should be supported in the constrained version of EST. The RA/CA (RFC5280 terms) side of things in generally assumed not be seriously contrained. (I expect to install a CA on an openwrt based Turris home router, but that's equivalent to a 15 year old laptop, and hardly counts as constrained) There is no reason why a RA/CA(%) can't support server-side key generation according to RFC7030 section 4.4 as well as permitting capable devices to generate their own keys. Having the CA generate keys seemed to be all the rage at some point. I was never clear if this was because desktop OSes couldn't be trusted to do it properly, or because end-users wanted their private key as part of their mobile profile, or because of the implicit escrow that it permitted. (Remember splitting signing and encrypting keys...) Panos' situation is, I understand, that he has customers with an extensive deployment of devices in the field. They currently use a proprietary enrollment and key distribution system. They want to "upgrade" to CoAP-EST, but clearly there are some concerns about local key generation. I don't know why exactly, but I suspect it has to with the validation (FIPS140) of the libraries available on that platform: perhaps they are not validated to create their own keys...(yet?) But they can be field upgraded in an unattended fashion to use a standard protocol, as long as they don't have to do new crypto tricks *today*. (%)- In smaller/self-contained systems, the Registration Authority (RA) is often co-located (part of, implemented by the same system) with the Certificate Authority. I actually don't know if the RA or CA generates the private key. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] EST over CoAP
Hannes Tschofenig <hannes.tschofe...@arm.com> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] EST over CoAP
Hannes Tschofenig <hannes.tschofe...@arm.com> 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) > 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. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-coap-est-00
Benjamin Kaduk <ka...@mit.edu> wrote: >> Jim Schaad <i...@augustcellars.com> wrote: >> > In section 2 - There will be a problem in that the port format extension is >> > being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and 1.3 >> > section for clarity. >> >> I don't understand what you are referring to. >> >> What is the "port format extension" you are referring to, and where in >> section 2 do you think we are depending upon it? > [...] DTLS > implementations MUST use the Supported Elliptic Curves and Supported > Point Formats Extensions [RFC4492]; the uncompressed point format > MUST be supported; [RFC6090] can be used as an implementation method. Ah, so s/port/point/ > The uncompressed point format only exists in (D)TLS 1.2 and lower. > (TLS 1.3 does not separately negotiate point format, rather, the > point format is determined by the group/curve to be used.) I think we were just being overly specific, I'm not sure why. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-coap-est-00
peter van der Stok <stokc...@xs4all.nl> wrote: >> >> DTLS connection is going to be required to act as an RA. RAs >> are required >> >> to have the entire request for adding authentication as necessary. >> >> > This is visible in the figure of section 6, but needs elaboration in >> the >> > text. >> >> I don't understand why we have that paragraph. >> An end point that terminates the Pledge (D)TLS connection and acts as >> an RA *IS* a Join Registrar, not a Proxy. >> > Thus is outside the BRSKI context, and thus a proxy with RA (separate or not) Let me delete "Join" from above sentence. A device that terminates the DTLS security (CoAPS) and then talks to the CA is a Registration Authority according to EST and RFC5280. It's not a proxy. (And it doesn't matter if it speaks HTTPS or CMS or CMP or super-pigeon-telepathy to the CA) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-coap-est-00
Jim Schaad <i...@augustcellars.com> wrote: > In section 2 - There will be a problem in that the port format extension is > being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and 1.3 > section for clarity. I don't understand what you are referring to. What is the "port format extension" you are referring to, and where in section 2 do you think we are depending upon it? I'm thinking that you are jumping to a conclusion based upon some poorly written text on our part :-) But, since I think all the authors are ignorant of that extension, we must be misleading you unintentionally. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-coap-est-00
peter van der Stok <stokc...@xs4all.nl> wrote: >> * In section 6- All proxies are required by CoAP blocking to re-assemble >> the entire message at the proxy. It can re-block things going to the next >> proxy. While there is no requirement that the proxy get the entire message >> before sending on pieces, this should be common practice and would be >> required for a CoAP/HTTP proxy. > Agree fully, we need to clarify that. If we are talking about CoAP->HTTP proxy, then clearly that's absolutely true. How could it be any other way? We can't do CoAP block mode over HTTP that I know of :-) There are other proxy types that we need to describe. >> * Should probably add a note in section 6 that any proxy that terminates >> the >> DTLS connection is going to be required to act as an RA. RAs are required >> to have the entire request for adding authentication as necessary. > This is visible in the figure of section 6, but needs elaboration in the > text. I don't understand why we have that paragraph. An end point that terminates the Pledge (D)TLS connection and acts as an RA *IS* a Join Registrar, not a Proxy. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] changes to draft-richardson-enrollment-roadmap-01.txt
Htmlized:
https://datatracker.ietf.org/doc/html/draft-richardson-enrollment-roadmap-01
diff:
https://www.ietf.org/rfcdiff?url2=draft-richardson-enrollment-roadmap-01
I posted an -01 of the enrollment roadmap document. The intro says:
There are numerous mechanisms being proposed to solve the problem
of securely introducing a new devices into an existing managed network.
This document provides an overview of the different mechanisms showing what
technologies are common. The document starts with a diagram showing the
various components and how they go together to form five enrollment
scenarios.
The work crosses many groups, but does not fit into any of them.
The document might be good as a way to keep track of things, but may not be
worth publishing.
Yes, could go the wiki way, but I find it significantly less satisfying.
In particular I'd like to include guidance on why one process vs another,
which I think would be worth preserving.
On the other hand, there are sections explaining which documents are of
cross-WG interest, and if they have been adopted in any place (or not!!).
That's really ephermeral information that doesn't belong in an RFC until it's
been resolved.
It would also be nice to have a different name than "Transition to
Constrained Enrollment" that more accurately reflected the interests of that
group of deployers (it includes Lighting/Fairhair, and
electricity-AMI/Itron/Cisco.)
If there are those who want to review/contribute to it,
https://github.com/anima-wg/enrollment-roadmap.git might be the best place
to send pull requests. I'm personally not enthralled by using github issues
for discussion (I prefer email lists), but I don't object to it.
If there is interest in publishing it, my suggestion is to use iot-dir
to get some beef into it, and then submit as an AD-sponsored document.
Alternatively saag.
I think that the document should expand by about 4 pages of discussion, and
then sit in stasis for awhile.
The most significant change in -01 is that I changed how the boxes around
the ascii art diagram are rendered. I hope that it is more readable that
way. {If you haven't tried "asciio", I suggest you try it out.}
Other than that, more text in the sections.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Application Layer TLS
Derek Atkins <de...@ihtfp.com> wrote: >> based on the recent email discussion about the DTLS proxy I thought it might >> be useful that there was some thinking about how to run TLS/DTLS at the >> application layer. > I don't understand this statement. The whole point of TLS/DTLS is that > it runs at the Application Layer (as opposed to at the network layer, DTLS has to provide many of the services of the Transport and Network layer (various amounts of reliability, fragmentation/segmentation) and there is overhead in that. When running over things like CoAP, which *ALSO* provides those services, and in a more constrained network happy way, DTLS is way less appealing. > Perhaps we need a better naming scheme here. In my opinion, the ISO layer naming system has always been better as documentation, rather than architecture :-) -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Application Layer TLS
Hannes Tschofenig <hannes.tschofe...@arm.com> wrote: > One question I was asked at the IETF meeting was why the HTTP Connect > functionality hasn't been defined in CoAP since this would make certain > use cases with proxy use simpler. HTTPS CONNECT invokes a multistage TLS connection: client->proxy and proxy->server. That obscures the server certificate from the client and VV, and we have a well established serious security issues in the "enterprise" world with the ability of the proxy to usefully validate the server certificate. An COAP (not COAPS) CONNECT mechanism which put the security inside CoAP (as EDHOC/OSCORE and presumably draft-tschofenig-layered-tls-00 and draft-friel-tls-over-http-00 do) solves the problem of certificate validation nicely because it offers end to end security. However, it's unclear to me how it would be better than NAT66 (with all of it's expensive state), which is why I want a mechanism where the relay state is stored in the network (echoed, source routed back to the proxy). -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] DTLS proxy in EST-coaps
peter van der Stok <stokc...@xs4all.nl> wrote: >> So, in the ANIMA BRSKI context, we have the Join Proxy to connect the >> insecure (unencrypted) network with the JRC as we can not assume the >> registar (JRC) is within radio distance of all pledges. >> >> For EDHOC and DTLS-over-COAP, we can use the option as described in >> draft-ietf-6tisch-minimal-security section 5.1 to keep the proxy >> stateless. >> >> For DTLS, I thought we had a few IDs on how to relay DTLS in a >> stateless manner. I can't seem to find any (Yes, I did look through >> expired drafts too). > You mean expired est-coaps drafts? Indeed, the draft never considered > these, assuming they were off topic and were adequately treated > elsewhere. I don't think that it was est-coaps. I think it was maybe 2 years ago, there were some proposals to proxy DTLS in a stateless way. I was sure at the time that a solution on top of CoAP would be better, so I didn't pay a lot of attention. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] some thoughts about vanderstok-ace-coap-est
Carsten Bormann <c...@tzi.org> wrote: >> I'm less convinced that we ought to be using this mechanism to shorten >> /.well-known/est to /est (why stop there? can't we go to /?) > Why do you think that a node can only have one EST endpoint? It could have hundreds, I agree. Could also have hundreds of different IPs in the /64 answer. If it had more than one, then shortening would have to be done differently for each, I think. We already have /.well-known/est as well. > It should be possible to have many, and the client should be able to > choose the one that is actually doing the right thing for them. I'm pretty sure that I have no way to describe the logic to a client. >> It seems like maybe a 301-like (Moved Permantly) reply from >> /.well-known/est/*, but CoAP doesn't have 301 codes…. > (The link-format self-description is exactly the replacement for the > HTTP 301 here. Same number of roundtrips...) yes, that's a good point, except that for the end-point that has the single end point at /.well-known/est, then there is no 301. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] some thoughts about vanderstok-ace-coap-est
Michael Richardson <mcr+i...@sandelman.ca> wrote: > Section 4.1 provides for the process to start with a discovery > operation. ... > REQ: GET /.well-known/core?rt=ace.est > I can see the architectural reasons for why we do that, but I really > have to ask why if we really really need this extra round trip. Having read rfc6690 over again in order to implement this, I am now further convinced that using this mechanism as a way to shorten the /.well-known/est to something else is not entirely right. I can see how a CoAP multicast to /.well-known/core?rt=ace.est ought to return a list of hosts that support EST, and that EST ought to be returned in a list of supported interfaces. I'm less convinced that we ought to be using this mechanism to shorten /.well-known/est to /est (why stop there? can't we go to /?) It seems like maybe a 301-like (Moved Permantly) reply from /.well-known/est/*, but CoAP doesn't have 301 codes (weird to me that rfc6690 got published with an informative reference to CoAP, as WIP... I guess the WG wanted to get it out. I wish our process would let us update that reference to the RFC, because it confuses the rfc dependancy process) > The alternative is that we either have to use /.well-known/est, or that > we wind up standardizing something (maybe /e) that isn't inside > /.well-known. > Can DTLS compression do better things for us instead? > 2) DTLS and HelloVerifyRequest. > SHOULD CoAP-EST servers always perform the HelloVerifyRequest state? > Again, it's an extra round trip. Always doing it would simplify the > code paths on both ends. > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= > IPv6 IoT consulting =- -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] some thoughts about vanderstok-ace-coap-est
peter van der Stok <stokc...@xs4all.nl> wrote:
> Michael Richardson schreef op 2017-11-10 19:41:
>> {In some ways this should be a discussion among the authors of which I am
>> now
>> one, but I feel that the discussion belongs in public}
>>
>> 1) discovery.
>>
>> Section 4.1 provides for the process to start with a discovery operation.
>>
>> The presence and location of (path to) the management data are
>> discovered by sending a GET request to "/.well-known/core" including
>> a resource type (RT) parameter with the value "ace.est" [RFC6690].
>> Upon success, the return payload will contain the root resource of
>> the EST resources. It is up to the implementation to choose its root
>> resource; throughout this document the example root resource /est is
>> used. The example below shows the discovery of the presence and
>> location of management data.
>>
>> REQ: GET /.well-known/core?rt=ace.est
>>
>> I can see the architectural reasons for why we do that, but I really have
>> to
>> ask why if we really really need this extra round trip.
> This is the standard way of discovering coap endpoints.
> It's done once at start-up. It's extra to what?
Yes, once after a whole bunch of DTLS setup packets back and forth.
So perhaps it fades into noise compared to the DTLS setup...
>> The alternative is that we either have to use /.well-known/est, or that
>> we wind up standardizing something (maybe /e) that isn't inside
>> /.well-known.
>>
> I don't understand this last phrase,
We could go against some architecture decisions and standardize /e or
something like that rather than /.well-known/est or the lookup.
Given the size of the vouchers, the certificates being passed around by
DTLS, and the DTLS record format... does shortening the URLs from
/.well-known/est buy much? I shall look at the example packets in the
document to see.
Can the response from core?rt=ace.est be "/" or ""?
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [6tisch] EDHOC and EALS use in 6tisch (minimal) bootstrap
peter van der Stok <stokc...@xs4all.nl> wrote: >> There are two of them because there is some concern that a full >> zero-touch bootstrap will require too many round trips. In the >> smallest networks a completely manual bootstrap is acceptable to some. > I need some more explanation here. It will help if there are some > numbers comparing the two approaches. And is "completely manual" > identical to "one touch"? Or do you see gradations from completely > manual to fully automatic? "completely manual" means: attach JTAG to device, write K1 key in. Or, "burn keys into source code", deploy. If one was using one of the testbeds, that might be rather easy. >> In the biggest industrial networks, nothing less than a full >> asymmetric key bootstrap is acceptable. This is often due to human >> factors as well well (installers not trusted with symmetric keys!). >> In between are some networks where managing a large number of >> (hopefully unique!) symmetric join keys that have to be provisioned at >> the factory is acceptable. This is how pre-6tisch 802.15.4 networks >> are being deployed today. > The above applies to 6tisch networks only? I'm not claiming that the constraints and opportunities that are specific to 6tisch networks are unique to 802.15.4 TSCH in Industrial settings. I'm rather saying that these are the constraints that allow us to make progress without unweidly scope creep. >> We are doing this work in 6tisch because we can pin down a number of >> variables that would otherwise cause significant scope creep: 1) we >> assume a clueful network operator (or contractor) who can sanely >> operate our Join Registrar/Coordinator [which is in the zero-touch >> case, is a CA]. ---> this means our solution does not scale to residential or small >> office situations, and that is acceptable to us. > That is a very large logical step for me; small offices and residential > are small networks in my view. And small networks do not accept zero > touch? Probably, I misunderstand the reasoning. Such networks do not at present, by default, have clueful operators to run the JRC. If a JRC can be assumed (homenet...), if it can be packaged up to be trivial, or if an upstream ISP or service provider can provide it, then progress could be made. That's a lot of IFs however, and it can hide a lot of ratholes. >> 4) we use RPL as the routing protocol across a mesh, which forms one >> (or more) tree-like DAGs. Close to the root there are significant >> bandwidth constraints, and the convergence of traffic there can cause >> congestion. If properly provisioned, upper-mesh nodes may not suffer >> as much from energy, it can really hurt nodes further down the tree if >> they transmit packets upwards, only to have them dropped due to >> congestion, and then are forced to carry useless retransmits. As >> such, we are looking for solutions that where can coordinate the join >> process centrally, and we can accomodate innovation at the edges in >> the form of DoS defenses. > Coordinate meaning a central control algorithm? The RPL bandwidth > constraints at the root is a general problem. Can this not be separated > out? Once the network is constructed there are a number of observations. 1) if the network is for control (such lighting), P2PRPL might provide for completely different paths which are not so contrained. 2) RPL DAO projection could remove traffic away from the root. 3) a data collector (in the P2MP metering scenarios) can also do management of bandwidth 4) 6tisch includes mechanisms to allocate bandwidth for different applications via the 6p mechanisms, so bandwidth can be reserved and latency can be made deterministic. 5) 6tisch envisions (but is not yet chartered) to deal with a PCE, [such as is used in ISA100, I'm told] that could plan tracks across the mesh in a centralized way. The point is that we can't spend very much of the available bandwidth for join traffic, it would be wasteful and would make the impact of DoS attacks higher. >> e) we think that our enrollment protocol is ideally suited to make the >> introductions between RS<->RO, and C<->RqP that ACE needs for >> bootstraping it's trust model. > RS <-> RO and C<->RqP?; what is the mapping to pledge, JA and > Registrar? > Looking forward to the presentations, I haven't asked for time at ACE about the join process. I think this is a simple application of OSCOAP to generate a new set of keys. This is a partly open OSCOAP issue. I'd also like to ge
Re: [Ace] edhoc section 4.3.2
Göran Selander <goran.selan...@ericsson.com> wrote: > In issue 16 it was requested to allow multiple uses of ephemeral keys > and it was added in the security considerations. I think it makes sense > to mandate the verification of nonce uniqueness during reuse of > ephemeral keys and have reopened issue 16: > https://github.com/EricssonResearch/EDHOC/issues/16 Good, this lets a node trade off storage and compute power. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] edhoc section 4: N_U/N_V question
N_U, N_V, E_V, Alg_V, Enc(K_VE; ID_V, Sig(V; Mac(K_VM; prot_2)))| | <---+ | message_2 | | | | | |N_U, N_V, Enc(K_UE; ID_U, Sig(U; Mac(K_UM; prot_3))) Why is N_U echoed back to U in message 2? Why are N_U and N_V included in message 3? If the nonce acts as a defense against off-path attacks, then at least N_U does not need to be in message 3. Including N_U in message 2 defends an off-path attacker racing V to reply to message_1, which seems unlikely. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] some comments on draft-ietf-cose-msg-24 and draft-ietf-ace-cbor-web-token-01
I am implementing some Ruby code to validate the claims shown in the appendix A of draft-ietf-ace-cbor-web-token-01. It wasn't obvious at first, or maybe I just don't get it, but the examples there are not, I think, signed. We are looking at the content that would get signed. What I see in A.2 is a claim about a public key, but no signature: "This is then packaged signed and encrypted using COSE." Are there any plans to provide a signed test vector as part of CWT? It also seems that perhaps CWT doesn't not need all of the modes that ietf-cose-msg provides. Also, cose-msg has 10 further revisions since the -14 that cwt points to... I don't know if there are any things affecting it. I am currently making sure that I can validate some of the vectors in Appendix C of ietf-cose-msg. I think that the examples are from: https://github.com/cose-wg/Examples I wonder if the directories could say "c-1-1" or something in them? (or the other way around). I think that: C.1.1. Single Signature is ecdsa-01.json, which has a nice "title":"ECDSA-01: ECDSA - P-256" maybe that could be in the document? (My thanks for the LotR inspired keys!) I am aware that ietf-cose-msg-24 has past the WGLC... ietf-cose-msg-24 says on pg 11: protected: Contains parameters about the current layer that are to be cryptographically protected. This bucket MUST be empty if it and after explaining that a zero length string should be used, it says: "This avoids the problem of all parties needing to be able to do a common canonical encoding." Isn't saying it's a zero-length string, a canonical encoding? -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Summary of ACE Group Communication Security Discussion
Michael StJohns <mstjo...@comcast.net> wrote: > The multiparty (group) symmetric key solution is only wanted for a > single corner of the solution space - low latency, no cost > systems. E.g. lightbulbs. Given there is a worked example of the > insecurity of multiparty symmetric key systems (e.g. the attack on the > symmetric signing key of the HUE lights), I'm unclear why anyone at all > would think that pursuing a known bad solution in the IETF is a good > idea. Also, there is the question about cost, so look at: https://www.ietf.org/proceedings/97/slides/slides-97-lwig-2-lightweight-crypto-00.pdf From this morning. 261ms for k163 on a specific device. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Summary of ACE Group Communication Security Discussion
Michael StJohns <mstjo...@comcast.net> wrote: >> I'm less sure that I agree with the subsequent view that we can't >> adopt this item until we have assurance; I'd say that asking for the >> issue to be addressed as part of the adoption process is reasonable, >> and objecting at WGLC if it has not been addressed is the right way. > http://www.techworm.net/2016/11/researchers-use-drones-hijack-philips-hue-smart-lights.html > describes how the use of multi-party symmetric key systems weakens even > minimal security guarantees in a IOT system. In this article, its > noted that the HUE lights have firmware that's signed/encrypted by a > symmetric key (which - by definition then needs to be included in every > device to decrypt/verify the firmware), and that the attackers were > able to extract the key from a lightbulb with relative ease; craft > their own firmware and cause the lightbulbs to load it in a chain > reaction. I had read all about this, and I wondered how they had gotten the bogus firmware accepted; I thought that this was the "bug", but I hadn't read (or I had missed) that the firmware was symmetric signed. That's really really dumb. > So I'd turn this around and ask for a offer of proof that we can find a > way to do this safely *BEFORE* having the IETF invest time and > resources in the work. I don't expect a fully fleshed out solution, > but I haven't seen even a hint that anyone knows how to mitigate the > risks. I see your point. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
