Re: [Emu] EMU PSK Method work Item

Bernard Aboba wrote: An EAP method with a new type code that is separated from the existing spec would not be EAP-TLS. It would be a new protocol. So as to avoid confusion, it would be best to use a different name, such as "EAP-TLS-PSK". Right. --Jari _

Re: [Emu] EMU PSK Method work Item

Salowey, Joe wrote: The security requirements in 4017 are not comprehensive, however I don't think the security requirements for PSK need to be comprehensive. I would rather not open up the list of requirements for PSK too broadly. I believe 4017 and 3748 provide a decent set and expanding them

[Emu] FW: EMU WG at IETF-65

This is the current EMU WG slot in the agenda for IETF-65: TUESDAY, March 21, 2006 ... 1850-1950 Afternoon Session IV INT l3vpn Layer 3 Virtual Private Networks WG RAI simple SIP for Instant Messaging and Presence Leveraging Extensions WG RTG rpsec Routing Protocol Security

Re: [Emu] RFC 2716: request for implementations

Looks great, thank you Bernard! Here's a diff between the RFC and your draft for everyone's viewing pleasure: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc2716.txt&url2=http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-00.txt A couple of quick c

Re: [Emu] RFC 2716: request for implementations

Yes. All of this sounds very reasonable. I was surprised to learn about the privacy part. --Jari Bernard Aboba wrote: 5. Security Considerations This needs more work, to fill in the descriptions required by RFC 3748. Right. Here are the claims that I think can be made: Auth. mechan

[Emu] FW: I-D ACTION:draft-mahy-eap-enrollment-01.txt

[EMAIL PROTECTED] wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : An Extensible Authentication Protocol (EAP) > Enrollment Method > Author(s) : R. Mahy > Filename: draft-mahy-eap-enrollment-01.txt >

[Emu] FW: I-D ACTION:draft-funk-eap-ttls-v1-01.txt

[EMAIL PROTECTED] wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : EAP Tunneled TLS Authentication Protocol Version 1 > (EAP-TTLSv1) > Author(s) : P. Funk, S. Blake-Wilson > Filename: draft-funk-eap-ttl

[Emu] EMU WG agenda for IETF-65, take one

Here's the initial plan for our session in Dallas. Send e-mail to the co-chairs if you have suggestions or other input regarding this agenda. EAP Method Update WG (emu) TUESDAY, March 21, 2006 1850-1950 Afternoon Session IV Room Monet WGs meeting at the same time: calsify, l3vpn, monami6, simple

[Emu] FW: Last Call: 'The Protected One-Time Password Protocol (EAP-POTP)' to Informational RFC (draft-nystrom-eap-potp)

FYI. Comments on this EAP method specification would be most appreciated. >The IESG has received a request from an individual submitter to consider the >following document: > >- 'The Protected One-Time Password Protocol (EAP-POTP) ' >as an Informational RFC > >The IESG plans to make a decisio

Re: [Emu] FW: Last Call: 'The Protected One-Time Password Protocol (EAP-POTP)' to Informational RFC (draft-nystrom-eap-potp)

Hi Hannes, > I must have missed it but who did the expert review for EAP-POTP? Technically, it does not need expert review for IANA allocation since an existing allocation (#32) is used. But I believe the document does need wider IETF review due to its potential impact in the real world, and that

[Emu] FW: Document Action: 'The Protected One-Time Password Protocol (EAP-POTP)' to Informational RFC

FYI > The IESG has approved the following document: > > - 'The Protected One-Time Password Protocol (EAP-POTP) ' > as an Informational RFC > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG conta

[Emu] an effort to bring legacy EAP methods to RFCs

edit the document, but we hope that the rest of the process in the RFC Editor, ISR, IESG RFC 3932 review, etc. goes smoothly. Jari Arkko ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu

[Emu] Re: Last Call: draft-tschofenig-eap-ikev2 (EAP-IKEv2 Method) to Experimental RFC

FYI > The IESG has received a request from an individual submitter to consider > the following document: > > - 'EAP-IKEv2 Method ' > as an Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive commen

Re: [Emu] Last Call: draft-funk-eap-ttls-v0 (EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0)) to Informational RFC

> The IESG has received a request from an individual submitter to consider > the following document: > > - 'EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0) ' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on

Re: [Emu] Suggestion: draft-arkko-eap-aka-kdf-09

