successfully implement EAP-TEAP in a manner that interoperates with
deployed implementations.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
require 0x00 and length to be added
around the seed shown above, I'd note that there does not seem to be any
MUST statement about that in RFC 5295 and as such, I think the versions
described above (and the ones used in known implementations today) seem
to be justifiable especially taken into ac
equest
containing a TEAP/Start packet. This packet includes a set Start (S)
bit, the TEAP version as specified in Section 3.1, and an authority
identity TLV.
This is still valid with M=0 for that TLV..
--
Jouni MalinenPGP id EFC895FA
___
On Wed, Oct 21, 2020 at 02:14:45PM -0700, Joseph Salowey wrote:
> On Wed, Oct 21, 2020 at 12:11 PM Jouni Malinen wrote:
>
> > On Wed, Oct 21, 2020 at 09:30:33AM -0700, Joseph Salowey wrote:
> > > Errata 5127: https://www.rfc-editor.org/errata/eid5127
> > > Proposed
length" and use the "2-octet unsigned integer in network byte
order" from that to determine the exact encoding of the seed. And the
first 0x00 as part of the label to TLS-PRF would be be confusing as well
with this explanation that is clearly defining the label without
including the explicitly noted "\0" after the label.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
present)? How would
the correct IMCK[j] be determined by the peer and the server if one of
them derived MSK/EMSK but the other one did not derive either for inner
EAP method j?
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
role, i.e., hostapd as the access point forwarding
EAP to an external RADIUS authentication server does not place such a
constraint on the exchange.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
"" instead of that 3 octet seed)
The "and the length is 64 octets" part just above this is a bit
confusing with this, though.
IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60)
(this is actua
tion for provisioning the new PAC (which seem
a bit inconvenient for some use cases IMHO, but nevertheless, I don't
see this needing any additional mechanism for indicating when the
NewSessionTicket is not going to be showing up).
--
Jouni Malinen
On Mon, Jul 22, 2019 at 03:12:15PM -0400, Joseph Salowey wrote:
> On Mon, Jul 1, 2019 at 4:11 PM Jouni Malinen wrote:
> > (2) S-IMCK[j] derivation when inner EAP methods in the sequence derive
> > both MSK and EMSK (or even more complicated, if there are multiple inner
> &g
On Mon, Jul 22, 2019 at 01:50:26PM -0400, Joseph Salowey wrote:
> On Mon, Jul 1, 2019 at 4:11 PM Jouni Malinen wrote:
> > (1) Crypto-Binding TLV format for the cases where the negotiated TLS
> > cipher suite uses SHA256 (or SHA384, for that matter) instead of SHA-1 (and
&
On Sat, Jul 13, 2019 at 08:59:04AM +0200, Alan DeKok wrote:
> On Jul 12, 2019, at 11:08 PM, Jouni Malinen wrote:
> > It would seem to make sense to me to allow the EAP-TLS 1.3 server to
> > send out either an empty plaintext or a one octet plaintext to avoid
> > this issue
an
EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
Message.
(this is where that TLSPlaintext.length = 0 should also allow 1 to make
this easier to implement and deploy)
--
Jouni MalinenPGP id EFC895FA
___
I've filed number of errata entries against RFC 7170. The email responses
from rfc-editor seem to be cc'ed to this mailing list, but I don't receive
them from the list or see them in the list archive. Anyway, if there are
anyone here who would be interested in getting these reports reviewed and
On Mon, Jan 28, 2019 at 8:46 PM Alan DeKok
wrote:
> The EMU charter says:
>
> - Define session identifiers for fast re-authentication for
> EAP-SIM, EAP-AKA, and EAP-AKA’. The lack of this definition
> is a recently discovered bug in the original RFCs.
>
> I have recently uploaded a document
On Thu, May 31, 2018 at 2:45 PM, John Mattsson
wrote:
> Except editorials, the main change is that the Exporter labels has been
> changes to conform with RFC 5705 and that the labels are now to be
> registered by IANA as they should be.
>
> Review and comments are very welcome. Preferable so
in
Section 5.1.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Fri, May 13, 2011 at 6:29 PM, Alan DeKok al...@deployingradius.com wrote:
The reason for the name change is that there have been questions
raised about whether this document should be left as EAP-FASTv2, or
whether it should request allocation of a new EAP type.
Since the document name
On Fri, Sep 3, 2010 at 11:51 PM, RFC Errata System
rfc-edi...@rfc-editor.org wrote:
http://www.rfc-editor.org/errata_search.php?rfc=5216eid=2510
Section: 3.1
Please note that similar language exists in other places of the
document, too (2.1.5 and 3.2) and the same comments should apply to
to indicate that this is
indeed the case (just note that EAP-FAST-GTC is not allowed in
unauthenticated/anonymous provisioning, but it is allowed in
server-authenticated provisioning).
--
Jouni MalinenPGP id EFC895FA
with the
way this is done in PEAPv0+cryptobinding and the order used in deployed
EAP-FAST implementations would thus not match with the EAP-MSCHAPv2
definition for MSK derivation.
--
Jouni MalinenPGP id EFC895FA
On Sat, Dec 20, 2008 at 06:05:41PM +0530, yogendra pal wrote:
I hope Jouni can test the case-2, case-3, case-4 with his
implementation for further verification.
I can confirm that I get the same key derivation results (IK', CK',
K_encr, K_aut, K_re, MSK, EMSK) for these cases.
--
Jouni
:
c2ad95db83cfbd1b886d3c91f355d321903107f9e77377671d1b2772ed1c475c36b92a1d07dca082962b83ac7d6cd70ef024d4cf2f4ce97716e15f9fa4fb934c
EMSK:
229a30ae81329be2516da975335a7d95956f8a9524548845b97a89778e18f98bd901cb33fa3389add3f29eb1b671af338744a8b9219715fbb96f8a20d724bd88
--
Jouni MalinenPGP id EFC895FA
only for EAP-AKA' and only
when using AT_KDF Key Derivation Function value 1.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
worth doing, I
won't be against the text changes you propose here. I think the protocol
would work either way and at this point, my main preference is just to
get EAP-GPSK published rather sooner than later ;-).
--
Jouni MalinenPGP id EFC895FA
don't see any particular
need for this to be 32 octets, but that would be consistent with other
uses of GKDF and anyway, this matches with the KS-octet 'zero' used in
Ch. 4.
--
Jouni MalinenPGP id EFC895FA
this as one of the best ways to
evaluate protocol designs and specifications and more or less mandatory
part of standard development.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https
authentication). In addition, both the R0KH-ID
(NAS-Identifier) and R1KH-ID (authenticator MAC address) are mixed in
into the key derivation after the EAP authentication.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing
. This would require 16-octet key
(Y), but the values passed into GKDF in 6.1.3 are of 1 octet (0x00) and
32 octets (MK). How is this supposed to work?
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu
HMAC-SHA256 -based KDF. Since the 802.11r KDF construction is also
claimed to be compliant to NIST recommendations, it is somewhat odd to
see EAP-GPSK take the other direction with the reasoning that this came
from NIST..
--
Jouni MalinenPGP id EFC895FA
of causing extra issues
to vendors who work with EAP implementation and just rely on external
TLS libraries..
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman
implementation with maintenance and
memory/flash footprint concerns.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
update for 14. References to move this into the
normative list)
4. Key Derivation
- s/needs to instantiated/needs to be instantiated/
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
those
transmitted in GPSK-2.
* There's something wrong with this sentence..
s/whose //
s/do match/that do not match/
9.4. Replay Protection
- typo: s/RAND_P/RAND_Client/
9.8. Denial of Service Resistance
- typo: s/RAND_S/RAND_Server/
--
Jouni Malinen
session specific information? Is that 0x0C just a typo? EAP-TLS uses EAP
type 13 (0x0D) and I would have expected to see 0x0D || ... here.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https
implementation, but expanded types have been tested with
other implementations.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
-CMAC..
Thanks for your review. Please find the updated draft at:
http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/
Thanks. The changes looked fine ot me.
--
Jouni MalinenPGP id EFC895FA
___
Emu
/snapshots/). For
testing, I'm using hostapd as a RADIUS server with EAP-GPSK server and
eapol_test (test tool from wpa_supplicant) as a EAP-GPSK peer and IEEE
802.1X authenticator/RADIUS client. EAP-GPSK parts are in
hostapd/eap_gpsk.c and wpa_supplicant/eap_gpsk*.[ch].
--
Jouni Malinen
38 matches
Mail list logo
