ow one can
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
es and as such, would 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 justif
EAP request
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
rpret 64 to be
the "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
e was 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
with empty seed "" 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)
et option 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
the
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 that
oving ahead? I'm
copy-pasting that errata information below for easier access for
reviewing/commenting:
Status: Reported
Type: Technical
Reported By: Jouni Malinen
Date Reported: 2017-05-07
Section Appendix A says:
EAP-AKA
EAP-AKA is defined in [RFC4187]. The EAP-AKA Session
LS
Exporter Label Registry. This label is used in derivation as defined 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 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 (individual draft) cur
On Fri, Sep 3, 2010 at 11:51 PM, RFC Errata System
wrote:
> http://www.rfc-editor.org/errata_search.php?rfc=5216&eid=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
them.
> Original Text
> --
i.e., to get the TLS Message Length added into them (both
for all frames and also with the difference in Phase 1 vs. Phase 2 as
described above). Obviously, this is not really a desired situation
since it takes considerable amount of time to come up with all the
needed workarounds to interop
ion rules as was done with
EAP-PEAP cryptobinding and EAP-FAST.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
n in
draft-cam-winget-eap-fast-provisioning and for the goal of describing a
deployed protocol and allowing vendors to implement it in interoperable
way, it is useful to get this described somewhere and this draft looks
like the best place to do so at this point.
--
Jouni Malinen
tches with the order I described above
and including this note in the draft would indeed be a helpful
clarification.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
e MS-CHAPv2 key derivation, I think I ended up agreeing 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 Malinen
ion after PAC has been previously provisioned). Anyway, it is
probably clearer to just specify that EAP-FAST-GTC is used in all cases
inside EAP-FAST tunnel since the draft seems to indicate that this is
indeed the case (just note that EAP-FAST-GTC is not allowed in
unauthenticated/anonymous prov
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 c
Identity: "4ec9a95ae5b8deaceb0d8"
COUNTER: 1
NONCE_S: 2a949450a95d31eaa2a4f6ea9faaa56c
MK = PRF'(K_re,"EAP-AKA' re-auth"|Identity|counter|NONCE_S)
MSK:
c2ad95db83cfbd1b886d3c91f355d321903107f9e77377671d1b2772ed1c475c36b92a1d07dca082962b83ac7d6cd70ef024d4cf2f4ce97716e15f9fa4fb934c
EMSK:
229a30ae81329be2516da97
lue ..") should be modified to apply 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
it was merged into the main standard, i.e., this should
now be IEEE Std 802.11-2007 instead of IEEE 802.11i. Neither of these
references were listed in 16.1 or 16.2. Should this be added to 16.2?
--
Jouni MalinenPG
octets vs. 70 octets)? I would rather optimize the packet
sizes be removing 32 octets from GPSK-3..
Anyway, if there was consensus on this being something worth doing, I
won't be against the text changes you propose here. I think the protocol
would work eith
the RAND_Server, or the CSuite_Sel fields do not match
those transmitted in GPSK-2. An EAP peer MUST silently discard any
packet whose MAC fails.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
HMAC-SHA256 could use any key length. I 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 Malinen
, or even
suitability for anything ;-). I see 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
___
r registry
setup:
o 0x00 : Reserved
o 0x01 : Protected Results Indication
The PData/Specifier field is 24 bits long and all other values are
available via IANA registration."
s/0x00/0x/
s/0x01/0x0001/
s/24 bits/16 bits/
--
Jouni Malinen
peer during
association (before EAP 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
___
ite #1 is used. 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 mai
can agree
with the second. Anyway, I certainly support the idea of using something
existing as a starting point whether the end result ends up using the
same method number and version or not.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
get interesting if new extensions are added and if some of the
implementations are not exactly prepared for this.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
re using
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
DFK output is not
mixed into the Hash-Function input (should it?), this does not change
the derived keys, but is just a cleanup and small speed improvement
(drop one SHA256 operation).
--
Jouni MalinenPGP id EFC895FA
__
plement them, but until that, there is a risk of causing extra issues
to vendors who work with EAP implementation and just rely on external
TLS libraries..
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing
entation
would need to bring in another TLS 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
and matching 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.
On Mon, Jan 08, 2007 at 07:39:06PM -0800, Jouni Malinen wrote:
> > Title : EAP Generalized Pre-Shared Key (EAP-GPSK)
> > Author(s) : C. Clancy, H. Tschofenig
> > Filename: draft-ietf-emu-eap-gpsk-02.txt
>
> Some comments..
And one
client MUST silently discard any packet containing
whose RAND_Client, RAND_Server, or CSuite_Sel fields do match 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:
and some
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.o
ested EMSK derivation
with another 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
oded as 6-octet
arrays").
In addition, CSuite_SEL in 6.1.3 and 6.2.3 should have been CSuite_Sel
to remain consistent with the spelling in rest of the draft.
--
Jouni MalinenPGP id EFC895FA
___
Emu maili
Ciphersuite 2? Why bother generating a sequence of 32
octets of 0x00 for HMAC-SHA256 key (which could as well be zero-length).
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
ze - 1) / size ) which could be
written as n = int( (X - 1) / size ) + 1.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
CCM
had been used instead of EAX since I first had to figure out what
exactly EAX is doing whereas I was already familiar with CCM because of
IEEE 802.11i background.
--
Jouni MalinenPGP id EFC895FA
___
Emu
easier to report somewhat meaningful
report to the user. Now, I can just report "possible PSK mismatch or
server unreachable" after a (potentially long) timeout if GPSK-2 with
incorrect MAC is silently ignored. Would there be any mechanism to make
this report more information
lementation (http://hostap.epitest.fi/releases/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_sup
cted result indication for the
failure case. Peer would reply with GPSK-ERROR and server would finish
the negotiation with EAP-Failure.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
ield before the variable length ID_Server and
ID_Client would resolve this by making it explicit where the boundary
between ID_Client and ID_Server is.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
E
o SEC function as Y..
> We could also write "... input should be the data following OP-Code in
> the message." It might be easier.
Yes.
> Do I miss the issue here?
Maybe. My main point was that SEC is a defined function and it does
he ciphersuite. The
first three octets are the vendor-specific OID, and the last three
octets are vendor assigned.
7.2: s/indiciates/indicates/
7.3:
s/256-bit RAND_Server/32-octet RAND_Server/ in Figure 7 (GPSK-1)
(to be consistent with other figures)
s/PD_Payload_1/PD_Payload_2/ i
58 matches
Mail list logo
