2119 key word looks a bit too
strong in my opinion. That may cause a developer to come up with an option
toggle etc. that is unnecessary just to satisfy RECOMMENDED.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
en it's used with cryptographic
calculations by the peer or the server. Even if the same value were safe,
it would be harder to call it a nonce in that case.
[cut a good summary of TEAPv1 document history]
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
ttribute with both the EMSK and MSK
Compound MAC fields zeroed out. Nonce is used untouched.
If flip a bit in received or sent nonce right when it's packed into a
message, I see, for example, in eapol_test this before failure:
EAP-TEAP: MSK Compound MAC did not match
Or
attribute naming, free position in attribute list,
not using duplicates and separate documents would ease implementation.
These should be easy to update too. The length of new attributes may be a
bigger problem. This would be a good point to raise in tomorrow's meeting?
Thanks,
Hei
authenticated
version of EAP-TLS?
- Do all these need to be synchronisation to avoid too many documents?
Looking forward to your presentation,
Heikki
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
lease send signs of support to the mailing list if you feel these
> drafts are worth the WG's time.
>
I support adoption of the both drafts.
There are some comments I have from (I work on the server side)
implementor's perspective which I'll get back separately should the draft
under consideration for adoption.
>
> Please respond by April 23, 2025.
>
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
On Thu, 20 Mar 2025 at 05:51, Alan DeKok wrote:
> On Mar 19, 2025, at 7:14 PM, Heikki Vatiainen
> wrote:
>
> > Giving up on using EMSK does sound like giving up something important,
> but is it so? Can someone tell what's the importance of EMSK being used in
>
ports EMSK and PAP. For us it's fine to go to any direction with regard
to how EMSK is, or is not, used.
Thanks,
Heikki
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
at user from tracking what networks or services a
> specific client is using."
>
>
>
> Please post any feedback you have about this proposed item.
>
>
>
> Thanks,
>
>
>
> Joe
> ___
> Emu mailing list -- emu@ietf.org
2 to mandate use of EMSK when
the method's specification supports it. The RFC talks about inner method
supporting EMSK, but that's unclear. Does it mean the specification's
support of EMSK or simply what the particular implementation has decided to
support.
Would it be OK and by the RFC t
-Hoc Wireless Networks", 1999.
Frank Stajano has made the paper available at:
https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-duckling.pdf
Should the document link to the paper?
Second, the new section '1.4. Supported EAP Methods' has a typo:
'suported&
On Fri, 4 Oct 2024 at 23:53, Alan DeKok wrote:
> On Oct 4, 2024, at 3:18 PM, Heikki Vatiainen
> wrote:
> > I was thinking something like this:
> > - EAP client has credentials for EAP methodX that are about expire;
> provisioning is required
> > - The client att
On Fri, 4 Oct 2024 at 20:30, Alan DeKok wrote:
> On Oct 4, 2024, at 12:46 PM, Heikki Vatiainen
> wrote:
>
> > That is, switching to a non-provisioning fully credentialed
> authentication with a NAK shouldn't be done when the initial
> EAP-Response/Identity contain
oning method, it then replies with an
> EAP method which matches the one proposed by the supplicant in the
> NAI. The EAP process then proceeds as per the EAP state machine
> outlined in {{RFC3748}}.
>
> ...
>
>
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
ere's more about NAKs on the list in messages discussing
draft-ietf-emu-bootstrapped-tls-06 comments, including comments Alan is
considering for this draft.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
of section 4 ends with '... , and _it not used_ for any
subsequent network access.'
Suggested change: s/it/is/
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
"
and "tls-pok-...@ttls.eap.arpa" would allow the server to immediately
select the client's desired EAP method.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
Your input on this document would be very much appreciated.
>
> -Peter and Joe
>
>
> ___
> Emu mailing list -- emu@ietf.org
> To unsubscribe send an email to emu-le...@ietf.org
>
--
Heikki Vatiainen
h...@radiatorsoftware.com
_
; _______
> Emu mailing list -- emu@ietf.org
> To unsubscribe send an email to emu-le...@ietf.org
>
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
ve being said, using SIM based EAPs with tunnelling EAP methods
is likely rare. I have never seen them used in practice. However, real
implementations exist that allow doing this. Maybe, for example, IOT
experts could say if they see use for TEAP/PEAP/EAP-TTLS used for
tunnelling SIM based EAPs?
--
Heik
://en.wikipedia.org/wiki/Extensible_Authentication_Protocol#EAP-TLS
I haven't seen any use of "WFA-UNAUTH-TLS", though.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ur position.
>
I have read the draft and support its adoption.
I will reply with comments separately and help with reviewing the draft
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
nters if they're notified about
what to look out for, if needed.
[1] https://en.wikipedia.org/wiki/Billion_laughs_attack
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
'll push a pull request to update the examples C.11. and C.13. (EAP-TLS
like exchange) so that the both show client certificate. There's also an
extra Intermediate-Result in C.13.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu
On Mon, 28 Aug 2023 at 21:09, Alexander Clouter
wrote:
> On Mon, 28 Aug 2023, at 15:43, Heikki Vatiainen wrote:
> >
> >> If an inner method supports export of an Extended Master Session Key
> >> (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in
>
ilarly to inner authentication methods. Would it be possible to clarify
the type of PKCS exchange (inner method, something else). Because it
appears to be an inner method, also add text to section 3.11. where the use
of the two TLV types is required.
--
Heikki Vatiainen
h...@radia
On Mon, 28 Aug 2023 at 13:25, Alexander Clouter
wrote:
> On Sun, 27 Aug 2023, at 18:16, Heikki Vatiainen wrote:
>
> > https://github.com/emu-wg/rfc7170bis/pull/27
> >
> > Alex, please comment. I've discussed this with a colleague and we think
> the
> > c
//github.com/emu-wg/rfc7170bis/pull/27
Alex, please comment. I've discussed this with a colleague and we think the
current draft would break compatibility with the existing implementations.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing
would suffice when some of the term
is used. There are of course cases when a specific term, such as 'EAP
method', is needed.
Heikki
> Eliot
>
> On 25.08.23 21:27, Alan DeKok wrote:
> > On Aug 25, 2023, at 10:07 AM, Heikki Vatiainen
> wrote:
> >> I have one sma
On Sat, 26 Aug 2023 at 21:13, Michael Richardson
wrote:
>
> Heikki Vatiainen wrote:
> > Test with Windows 11 and eapol_test - EAP-TLS followed by EAP-MSCHAPv2
>
> Are you saying that Windows 11 also has implemented (accessible via
> "insider
> program" only)?
s
is no longer a problem, but with TLS 1.2 client certificate is not
encrypted.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
s forbidden. A simpler way to do this
is a reminder that EAP servers can turn off resumption in the part of the
configuration that processes inner EAP-TLS.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
er program version and eapol_test (wpa_supplicant) is
directly from git for EAP-FAST-MSCHAPv2 and other updates that were added
since the latest wpa_supplicant release 2.10.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
request that updates the 'EAP authentication' part to
say 'inner authentication' so that in case there's an inner method (perhaps
provisioning?) that's not EAP but that can provide keying material, the
text won't be too restrictive.
t TLS_RSA_WITH_AES_128_CBC_SHA is a
mandatory ciphersuite and then refer to section 3.2. for more information.
Section 3.2. has the updated information but A.4. and A.5. still have old
RFC 7170 ciphersuite.
Example flows C.11., C.12. and C.13. are not named.
-
t; is updated, it would make the text
more consistent with the other parts of the draft and allow EAP-TLS -like
behaviour to work with eapol_test (wpa_supplicant).
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Sat, 19 Aug 2023 at 00:26, Michael Richardson wrote:
> Heikki Vatiainen wrote:
> > Should it be noted that this provisioning method is only available with
> > TLS 1.2 and earlier because the method requires anonymous ciphersuites?
> > It confirms to the re
On Fri, 18 Aug 2023 at 19:57, Alan DeKok wrote:
> On Aug 18, 2023, at 12:47 PM, Heikki Vatiainen
> wrote:
> > Should it be noted that this provisioning method is only available
> > with TLS 1.2 and earlier because the method requires anonymous
> > ciphersuites? It con
hod is only available
with TLS 1.2 and earlier because the method requires anonymous
ciphersuites? It confirms to the reader that this is the intended
case.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
put the device back to the
(re)-provisioning VLAN.
However, I think this is outside of scope of this draft/RFC and is
something that the device/application and server software vendor must take
care of. The new text in the draft is enough now.
--
Heikki Vatiainen
h...@radiatorsoftware.co
hort while. Is this a problem when the device is
malicious? Can a belt-and-suspenders method be to return a 'deny all'
packet filter with Access-Request until the CoA or disconnect takes action?
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
be for a future revision?
To summarise: Using an authentication protocol for provisioning appears to
create interesting scenarios to consider. I hope the above points are found
useful. More are likely found when working on implementing the provisioning
parts, which we haven't done yet.
-
d provide both EAP peer identity
hiding and shorter message than what's traditionally used (TLSv1.2 or
earlier with full CA chains).
EAP-pwd was also mentioned and while it doesn't provide EAP peer identity
hiding, it authenticates with 4 short request-response pairs (1 for EAP
Identity and 3
ertificates (trust anchors) would need to be know be the other TLS
endpoint if this is done. This is yet another good reason to use TLSv1.3
even though TLSv1.2 and earlier still remain in wide use with TLS based EAP
methods.
--
Heikki Vatiainen
h...@radiatorsoftware.com
_
hanges, if they'd be needed for Wi-Fi. I
haven't checked if any of the 802.* specifications already define something
like this that's already used with wired and wireless LANs.
How common are the link layer protocols that use MSK in such a way that
forward security is not achie
Type = 0x0D
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
Type, 128)
[cut some other definitions]
MSK = Key_Material(0, 63)
EMSK = Key_Material(64, 127)
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
rom the two keys as follows:
MSK = MasterReceiveKey + MasterSendKey + 32 bytes zeroes (padding)
But it doesn't follow with EMSK definition.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Fri, 24 Mar 2023 at 20:42, Alexander Clouter
wrote:
> On Fri, 24 Mar 2023, at 17:51, Heikki Vatiainen wrote:
>
> "A new contestant has entered the arena..."
>
Indeed. It's about the time we implement this too.
> The implementation was done based on the
has different EMSK
capability than the previous method, the compound chaining jumps to the
different tracking. There's no compound calculation for the full chain.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
nd I suspect there will be a lot more active interest.
>
> Just my thoughts.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
; Internet-Drafts are also available by rsync at
> > rsync.ietf.org::internet-drafts
> >
> >
> > _______
> > 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
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Fri, 27 Jan 2023 at 13:30, Eliot Lear wrote:
>> On 27.01.23 12:17, Heikki Vatiainen wrote:
>>
>> For example, an OTP system could do this:
>> - Start authentication with username + static password; if ok then
>> - Server prompts for the next method: Choose 1 fo
the last
Basic-Password-Auth-Resp TLV. If the server isn't careful, Bob may end
up in authentication and other logs and any possible authorisation may
be done as Bob.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
s://www.rfc-editor.org/rfc/rfc7155.html#section-4.3.1
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
port deleting the PAC related parts. That would make it
clearer which parts of TEAP remain in active use.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
it?
In any case, it seems that PAC-Acknowledge does not cause a problem where
the peer and server have a different understanding of which type PAC was
acknowledged: It's always the Tunnel PAC.
--
Heikki Vatiainen
h...@radiatorsoftware.com
handshake' is based on TLS session ticket or TLS session id.
That is, when TLS state kept on client or server side is used to start an
initial (or renegotiated) TLS handshake. This hansdhake may succeed or fail.
'resumed session' a session that is re-established after a successful
'abbreviated handshake'.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Tue, 10 Jan 2023 at 19:26, Alan DeKok wrote:
> On Jan 9, 2023, at 5:17 PM, Heikki Vatiainen
> wrote:
> Is it known how widely Unauthenticated mode is used? Can this be left as
> it is for this round of TEAP update?
>
> Implementors please speak up. :)
>
> I th
s Server Unauthenticated
Provisioning Mode to TEAP.
> No idea what to do here.
>
Is it known how widely Unauthenticated mode is used? Can this be left as it
is for this round of TEAP update?
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t;
> This aligns nicely with the 'label | seed' definition seen earlier for
> PRF/P_ too.
> Not to sure why the '0x00' is still needed, but maybe it was to stop
> people messing up the seed with a NULL/empty value rather than a single NUL
> byte or vice versa;
nting it. In other words, maybe this had
started before the 5G privacy protection method was published.
Thanks,
Heikki
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
s://datatracker.ietf.org/doc/draft-dekok-emu-rfc7170bis/
> 2) https://github.com/alandekok/rfc7170-bis.git
>
>
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
--
Heikki Vatiainen
h...@radiatorso
eting, but I've looked into the
WBA specification. What it does is that it tells how to encrypt the
permanent identity hiding the IMSI from eavesdropper.
Thanks,
Heikki
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ing this
would match the previous paragraph.
Other minor suggestions and fixes
+
EAP-Response/Identity could be used as the common notation for the two uses
in section 3.1.
Section 6.1 has '... do not provided ...'. Remove 'ed'.
Section 7 has a typo: tje
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
P-FAST, please let me know. A quick
look shows that it may need something that's not available in its git
repository yet.
Are there any other clients that could be used for testing?
Thanks,
Heikki
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
E
7;.
6.1 Protected Success and Failure indicators
++
Paragraph 5 says '... TTLS with inner PAP or CHAP.'. I'd change the inner
protocols to 'PAP, CHAP or MS-CHAP'.
Paragraph 7 says '... do not provided protected ...'. Change 'provided' to
'provide'.
Paragraph 7 also suggests replacements for PAP and CHAP to ensure protected
indicators can be used. A replacement for MS-CHAP could be EAP-MSCHAP-V2 or
possibly EAP-MD5?
8. References
+++
[PEAP-MPPE], [PEAP-PRF] and [PEAP-TK] point to different parts of [MSPEAP].
It might be useful to clarify that this is the case in order to minimise
the problem with broken links.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
d, not at least recently, and now when TLS 1.3 forces
changes to implementations it would also provide a good chance to let go of
features that are not needed any longer.
Thanks,
Heikki
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@
rosoft maintains says very little about client
certificates, basically just allowing them to be requested by the server. I
don't see anything that changes the use of inner tunnel authentication by
the use of them and now the draft confirms this.
Thanks,
He
ple, wpa_supplicant recognises this and logs 'EAP-TTLS: ACKing
EAP-TLS Commitment Message' during EAP-TTLS resumption.
Thanks,
Heikki
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t allow for
>the server certificate to change without out-of-band validation of
>the certificate and is therefore not suitable for many deployments
>including ones where multiple EAP servers are deployed for high
>availability.
>
>
--
Heikki Vatiainen
h...@radia
discussion next but
I thought I'd start by replying to Joe's call before the May 20th deadline.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
72 matches
Mail list logo