Yes, that is the question. I do not myself have an implementation yet. I know people are working on one, but without an implementation I'm not sure I can provide test vectors. Jari Tschofenig, Hannes (NSN - FI/Espoo) wrote: Yogendra, do you plan to contribute text? Ciao Hannes

Re: [Emu] idraft-arkko-eap-aka-kdf-09 and AT_CHECKCODE

Jouni, It looks like draft-arkko-eap-aka-kdf-09.txt updates the RFC 4187 definition of AT_CHECKCODE by changing the length of Checkcode field to be "0 or 32 bytes". This does not look correct since EAP-AKA continues to use 20-byte Checkcode value and the same definition of the attribute is share

Re: [Emu] Addition of figures for peer's behaviour with AT_BIDDING and AT_KDF.

Thanks for the input. The draft has already been approved, but I can look at this during AUTH48. Jari yogendra pal wrote: Hi Jari, I would like to contribute some figures which could be useful in representing peer's behaviour in scenario mentioned in the draft-arkko-eap-aka-kdf-XX. 1. We can

Re: [Emu] Suggestion: draft-arkko-eap-aka-kdf-09

simple second RFC that just contains the test vectors. I can agree to take care of the practical details of that, if someone provides the actual data. Jari Jouni Malinen wrote: On Tue, Nov 11, 2008 at 08:55:36AM +0200, Jari Arkko wrote: Yes, that is the question. I do not myself have an

Re: [Emu] Suggestion: draft-arkko-eap-aka-kdf-09

Wonderful. Are we ready to include these values in an appendix of the RFC? Russ, would you mind if we do that? Jari Jouni Malinen wrote: 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 verif

Re: [Emu] Potential Notes in EAP-FAST Documents

Speaking as an individual, I'm fine with this. It is important to document the EAP methods as they actually exist in wide deployment. That being said, we should also recognize the problems that codepoint overloading causes (even if the overloading issues are somewhat mitigated by the context ie

Re: [Emu] Potential Notes in EAP-FAST Documents

Bernard, c. EAP negotiation issues. Neither the IESG note nor the text explicitly states what is wrong with using an EAP Type Code for incompatible versions of an EAP method that does not support version negotiation. They should state this. Indeed, it would appear that some members of the

Re: [Emu] Potential Notes in EAP-FAST Documents

Pasi, If folks are opposed to publishing descriptions of deployed EAP method when they're less than perfect (or even ugly hacks with bad architecture), and may not offer perfect security in all circumstances (but accurately document their limitations), they should have said so much earlier.

Re: [Emu] EAP - TLS 1.3

I don’t want to push the decision in either direction without looking into the details. But I wanted to point out that there’s usually a third alternative between “no need for new documents” and “need a new RFC to describe the new version”. Explaining that the old protocol can be used and what

Re: [Emu] [Reap] EAP - TLS 1.3

I think it would be perhaps useful to take some sort of reset on this thread :-) I think there are at least three groups of people talking past each other, and making assumptions that may not be correct. While this isn’t really a topic that I’m driving, let me make a first cut at doing that res

Re: [Emu] EAP-SIM/AKA and missing Session-Id derivation rules for fast reauth

Thanks for bringing this up, Jouni. I agree that this need to be specified somehow. (Another possible way to document this is to put it in the revision that we were planning for EAP-AKA’.) Jari ___ Emu mailing list Emu@ietf.org https://www.ietf.org/m

[Emu] Potential re-establishment of the EMU working group

Hi, I’ve been thinking of what to do with the EAP work that got discussed both in the SAAG meeting last time (my drafts), as well on the list. The latter was more on the EAP-TLS side, and it seems that the discussion has converged to a reasonable direction recently. Wondering how we could get

Re: [Emu] Potential re-establishment of the EMU working group

> The Session ID also needs to be defined for SIM and AKA, as per Jouni's > comments. That doesn't fit in with AKA' changes. Yeah, I was thinking about that but didn’t go far enough. But you’re right. Maybe this needs to be a separate item for EAP-SIM. > It may also be worth re-examining EAP-

Re: [Emu] Potential re-establishment of the EMU working group

Alan, John, > On Dec 22, 2017, at 1:12 PM, John Mattsson wrote: >> In TLS 1.3, ECC is mandatory to support. This drastically reduces the sizes >> of certificates and signatures (public key sizes from 384 bytes (RSA and >> DHE) to 32 bytes (ECDHE) and signatures from 384 bytes (RSA) to 64 bytes

[Emu] Potential re-establishment of the EMU working group, version 2

Here’s a second spin of the potential WG charter. I will talk to the ADs and see what we can do with this… would also appreciate any further comments or expressions of support or objection from you all :-) Jari EAP Maintenance Update (emu) or EAP Method Maintenance Update (emmu) --

