andate TLS 1.3 now, but
perhaps we will mandate it one day. I just don't see any of the current
arguments against mandating TLS 1.3 changing in 10 or even 20 years.
Alan DeKok.
___
Uta mailing list -- uta@ietf.org
To unsubscribe send an email to uta-le...@ietf.org
Thanks. I will address these comments, and the updated text will be
available in the next revision of the document.
> On Apr 6, 2025, at 8:04 AM, Yingzhen Qu via Datatracker
> wrote:
>
> Document: draft-ietf-bfd-secure-sequence-numbers
> Title: Meticulous Keyed ISAAC for BFD Authentication
erywhere _else_ is fine. And if that's true, what is the plan for mandating
TLS 1.3, and when we will put that plan into effect.
If those other issues can't be addressed, then by the same token, there's no
need to address the "don't mandate TLS 1.3" argumen
erywhere _else_ is fine. And if that's true, what is the plan for mandating
TLS 1.3, and when we will put that plan into effect.
If those other issues can't be addressed, then by the same token, there's no
need to address the "don't mandate TLS 1.3" argument.
Al
Thanks. I will address these comments, and the updated text will be
available in the next revision of the document.
> On Mar 20, 2025, at 7:22 AM, Ben Niven-Jenkins via Datatracker
> wrote:
>
> Reviewer: Ben Niven-Jenkins
> Review result: Ready
>
> Hello,
>
> I have been selected as the
andate TLS 1.3 now, but
perhaps we will mandate it one day. I just don't see any of the current
arguments against mandating TLS 1.3 changing in 10 or even 20 years.
Alan DeKok.
___
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
rdless authentication
> schemes such as the CTAP2 version of FIDO2."
>
> We could make some modifications to this if necessary. We also have some
> items for provisioning.
>
> Alan DeKok.
>
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
m/emu-wg/charter/pull/4/files and indicate if you support
> the charter revision. You may comment on the charter by responding to this
> thread or commenting on the pull request.
The charter updates describe one privacy-preserving proposal. Given the
EAP-FIDO draft, should we allow for
ticator are discussed in
>> [draft-ietf-radext-deprecating-radius].
>
> Is it correct that we should add this sentence to the end of Section 5.2 as
> its own paragraph, and add draft-ietf-radext-deprecating-radius as an
> informative reference, with anchor &q
ps a different question is "Do we want to avoid mandating TLS 1.3 for
everyone *else* in the world, simply because one use-case refuses to upgrade?"
My answer to that would be "no". The benefit gained everywhere else by
mandating TLS 1.3 likely outweighs the minor problems of
ps a different question is "Do we want to avoid mandating TLS 1.3 for
everyone *else* in the world, simply because one use-case refuses to upgrade?"
My answer to that would be "no". The benefit gained everywhere else by
mandating TLS 1.3 likely outweighs the minor problems o
On Apr 3, 2025, at 6:33 PM, rfc-edi...@rfc-editor.org wrote:
> 1)
This is fine.
> 2)
This is fine.
> 3)
I will do that shortly.
> 4)
The changes are fine.
>
> 8)
The "no ALPN" and "1.0" are used only in the row / column headings, not in
the table entries. The intent is to
If EMSK is not essential, TEAPv2 could then be the version that clearly
> defines how EMSK is used.
Yes.
Even if EMSK is essential, it's worth documenting TEAPv1. And we can't
change TEAPv1 without declaring that existing deployments are not compliant.
So we pretty much have to publ
so note that TEAP doesn't define implicit challenges for EAP-MSCHAPv2,
while TTLS does. I suspect that it would be a good idea to do that, too.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
> 1) declare the MSFT behaviour TEAPv0. Crypto-Binding contains only the
>> MSK Compound MAC, the EMSK Compound MAC is always zero
>
> Is version 0 even valid?
> What do these old versions declare as their version?
Sorry, TEAPv1.
So TEAPv1 is "MSK Compoun
be required to upgrade to TEAPv2, but people who do upgrade will
be able to use the EMSK Compound MAC.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
ive the EMSK Compound MAC. Write it down.
Test it with implementations.
3) issue TEAPv1 which defines the EMSK Compound MAC, and uses it in the
Crypto-Binding TLV.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
+1
> On Feb 27, 2025, at 2:09 PM, Peter Yee wrote:
>
> For the record, I think that charter statement is fine. The sole change I
> would suggest is s/user and/user, and/ . It’s an awfully long, uninterrupted
> sentence otherwise.
> -Peter
> On 2/27/25, 10:13
spect the answer is that everyone uses the MSK Compound-MAC, and ignores
the EMSK Compound-MAC. If so, it needs to be documented.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
to get the final draft
before the cutoff for IETF 122.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
of the EAP Method Update (EMU) WG of the IETF.
>
> Title: Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Author: Alan DeKok
> Name:draft-ietf-emu-rfc7170bis-21.txt
> Pages: 120
> Dates: 2025-02-06
>
> Abstract:
>
> This docum
ng each individual change as a
separate git commit. The hope is that the resulting series of commits will be
easy to understand and to review.
So I had hoped that 7170bis was done. But in the interest of improving the
document to increase interoperability, it looks like it needs
any any" - remove duplicate "any"
Done.
> I find the following sentences a bit weird. I think it can just be removed:
>
> We now discuss the NAI format in more detail. We first discuss
> the eap.arpa realm, and second the use and purpose of the
> u
On Jan 29, 2025, at 10:24 AM, John Chittum <2096...@bugs.launchpad.net> wrote:
> When is 3.2.7 likely to land? Moving forward to 3.2.7 makes sense. in
> the short term, I can land my removal of the `wtmpdb` dependency, and
> note that `radlast` won't function. that's true in 24.10 now. I'm
> slight
We're going to put `radlast` behind a `configure` flag in 3.2.7. That
way the packages can be built without it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2096611
Title:
Revert Upstream dependen
TBH I don't know if anyone is still using the radlast / radutmp stuff.
It might be OK to just delete that functionality entirely.
For compatibility, perhaps move radlast and anything else it needs into
a freeradius-last package? That way people who want it can still use
it, and the main set of us
y works, sort of". And then immediately publish TEAPv2, which would
more clearly define the cryptographic derivations.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
On Jan 7, 2025, at 10:55 AM, internet-dra...@ietf.org wrote:
>
> Internet-Draft draft-ietf-emu-rfc7170bis-20.txt is now available. It is a work
> item of the EAP Method Update (EMU) WG of the IETF.
>
> Title: Tunnel Extensible Authentication Protocol (TEAP) Version 1
>
I do not know of any IPR for this document. I'm OK with publishing it.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
pport keys generation. However such a sentence could be
> off-putting implementers.
I'll clarify. Jouni also pointed out that because EAP-TLS works, it is
highly likely that other EAP types work so long as they derive MSK and EMSK.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
heir implementation
matches this behaviour, then we're good to go. I fully expect this to be the
case, because all implementations appear to be interoperable. But it would be
good to get explicit feedback from the implementors that this is the case.
Alan DeKok.
the challenge and the issued token to
> send to the server to verify.
>
>
> Some initial comments on the document
> - I dont think EAP-PPT generates key material, it requires the tunnel method
> to generate key material as the pr
t is the official position of the
IETF that vendors shouldn't claim compliance with an Internet Draft, then
perhaps the IETF should ensure that useful and implemented Internet Drafts are
(a) published as an RFC, or (b) removed from public presence.
Alan DeKok.
_
ld have been,
I'll try to find some time.
Alan DeKok.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
re, it's a very good idea to recommendation that
implementations support it, with a caveat that adminstrators do not enable it
in production.
Alan DeKok.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
connection. That can easily be
done, and is really just an implementation detail.
Perhaps CoAP has issues with one CoAP client doing multiple authentications
at the same time. But that's a CoAP issue, and has nothing to do with EAP.
Alan DeKok.
__
s must be
> considered.
I still don't understand this. The CA doesn't have to be online. The client
has to have a copy of the CAs public cert. Perhaps any OCSP system has to be
online.
But I don't think anything in RFC 5280 requires t
ward FIDO traffic to my web server. But your EAP
server can't forward traffic to my web server.
So is this an attack we care about? It may be sufficient to say "attacks
within your organization are possible, but the solution to that is to police
y
CA is unreachable. The TACACS+ TLS
server has to be configured with the CA cert, and all intermediate certs. The
client should ideally also be configured with the CA cert. There's no need to
contact the CA, the CA cert is just a file
o binding issues aren't relevant. i.e. the client can just use the
servers challenge.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
phic binding. That exchange could stay inside of EAP-FIDO, and
wouldn't have to affect any FIDO exchanges.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
#x27;t support them
MUST be safe.
The second priority is to ensure that the provisioning workflows will always
work, and do something useful.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
> tls-pok-dpp.eap.arpa.
> I don't think that there are any options other than anonymous@ or
> empty-string.
As per Heikki's comment, it should be tls-pok-...@method.eap.arpa. i.e.
tls-pok-...@teap.eap.arp
Alan DeKok.
___
Emu mai
had determined that it couldn't start
> provisioning at this time. Instead of being helpful, the server should be
> clear that this authentication can not continue and must fail.
If the server can't authenticate, it just sends EAP Failure.
Alan DeKok.
_
bout
> eap.arpa probably shouldn't allow this to happen.
Agreed.
> There'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.
I'll try to publish a new draft early next week.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
Perhaps:
# EAP Peers
An EAP session begins with the peer receiving an initial
EAP-Request/Identity message. An EAP peer supporting this
specification MUST examining the identity to see if it uses the eap.arpa
realm. If not, the EAP peer MUST process the request normally.
The EAP peer MUST ch
+1 to all of this.
I'll add some notes to the eap.arpa document to raise issues brought up here:
* EAP type selection can be done by examining the provisioning NAI
* NAKs should be handled specially for provisioning NAIs
* There is no method to NAK a particular kind of provisioning.
e.g.
+1
> On Sep 24, 2024, at 5:39 PM, Eliot Lear wrote:
>
> Signed PGP part
> I think this draft ready to go as well. I know that Owen has prototyped it,
> and I'd like to see it advance.
>
> Eliot
>
> On 23.09.2024 21:01, Peter Yee wrote:
>> Draft-ietf-emu-bootstrapped-tls has two days left o
dated their RADIUS implementation in 25
years.
There is a work-around for the checkpoint issue, so additional configuration
changes for FreeRADIUS aren't a good idea.
Alan DeKok.
signature.asc
Description: Message signed with OpenPGP
The patch looks good to me, thanks.
> On Aug 20, 2024, at 9:42 PM, Santiago Ruano Rincón
> wrote:
>
> Hi!
>
> El 20/08/24 a las 15:14, Santiago Ruano Rincón escribió:
>> Hello Herwin,
>>
>> Thanks a lot for testing the proposed packages!
>>
>> El 15/08/24 a las 17:04, Herwin Weststrate esc
EAP Method Update (EMU) WG of the IETF.
>
> Title: The eap.arpa domain and EAP provisioning
> Author: Alan DeKok
> Name:draft-ietf-emu-eap-arpa-02.txt
> Pages: 18
> Dates: 2024-08-12
>
> Abstract:
>
> This document defines the eap.arpa dom
o note that the username portion defines
the _type_ of provisioning being done. Different usernames are different kinds
of provisioning. And empty usernames are different from non-empty usernames.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
On May 10, 2024, at 6:48 PM, Haoyu Song via Datatracker
wrote:
>
> Reviewer: Haoyu Song
> Review result: Ready with Nits
>
> I’m the assigned INTDIR reviewer for this document. This document defines the
> Tunnel Extensible Authentication Protocol V1 which obsoletes RFC7010.
>
> I couldn’t find
rk
> item of the EAP Method Update (EMU) WG of the IETF.
>
> Title: The eap.arpa domain and EAP provisioning
> Author: Alan DeKok
> Name:draft-ietf-emu-eap-arpa-01.txt
> Pages: 17
> Dates: 2024-07-30
>
> Abstract:
>
> This document defines
anges per sessions, the use of
resumption will tie two sessions together
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
th it".
As these recent attacks show, there is a need for increased security at the
edge. The question I have is how we increase security, not whether we want
increased security.
Alan DeKok.
___
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org
On Jul 16, 2024, at 4:14 PM, Seth Arnold <2073...@bugs.launchpad.net> wrote:
> When playing with the shell script I thought I noticed patterns in the last
> character of the output so I investigated further to make sure that these are
> actually emitting roughly what we expect:
Due to the way
TBH the simplest thing to do is just to drop the rad secret program.
It not used for anything, and is just a helper script.
> On Jul 16, 2024, at 1:35 PM, Andreas Hasenack <2073...@bugs.launchpad.net>
> wrote:
>
> The freeradius update to 3.2.5 enabled a new binary and two new modules,
> as par
ot;, and not EAP or RADIUS specific.
Alan DeKok.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
might be late 2024
before this work starts.
Alan DeKok.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
ementations can tweak their transport layer, and change
almost nothing else. So it's closer to a transport profile than a brand new
protocol, packet encoding, state machine, etc.
> Q_ED_1:
>
> I think the Abstract is too long. Any explanations, clarifications and details
> shoul
e draft, and the lack of experience with
implementations, I'd suggest that "Experimental" is more appropriate.
Alan DeKok.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
date this one.
> Section 6
>
> - "The Auth Type field MUST be set to TBD1 (Meticulous Keyed ISAAC)". There
> is no IANA registration for just ISAAC anymore, so it will be one of the 2
> auth types from optimizing-authentication?
It may be best to update the IANA section of this document to define
Meticulous Keyed ISAAC. That way everything is in one document.
Alan DeKok.
(removing secdir)
The security analysis is perhaps simplified a bit by understanding the
limited use-case for BFD. From the introduction to RFC 5880:
The goal of Bidirectional Forwarding Detection (BFD) is to provide
low-overhead, short-duration detection of failures in the path
be
m of the EAP Method Update (EMU) WG of the IETF.
>
> Title: Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Author: Alan DeKok
> Name:draft-ietf-emu-rfc7170bis-19.txt
> Pages: 110
> Dates: 2024-06-07
>
> Abstract:
>
> This document de
I'm not aware of any IPR on the drafts.
> On Jun 3, 2024, at 9:29 PM, Reshad Rahman
> wrote:
>
> BFD WG,
>
> This email starts a 2 week Working Group Last Call for the following 3
> documents, please review and provide comments by end of day on June 17th.
> Feedback such as "I believe the d
ot; list for too long.
> Alas, I had no opportunity to check whether all nits from
> https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-17.txt
> are false positive.
I'll double-check.
Alan DeKok.
_
On May 29, 2024, at 2:29 PM, Warren Kumari via Datatracker
wrote:
> My primary remaining comment is that Abstract for the document briefly should
> say *how* it updates RFC9427 - that way when someone reads RFC9427 they need
> only check this new document's Abstract to know if they need to read t
ype Type
> Codes’
> registries for new registrations and updates there registries with a NOTE:”
Will do.
> ** idnits reports:
>
> -- Obsolete informational reference (is this intentional?): RFC 5226
> (Obsoleted by RFC 8126)
Updated, thanks.
Alan DeKok.
___
On May 28, 2024, at 10:43 AM, Jeffrey Haas wrote:
>
> Hopefully this addresses Alan's comments:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-large-packets-11
That looks good, thanks.
Alan DeKok.
Yes.
> '[]' I have no idea, in TLS 1.3 it would signify encrypted messages, but
> clearly that can't be the case here (TLS server_key_exchange can't be
> encrypted).
TBH that's left over from 7170, and I'm not entirely sure.
> I like the ASCII art in Section C.1-C.10, not so much in C.11 on
> because it is harder to see which way the arrows point (less white space).
That diagram was a later addition. I'll see if I can find time to re-do
the diagrams manually before AUTH 48.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
hat 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?
Sure. I'll update the document.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
plicit that
> this is data used by EAP?
The rest of the document discusses how the EAP server handles the inner
tunnel data, so I think it's already explicit that the data is handled by EAP.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
opped".
Alan DeKok.
> The options are send one or the other, depending on the conditions or just
> send one regardless of the conditions, perhaps the answer is to just send
> Result TLV regardless?
The document already mandates sending a Result TLV to indicate the final
result of authentication, so I t
On May 20, 2024, at 8:12 PM, Orie Steele wrote:
>
> On Mon, May 20, 2024 at 6:24 PM Alan DeKok
> wrote:
>>
>> "It MUST only send a NAK TLV for a TLV which is marked mandatory."
>>
>
> It MUST send a NAK TLV for any TLV which is marked mandatory but
PKCS#10 TLV (see Section 4.2.17). The TEAP server
> issues a
> 1232 Simple PKI Response using a PKCS#7 [RFC2315] degenerate (i.e.
> 1233 unsigned) "Certificates Only" message encoded into the body of a
> 1234 PKCS#7 TLV (see Section 4.2.16), only after an inner
P address filtering? If the client has
correct TLS credentials, does it really matter what IP it comes from?
i.e. will the move to TLS still have servers identify clients by IP address?
Servers could also be configured to limit connections by source IP, as an
additional layer of security.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
24.
> Please, send your opinions on the list by this date. Please also indicate
> whether you are ready to review / contribute.
(chair hat off)
I support adoption. I'm ready to review / contribute.
Alan DeKok.
___
Uta mailing
n479
>
> Wikipedia has more info about its history and pointers to the first commits
> from 10+ years ago:
> https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol#EAP-TLS
>
> I haven't seen any use of "WFA-UNAUTH-TLS&
U) WG of the IETF.
>
> Title: Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Author: Alan DeKok
> Name:draft-ietf-emu-rfc7170bis-16.txt
> Pages: 111
> Dates: 2024-03-26
>
> Abstract:
>
> This document defines the Tunnel Extensib
r" construct and at what
> Tn+delta? And if you say "the highest version available" you're making it
> even more intractable/worse.
>
> The current wording seems the least disruptive to me. Yes, in some number of
> years we'll have to
358
Of the different methods, I think the wpa_supplicant method is the least
preferred.
Alan DeKok.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
e.g.
provisioning.t...@eap.arpa
instead of
provision...@teap.eap.arpa
I think the second looks clearer to me.
Alan DeKok,
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
>
> PS: There was also an issue that the current draft recommends Expert Review
> for assignment of new values but then also expects RFCs: "The intention is
> that any non-prefix allocation will be accompanied by a published RFC.". I
> think it will be beneficial to have &q
unauthenticated mode since 2008 (RFC 5216 Section
2.1.1). But there's been no way to actually use it.
Hopefully this set of documents will address that issue.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
pa
document, too.
* define an eap.arpa domain for use with a number of proposed provisioning
methods.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
OR
> messages sent in EAP-FIDO.
Is that fixed, or negotiated?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
to be explicit. If we have an attribute that says "MUST be of
> length one", some vendor will ignore it, on the sending or receiving side.
> How do we deal with two PKIDs? do we take the first one? The last one? Do we
> abort completely?
> I find it better to be explicit,
ate versions.
An alternative would be to do the version negotiation inside of the TLS
tunnel. That's also imperfect, but at least gives EAP-FIDO complete control
over all aspects of the protocol.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
is problem; sort of like
> GREASE...but to fix an insecurity instead.
I think that changes existing implementations. Unless the recommendation is
for each end to add a dummy Outer-TLV which implementations are *known* to
ignore.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
x27;t
> send it by default to unauthenticated servers, but offer a way for the user
> to override that default?
I believe that Identity-Hint is not useful for server unauthenticated
provisioning, and therefore should not not be used in that
On Mar 1, 2024, at 10:21 PM, David Mandelberg via Datatracker
wrote:
>
> (nit) If I understand the TEAP version negotiation and Crypto-Binding
> correctly, the negotiated version is not cryptographically verified until
> either (1) after the first inner method is completed or (2) just before the
[THIS-DOCUMENT]
Fixed.
>
> Protection against Man-in-the-Middle Attacks
>
> Maybe rename to "on-path attacks" ?
Fixed.
> Appendix C.4 should clarify the TLS version used (1.2). Should it be
> changed to use a TLS 1.3 example?
I think so, yes. I'll have to dig into that. I don't think I can get that
updated today before the deadline.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
This update includes guidelines for DNS operators and implementors.
> Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-dekok-emu-eap-arpa-01.txt
> Date: February 25, 2024 at 5:23:32 PM EST
> To: "Alan DeKok&
Looking at the paper in more detail, I think we should be fine.
The attacks are for things like "seed is all zero", which we don't care about
here.
The main take-away is to change the way we seed ISAAC a little bit, and we
should be fine. I'll work something out tomorrow.
On Feb 5, 2024, at 4:50 PM, Reshad Rahman
wrote:
>
> Yes wikipedia links to https://eprint.iacr.org/2006/438.pdf
Ah, OK.
Unfortunately there's no source code, and no test vectors. So I'm a bit wary
of "rolling my own". That being said, Page 5 has this text:
It is straightforward to dis
+. Wikipedia only lists ISAAC:
https://en.wikipedia.org/wiki/ISAAC_(cipher)
Alan DeKok.
in overflow, which can make the software do things".
I think it took about 4 rounds before I manage to get it through that if an
attacker can write to the configuration files, he can just *configure* the
software to do something. He doesn't need to "exploit" it with an overflow.
I that hope that the secdir review can avoid commenting on useless and
irrelevant attacks.
Alan DeKok.
packet is a new signal that the
session is still up. I don't see much use for a non-meticulous Auth Type
method, as packets can just be replayed.
Alan DeKok.
1 - 100 of 1089 matches
Mail list logo
