headers
Joe Salowey | 13 Jun 2011 22:22
Picon
Favicon

Re: Results of consensus call on tunnel method document

It looks like we have rough consensus for a new EAP type.   I Agree, that with a new EAP type it makes sense to
start the version at 1.  I was originally thinking of the SSL 3.0 to TLS 1.0 transition where the protocol
version went from 3.0 to 3.1, but in that case TLS did not have an 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:
>> 
>>> 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, moving to a new EAP type code would seem to make EAP method negotiation somewhat better since
all implementation may not implement v1.   
>>>> 
>>>> I'm OK with assigning a new EAP method type code,  but I'd like to try to maintain some backward
compatibility with the v1 versioning in the case that v1 
>>>> 
>>>> implementations find it advantageous to negotiate the v2 feature set under the v1 type code. 
>>> 
>>> None of this seems to me to be relevant to the IETF, the emu WG or the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Thomsen | 7 Jun 2011 17:41
Favicon

Re: draft-urien-eap-smartcard-20.txt

Hi Pascal,

sorry, I don't quite understand what you mean by "former EAP-AKA version", but I've stumpled upon a few
things I don't quite understand:

1:
--
In test #2 (Wrong SQN) you're calculating MAC-S with a non-zero AMF giving 7CD924E739F12369. According to
3GPP TS 33.102 AMF is set to zeros when calculating AUTS. When doing that I get 0010C1DA38A75A31 instead.

According to RFC4187 AT_AUTS should include "the AKA AUTS parameter, 112 bits" I don't see anything about
the AMF field not being zeroed, as it is per usual.

2:
--
In test #6 (Reauth, Good Counter) the counter value is 0000, whereas RFC4187 specifies that the minimum
counter value of the first packet should be 0001. Also, you use the 64-byte MSK value generated in test #1
instead of MK, whereas RFC4187 specifies XKEY'=SHA1(Identity|counter|NONCE_S|MK). This obviously
gives a quite different result than what you get.

3:
--
In the "Get MSK" commands in test #1 and test #6 the first 32 bytes of MSK are switched with the last 32 bytes of
MSK. I don't see anything in your document stating that this should be the behaviour.

4:
--
In test #6 and test #7 the MAC is not calculated over (EAP-packet | Nounce-S), as specified in RFC4187.

Kind regards,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sam Hartman | 28 Jun 2011 21:33
Picon
Favicon

Proposed changes for Channel Binding draft


Over the past couple of days I've been organizing proposed edits for the
channel binding document.

First, I could really use some help producing some ascii art diagrams. I
think I have non-ascii-art diagrams for the packets involved; is anyone
willing to step forward and help with this?

Secondly, I'd like to ask the chairs' permission to revisit the encoding
decision.  I was uncomfortable with how rough that consensus was and
despite being not in the rough, I've been trying to work through whether
we're doing the right thing.

A couple of things have caused me to believe that Alan is right and that
encoding #2 (re-using RADIUS encoding for RADIUS AVPs) is the right
approach.

1) With encoding 1 (the current text) we cannot encode an attribute
value greater than 254 octets. This isn't an issue for RADIUS, but if we
ever had some other attribute format it could be an issue. We all agree
that 255 octets is as long (or longer) than any attribute we'd want to
see in channel binding.  However  with overhead for things like vendor
numbers, diameter attribute numbers or the like, I'm concerned that in
the future we might be off by one or two octets in what  we can encode
vs what we need to encode.

2) I recently re-read draft-ietf-radext-radius-extensions again.  RADIUS
attribue naming is getting more complicated.  I think there's more
RADIUS-specific code to re-use.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Joe Salowey | 28 Jun 2011 23:10
Picon
Favicon

Re: Proposed changes for Channel Binding draft

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 into a separate document if it is going to
hold up the main document.  

Cheers,

Joe

On Jun 28, 2011, at 12:33 PM, Sam Hartman wrote:

> 
> 
> Over the past couple of days I've been organizing proposed edits for the
> channel binding document.
> 
> First, I could really use some help producing some ascii art diagrams. I
> think I have non-ascii-art diagrams for the packets involved; is anyone
> willing to step forward and help with this?
> 
> Secondly, I'd like to ask the chairs' permission to revisit the encoding
> decision.  I was uncomfortable with how rough that consensus was and
> despite being not in the rough, I've been trying to work through whether
> we're doing the right thing.
> 
> A couple of things have caused me to believe that Alan is right and that
> encoding #2 (re-using RADIUS encoding for RADIUS AVPs) is the right
> approach.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hoeper Katrin-QWKN37 | 29 Jun 2011 00:29
Favicon

Re: Proposed changes for Channel Binding draft

Hi Sam,

I volunteer to create the ascii-art diagrams. Please send me your files,
including existing images.

Katrin

PS: My new contact info

Katrin Hoeper
Motorola Solutions, Inc
1301 E Algonquin Rd
Schaumburg, IL 60196
USA
khoeper <at> motorolasolutions.com

-----Original Message-----
From: emu-bounces <at> ietf.org [mailto:emu-bounces <at> ietf.org] On Behalf Of
Sam Hartman
Sent: Tuesday, June 28, 2011 2:34 PM
To: emu <at> ietf.org
Subject: [Emu] Proposed changes for Channel Binding draft

Over the past couple of days I've been organizing proposed edits for the
channel binding document.

First, I could really use some help producing some ascii art diagrams. I
think I have non-ascii-art diagrams for the packets involved; is anyone
willing to step forward and help with this?
(Continue reading)

Permalink | Reply | 1 comment |

Gmane