Re: [Emu] teap-brski
-Original Message-
From: Emu On Behalf Of Dan Harkins
Sent: 06 June 2019 15:13
To: an...@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
https://www.ietf.org/mailman/listinfo/emu
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
[Emu] EAP-CREDS - Questions for the WG
Hi all, we are working on the definition of an EAP mechanism that should help managing device credentials for access networks. We are finalizing some parts of the document and I would like to get the input from the WG (I know it is not a WG document, yet, but I hope it will get adopted). [*] In particular, I have the following issues that I can solve in different ways and the reasons to adopt one or the other might depend on some practical aspects when implementing EAP methods. Here's the questions: * *EAP-CREDS Headers Format. *Usually EAP methods use the standard EAP header format (Code, Identifier, Length, and Type fields), however (thanks for the suggestions) EAP-CREDS now is required to be used as a tunneled method where the requirement is that the outer method provides the server/client auth and confidentiality. This means that messages are encoded as payloads of (for example) EAP-TLS and, technically, they do not need all those fields anymore. Moreover, we can have the EAP-CREDS to use 32-bits sizes of the messages, therefore we would not need the Length. My question for the group is: shall we keep the same header to provide ease of development (since libraries already know how to handle those headers) even if this might result in wasting few bytes for each message ? * *Fixed-Size TLVs.* In EAP-CREDS we define several TLVs, some of them, it turns out, do not need to be variable length, but they are, de facto, Fixed in size (e.g., it might be just one-byte value). Initially, we thought about omitting the 'TLV Length' field and have developers to "derive" the size of these TLVs by the 'TLV Type' field. For example, if a TLV 'A' is just a 1 byte value, shall we still have the 'TLV Length' (set to '1') or we shall omit the 'TLV Length' for these structures ? * *TLVs Length Size.* In EAP-CREDS we expect the majority of the messages to be relatively small (since we provide the possibility to encapsulate other protocols, that might not be true in that case; For the integrated provisioning protocol, SPP, that is true). However, with the increasing size of keys and crypto-related data structures, the use of a 16-bit length field might not be enough very soon. In order to address that, we currently use an extra 32-bit field for the message length that is used instead of the standard 'Length' field and a 24-bit field for the TLV Length. Does this make sense for everybody ? Shall we use a different approach (e.g., provide a 32-bit field for the TLV Length instead) ? Thanks for the feedback :D Cheers, Max [*] = The version that is currently available in the Datatracker is quite outdated, however, as soon as we finalize some of these aspects we will publish the new version. The GIT repository is available (more updated, but not at the latest version) is available at GitHub (https://github.com/openca/eap-creds) P.S.: I added the EAP-CREDS implementation for the Hackaton, please let me know if you want to participate. I have not organized any hackaton events before, so there might be glitches/issues/etc. because of my inexperience... if anybody would like to help, that would be great! -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
