Narayanan, Vidya | 8 Jul 07:50 2006

Review of draft-simon-emu-rfc2716bis-02

All,
Apologies for such a long delay - this review is long overdue (since I
volunteered to review 01 after Dallas)! 

The draft is mostly in good shape. I have the following
comments/questions on it (I'm trying not to cover the ones that Joe's
comments have already addressed or those that are already under
discussion). 

Technical Comments: 

1. Parts of the draft seem to be written with PPP as the EAP lower layer
in mind (e.g., Fragmentation and certificate revocation text) - given
that EAP is widely used over other lower layers now, there should
probably be some text to support that. 

2. Section 2 refers to client authentication via means other than
certificates. While client authentication is optional in TLS, when
present, isn't it always based on certs? I haven't fully read 4346bis -
perhaps something has changed there. Other TLS-based protocols will be
different EAP methods (and hence, different EAP Types) anyway, right?
So, I'm confused by the text on other peer authentication means. 

3. Towards the end of section 2.1, the following text is present "The
peer will then verify the hash in order to authenticate the EAP server."
A hash cannot be sufficient to authenticate the server. I think the
"verify_data" in the TLS finished message is a PRF - so, I'd imagine
this to be an HMAC? I'd think that either an HMAC or a signature is
required to authenticate the server. 

(Continue reading)

