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

[Hannes Tschofenig <[e-mail]>]

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 <[e-mail]> 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
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/emu
> 
> 
> 


_______________________________________________
Emu mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/emu