Re: [Emu] Kathleen Moriarty's Yes on charter-ietf-emu-04-00: (with COMMENT)

Mohit, Kathleen, I’d suggest editing the current milestones as follows. The edit and schedule suggestions are based in part on what I think the 3GPP schedules are going to be. They need some stuff soon (e.g., any fixes to existing EAP-AKA’; there’s a technical specification with a few paragraphs l

Re: [Emu] Ben Campbell's No Objection on charter-ietf-emu-04-00: (with COMMENT)

Hi Ben, And thanks for your feedback. > First bullet point: "or other new concerns." makes this very open ended. Is > this planned to be a standing working group? If not, can we put some > constraints around "other new concerns”? Understood. Note that the sentence starts with “Update the securi

Re: [Emu] Mirja Kühlewind's No Objection on charter-ietf-emu-04-00: (with COMMENT)

Mirja, > I would actually rather like to see milestones for when the work is supposed > to > be finished (send to IESG for publication) than when it is supposed to start > (wg adoption) as the first is probably harder to achieve in time than the > second. I suggested edits to the milestones in a

Re: [Emu] Spencer Dawkins' No Objection on charter-ietf-emu-04-00: (with COMMENT)

> "This working group has been chartered to provide updates to some > commonly used EAP method." > > really singular? Or should it be "commonly used EAP methods”? Uh… a bug. Thanks for the careful read. For Kathleen: OLD: This working group has been chartered to provide updates to some common

Re: [Emu] Call for agenda items

Hi Joe, I’d like us to talk about both RFC 5448bis and, separately the work on adding PFS to EAP-AKA’. I plan to submit new version of drafts on both topics. Jari ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

[Emu] Fwd: New Version Notification for draft-arkko-eap-aka-pfs-01.txt

FYI > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-arkko-eap-aka-pfs-01.txt > Date: 5 March 2018 at 16.18.46 GMT+2 > To: "Jari Arkko" , "Vesa Torvinen" > , "Karl Norrman" > >

[Emu] Fwd: New Version Notification for draft-arkko-eap-rfc5448bis-01.txt

FYI > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-arkko-eap-rfc5448bis-01.txt > Date: 5 March 2018 at 16.18.37 GMT+2 > To: "Jari Arkko" , "Vesa Lehtovirta" > , "Vesa Torvinen" , &

Re: [Emu] Call for adoption of draft-mattsson-eap-tls13-02

> I would like to add my support to adopting this draft as a working group > item. EAP-TLS is a core EAP method and with TLS 1.3 maturing, this work item > is very meaningful. +1 It has been a while since you Joe asked the question… I think we need this draft and the other drafts that are up

[Emu] EAP-AKA' -bis and -DH implementations

I just wanted to send an update and say that we (Ericsson) are working on implementations for both EAP-AKA’ with the adjustments as specified in draft-arkko-eap-rfc5448bis, and the actual extensions as specified in draft-arkko-eap-aka-pfs. We will be reporting on our experiences once we are at

Re: [Emu] I-D Action: draft-ietf-emu-rfc5448bis-00.txt

Thanks for your review and suggestions, John. > - I think the document still need to have the first-page header "Updates: > 4187". My understanding of Obsoletes is that it replaces the older document > and that the new document can be used alone without reference to the older > document. > > -

[Emu] Some observations on RFC 4187 attribute table

As part of ongoing (new) implementation effort, my colleague realised that there are couple of oddities in the RFC 4187 attribute table (Section 10.1). First, for AT_CHECKCODE, the table indicates “0” for EAP-Response/AKA-Identity, yet Section 10.13 says “ The AT_CHECKCODE attribute MAY be used

Re: [Emu] I-D Action: draft-ietf-emu-rfc5448bis-01.txt

FYI the below comments have all been accepted in my to-be-published -02 version. Jari > -- Section 1 > > - Section 5 and 6 is missing from the document structure description. Is this > intentional? > > - OLD "updates to RFC 5448 AKA' and" > NEW "updates to RFC 5448 EAP-AKA' and" > > -- Sect

Re: [Emu] I-D Action: draft-ietf-emu-rfc5448bis-02.txt

> The Abstract says: This specification defines a new EAP method... > > At this point, we should probably drop 'new'. Yes. It was a remnant of RFC 5448… Fixed in my copy. Jari ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/

[Emu] Fwd: New Version Notification for draft-ietf-emu-rfc5448bis-03.txt

c5448bis-03.txt > has been successfully submitted by Jari Arkko and posted to the > IETF repository. > > Name: draft-ietf-emu-rfc5448bis > Revision: 03 > Title:Improved Extensible Authentication Protocol Method for > 3rd Generation Authentication and

Re: [Emu] draft-ietf-emu-rfc5448bis-03

Thanks for your review, Russ. I will look carefully into your comments. But for starters, you make a good point about the abstract/introduction. And obviously the language used to refer to the AT_KDF attribute number vs. value needs to be precise. Jari

Re: [Emu] WGLC for draft-ietf-emu-rfc5448bis

Thanks for your review, Jim. > Any issues that I have here might have already been raised and discussed. If > so just not that and ignore. > > Section 3.4 - I am curious why you did not make the hash function a property > of the HKDF function rather than making it a hard coded value. I would

Re: [Emu] WGLC for draft-ietf-emu-rfc5448bis

> The one change I think you might consider doing is to put a "future version > note" into the document with the suggestion that this be considered. Good idea. I will write something. Jari ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mail

Re: [Emu] WG adoption call for draft-arkko-eap-aka-pfs

Max, Alan, First, thank you for your review and expressing that this is an important step in moving the mobile network authentication schemes to present-day crypto approaches :-) With regards to the IPR question, I want to stay away from discussing anyone’s licensing conditions, as I don’t rep

