Re: [Emu] Working group Last Call for RFC 7170bis
On 25.03.23 14:28, Alexander Clouter wrote: On Sat, 25 Mar 2023, at 12:03, Eliot Lear wrote: I ask that as you consider this thread, you think beyond Basic-Auth to the PKCS operations. I definitely am not qualified to think on this, I would be a fool to not yield to those using those attributes! Other than your group, is anyone aware of any other implementation of the PKCS machinery and using it in anger? My group is a group of partners. Does the draft for RFC7170bis describe completely something that your group implemented? Does it need your proposed CSR related TLV attribute to be included? The CSR helps, and is a hindrance if it's not there. We implemented an earlier version of the spec in which we added a new mode to wpa_supplicant in which there is no intermediate result required for those last components, but it won't be a lot of trouble to reimplement based on what is in the spec. Maybe worth bringing up is I have no idea what the language mentioned in https://github.com/emu-wg/rfc7170bis/issues/8 actually does to an implementation using these attributes; ""..in a degenerate Certificates Only PKCS#7 SignedData Content as defined in [RFC5652]." what is 'degenerate' here do or mean? Sorry- 'degenerate case'. There are two normal uses of TEAP in this case: * Just a simple EAP-TLS-like authentication (no inner eap). * Renewal flow (whether that's the trust anchor or the client cert or both). But we should be prepared for other stuff in the future. Consider a RATS attestation token as an extension, for instance. That might become part of a regular flow. Eliot OpenPGP_signature Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Working group Last Call for RFC 7170bis
On Sat, 25 Mar 2023, at 12:03, Eliot Lear wrote: > I ask that as you consider this thread, you think beyond Basic-Auth to the > PKCS operations. > I definitely am not qualified to think on this, I would be a fool to not yield to those using those attributes! Other than your group, is anyone aware of any other implementation of the PKCS machinery and using it in anger? Does the draft for RFC7170bis describe completely something that your group implemented? Does it need your proposed CSR related TLV attribute to be included? Maybe worth bringing up is I have no idea what the language mentioned in https://github.com/emu-wg/rfc7170bis/issues/8 actually does to an implementation using these attributes; ""..in a degenerate Certificates Only PKCS#7 SignedData Content as defined in [RFC5652]." what is 'degenerate' here do or mean? Cheers___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Working group Last Call for RFC 7170bis
I ask that as you consider this thread, you think beyond Basic-Auth to
the PKCS operations. Those are becoming really important to our base.
Eliot
On 25.03.23 09:52, Alexander Clouter wrote:
On Sat, 25 Mar 2023, at 01:08, Heikki Vatiainen wrote:
If you are using eapol_test prior to a few TEAP patches
(reversed EAP-FAST MSK calculation and ordering of the
Cryptobinding processing) then it should just work out the box.
I think the case in question where the inner methods were two
Basic-Password-Auths (e.g., machine and user type). eapol_test was
from the latest git source exactly of the reasons you mentioned.
Ahhh, we only implemented EAP-Payload and ignored Basic-Password-Auth.
RFC 7170 is from 2014. It may have been useful at that time, but is
this still the case? Is it reasonable to implement TEAP in 2020s but
not having EMSK supported for an inner EAP that has EMSK defined.
Conjuring up a scenario so it can be picked apart and discussed...
Is it possible to build an implementation of something like EAP-TLS
backed by an external system (ie. TPM/hardward-offload) and the EMSK
material are not avaliable?
RFC5247 section 1.2 has this to say about the EMSK: "...and is never
shared with a third party." I read this to include any userspace code
implementation (ie. Radiator, FreeRADIUS, hostapd, ...) as a 'third
party' as section 1.5 there also labels the backend authentication
server as a third party.
If the other end was an implementation though that does provide the
EMSK, we would have a legitimate split.
Of course, if no one is doing this do we need to describe it?
Otherwise could we describe it confidently? Probably not.
Just to spice things up a bit, Vendor-Specific-TLVs also can be the
authentication method here which means they could do anything they
want, including not providing an EMSK.
Thing is it looks like neither Cisco or Microsoft have implemented
Vendor-Specific-TLVs in this way so one option could be to remove
support for them for authentication and instead point to that they
should be implemented via an vendor specific EAP method (wrapped in
EAP-Payload-TLV).
Removing Vendor-Specific-TLVs would then leave Basic-Password-Auth as
the oddity...which leads to other than Radiator and hostapd ("pants
may explode and here be dragons" labelling)...has anyone else
implemented and use in the wild Basic-Password-Auth? Microsoft only do
EAP-{TLS,MSCHAPv2} and it looks like Cisco too from
https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/216510-eap-chaining-with-teap.html#anc6
...maybe we can burn Basic-Password-Auth too?
At the moment there is no way anyway for Windows to push the users
plaintext password to the server anyway, so not sure if anything
tangible would be lost in doing this. Also provides an opportunity to
punt people towards EAP-PWD?
TEAP can be implemented as the draft currently says. Mandatory EMSK
would make it simpler, though.
The PAC was removed as it turned out no one implemented it, so if this
is tweak is also something that 'empirically' continues to work then I
would support this.
None of this is here because we want it, it is there as it looks
to be how Windows implemented things.
We haven't tried with Windows yet. Windows doesn't export EMSK for
all methods that could support it?
You are right, it does, so we could probably just do this.
Means we could also burn the MSK CMAC if we burn Basic-Password-Auth :)
Starting to think if it ever happens that TEAPv2 is going to look very
different to TEAPv1...
Ending up with different EMSK values
I do not understand why the EMSK calculations would be different
for the same method?
In other words, because the peer and server do not know about each
other's EMSK capabilities, they can end up calculating different
tracking for EMSK derived compound values. Wouldn't this be the case
with non-mandatory EMSK support?
I see, yes, this would be problematic.
Cheers
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
OpenPGP_signature
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Working group Last Call for RFC 7170bis
On Sat, 25 Mar 2023, at 01:08, Heikki Vatiainen wrote:
>>> If you are using eapol_test prior to a few TEAP patches (reversed EAP-FAST
>>> MSK calculation and ordering of the Cryptobinding processing) then it
>>> should just work out the box.
> I think the case in question where the inner methods were two
> Basic-Password-Auths (e.g., machine and user type). eapol_test was from the
> latest git source exactly of the reasons you mentioned.
Ahhh, we only implemented EAP-Payload and ignored Basic-Password-Auth.
> RFC 7170 is from 2014. It may have been useful at that time, but is this
> still the case? Is it reasonable to implement TEAP in 2020s but not having
> EMSK supported for an inner EAP that has EMSK defined.
Conjuring up a scenario so it can be picked apart and discussed...
Is it possible to build an implementation of something like EAP-TLS backed by
an external system (ie. TPM/hardward-offload) and the EMSK material are not
avaliable?
RFC5247 section 1.2 has this to say about the EMSK: "...and is never shared
with a third party." I read this to include any userspace code implementation
(ie. Radiator, FreeRADIUS, hostapd, ...) as a 'third party' as section 1.5
there also labels the backend authentication server as a third party.
If the other end was an implementation though that does provide the EMSK, we
would have a legitimate split.
Of course, if no one is doing this do we need to describe it? Otherwise could
we describe it confidently? Probably not.
Just to spice things up a bit, Vendor-Specific-TLVs also can be the
authentication method here which means they could do anything they want,
including not providing an EMSK.
Thing is it looks like neither Cisco or Microsoft have implemented
Vendor-Specific-TLVs in this way so one option could be to remove support for
them for authentication and instead point to that they should be implemented
via an vendor specific EAP method (wrapped in EAP-Payload-TLV).
Removing Vendor-Specific-TLVs would then leave Basic-Password-Auth as the
oddity...which leads to other than Radiator and hostapd ("pants may explode and
here be dragons" labelling)...has anyone else implemented and use in the wild
Basic-Password-Auth? Microsoft only do EAP-{TLS,MSCHAPv2} and it looks like
Cisco too from
https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/216510-eap-chaining-with-teap.html#anc6
...maybe we can burn Basic-Password-Auth too?
At the moment there is no way anyway for Windows to push the users plaintext
password to the server anyway, so not sure if anything tangible would be lost
in doing this. Also provides an opportunity to punt people towards EAP-PWD?
> TEAP can be implemented as the draft currently says. Mandatory EMSK would
> make it simpler, though.
The PAC was removed as it turned out no one implemented it, so if this is tweak
is also something that 'empirically' continues to work then I would support
this.
>> None of this is here because we want it, it is there as it looks to be how
>> Windows implemented things.
> We haven't tried with Windows yet. Windows doesn't export EMSK for all
> methods that could support it?
You are right, it does, so we could probably just do this.
Means we could also burn the MSK CMAC if we burn Basic-Password-Auth :)
Starting to think if it ever happens that TEAPv2 is going to look very
different to TEAPv1...
>>> Ending up with different EMSK values
>> I do not understand why the EMSK calculations would be different for the
>> same method?
> In other words, because the peer and server do not know about each other's
> EMSK capabilities, they can end up calculating different tracking for EMSK
> derived compound values. Wouldn't this be the case with non-mandatory EMSK
> support?
I see, yes, this would be problematic.
Cheers___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
