Re: [Anima] [Emu] teap-brski

-----Original Message-----
From: Emu <emu-bounces@ietf.org> On Behalf Of Dan Harkins
Sent: 06 June 2019 15:13
To: anima@ietf.org; emu@ietf.org
Subject: [Emu] teap-brski

  Hello,

  In a private thread on teap-brski the topic of co-location of the TEAP server and the BRSKI registrar was brought up. It was suggested that the discussion move to these lists to get more input from the experts.

  In draft-lear-eap-teap-brski-02 the architecture shows a the TEAP server and the BRSKI registrar as separate while mentioning that they can be co-located.

The following assumes they are not co-located.

  The BRSKI pledge in this draft is called a "device" and the device establishes a provisional TLS connection (through TEAP) to the TEAP server over 802.1X or something similar. The device does not connect to the registrar. The device then creates a voucher request and sends it to the TEAP server using a newly defined TEAP TLV. The registrar signs the request, forwards it onto a MASA, and sends the voucher it gets back from the MASA to the device using another newly defined TEAP TLV.

  So the question is, will this even work? If the TEAP server and BRSKI registrar are separate entities then the voucher will include the TEAP server's EE certificate but it will be signed by the registrar's EE certificate. From my admittedly limited understanding of BRSKI I think the MASA will reject this voucher request because it fails the "proximity" check (if I understand the proximity check correctly). The MASA will treat the registrar as a man-in-the-middle.

  BRSKI folks: is this correct? Will a voucher request be rejected from a deployment like this?

[ofriel] I believe this will fail the proximity check as outlined in https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-5.5.5

However, there is an interesting definition in https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-3.4

        leaf prior-signed-voucher-request {

          type binary;

          description

            "If it is necessary to change a voucher, or re-sign and

             forward a voucher that was previously provided along a

             protocol path, then the previously signed voucher SHOULD be

             included in this field.

             For example, a pledge might sign a voucher request

             with a proximity-registrar-cert, and the registrar

             then includes it in the prior-signed-voucher-request field.

             This is a simple mechanism for a chain of trusted

             parties to change a voucher request, while

             maintaining the prior signature information.

             The Registrar and MASA MAY examine the prior signed

             voucher information for the

             purposes of policy decisions. For example this information

             could be useful to a MASA to determine that both pledge and

             registrar agree on proximity assertions. The MASA SHOULD

             remove all prior-signed-voucher-request information when

             signing a voucher for imprinting so as to minimize the

             final voucher size.";

        }

Most notable: “This is a simple mechanism for a chain of trusted parties to change a voucher request, while maintaining the prior signature information.”

So with some extra definition, one could envisage the TEAP server signing the Voucher request using its cert and including the Pledge’s voucher request in its prior-signed-voucher-request and sending it to the RA, and then the RA in turn signing the request using its own cert, and including the TEAP server’s voucher request in its prior-signed-voucher-request. The pledge could also assert the TEAP EE cert in its voucher request, with the TEAP server asserting the RA’s cert in its voucher request. The MASA could in theory then validate the full chain of trust back.

Now, that’s reading a lot into that one statement, and the rest of BRSKI certainly doesn’t describe operation like that, and its far easier to mandate that the TEAP server *is* the Registrar.

  EMU folks: if the answer from the BRSKI folks is that this doesn't work then is there any sort of weird tunneling or "phase 2" trickery that can be added to TEAP to get this to work or should we just explicitly state that the TEAP server and the registrar are the same entity (they authenticate with the same certificate)?

  Thanks,

  Dan.

_______________________________________________

Emu mailing list

Emu@ietf.org<mailto:Emu@ietf.org>

https://www.ietf.org/mailman/listinfo/emu