#12: TLS Extensions
> Section 4.2.1.3
>
> " In order to meet the requirements in this document TLS
> extensions MAY
>be used. For example, TLS extensions may be useful in providing
>certificate revocation information via the TLS OCSP extension
(thus
>meeting the requirement in
#11: TLS version
> Section 4.2.1
>
> " The tunnel based method MUST support TLS version 1.2 [RFC5246] and
>SHOULD support TLS version 1.0 [RFC2246] and version 1.1
> [RFC4346] to
>enable the possibility of backwards compatibility with existing
>deployments."
>
> I am not sur
#10: Emergency Services
> Section 3.5
>
> " When wireless VOIP service is provided, some regulations
> require any
>user to be able to gain access to the network to make an emergency
>telephone call."
>
> Which regulations are being referred to? In a number of
> places, supp
#9: Peer Identity Protection
> Section 3.4
>
> " When performing an EAP authentication, the peer may want to
protect
>its identity, only disclosing its identity to a trusted backend
>authentication server. This helps to maintain the privacy of the
>peer's identity."
>
> With
#8: Cryptographic Binding Text
> Section 3.2
>
> " In
>particular, when weak methods are used, security policies
enforcing
>that such methods can only be executed inside a tunnel but never
>outside one are required to mitigate the attack."
>
> The requirement that methods only
#7: Password Authentication
> Section 3.1 Password Authentication
>
> " Many legacy systems only support user authentication with >
passwords.
>Some of these systems require transport of the actual username and
>password to the authentication server. The tunnel method
> MUST sup
Description:
Section 2 " Because this specification is an informational specification
(not able to directly use [RFC2119])," Since a large number of
Informational RFCs reference RFC 2119 and use normative language, this
statement seems odd. Perhaps what it is trying to say is that the terms
don't
> -Original Message-
> From: Richard [mailto:rishy...@gmail.com]
> Sent: Monday, July 27, 2009 7:54 AM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: If we use the Radius property extension
>
> Hi, all:
>
> The link to the slide:
> http://www.
> -Original Message-
> From: Richard [mailto:rishy...@gmail.com]
> Sent: Monday, July 27, 2009 2:57 PM
> To: Dan Harkins
> Cc: Joseph Salowey (jsalowey); emu@ietf.org;
> dstan...@arubanetworks.com
> Subject: Re: [Emu] If we use the Radius property extension
>
If you are on the agenda to present in the meeting please send your
slides to the chairs so they can be uploaded to the server.
Thanks,
Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
The announcement indicates that the draft will be published as
informational, however Glen Zorn (one of the authors) has requested that
this be changed to standards track so the status is currently under
discussion. Since the document is in IETF last call comments on the
draft including its standa
-Original Message-
From: ietf-announce-boun...@ietf.org
[mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG
Sent: Monday, July 13, 2009 2:22 AM
To: IETF-Announce
Subject: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using
Only APassword) to Informational RFC
The IE
Draft EMU agenda is available at:
http://www.ietf.org/proceedings/09jul/agenda/emu.txt
Let the chairs know if you have and additions or comments.
Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
I believe this revision addresses all outstanding comments, this should
be ready for the IESG. Please review and indicate if the document is
ready or if there are outstanding issues.
Thanks,
Joe
> -Original Message-
> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On
> Beha
;
> > >
> > > [KH] Disagree, see my comments to your suggestions #2.
> > >
> > [Joe] So, I see i1 as the messages used in EAP channel
> bindings. i2
> > looks to me like validation that should be done by the AAA protocol.
> I
> > think I may not h
> -Original Message-
> From: Hoeper Katrin-QWKN37 [mailto:khoe...@motorola.com]
> Sent: Friday, June 19, 2009 5:39 PM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] draft-ietf-emu-chbind-02 and AAA interaction
>
> Joe,
>
> Thank you fo
After reviewing recent comments from Klaas on the list on Channel
bindings there is one issue I would like to try to resolve before
bringing this draft to last call.
In section 5.1, the draft defines a message i2, which is the message
carrying AAA attributes from the authenticator to the server
I'm not sure I quite understand the differences between the two cases.
I think Klaas is saying that we need a protocol to exchange channel
binding information, but we should stop before we define rules on how to
evaluate this information. While I think that the requirements for the
protocol ar
Below, Glen suggests that it would be better to list specific
requirements from RFC 5247 and RFC 4962 to avoid later confusion. This
sounds like a good idea, is someone willing to contribute some text on
this? I think it would be a distilled list of requirements from the two
drafts normalized so
Hi Glen,
Thanks for the review. I've incorporated most of the suggestions into a
new revision. I have a question for you below.
> Same section, last paragraph, says:
>
>Since EAP authentication occurs before network access is
> granted the
>tunnel method SHOULD enable an inner exc
Hi Glen,
Thanks for the review. I've incorporated most of the suggestions into a
new revision. I have a question for you below.
> Same section, last paragraph, says:
>
>Since EAP authentication occurs before network access is
> granted the
>tunnel method SHOULD enable an inner exc
Hannes said:
>
> I understand the issue of defining channel bindings.
> draft-ietf-emu-chbind-00 does this but it does not define payloads.
> Do we really need to split this aspect into separate drafts?
>
[Joe] Not necessarily.
> The aspect of having the possibility to carry an opaque blob
>
> -Original Message-
> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On
> Behalf Of Hannes Tschofenig
> Sent: Sunday, March 01, 2009 10:46 AM
> To: 'Alan DeKok'; emu@ietf.org
> Subject: Re: [Emu] Draft agenda for IETF 74
>
> Hi Alan,
>
> a few questions inline. What is mor
I believe the document contains all the changes discussed in the meeting
and on the list. The document should be ready for working group last
call. It would help if a few people could review it to make sure it is
complete. The following link provides to access to diffs and previous
versions:
ht
Interesting, so it looks like EAP-MSCHAPv2 isn't fully defined except
within a tunnel method, so its behavior is specific to the tunnel
method...
> -Original Message-
> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On
> Behalf Of pasi.ero...@nokia.com
> Sent: Thursday, Februa
>
> Are you saying that the registry of "EAP-FAST PAC Attribute
> Types" also
>
> relates to RFC 4507, which is a standards track document?
>
[Joe] This is not directly related to 4507. RFC 4507 treats tickets as
opaque.
>
> If so, then I may see your point. RFC 5226 does permit
> v
Section 4 defines two channel binding options
- Binding channel information into the EAP method key derivation
- Exchanging channel information between peer and authenticator for
validation
These options are not mutually exclusive. For example a method could
exchange data that is bound into the
Thanks to Paul Sangster the notes from IETF 73 can be found at
http://www.ietf.org/proceedings/08nov/minutes/emu.txt. Let the chairs
know if you have any corrections or additions.
Thanks,
Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mai
> -Original Message-
> From: Katrin Höper [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 03, 2008 8:05 AM
> To: Joseph Salowey (jsalowey)
> Cc: emu@ietf.org
> Subject: Re: [Emu] Review of Requirements for a Tunnel Based
> EAP Method
>
> On Sun, Nov
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Katrin Höper
> Sent: Friday, October 31, 2008 8:22 AM
> To: emu@ietf.org
> Subject: [Emu] Review of Requirements for a Tunnel Based EAP Method
>
> Hi,
>
> I have problems with some of the cryptogra
Here is the list of revisions planned for the next revision of the
tunnel method requirements document.
+ 4.5.1.2 authentication of server
Issue: I don't think it is as important to protect the username as the
password.
Resolution: Update 4.5.1.2 as
"The EAP server MUST be authenticated before th
Hi Again,
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Stefan Winter
> Sent: Tuesday, August 12, 2008 6:45 AM
> To: emu@ietf.org
> Subject: [Emu] Review of emu-eaptunnel-req-00, chunk 2 of 2
>
> (continuing from 4.2.2 on)
>
> 4.3 Tunnel payload
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Stefan Winter
> Sent: Tuesday, August 12, 2008 6:40 AM
> To: Josh Howlett
> Cc: emu@ietf.org
> Subject: Re: [Emu] Review of emu-eaptunnel-req-00, chunk 1
>
> Hi,
>
> > This is a desirable property
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Klaas Wierenga
> Sent: Monday, August 11, 2008 8:20 AM
> To: emu@ietf.org
> Subject: [Emu] Review of Requirements for an Tunnel Based EAP Method
>
> 1. intro
>
> reference for PEAP is missing, too
Hi Stefan,
Thanks for doing this review. Comments inline below
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Stefan Winter
> Sent: Friday, August 08, 2008 7:10 AM
> To: emu@ietf.org
> Subject: [Emu] Review of emu-eaptunnel-req-00, chunk 1
>
>
The ITU-T SG 17 has sent a response to our comments on X.1034. It can
be found here:
https://datatracker.ietf.org/liaison/475/
Cheers,
Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Here is a draft liaison response for ITU-T Recommendation X.1034.
Please send any comments on this by Monday 9/8.
Thanks,
Joe
The EAP Method update (EMU) working group in the IETF has review the
document "ITU-T Recommendation X.1034" that is the subject of a liaison
statement submitted on 200
Since there have been no additional comments on GPSK and client state
the draft revision should also include text to resolve this issue along
the lines of
http://www.ietf.org/mail-archive/web/emu/current/msg00908.html.
Thanks,
Joe
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[
Please send comments no later than 8/27 so we have time to prepare a
response.
Thanks,
Joe
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of [EMAIL PROTECTED]
> Sent: Wednesday, August 06, 2008 11:57 PM
> To: emu@ietf.org
> Cc: [EMAIL PROTECTED]
>
In order to make progress I propose the following resolution to this
issue:
Modify text in the third paragraph from the end of section 10 to read:
"For GPSK-3, a peer MUST silently discard messages where the
RAND_Peer or the CSuite_Sel fields do not match
those transmitted in GPSK-2. An EA
If we make the change below then we also have to change section 12.9. I
think this is a bit problematic since at one point we had consensus to
address the issues on client state avoidance raised by folks at
Stanford. The goal was that the peer could store its nonce on a
per-server basis rather th
In general I think the document is a good start. I think it needs some
work in a few areas
1. Section 1
- The following sentence is a bit odd:
"Here, a Network Access Server (NAS), or pass-through authenticator, may
authenticate to the backend AAA infrastructure using one set of
credentials,
Currently GPSK makes an implicit assumption that the MAC output size
will be the same as the key size. This will not always be the case as
it is possible for the MAC output size to be different than the key
size. For example it has been pointed out that AES-CMAC-256 has a 128
bit output.
It s
I think this issues has been raised in the past, does anyone on the list
have any specific scenarios where EAP header protections are important?
If not the requirement can be downgraded or removed entirely.
With respect to making one method look like another, some systems such
as 802.1X-2004, do
I'm in favor of accepting this document as an EMU work item.
Joe
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Alan DeKok
> Sent: Thursday, June 05, 2008 6:51 AM
> To: emu@ietf.org
> Subject: [Emu] EMU WG Consensus call on acceptance of the
> t
dnesday, April 30, 2008 4:54 PM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] EMU charter revision,
>
> [Joe] Jari had asked to keep this open to TLS. I think he
> was suggesting it could be done as a TLS extension and would
> not require tunneling. I agr
In order to get things moving we will send the following charter update
to Pasi tomorrow. I will also let Pasi and Tim know there is interest
in secure password methods and they should consider it as a topic for
SAAG.
Description of Working Group:
The Extensible Authent
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Bernard Aboba
> Sent: Tuesday, April 29, 2008 12:50 PM
> To: emu@ietf.org
> Subject: Re: [Emu] EMU charter revision,
>
> In re-reading this charter, I still don't think we're quite there:
>
> a.
Hi Yoav,
You bring up an interesting point in discussing the need for EAP
password based authentication within other protected protocols. If this
is targeted at working with legacy databases then I think it can be
accommodated under the current charter. An EAP protected tunnel is
required for so
> -Original Message-
> From: Dan Harkins [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 11, 2008 10:38 AM
> To: Joseph Salowey (jsalowey)
> Cc: emu@ietf.org
> Subject: Re: [Emu] EMU charter revision
>
>
> Hi Joe,
>
> Thank you for giving m
Below is a revision to the EMU charter that is intended to reflect the
discussions in the Philadelphia meeting. Please respond to the list if
you approve of the charter or if you have any comments on the charter.
I would like to have responses by 4/24.
Thanks,
Joe
Description of Working Group:
2008 2:09 AM
> To: Dan Harkins
> Cc: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] comment on draft-ietf-emu-eap-gpsk
>
> Joseph Salowey (jsalowey) <> scribbled on :
>
> > Thanks Dan, I agree with your assessment. I think we
> should include
&
Thanks Dan, I agree with your assessment. I think we should include
text similar to what you propose in the document.
Joe
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Dan Harkins
> Sent: Tuesday, April 01, 2008 3:26 PM
> To: emu@ietf.org
> S
Draft meeting minutes for IETF-71 are available below and at
http://www.ietf.org/proceedings/08mar/minutes/emu.txt. Thanks to
Dorothy and Charles who took excellent notes. Let me know if there are
any additions or corrections.
Thanks,
Joe
EMU
IETF-71 - Philadelphia
Thursday, March 13, 2008 09
Sorry, make that draft-harkins-emu-eap-pwd-01
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Joseph Salowey (jsalowey)
> Sent: Monday, March 10, 2008 2:55 PM
> To: Dan Harkins; SeongHan Shin
> Cc: Kazukuni Kobara; emu@ietf
elow ID (Password only Mechanism)
> >> http://tools.ietf.org/id/draft-harkins-emu-eap-pwd-00.txt
> >> to be presented at IETF 71.
> >>
> >> The idea of the protocol seems interesting.
> >> However, I found that th
ter revision,
> specifically the change that says the password-based method
> can only be via the tunneled method. I do approve of the
> inclusion of tunneled methods in the charter though and would
> be willing to contribute as a reviewer.
>
> regards,
>
> Dan."
> On Tue,
EMU Agenda
IETF 71
THURSDAY, March 13, 2008
0900-1130 Morning Session I
-
+ Administrivia (5 min)
- agenda, blue sheets, note takers
+ Document Status (5 min)
- EAP-TLS - draft-simon-emu-rfc2716bis-13.txt
- EAP-GPSK - draft-ietf-emu-eap-gpsk-08.txt
e password only method" such as the on
proposed in the draft?
Thanks,
Joe
> -Original Message-
> From: Dorothy Stanley [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 22, 2008 8:25 AM
> To: Joseph Salowey (jsalowey)
> Cc: emu@ietf.org
> Subject: Re: [Emu] EMU cha
008 11:35 AM
> To: Joseph Salowey (jsalowey)
> Cc: emu@ietf.org
> Subject: Re: [Emu] Draft Agenda for IETF-71
>
>
> > + Channel Bindings (20 min)
> > - draft-clancy-emu-chbind-00.txt
> > - draft-clancy-emu-aaapay-00.txt
> >
> >
> I haven't
Draft meeting agenda is attached below, let me know if you have any
additions or corrections.
Thanks,
Joe
EMU Agenda
IETF 71
THURSDAY, March 13, 2008
0900-1130 Morning Session I
-
+ Administrivia (5 min)
- agenda, blue sheets, note takers
+ Document
starting point for discussions on the
list and in the Philadelphia meeting.
Thanks,
Joe
> -Original Message-
> From: Joseph Salowey (jsalowey)
> Sent: Monday, February 04, 2008 9:13 PM
> To: emu@ietf.org
> Subject: EMU charter revision
>
> Below is a revised charte
Hi Gondi,
I think proposals on handover are better evaluated in the HOKEY
(Handover Keying) working group, which is currently working in this
problem space.
Cheers,
Joe
> -Original Message-
> From: Vamsi Krishna Gondi [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 14, 2008 6:
working group interest in pursuing a method of
this type.
Cheers,
Joe
> -Original Message-
> From: Dorothy Stanley [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 12, 2008 8:13 AM
> To: Joseph Salowey (jsalowey)
> Cc: emu@ietf.org
> Subject: Re: [Emu] EMU charter re
Below is a revised charter update based on the discussion on the list.
I have left the password based method item as a tunnel method because
this represents the consensus the working group has reached. I also
believe the working group will have to focus on the tunnel method
related items for the n
5 PM
> To: Joseph Salowey (jsalowey)
> Cc: Dan Harkins; emu@ietf.org
> Subject: RE: [Emu] EMU charter update,
>
>
> Hi Joe,
>
> I don't think I've been very clear. In fact, after speaking
> to other people about this topic I'm pretty sure I have not
> -Original Message-
> From: Hao Zhou (hzhou)
> Sent: Monday, January 28, 2008 1:50 PM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] WG consensus on charter update
>
> Joe:
>
> I am ok with the updated charter, with the following minor
> -Original Message-
> From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 28, 2008 1:40 PM
> To: Joseph Salowey (jsalowey)
> Cc: emu@ietf.org
> Subject: Re: [Emu] WG consensus on charter update
>
> I know it's after the deadline,
So far I have only seen responses from Dan Harkins on the proposed
charter update
( http://www1.ietf.org/mail-archive/web/emu/current/msg00712.html )
Please respond on the list if you have reviewed the charter and have
comments or if you approve of the current text. Also make sure to
review the
Hi Dan,
Comments inline below:
> -Original Message-
> From: Dan Harkins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 23, 2008 11:34 AM
> To: Joseph Salowey (jsalowey)
> Cc: Dan Harkins; emu@ietf.org
> Subject: RE: [Emu] EMU charter update,
>
>
>
> -Original Message-
> From: Dan Harkins [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 22, 2008 5:12 PM
> To: Joseph Salowey (jsalowey)
> Cc: Dan Harkins; emu@ietf.org
> Subject: RE: [Emu] EMU charter update,
>
>
> Hi Joe,
>
> OK, so the
> -Original Message-
> From: Dan Harkins [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 22, 2008 2:13 PM
> To: Joseph Salowey (jsalowey)
> Cc: emu@ietf.org
> Subject: RE: [Emu] EMU charter update,
>
>
> Hi Joe,
>
> On Tue, January 22, 2008 1
e
> working group we could fall back on the "must be a strong
> shared secret"
> requirement.
>
> The tunneled method should be resistant to dictionary
> attack but if the non-tunneled one was also resistant to
> dictionary attack wouldn't that be g
Hi Madjid,
Comments inline below:
> -Original Message-
> From: Nakhjiri Madjid-VXT746 [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 18, 2008 5:03 PM
> To: [EMAIL PROTECTED]; emu@ietf.org
> Subject: [Emu] 2716bis13: Support of certificate_status extension
>
> Hi,
>
> Question on
Below is a draft of the EMU charter that reflects discussions we had at
IETF 70. Please review this and send comments. I would like to have
comments in by January 23, 2008.
Thanks,
Joe
Description of Working Group:
The Extensible Authentication Protocol (EAP) [RFC 3748] is a network
access a
Below are the draft minutes for the IETF-70 EMU meeting. Thanks to
Nancy, Steve and Sue for taking notes. Please let me know if you have
any corrections.
EMU Minutes
==
TUESDAY, Dec
Below is the PROTO write-up for EAP-GPSK. Please let me know if there
are any issues with the write-up. I will send EAP-GPSK to the IESG in
the next few weeks.
Thanks,
Joe
--
(1.a) Who is the Document Shepherd for this document? Has the Document
Shepherd personally reviewed this vers
Here is the summary that was sent to the SAAG list for emu. I will post
full minutes later this week.
Thanks,
Joe
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Joseph Salowey (jsalowey)
Sent: Thursday, December 06, 2007 9:23 AM
To: [EMAIL PROTECTED
, 2007 3:28 AM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] EMU charter update for tunneled method
>
> Here is my feedback on this proposed charter update.
>
> 1) RFC 3748 and RFC 4017 requirements should apply to
>all deliverables. The proposed language
I received some feedback that it would be more productive to move the
method presentations before the requirements discussion so the
requirements discussion can benefit from the lessons learned in the
existing method designs. The updated agenda looks like:
EMU
TUESDAY, December 4, 2007
0900-1130
In adding the tunneling method to the charter we need to make sure we
work off a valid set of requirements. We have a set of requirements
that are based on tunneling passwords:
1. Transport of encrypted password for support of legacy password
databases (REQUIRED)
2. Mutual authentication (specifi
Below is an updated agenda for EMU at IETF 70. Let me know if you have
any corrections or additions. We also need 2 note takers. Instead of
wasting time in the meeting looking for note takers it would be helpful
if a few participants volunteered ahead of time.
Thanks,
Joe
EMU
TUESDAY, Dece
Below is the draft agenda for the EMU session at IETF 70 in Atlanta.
Let me know if you have something you want to present in one of the
sections:
EMU
TUESDAY, December 4, 2007
0900-1130 Morning Session I
Cypress
===
1. Administrivia (5 min)
2. Draft updates (
Below is a proposed update to the EMU charter to add a tunneled method.
The following are the changes to the existing charter:
- add charter item for tunneled EAP method
- modified password based item to make use of the above tunneled method
- modify "enhanced TLS" item to focus on adding channel
We have working group consensus to move forward with working on a
tunneled EAP method in order to provide the basis for a password based
EAP method. The next steps are to revise the working group charter to
include the tunneled EAP method item and make sure we have a good set of
requirements to wo
tp://www1.ietf.org/mail-archive/web/emu/current/msg00670.html
>
> We agree that this solution seems to solve the issue in the
> cleanest way.
>
> Andre Scedrov, John Mitchell, Arnab Roy, Paul Rowe
>
> >Date: Wed, 3 Oct 2007 21:22:31 -0700
> >From: "J
-
> From: Joseph Salowey (jsalowey)
> Sent: Monday, October 15, 2007 2:30 PM
> To: 'Bernard Aboba'; emu@ietf.org
> Cc: [EMAIL PROTECTED]
> Subject: RE: Revised liaison response for IEEE 802.11u EAP
> method for emergency calls
>
>
>
> > -Original
> -Original Message-
> From: Pascal Urien [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 24, 2007 6:52 AM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Subject: Re: [Emu] Moving forward with the EMU password method
>
> Hi Joe,
>
>I support m
> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 15, 2007 1:06 PM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Cc: [EMAIL PROTECTED]
> Subject: RE: Revised liaison response for IEEE 802.11u EAP
> method for emerg
I modified the liaison response below based on the comments received.
Please respond indicating if this looks OK or indicate what needs to be
modified or added.
Thanks,
Joe
==
802.11u Liaison response for EAP Methods for Emergency Comm
> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 02, 2007 1:03 PM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Cc: [EMAIL PROTECTED]
> Subject: RE: Draft liaison response for IEEE 802.11u EAP
> method for emergenc
I think this is a good approach.
> -Original Message-
> From: Charles Clancy [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 20, 2007 4:11 AM
> To: Tschofenig,Hannes (NSN - DE/Germany - MiniMD)
> Cc: emu@ietf.org
> Subject: Re: [Emu] EAP-GPSK & Key Derivation Function
>
> All,
>
I think the problem is real, although not catastrophic. I would prefer
not to remove the identity from the key derivation so either option 2 or
3 is good. I think 2 is maybe a little bit cleaner and 3 is less of a
change to the existing draft. Since we do not have many implementations
yet I would
At the IETF in Chicago we had a hum as to the direction we should take
with the password based method. I would like to clarify the choices and
determine working group consensus on the list. The two directions are
given below please express you preference by 10/25.
Option 1 - Password based metho
Hi Hannes,
Comments inline below.
> -Original Message-
> From: Hannes Tschofenig [mailto:[EMAIL PROTECTED]
> Sent: Saturday, September 22, 2007 6:23 AM
> To: Bernard Aboba
> Cc: Joseph Salowey (jsalowey); emu@ietf.org;
> [EMAIL PROTECTED]; ECRIT
> Subject: Re: D
> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 17, 2007 10:20 AM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: Draft liaison response for IEEE 802.11u EAP
>
I added these issues to the issue list at
http://www3.tools.ietf.org/wg/emu/trac/report/1
Joe
> -Original Message-
> From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD)
> [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 20, 2007 1:51 AM
> To: emu@ietf.org
> Subject: [Emu] Open Iss
The EMU working group has a liaison request from IEEE 802.11u on EAP
methods for emergency calls. The liaison request can be found on the
liaison statement page, https://datatracker.ietf.org/liaison/ (May
2007). We had a presentations and discussion of this topic at the
Chicago EMU meeting. Belo
Hi Sam,
This does sound reasonable. Some questions for the group to solidify
what it means to support channel bindings:
1) Is encryption required or is integrity protection enough.
In my opinion integrity protection should be sufficient since channel
bindings communicate parameters that are v
Below are minutes to the EMU session at IETF-69. I will also upload
them to the proceedings page. Let me know if you have any corrections.
Thanks to Mauricio and Nancy for taking good notes.
Joe
Notes from EMU meeting at IETF 69
Tuesday, July 24, 2007
Chicago
Agenda
---
+
301 - 400 of 518 matches
Mail list logo
