Subject: [Anima-bootstrap] EST in anima thoughts

From: Toerless Eckert <[email-masked]>
Date: Fri, 21 Aug 2015 08:21:58 -0700

So, RFC7030 (EST) unfortunately only covers TLS conection. Which makes
it a bit harder to figure out how to create a working TLS connection from
a new enrollee to the registrar:

        access-lan      ......ACP..........
  client -------- proxy ------------------ ANer ---- Registrar
      LLc       LLp  ULAp                           REGa

Client hass link-local scope address LLC, proxy (existing AN router) has
link-local scope address LLp. Proxy also has ACP IPv6 address ULAp.
Registrar has IPv6 address REGa, reachable via ACP (normally ACP would
be in the ACP, so REGa would be an ACP address, but lets assume we do
not care). 

proxy is aware of registrar address REGa (from some form of service discovery -> GARP).

If this was all IPv4 (eg: with rfc3927 link local scope addresses on the
access-lan), then i am pretty sure that we could solve this by having
proxy simply providing PAT (Port Address Translation, overloading address):

   "Inside"                  "Outside"

  (LLc,(LLp,port 443) ) <-> (ULAp, (REGa, port 443))

In IPv6, there is likely all kind of political issues to call what
we want to do NAT, but i think we would get the same result if proxy
was just a transparent TCP proxy: server socket on LLP, when connection
from client is established, establish TCP connection to REGa, pass
packets back and forth. Done.

What do you folks think ? Is this the most easy way to pass on the
EST connection during initial enrollment ? Any stuff that might not
work ?  What would be reasons not to do it this way ?

"What could EAP do better" ? ;-))

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Aug 2015 14:16:48 +1200

> packets back and forth. Done.

I'd call that a TCP relay, but it seems like a perfectly clean solution,
and it's better than NAT anyway: nothing tricky at all.

The only alternative I can think of is to give the client a temporary
address ULAc with the next hop router being LLp, and tell it to TLS
directly to REGa. But then you have to rescind ULAc a few milliseconds later.

    Brian

> _______________________________________________
> Anima-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap
>

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 22 Aug 2015 03:48:03 -0700

> and it's better than NAT anyway: nothing tricky at all.

Thanks, yes. I'm always coming from the option that permits HW
acceleration, which would be a nat flow, but i also don't see
how HW acceleration would be relevant here. Rather the opposite:
DoS protection: limited number of parallel connection per interface,
limited rate of connection setup etc. pp.

> directly to REGa. But then you have to rescind ULAc a few milliseconds later.

Right, but the worst thing is that the proxy needs to inject that address
into the routing protocol, so you'd be flooding routes temporarily.

Cheers
    Toerless

---

From: Robert Cragie <[email-masked]>
Date: Sun, 23 Aug 2015 10:06:37 +0100

We had a similar issue with low power mesh networks and the authentication model looks similar to that shown below. The joining node (client below) would often not be in direct communication with the authenticator (Registrar below), therefore a 802.1X model applied, which is similar to the one you show below. However, we used PANA (RFC 5191) and developed PANA Relay (RFC 6345) to solve the particular problem of the joining node not being in direct communication with the authenticator. This uses LL addresses between the joining node and the relay element (proxy) and normal internet routing between the relay element and the authenticator and encapsulates the traffic along with joiner metadata all the way to the authenticator, so no state retention needed in intermediaries for the purposes of authentication. As PANA is an EAP transport, we then used EAP-TLS to do the authentication. The secure PANA session was then used to deliver additional configuration to the joining device securely. An alternative would be to continue using the TLS session (in an EAP-TTLS way) to carry additional transactions, e.g. EST.

The reason we chose encapsulation over a stateful solution (NAT) was to avoid the need to store state at intermediaries.

Robert

-----Original Message-----
From: Anima-bootstrap [mailto:[email-masked]] On Behalf Of Toerless Eckert
Sent: 21 August 2015 16:22
To: [email-masked]
Subject: [Anima-bootstrap] EST in anima thoughts

So, RFC7030 (EST) unfortunately only covers TLS conection. Which makes it a bit harder to figure out how to create a working TLS connection from a new enrollee to the registrar:

Client hass link-local scope address LLC, proxy (existing AN router) has link-local scope address LLp. Proxy also has ACP IPv6 address ULAp.
Registrar has IPv6 address REGa, reachable via ACP (normally ACP would be in the ACP, so REGa would be an ACP address, but lets assume we do not care).

If this was all IPv4 (eg: with rfc3927 link local scope addresses on the access-lan), then i am pretty sure that we could solve this by having proxy simply providing PAT (Port Address Translation, overloading address):

   "Inside"                  "Outside"

In IPv6, there is likely all kind of political issues to call what we want to do NAT, but i think we would get the same result if proxy was just a transparent TCP proxy: server socket on LLP, when connection from client is established, establish TCP connection to REGa, pass packets back and forth. Done.

What do you folks think ? Is this the most easy way to pass on the EST connection during initial enrollment ? Any stuff that might not work ?  What would be reasons not to do it this way ?

Cheers
    Toerless

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

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 23 Aug 2015 06:29:28 -0700

Thanks, Robert,

I didn't quite get from your description whether you are saying that PANA
itself would be an applicable solution or part of the solution for ANIMA:
using PANA instead of EST or EST over PANA.

Short of PANA it seems should compare TLS over TCP-Proxy with TLS
over EAP (EAP-TTLS rfc5281), right ?

TCP-Proxy seems to me to be a very simple solution:
 - You have some pre-existing TLS implementation on client and server (registrar),
   no need to change any of their code. Just have the client connect to the
   proxy initially and to the registrar later for renewal. 
 - TCP-Proxy code without hardening seems very lightweight. Then add limiter
   for total number of simultaneous connection (attempts) per proxy-interface.

With EAP-TTLS i am still baffled:
 - Overall, it looks to me as if EAP-TTLS does not allow to re-use existing
   TLS code, eg: take an existing TLS implementation with a southbound API
   to use a reliable transport stream and link that to EAP-TTLS instead of TCP.
 - Instead it looks as if EAP-TTLS is defining how to hook EAP somehow into
   the middle of the TLS design. 
   - I have no clue how EAP provides reliable, flow-controlled connections.
     I was not aware of it being able to use TCP or SCP, so i efar it either
     reinvents the flow-control/congestion wheel or by not using it, it changes
     the upper layer (TLS) reliability behavior. 
   - EAP-TTLS talks about differentiating authentication and transport phases of
     TLS and modifying/linking them to EAP, but i also have no clue why and
     for what benefit.
 - Overall it seems like a lot of complexity, and i have no idea what benefit
   we'd get out of it. Who could tell us ?

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: Robert Cragie <[email-masked]>
Date: Wed, 26 Aug 2015 14:36:02 +0100

I am not sure if it is a viable solution. My main aim was to compare it to something already done for a similar purpose. There are differences of course and the TCP proxy mechanism may be more appropriate in the anima case.

PANA/EAP/EAP-TTLS would be the "secure transport" for EST, carried using TLS, as application data of an EAP-TTLS session carried in a PANA session. This would allow "guesting" of a device (enrollee) before it actually becomes part of the network and use of a dedicated authentication protocol to carry the traffic through the network.

EAP-TTLS is just an EAP method and is basically EAP-TLS (RFC 5216) plus allowing application data to follow (data phase). In RFC 5281, it shows the data phase carrying AVPs or EAP; in this case, it could carry EST. Regarding reusing existing TLS code - I have implemented a system with PANA, EAP and EAP-TLS which used the same TLS libraries as the application data TLS, so whilst it may not be possible out-of-the-box with existing TLS implementations, it is not too hard to modify them.

EAP is a lock-step protocol using UDP and EAP-TLS/TTLS has retransmission mechanism similar to that used for DTLS. So in some respects it does, as you say, reinvent the flow control/congestion wheel, however it is widely used.

Regarding the complexity assertion - that indeed does come up. However, certainly in the scenario we used it in, doing it any other way more or less results in the same amount of complexity (if not more), just in a different place. We used it because our scenario was very similar to the 802.1X model, which uses EAP and therefore we wanted to try and align with what is done in 802.1X model.

Robert

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]]
Sent: 23 August 2015 14:29
To: Robert Cragie
Cc: [email-masked]
Subject: Re: [Anima-bootstrap] EST in anima thoughts

Thanks, Robert,

I didn't quite get from your description whether you are saying that PANA itself would be an applicable solution or part of the solution for ANIMA:
using PANA instead of EST or EST over PANA.

Short of PANA it seems should compare TLS over TCP-Proxy with TLS over EAP (EAP-TTLS rfc5281), right ?

Cheers
    Toerless

On Sun, Aug 23, 2015 at 10:06:37AM +0100, Robert Cragie wrote:
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2557590 ARM Holdings plc,
> Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in
> England & Wales, Company No:  2548782
>

---

From: Sandeep Kumar <[email-masked]>
Date: Wed, 26 Aug 2015 15:53:37 +0200

There was a similar solution suggested sometime back using a DTLS relay for
constrained environments.
https://tools.ietf.org/html/draft-kumar-dice-dtls-relay-02

There are two options, one stateless and the other statefull approach with
their pros and cons. Also security considerations are a good read to
understand the pros and cons.

regards
Sandeep

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 26 Aug 2015 07:23:29 -0700

I am also worried about that TTLS saying TTLSv0 and being informational.
To me this sounds as if in all of its complexity its incomplete,
potentially contentuous and likely sparsely implemented/tested...