Re: [Emu] WG adoption call for draft-arkko-eap-aka-pfs

Alan, Circling back to this. I’ll first agree with your summary about the importance of the tech, that there’s some risk but the risk is likely low but non-zero, and that in an ideal situation you wouldn’t have to deal with this. However, I would like to point out that * The draft is an *opti

Re: [Emu] WG adoption call for draft-arkko-eap-aka-pfs

Re: optional but everyone requiring a feature. I think in this case the “can require everyone to do it” is probably far away in the future, in practice. Given that Release 15 does not require this extension, it only requires RFC 5448 EAP-AKA’ (or the bis), this means that there will be lots of

Re: [Emu] minor Issues/PRs for draft-ietf-emu-rfc5448bis

Thanks for your review, Sean. Jari ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-rfc5448bis-03

Russ, Thanks again for your comments. A new version has been posted, with changes to e.g. the abstract and the introduction. Can you check if you like these better, and if any further changes come to mind? Thanks. Jari > On 14 Nov 2018, at 6.06, Russ Housley wrote: > > I agreed to review thi

Re: [Emu] minor Issues/PRs for draft-ietf-emu-rfc5448bis

Sean: I believe I have addressed all your comments. The new draft includes changes; the git issues have some responses. If you can, take a look at the new version! Jari ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] minor Issues/PRs for draft-ietf-emu-rfc5448bis

Thanks! ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WGLC for RFC5448bis

Thanks for your review, John. I agree with all the points and will address them in a new version during the IETF week. Jari ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP-AKA' and Re: WG adoption call for draft-arkko-eap-aka-pfs

Michael, Thanks for your comments. A couple of responses: with regards to deployment, there’s some amount of EAP SIM/AKA deployment, but until now it hasn’t been for the primary mobile network access. It was only used for Wireless LANs when you have a SIM card. Nevertheless, both protocols are

Re: [Emu] AD review of draft-ietf-emu-rfc5448bis-06

Roman, Many thanks for your review. We have gone through all the reviews and comments and are about to post a new draft version in few hours, currently in https://arkko.com/ietf/eap/draft-ietf-emu-rfc5448bis-from--06.diff.html

Re: [Emu] [Gen-art] Genart last call review of draft-ietf-emu-rfc5448bis-06

Thanks for your review, Dan. Some responses below. We are also about to publish a new document version. > This is a very detailed and well-written document that describes a new > specification of the specification of EAP-AKA' to support 5G deployments. This > specification is ready, but I have a

Re: [Emu] [Last-Call] Secdir last call review of draft-ietf-emu-rfc5448bis-06

Thanks for your review, Kyle! Inline: >> From the perspective of clarity and completeness, this document is Ready With > Nits: it is well-written and mostly quite clear, even to someone without a > great deal of knowledge of 3GPP systems. In addition to digging into RFCs 4187 > and 5448, I had to

[Emu] Fwd: New Version Notification for draft-ietf-emu-rfc5448bis-07.txt

