The following is the draft agenda for IETF 72. If there are no
comments or additions, it will be submitted later this week to the IETF
web site.
Agenda for IETF 72:
Blue sheets and Agenda updates
5 minutes
draft-ietf-emu-eaptunnel-req-00.txt
60 minutes
Intermezzo (Some people need to leave
The intent of this requirement is to protect any data sent outside the
TLS data. This would include the EAP header and any method specific
fields such as version number field. We know we cannot protect these
data before a TLS session is established, most likely we are talking
about validation after
Bernard:
There might be multiple uses cases for credential provisioning and
enrollment. One case is just like you mentioned to initial bootstrap the
device. Other case might be provisioning additional credentials used for
other applications once the device has been fully provisioned. Third
case w
Bernard:
Section 4.4 lists the requirement for channel binding as "The tunnel
method MUST be capable of supporting EAP channel bindings described
above.". I think this is the intent of the requirement. Section 4.1.1
language of "MUST support" might be too strong. Are you ok with changing
Section
Alan DeKok [mailto://[EMAIL PROTECTED] writes:
> The following is the draft agenda for IETF 72. If there are no
> comments or additions, it will be submitted later this week to the IETF
> web site.
Given some of the recent comments on the list, I wonder if it would be
permissible to discuss ea
Given this, the requirement could be rephrased to highlight the items
that need to be protected (type code, version numbers, etc.), while dropping
the
EAP Header protection requirement.
-Original Message-
From: Hao Zhou (hzhou) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2008 7:
Yes, changing the language to be consistent with Section 4.4 would be good.
I would also remove the reference to RFC 4962 Section 3, and substitute one
to RFC 4017 instead (since channel bindings are explicitly discussed there
and indicated as optional).
From: Hao Zhou (hzhou) [mailto:[EMAIL P
Sounds fine to me.
> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 09, 2008 5:05 PM
> To: Hao Zhou (hzhou); Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] Review of Requirements for an Tunnel Based
> EAP Method
>
> Given this, t
I'm ok with saying that the tunnel method MUST support attribute
extensibility and EAP methods running within it. As you say, an EAP method
could handle the credential provisioning, it doesn't need to be part of the
tunnel protocol. The WFA's WPS EAP method is an example of this.
If there i
I think this is a very good idea. +1 and all that jazz. I hope some
time can be alloted to discuss this.
Dan.
On Wed, July 9, 2008 10:28 am, Glen Zorn wrote:
> Alan DeKok [mailto://[EMAIL PROTECTED] writes:
>
>> The following is the draft agenda for IETF 72. If there are no
>> comments or
10 matches
Mail list logo
