Subject: [Anima] est-coaps clarification on /att and /crts

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Dec 2018 11:29:23 -0500

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jim Schaad <[email-masked]>
Date: Tue, 11 Dec 2018 09:50:00 -0800

Clarification requested - exactly what element is the Registrar?

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.

Jim

> -----Original Message-----
> From: Ace <[email-masked]> On Behalf Of Michael Richardson
> Sent: Tuesday, December 11, 2018 8:29 AM
> To: [email-masked]; [email-masked]
> Cc: Peter van der Stok <[email-masked]>; max pritikin
> <[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]>
> Subject: [Ace] est-coaps clarification on /att and /crts
> 
> 
> 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.
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)
> 
permit
> /att and /crts actions to be done by clients that it does not
interesting
> things), and the /crts would show the name of the operator.
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 <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 11 Dec 2018 17:57:30 +0000

Hi Michael,

I thought about this for the EST-coaps draft. EST allowed for unauthenticated /cacerts and /csrattrs (/crt and /att in EST-coaps) as you are suggesting. It is not as simple in EST-coaps. Two reasons: 
1) There are constrained networks where an easy amplification attack could take place. For example the /crt request is very small and the response can be big (a few KBs in the context of a constrained network is big). If unauthenticated, then /crts could be an easy amplification attack to saturate a constrained network. We don't want that to happen. We want all our clients to be authenticated by DTLS before they start loading up our RF network.
2) Additionally, there is a practical challenge of COAPS. When the DTLS handshake is taking place the server does not know what the request will be. In EST the server would send an HTTP WWW-Authenticate header to ask the client to authenticate. Such a mechanism does not exist in COAP, so it would not be straightforward unless we introduced a bunch of new things into COAP.

I think it is still right to authenticate clients even for /crt and /att in the EST-coaps context. Maybe that is something to be revisited in Constrained-BRSKI/voucher, but not taken lightly. 

Rgs,
Panos

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: Tuesday, December 11, 2018 11:29 AM
To: [email-masked]; [email-masked]
Cc: Panos Kampanakis (pkampana) <[email-masked]>; Peter van der Stok <[email-masked]>; Max Pritikin (pritikin) <[email-masked]>
Subject: est-coaps clarification on /att and /crts

* PGP Signed by an unknown key

A clarification question from an implementor (me) in the context of constrained BRSKI state machine.

The /att and /crts requests do not do anything to change the state of client or server.  It would seem that it might be safe to permit clients which have not yet authenticated to do this operation.
(/att gets CSR attributes, and /crts gets the list of trust anchors)

When EST-COAPS is used on its own, there usually needs to be a manufacturer trust anchor installed on the Registrar before any connection will be permitted.

When EST-COAPS is used as step 2 of constrained-BRSKI, whether or not the Registrar will accept any (and all) connections depends upon configuration of the operator.  Some devices might not be doing BRSKI (not need to, they already trust the operator, but they might still have IDevID only.  This might happen during a transition)

If the Registrar is "open" to new manufacturers, should the Registrar permit /att and /crts actions to be done by clients that it does not
recognize?   The /att call on an ANIMA ACP network would reveal to the
client the ULA that would be used for that client (and perhaps other interesting things), and the /crts would show the name of the operator.
Note that the later info probably is revealed just by doing the TLS handshake.

I think that they should be restricted in general, but I'm concerned that there might be some situation I've missed.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

* Unknown Key
* 0xDDD0DD65

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Dec 2018 17:16:50 -0500

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

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Dec 2018 17:21:47 -0500

Panos Kampanakis (pkampana) <[email-masked]> 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   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 12 Dec 2018 00:52:01 +0000

On Dec 11, 2018, at 3:16 PM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
Clarification requested - exactly what element is the Registrar?