Joseph Salowey (jsalowey | 11 Jul 15:24 2006
Picon

Presentations for EMU

The EMU agenda is available here:

http://www3.ietf.org/proceedings/06jul/agenda/emu.txt

Presenters please send me your presentations sometime today so I can
upload them.  

Thank you,

Joe
Lakshminath Dondeti | 12 Jul 14:49 2006

Review of draft-clancy-emu-eap-shared-secret-01

At 12:41 AM 7/10/2006, you wrote:

>EMU Working Group                                              T. Clancy
>Internet-Draft                                                       LTS
>Expires: December 28, 2006                                 H. Tschofenig
>                                                                  Siemens
>                                                            June 26, 2006
>
>
>                EAP Generalized Pre-Shared Key (EAP-GPSK)
>                draft-clancy-emu-eap-shared-secret-01.txt

<snip>

>1.  Introduction
>
>    EAP Generalized Pre-Shared Key (EAP-GPSK) is an EAP method defining a
>    generalized pre-shared key authentication technique.  Mutual
>    authentication is achieved through a nonce-based exchange that is
>    secured by a pre-shared key.
>
>    At present, several pre-shared key EAP methods are specified, most
>    notably
>    o  EAP-PAX [I-D.clancy-eap-pax]
>    o  EAP-PSK [I-D.bersani-eap-psk]
>    o  EAP-TLS-PSK [I-D.otto-emu-eap-tls-psk] and
>    o  EAP-SAKE [I-D.vanderveen-eap-sake].
>    Each proposal has its particular benefits but also its particular
>    deficiencies.  EAP-GPSK is a new EAP method that tries to combine the
>    most valuable characteristics of each of these methods and therefore
(Continue reading)

M. Vanderveen | 12 Jul 18:50 2006
Picon

Re: Review of draft-clancy-emu-eap-shared-secret-01

I agree with Lakshminath regarding the point about having actual ciphersuites in a different RFC, so they can be updated.
 
Personally I'm somewhat disappointed that AES-EAX was chosen, even though it's fame is that is simpler than CCM, which is what 802.11i proposes. Not having participated in the discussions on algorithm selection, I am wondering if anybody have given thought to what can be done to help the power and memory-limited mobile, who now has to have *hardware* to please everybody: the EAP for network access, SAP 4-way handshake for link-layer access, MobileIP for mobility, VPN to sooothe operator concerns, etc, to name a few possibilities. Not all of these must be done in hw, of course. What do the implementors have to say about these?
 
Michaela

Lakshminath Dondeti <ldondeti <at> qualcomm.com> wrote:
>
> EAP-GPSK offers cryptographic flexibility. At the beginning, the
> EAP server selects a set of cryptographic algorithms and key
> sizes, a so called ciphersuite. The current version of EAP-GPSK
> comprises two ciphersuites, but additional ones can be easily
> added.

Do we mean server proposes a suite of algms and the client selects
one? We probably need to think about the ciphersuite thing a
bit. Perhaps the IKEv2 like approach of the base protocol nailed
down in a document and have a "living" RFC that updates ciphersuites
as necessary.

Do you Yahoo!?
Next-gen email? Have it all with the all-new Yahoo! Mail Beta.
_______________________________________________
Emu mailing list
Emu <at> ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Lakshminath Dondeti | 12 Jul 19:17 2006

Re: Review of draft-clancy-emu-eap-shared-secret-01

Michaela,

Please feel free to start the discussion on algorithm selection.  The 
DT output is just "one" opinion.  If there is an argument for or 
against the choices of algorithms, the WG I am sure would want to hear it.

I am not entirely sure CCM is the right mode, but I am open to discuss that.

Lakshminath

At 09:50 AM 7/12/2006, M. Vanderveen wrote:
>I agree with Lakshminath regarding the point about having actual 
>ciphersuites in a different RFC, so they can be updated.
>
>Personally I'm somewhat disappointed that AES-EAX was chosen, even 
>though it's fame is that is simpler than CCM, which is what 802.11i 
>proposes. Not having participated in the discussions on algorithm 
>selection, I am wondering if anybody have given thought to what can 
>be done to help the power and memory-limited mobile, who now has to 
>have *hardware* to please everybody: the EAP for network access, SAP 
>4-way handshake for link-layer access, MobileIP for mobility, VPN to 
>sooothe operator concerns, etc, to name a few possibilities. Not all 
>of these must be done in hw, of course. What do the implementors 
>have to say about these?
>
>Michaela
>
>Lakshminath Dondeti <ldondeti <at> qualcomm.com> wrote:
> >
> > EAP-GPSK offers cryptographic flexibility. At the beginning, the
> > EAP server selects a set of cryptographic algorithms and key
> > sizes, a so called ciphersuite. The current version of EAP-GPSK
> > comprises two ciphersuites, but additional ones can be easily
> > added.
>
>Do we mean server proposes a suite of algms and the client selects
>one? We probably need to think about the ciphersuite thing a
>bit. Perhaps the IKEv2 like approach of the base protocol nailed
>down in a document and have a "living" RFC that updates ciphersuites
>as necessary.
>
>
>Do you Yahoo!?
>Next-gen email? Have it all with the

><http://us.rd.yahoo.com/evt=42241/*http://advision.webevents.yahoo.com/handraisers>all-new 
>Yahoo! Mail Beta.
Hannes Tschofenig | 12 Jul 19:16 2006
Picon
Picon

Re: Review of draft-clancy-emu-eap-shared-secret-01

Hi Michaela,

M. Vanderveen wrote:
> I agree with Lakshminath regarding the point about having actual 
> ciphersuites in a different RFC, so they can be updated.

I don't agree. Why would this be useful? You then have to read two 
documents to implement the EAP method. It would be the same as putting 
the packet format in another document.

New ciphersuites can be added later. They would be in a separate document.

>  
> Personally I'm somewhat disappointed that AES-EAX was chosen, even 
> though it's fame is that is simpler than CCM, which is what 802.11i 
> proposes. Not having participated in the discussions on algorithm 
> selection, I am wondering if anybody have given thought to what can be 
> done to help the power and memory-limited mobile, who now has to have 
> *hardware* to please everybody: the EAP for network access, SAP 4-way 
> handshake for link-layer access, MobileIP for mobility, VPN to sooothe 
> operator concerns, etc, to name a few possibilities. Not all of these 
> must be done in hw, of course. What do the implementors have to say 
> about these?
There was a discussion about this issue during today's meeting. There 
was indeed tendency to avoid EAX usage and focus on CCM instead.

Ciao
Hannes

>  
> Michaela
> 
> */Lakshminath Dondeti <ldondeti <at> qualcomm.com>/* wrote:
> 
>      >
>      > EAP-GPSK offers cryptographic flexibility. At the beginning, the
>      > EAP server selects a set of cryptographic algorithms and key
>      > sizes, a so called ciphersuite. The current version of EAP-GPSK
>      > comprises two ciphersuites, but additional ones can be easily
>      > added.
> 
>     Do we mean server proposes a suite of algms and the client selects
>     one? We probably need to think about the ciphersuite thing a
>     bit. Perhaps the IKEv2 like approach of the base protocol nailed
>     down in a document and have a "living" RFC that updates ciphersuites
>     as necessary.
> 
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Next-gen email? Have it all with the all-new Yahoo! Mail Beta. 
> <http://us.rd.yahoo.com/evt=42241/*http://advision.webevents.yahoo.com/handraisers> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Emu mailing list
> Emu <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
Hannes Tschofenig | 12 Jul 19:46 2006
Picon
Picon

Re: Review of draft-clancy-emu-eap-shared-secret-01

I agree that a discussion about the algorithms is good.
Moving them into a separate document isn't.

Lakshminath Dondeti wrote:
> Michaela,
> 
> Please feel free to start the discussion on algorithm selection.  The DT 
> output is just "one" opinion.  If there is an argument for or against 
> the choices of algorithms, the WG I am sure would want to hear it.
> 
> I am not entirely sure CCM is the right mode, but I am open to discuss 
> that.
> 
> Lakshminath
> 
> At 09:50 AM 7/12/2006, M. Vanderveen wrote:
> 
>> I agree with Lakshminath regarding the point about having actual 
>> ciphersuites in a different RFC, so they can be updated.
>>
>> Personally I'm somewhat disappointed that AES-EAX was chosen, even 
>> though it's fame is that is simpler than CCM, which is what 802.11i 
>> proposes. Not having participated in the discussions on algorithm 
>> selection, I am wondering if anybody have given thought to what can be 
>> done to help the power and memory-limited mobile, who now has to have 
>> *hardware* to please everybody: the EAP for network access, SAP 4-way 
>> handshake for link-layer access, MobileIP for mobility, VPN to sooothe 
>> operator concerns, etc, to name a few possibilities. Not all of these 
>> must be done in hw, of course. What do the implementors have to say 
>> about these?
>>
>> Michaela
>>
>> Lakshminath Dondeti <ldondeti <at> qualcomm.com> wrote:
>> >
>> > EAP-GPSK offers cryptographic flexibility. At the beginning, the
>> > EAP server selects a set of cryptographic algorithms and key
>> > sizes, a so called ciphersuite. The current version of EAP-GPSK
>> > comprises two ciphersuites, but additional ones can be easily
>> > added.
>>
>> Do we mean server proposes a suite of algms and the client selects
>> one? We probably need to think about the ciphersuite thing a
>> bit. Perhaps the IKEv2 like approach of the base protocol nailed
>> down in a document and have a "living" RFC that updates ciphersuites
>> as necessary.
>>
>>
>> Do you Yahoo!?
>> Next-gen email? Have it all with the 
>>
<http://us.rd.yahoo.com/evt=42241/*http://advision.webevents.yahoo.com/handraisers>all-new 
>> Yahoo! Mail Beta.
> 
> 
> 
> _______________________________________________
> Emu mailing list
> Emu <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 
> 
Lakshminath Dondeti | 12 Jul 19:55 2006

Re: Review of draft-clancy-emu-eap-shared-secret-01

At 10:46 AM 7/12/2006, Hannes Tschofenig wrote:
>I agree that a discussion about the algorithms is good.

At some point in the near future I will try and argue about 
algorithms :).  I hope to see others' proposals and views in the meanwhile.

>Moving them into a separate document isn't.

So I am drawing from the experience of IKEv2 and ESPv3.  The idea is 
purely based on document maintenance process.  If the algorithms are 
in a separate document, rev'ving them is easier without the worry of 
revising the based protocol itself.  Anyway, we don't have to discuss 
this to death.  If other folks feel the same way, they'll speak up, 
but otherwise, I am happy to let it die.

Lakshminath

>Lakshminath Dondeti wrote:
>>Michaela,
>>Please feel free to start the discussion on algorithm 
>>selection.  The DT output is just "one" opinion.  If there is an 
>>argument for or against the choices of algorithms, the WG I am sure 
>>would want to hear it.
>>I am not entirely sure CCM is the right mode, but I am open to discuss that.
>>Lakshminath
>>At 09:50 AM 7/12/2006, M. Vanderveen wrote:
>>
>>>I agree with Lakshminath regarding the point about having actual 
>>>ciphersuites in a different RFC, so they can be updated.
>>>
>>>Personally I'm somewhat disappointed that AES-EAX was chosen, even 
>>>though it's fame is that is simpler than CCM, which is what 
>>>802.11i proposes. Not having participated in the discussions on 
>>>algorithm selection, I am wondering if anybody have given thought 
>>>to what can be done to help the power and memory-limited mobile, 
>>>who now has to have *hardware* to please everybody: the EAP for 
>>>network access, SAP 4-way handshake for link-layer access, 
>>>MobileIP for mobility, VPN to sooothe operator concerns, etc, to 
>>>name a few possibilities. Not all of these must be done in hw, of 
>>>course. What do the implementors have to say about these?
>>>
>>>Michaela
>>>
>>>Lakshminath Dondeti <ldondeti <at> qualcomm.com> wrote:
>>> >
>>> > EAP-GPSK offers cryptographic flexibility. At the beginning, the
>>> > EAP server selects a set of cryptographic algorithms and key
>>> > sizes, a so called ciphersuite. The current version of EAP-GPSK
>>> > comprises two ciphersuites, but additional ones can be easily
>>> > added.
>>>
>>>Do we mean server proposes a suite of algms and the client selects
>>>one? We probably need to think about the ciphersuite thing a
>>>bit. Perhaps the IKEv2 like approach of the base protocol nailed
>>>down in a document and have a "living" RFC that updates ciphersuites
>>>as necessary.
>>>
>>>
>>>Do you Yahoo!?
>>>Next-gen email? Have it all with the

>>><http://us.rd.yahoo.com/evt=42241/*http://advision.webevents.yahoo.com/handraisers>all-new 
>>>Yahoo! Mail Beta.
>>
>>_______________________________________________
>>Emu mailing list
>>Emu <at> ietf.org
>>https://www1.ietf.org/mailman/listinfo/emu
Hannes Tschofenig | 12 Jul 20:05 2006
Picon
Picon

Re: Review of draft-clancy-emu-eap-shared-secret-01

Hi Lakshminath,

Lakshminath Dondeti wrote:
> At 10:46 AM 7/12/2006, Hannes Tschofenig wrote:
> 
>> I agree that a discussion about the algorithms is good.
> 
> 
> At some point in the near future I will try and argue about algorithms 
> :).  I hope to see others' proposals and views in the meanwhile.

Good. Looking forward to it.

During the mailing list discussions I proposed to recycle some of the 
IKEv2 algorithms. Maybe that's something we should be doing again.
RFC 4307 would be a good pointer.

> 
>> Moving them into a separate document isn't.
> 
> 
> So I am drawing from the experience of IKEv2 and ESPv3.  The idea is 
> purely based on document maintenance process.  If the algorithms are in 
> a separate document, rev'ving them is easier without the worry of 
> revising the based protocol itself.  Anyway, we don't have to discuss 
> this to death.  If other folks feel the same way, they'll speak up, but 
> otherwise, I am happy to let it die.
I am not sure whether IKEv2 or ESPv3 is a good example. Our goal was to 
develop a simple EAP method. To have something interoperable we have to 
define a mandatory to implement ciphersuite. I strongly believe that we 
have to put this ciphersuite into the EAP method document.

If you have to revise the mandatory to implement ciphersuite (because it 
is broken) then you must create a new EAP method document.

Ciao
Hannes

> 
> Lakshminath
> 
> 
>> Lakshminath Dondeti wrote:
>>
>>> Michaela,
>>> Please feel free to start the discussion on algorithm selection.  The 
>>> DT output is just "one" opinion.  If there is an argument for or 
>>> against the choices of algorithms, the WG I am sure would want to 
>>> hear it.
>>> I am not entirely sure CCM is the right mode, but I am open to 
>>> discuss that.
>>> Lakshminath
>>> At 09:50 AM 7/12/2006, M. Vanderveen wrote:
>>>
>>>> I agree with Lakshminath regarding the point about having actual 
>>>> ciphersuites in a different RFC, so they can be updated.
>>>>
>>>> Personally I'm somewhat disappointed that AES-EAX was chosen, even 
>>>> though it's fame is that is simpler than CCM, which is what 802.11i 
>>>> proposes. Not having participated in the discussions on algorithm 
>>>> selection, I am wondering if anybody have given thought to what can 
>>>> be done to help the power and memory-limited mobile, who now has to 
>>>> have *hardware* to please everybody: the EAP for network access, SAP 
>>>> 4-way handshake for link-layer access, MobileIP for mobility, VPN to 
>>>> sooothe operator concerns, etc, to name a few possibilities. Not all 
>>>> of these must be done in hw, of course. What do the implementors 
>>>> have to say about these?
>>>>
>>>> Michaela
>>>>
>>>> Lakshminath Dondeti <ldondeti <at> qualcomm.com> wrote:
>>>> >
>>>> > EAP-GPSK offers cryptographic flexibility. At the beginning, the
>>>> > EAP server selects a set of cryptographic algorithms and key
>>>> > sizes, a so called ciphersuite. The current version of EAP-GPSK
>>>> > comprises two ciphersuites, but additional ones can be easily
>>>> > added.
>>>>
>>>> Do we mean server proposes a suite of algms and the client selects
>>>> one? We probably need to think about the ciphersuite thing a
>>>> bit. Perhaps the IKEv2 like approach of the base protocol nailed
>>>> down in a document and have a "living" RFC that updates ciphersuites
>>>> as necessary.
>>>>
>>>>
>>>> Do you Yahoo!?
>>>> Next-gen email? Have it all with the 
>>>>
<http://us.rd.yahoo.com/evt=42241/*http://advision.webevents.yahoo.com/handraisers>all-new 
>>>> Yahoo! Mail Beta.
>>>
>>>
>>> _______________________________________________
>>> Emu mailing list
>>> Emu <at> ietf.org
>>> https://www1.ietf.org/mailman/listinfo/emu
> 
> 
> 
Joseph Salowey (jsalowey | 13 Jul 16:05 2006
Picon

IETF-66 EMU working group summary

The EMU working group meet at 9AM on Wednesday

The first topic of discussion was presented by Hannes Tschofenig on the
draft Generalized Pre-shared key (GPSK) EAP method which specifies a PSK
EAP Method.  There was consensus in the room to take this on as a
working group item to meet the PSK charter item with a modification to
the defined cipersuites (switch AES-CCM for AES-EAX).  The action is to
solicit comments on if this should be accepted as a working group item
on the EMU list. 

Next Bernard Aboba discussed the RFC2716bis (EAP-TLS) document.  The
presentation discussed some open issues of the draft.  Interoperability
problems with the TLS 3DES ciphersuites were discussed. It was noted
that some variants of EAP methods based on TLS method used the same
label strings in deriving the MSK from the TLS master secret. This is
thought to lead to some potential problems so it might be advisable to
use different label strings for this in the future.  Lastly, identity
privacy using TLS was discussed.  The draft needs to be updated and
listed as a working group draft on the charter page.

Next we had some presentations on EAP-TLS related methods.  Hannes
Tschofenig presented on EAP-TLS-PSK which is an EAP method specifically
for TLS PSK ciphersuites. Pascal Urien presented on an identity privacy
scheme for TLS.  The general feeling was this would be better evaluated
by the TLS group. Hao Zhou presented on some possible enhancements for
EAP-TLS.  More discussion on enhanced EAP-TLS is needed on the list. 

Dave Mitton presented on issues implementing new EAP methods.  One
problem was that some access points don't pass some EAP types they don't
know about.  The action is to assist the WIFI alliance develop tests for
this.   

Gmane