FYI > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-ietf-emu-rfc5448bis-07.txt > Date: 9 March 2020 at 22.34.13 GMT+2 > To: "Pasi Eronen" , "Jari Arkko" , "Vesa > Torvinen" , "Vesa Lehtovirta" > > >

Re: [Emu] General EAP discussion of protected alternate indication of success, RFC 4137, and IEEE 802.1X

John, This may be a side note in the TLS discussion, but just looked at the below list: > Looking at the other active documents in the EMU WG: > > draft-ietf-emu-rfc5448bis > draft-ietf-emu-aka-pfs > […] > None of them has a protected alternate indication of success […] And it seems to me that

[Emu] draft-arkko-emu-rfc3748bis

Hi, John and I have submitted a draft that updates RFC 3748, updating some of the security considerations, terms, references, the IANA considerations, and few other updates. While the believe that the update from RFC 3748 is useful, it is by no means something that absolutely has to be done, b

[Emu] Call with 3GPP on draft-ietf-emu-rfc5448bis

As mentioned in the meeting today, there will be a call with 3GPP folks around the RFC5448bis details on Wednesday the 17th of March 15:00 to 17:00 CET. The goal is to ensure that 3GPP does the right thing with regards to their specifications and references, as well as make sure the IETF draft a

Re: [Emu] Call with 3GPP on draft-ietf-emu-rfc5448bis

tps://www.gotomeet.me/MirkoCano/sa3ietf-conference-call-on-draft-rfc5448bis> New to GoToMeeting? Get the app now and be ready when your first meeting starts: https://global.gotomeeting.com/install/573986821 <https://global.gotomeeting.com/install/573986821> > On 8 Mar 2021, at 17.33, Jari Arkko

[Emu] New version of the PFS document

I submitted a new version of the draft. Quoting the change list: The -06 version of the WG draft is a refresh and a reference update. However, the following should be noted: * The draft now uses "forward secrecy" terminology and references RFC 7624 per recommendations on mailing list discus

[Emu] Fwd: New Version Notification for draft-ietf-emu-aka-pfs-07.txt

FYI > A new version of I-D, draft-ietf-emu-aka-pfs-07.txt > has been successfully submitted by Jari Arkko and posted to the > IETF repository. > > Name: draft-ietf-emu-aka-pfs > Revision: 07 > Title:Forward Secrecy for the Extensible Authenticati

Re: [Emu] Murray Kucherawy's Discuss on draft-ietf-emu-aka-pfs-11: (with DISCUSS and COMMENT)

Hi Murray, all, Thanks for taking a look at this! Some responses: > Further to Eric's point, I don't follow why this document, which specifies a > protocol with interoperability properties, isn't a Proposed Standard. Good question. In short, historical reasons. Dating back to early 2000s, th

Re: [Emu] Roman Danyliw's No Objection on draft-ietf-emu-aka-pfs-11: (with COMMENT)

Thanks, Roman. Inline: > Thank you to Carl Wallace for the SECDIR review. > > ** Section 1. Editorial > However, the danger of resourceful attackers attempting to gain > information about long-term keys is still a concern because many > people use the service and these keys are high-value

Re: [Emu] Warren Kumari's No Objection on draft-ietf-emu-aka-pfs-11: (with COMMENT)

Warren, Bo, > I'll note that the document was updated 10 July 2023, after the OpsDir review > (10 March 2023), but the (IMO) very reasonable suggestions were not taken: > "With only IETF technical background, it seems more readable if UICC, HSS can > expand on the first-time use.” Yes, of course.

Re: [Emu] Francesca Palombini's No Objection on draft-ietf-emu-aka-pfs-11: (with COMMENT)

Francesca, Sean, > Section 6.1: AT_PUB_ECDHE. The way Length is defined in RFC4187 (specifying > the > length of the attribute in multiple of 4 bytes), and given the length of the > ECDHE public key in the attribute value (currently 32 or 33 bytes), you > probably should mention something about p

Re: [Emu] Robert Wilton's No Objection on draft-ietf-emu-aka-pfs-11: (with COMMENT)

Thanks John and Robert. Will take change this. Jari ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-12.txt

t is now available. It is a work > item of the EAP Method Update (EMU) WG of the IETF. > > Title: Forward Secrecy for the Extensible Authentication Protocol Method > for Authentication and Key Agreement (EAP-AKA' FS) > Authors: Jari Arkko >Karl Norrman >