The Registrar terminology is from the Anima working group and is closely analogous to the “Registration Authority” we know and love from the PKI space.

   Join Registrar (and Coordinator):  A representative of the domain
      that is configured, perhaps autonomically, to decide whether a new

      device is allowed to join the domain.  The administrator of the

      domain interfaces with a "join registrar (and coordinator)" to
      control this process.  Typically a join registrar is "inside" its
      domain.  For simplicity this document often refers to this as just
      "registrar".  Within [I-D.ietf-anima-reference-model<https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-17#ref-I-D.ietf-anima-reference-model>] this is
      refered to as the "join registrar autonomic service agent".

It terminates the BRSKI protocol from the new device and, after processing and decisions, forwards messages to a manufacturer authorized signing authority to obtain vouchers and ensure records/audit-logs are kept. It also pulls those audit logs to make additional decisions. It is responsible for making the authorization decision concerning if the new device should be allowed to join the network.

It also optionally doubles as a enrollment over secure transport (RFC7030) registration authority in the normal PKI sense. This is recommended in that BRSKI recommends that devices go on to enroll and obtain a certificate.

- max

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
-= IPv6 IoT consulting =-

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 12 Dec 2018 02:59:12 +0000

Gotcha, so you are describing a provisional DTLS connection at the server. 

Just to give a bit more color, in a usecase we are working on right now the mesh network link rate <100Kbps. That network gets oversubscribed with legit cacert responses. I can only imagine how worse it would be if bad guys were allowed to send small /crt requests and trigger big cert responses. 

Just a 4.01 would not tell the client that he needs to send client certs for auth. In plain EST it would take an HTTP 401 with an 
WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge
header in the response. Unless we replicate that a generic 4.01 would not be enough for the client to know what to do. 

Another issue is EST-coaps request pipelining. A cacerts could precede an enrollment in the same DTLS connection (for really constrained devices that don't want to establish two connections). This could be opening room for unauthenticated enrollments when pipelining is used. 

I think it is a good idea to not repeat the EST behavior in regards to /crt and /att. Provisional TLS at the server could have value in Constrianed-BRSKI/voucher though, for some situations though. 

> So I think that we need to say something in EST-COAPS to explain that we do not see a use case for replying to /crts and /att for clients which are not recognized.  Is 401 (4.01) or 403 (4.03) more appropriate do you think? 

Currently we say that clients need to be authenticated in a DTLS connection before an EST-coaps request. Do you want to make it more explicit to say that even though EST allowed for it, EST-coaps does not allow unauthenticated /crt and /att? We can certainly add that. 

Rgs,
Panos

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: Tuesday, December 11, 2018 5:22 PM
To: Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]; [email-masked]
Cc: Peter van der Stok <[email-masked]>; Max Pritikin (pritikin) <[email-masked]>
Subject: Re: est-coaps clarification on /att and /crts

Panos Kampanakis (pkampana) <[email-masked]> wrote:
> unauthenticated /cacerts and /csrattrs (/crt and /att in EST-coaps) as 
> you are suggesting.

Exactly.

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

* Unknown Key
* 0xDDD0DD65

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Dec 2018 16:01:12 +0000

Hi Panos, Hi Michael,

> We want all our clients to be authenticated by DTLS before they start loading up our RF network.

I am curious what security model you have in mind? If you don't do client authentication then you are essentially issuing certificates to an anonymous entity. This feels like a very bad idea, particularly since the CA is supposed to assert the identifier of the client via the certificate.

What am I missing here?

Ciao
Hannes

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

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 12 Dec 2018 19:13:13 +0000

Hi Hannes,
Michael was only asking if allowing any anonymous entity to get the cacerts (trusted root cert list) is worth it. RFC7030 allows for this. Of course an enrollment would still require authentication/authorization. 
I was making the case that it is not worth to even allow anonymous get cacerts. 
Panos

-----Original Message-----
From: Hannes Tschofenig <[email-masked]> 
Sent: Wednesday, December 12, 2018 11:01 AM
To: Panos Kampanakis (pkampana) <[email-masked]>; Michael Richardson <[email-masked]>; [email-masked]; [email-masked]
Cc: Peter van der Stok <[email-masked]>; Max Pritikin (pritikin) <[email-masked]>
Subject: RE: est-coaps clarification on /att and /crts

Hi Panos, Hi Michael,

What am I missing here?

Ciao
Hannes

---

From: Jim Schaad <[email-masked]>
Date: Wed, 12 Dec 2018 11:17:49 -0800

> From: Ace <[email-masked]> On Behalf Of Hannes Tschofenig
> Sent: Wednesday, December 12, 2018 8:01 AM
> To: Panos Kampanakis (pkampana) <[email-masked]>; Michael
> Richardson <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: [Ace] est-coaps clarification on /att and /crts
> 
> Hi Panos, Hi Michael,
> 
> > We want all our clients to be authenticated by DTLS before they start
loading
> up our RF network.
> I am curious what security model you have in mind? If you don't do client
> authentication then you are essentially issuing certificates to an
anonymous
> entity. This feels like a very bad idea, particularly since the CA is
supposed to
> assert the identifier of the client via the certificate.
> 
> What am I missing here?

Hannes, 

What you are missing is that the question is not about issuing the
certificate.  That is going to require client authentication.  What is being
looked at is getting the list of trust anchors or the template for a
certificate request based on an anonymous client.

Jim

> 
> Ciao
> Hannes
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
recipient,
> please notify the sender immediately and do not disclose the contents to
any
> other person, use it for any purpose, or store or copy the information in
any
> medium. Thank you.
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Dec 2018 16:45:08 -0500

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Dec 2018 16:49:59 -0500

Hannes Tschofenig <[email-masked]> wrote:
> > 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.

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Dec 2018 16:52:03 -0500

>     Jim Schaad <[email-masked]> 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.