I'd be glad to add a reference.
On 9/1/10 7:40 AM, "Hoeper Katrin-QWKN37" wrote:
> I agree. That's why I was thinking that adding a reference that makes
> implementers aware of this problem would be a good idea. Then they can
> make an educated decision about whether they want to implement
> ad
The basic reason for this is that EAP methods have a well defined mechanism
to output key material. There hasn't been a mechanism to import data into a
method, channel bindings may change this.
Key generating EAP methods export an MSK. The MSK is then mixed with key
material extracted from the TL
On 9/1/10 4:56 PM, "Sam Hartman" wrote:
>>>>>> "Joe" == Joe Salowey writes:
>
> Joe> The basic reason for this is that EAP methods have a well
> Joe> defined mechanism to output key material. There hasn't been a
> Joe&
I like the direction the document is taking. I think the following are the
biggest open issues in the document;
- Refinement of use cases - not all of the examples in the document are
compelling (see detailed comments below). These need refining and we should
also look for use cases dealing
The EMU meeting is currently scheduled for Wednesday, November 10, 1510-1610.
I would like to focus most of this time on EAP channel bindings. Please let me
know if you have agenda items for the meeting. Priority will be given to items
relevant towards progressing the channel bindings docume
IETF-79 - EMU Working Group
WEDNESDAY, November 10, 2010,
1510-1610 Afternoon Session II
Garden Ballroom 1
1. Administrivia (note takers, blue sheets, agenda) - 5min
2. EAP Channel Bindings - Sam Hartman - 35min
http://tools.ietf.org/html/draft-ietf-emu-c
Draft meeting minutes available here:
http://www.ietf.org/proceedings/79/minutes/emu.txt
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Jan 10, 2011, at 11:51 AM, Sam Hartman wrote:
> At the last IETF, Glen proposed that rather than using diameter's
> namespace for channel binding AVPs we use the RADIUS namespace. There
> were two aspects to this concern. One is that diameter has a larger
> length value for attributes. If we'
Forwarding to the EMU list which works on EAP methods.
Begin forwarded message:
> From: Robert Cragie
> Date: February 22, 2011 7:30:27 AM PST
> To: t...@ietf.org
> Subject: [TLS] Alert processing in RFC 5216
> Reply-To: robert.cra...@gridmerge.com
>
> I have a question about RFC 5216 (EAP-TL
At first glance it looks to me like this is an issue. I'm going to add this as
an agenda item for Prague.
Joe
On Mar 14, 2011, at 8:11 PM, Bernard Aboba wrote:
> Since the EAP Session-Id is utilized in EAP lower layers such as IEEE
> 802.1X-2010, the interoperability of an EAP method impleme
Here is the draft agenda for IETF 80
IETF-80 - EMU Working Group
WEDNESDAY, March 30, 2011
1300-1500 Afternoon Session I
Karlin II & III
1. Administrivia (note takers, blue sheets, agenda) - 5 Min
2. EAP Session ID - EAP-SIM and EAP-AKA - 20 Min
3. EAP
Draft Minutes from the EMU meeting at IETF 80 are available at
http://www.ietf.org/proceedings/80/minutes/emu.txt.
Let me know if you have any corrections.
Thanks,
Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
This is a consensus call to validate the direction the draft-ietf-emu-chbind-07
and confirm the consensus around the encoding of the channel binding TLV.
Please respond to the following questions by May 2, 2011.
1. Do you agree with the direction taken in draft-ietf-emu-chbind-07. More
spe
This consensus call closes next week. This is an important working group work
item. If you have an opinion about this issue please send it to the list so we
can keep the work moving forward.
Thanks,
Joe
On Apr 18, 2011, at 11:11 AM, Joe Salowey wrote:
> This is a consensus call to valid
AM, Joe Salowey wrote:
> This is a consensus call to validate the direction the
> draft-ietf-emu-chbind-07 and confirm the consensus around the encoding of the
> channel binding TLV. Please respond to the following questions by May 2,
> 2011.
>
> 1. Do you agree with the
On May 16, 2011, at 11:29 AM, Dorothy Stanley wrote:
> I support allocating a new method type for the new standard method, sooner,
> rather than later.
>
> The new method is defined by an IETF group, based on submissions/modifications
> from multiple parties, and should carry/use an IETF rather
One benefit I see in keeping the same EAP method type code is it allows secure
version negotiation from v1 to v2 with version rollback protection. However,
moving to a new EAP type code would seem to make EAP method negotiation
somewhat better since all implementation may not implement v1. I'
On May 23, 2011, at 5:50 PM, Glen Zorn wrote:
> On 5/24/2011 12:53 AM, Joe Salowey wrote:
>
>> One benefit I see in keeping the same EAP method type code is it allows
>> secure version negotiation from v1 to v2 with version rollback protection.
>>
>> However,
equivalent code point
assigned.I'll add these to the list of changes for the next revision.
Cheers,
Joe
On May 30, 2011, at 11:25 PM, Glen Zorn wrote:
> On 5/31/2011 11:08 AM, Joe Salowey wrote:
>
>>
>> On May 23, 2011, at 5:50 PM, Glen Zorn wrote:
>>
>>&
Hi Sam,
I think you list some good reasons for going with encoding 2. I'm comfortable
with including this in the draft given that the document is still going through
working group review. I'll see if I can get some help on reviewing the 802.11
text, but I think it would be OK to move this int
EMU has been given a 2 hour slot on Tuesday Afternoon (7/26) from 13:00 to
15:00 PM.
Please send any requests for agenda slots to the chairs.
Thanks,
Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Below is a draft agenda for EMU at IETF 81. Please let the chairs know if you
have any updates.
Thanks,
Joe
EMU Working Group Agenda
IETF 81
Tuesday, July 26 1300-1500
---
1. Administrivia (5 min)
Note takes, blue sheets, Note Well, Agenda
2. Channel Bind
At the meeting in Quebec we discussed removing attributes specific to
particular media types or lower layers and including recommendations for a
small number of generally useful attributes in the draft.
The attribute that seems to be most useful would be one that indicates what
protocol is ca
On Aug 10, 2011, at 1:41 AM, Glen Zorn wrote:
> On 8/10/2011 12:31 PM, Joe Salowey wrote:
>
>> At the meeting in Quebec we discussed removing attributes specific to
>> particular media types or lower layers and including recommendations for a
>> small number of genera
This is the working group last call for draft-ietf-emu-chbind-09. Please send
your comments to the list by October 21, 2011.
Thanks,
Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
THe working group last call for draft-ietf-emu-chbind-09 ends October 21, 2011.
So far we have received few comments on the list. Please review the
document and post your comments to the list. Comments indicating that you have
read the document and not found any issues are also useful.
On Oct 19, 2011, at 3:52 PM, Dan Harkins wrote:
>
> Hi Sam,
>
> On Wed, October 19, 2011 12:59 pm, Sam Hartman wrote:
>> Hi. I've added PANA (pre-authentication).
>>
>> I wonder about the whole lower layer table.
>> Why is it important to distinguish PANA with pre-auth from pana without
>> pr
On Oct 19, 2011, at 5:05 PM, Yoshihiro Ohba wrote:
> Hi Sam,
>
> Since authorization and accounting with the use of the
> pre-authentication may be different from those with the use of normal
> authentication, it would be good to differentiate pre-auth and without
> pre-auth for network access a
There have not been any more comments on the list so please prepare a new draft
if you have time before the cutoff. I would also like to have a discussion of
this draft and last call changes in the EMU meeting in Taiwan.
One additional issue I found was in section 9 the NAS-Identifier text
r
EMU is schedule for Tuesday, November 15 from 9:00-11:30. Please send
requests for agenda time to the chairs.
Thanks,
Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
THe IETF 82 EMU agenda is posted in the usual place. Please let me know if you
have any corrections.
http://www.ietf.org/proceedings/82/agenda/emu.txt
Cheers,
Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
EMU met on Tuesday morning. EAP Channel bindings (draft-ietf-emu-chbind-11)
completed working group last call and a new draft has been issued incorporating
most of the comments. There are a few open issues so another revision will be
needed before forwarding to IESG.Open issues on the EA
I think the following appendices of the channel binding document are no longer
supported by the rest of the text and defined attributes. I think they are out
of date and should be removed:
A.3. Downgrading attacks
A.4. Bogus Beacons in IEEE 802.11r
A.5. Forcing false authorization in IEEE 80
I'm OK with the approach you propose.
Joe
On Dec 14, 2011, at 11:25 AM, Sam Hartman wrote:
>>>>>> "Joe" == Joe Salowey writes:
>
>Joe> I think the following appendices of the channel binding
>Joe> document are no longer support
, does he or she believe this
version is ready for forwarding to the IESG for publication?
Joe Salowey, EMU working group co-chair, is the Working Group Shepherd for this
document. The shepherd has reviewed the current version and believes it is
ready for publication.
(1.b) Has the
Back when we were looking at the crypto binding problem, a MITM in the
infrastructure was not part of the threat model. We had some discussion of
this, but we decided were able to get away with just using the MSK and that
this would be easier for deployment since the EMSK wasn't really availabl
er sell it.
Cheers,
Joe
On Jan 12, 2012, at 11:11 AM, Sam Hartman wrote:
>>>>>> "Joe" == Joe Salowey writes:
>
>Joe> Back when we were looking at the crypto binding problem, a MITM
>Joe> in the infrastructure was not part of the threat mod
The current tunnel method draft contains TLVs for PKCS#10 and PKCS#7 TLVs.
The purpose of either of these TLVs is not well described. I think we need to
describe the purpose of these TLVs better or remove them.
The PKCS#10 TLV makes a brief reference to the Simple PKI request of CMS (RFC
On Feb 29, 2012, at 10:09 PM, Dan Harkins wrote:
>
> On Wed, February 29, 2012 9:57 pm, Joe Salowey wrote:
>> The current tunnel method draft contains TLVs for PKCS#10 and PKCS#7 TLVs.
>>
>> The purpose of either of these TLVs is not well described. I think we
>>
rovide a level of
> authenticity to the certificates contained therein. Peers are advised
> to take into account the implied authority of the EAP server and to
> constrain the trust it can achieve through the trust anchor received
> in a PKCS#7 TLV.
>
> 4. Remove reference to RFC5422
>
Hi Sam,
If we added something along the following lines to the document would it be
sufficient:
"When performing server certificate validation implementations MUST provide
support rules in RFC 5280 for validating certificates against a known trust
anchor. In addition, implementations SHOULD s
IETF-83 EMU Agenda
THURSDAY, March 29, 2012, 520-1720 Afternoon Session II, Room 252A
Agenda
---
1. Administrivia (blue sheets, agenda, note takers, jabber) (5 min)
2. Mutual Crypto Binging and Channel Binding (Sam Hartman) (50 min)
- draft-hartman-emu-mutual-crypto-bind
- draft-ietf-emu-
Please respond on the list by May 25, 2012.
Thanks,
Joe
On May 14, 2012, at 12:10 PM, Sam Hartman wrote:
>
>
> This version includes a large number of changes mostly to respond to the
> secdir review.
>
> I'm not entirely sure that Stephen Hanna will be happy with the changes
> in section 9,
The NEA working group has produced a draft for carrying NEA posture methods
within EAP. It would be helpful if some EMU working group members reviewed the
draft. Please send your comments to the EMU list by June 4, 2012.
Thanks,
Joe
Begin forwarded message:
> From: internet-dra...@ietf.org
, 2012, at 2:01 PM, Joe Salowey wrote:
> The NEA working group has produced a draft for carrying NEA posture methods
> within EAP. It would be helpful if some EMU working group members reviewed
> the draft. Please send your comments to the EMU list by June 4, 2012.
>
> Th
So, is your concern with using only MSK crypto binding with an inner EAP
authentication method used to authenticate an unauthenticated/poorly
authenticated tunnel or is it more specific to the nea-pt-eap method?
For the first concern it may be sufficient to discuss the issue in the security
c
46 matches
Mail list logo
