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

Lakshminath Dondeti <ldondeti@qualcomm.com> Wed, 12 July 2006 17:56 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iwS-0008KG-K3; Wed, 12 Jul 2006 13:56:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iwR-0008K9-3F for emu@ietf.org; Wed, 12 Jul 2006 13:56:07 -0400
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0iwP-0002pA-N3 for emu@ietf.org; Wed, 12 Jul 2006 13:56:07 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6CHu0HH022176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Jul 2006 10:56:01 -0700
Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-91.qualcomm.com [10.50.76.91]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6CHtw5I026678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jul 2006 10:55:59 -0700 (PDT)
Message-Id: <7.0.1.0.2.20060712105107.06f86208@qualcomm.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Wed, 12 Jul 2006 10:55:56 -0700
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
From: Lakshminath Dondeti <ldondeti@qualcomm.com>
Subject: Re: [Emu] Review of draft-clancy-emu-eap-shared-secret-01
In-Reply-To: <44B5357C.5060300@gmx.net>
References: <7.0.1.0.2.20060711072555.043cf6c0@qualcomm.com> <20060712165015.57845.qmail@web54402.mail.yahoo.com> <7.0.1.0.2.20060712100845.0418ec58@qualcomm.com> <44B5357C.5060300@gmx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: emu@ietf.org
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/emu>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
Errors-To: emu-bounces@ietf.org

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@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@ietf.org
>>https://www1.ietf.org/mailman/listinfo/emu


_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu