would
strenghten the binding between identity and key.
We definitely need to add some specific text on what to do if MACs fail.
I imagine the server would send an EAP-Failure if it occured after
packet 2, and others would be silently dropped.
--
Dr. Charles Clancy, Research Scientist
Lab
ld the conversation just time out?
Perhaps we should add a "MAC Failed" message as Jouni suggested?
Sending it would leave the server state unchanged.
--
t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy
___
Emu mailing list
If the EAP Server is
unreachable, the client would never have received EAP-GPSK1.
--
t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
to define a mandatory to implement ciphersuite. I strongly
> believe that we have to put this ciphersuite into the EAP method
> document.
I think one document makes the most sense.
--
t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy
__
x27; opinions on EAX vs. CCM.
We could replace AES-EAX with AES-CBC. Would address both your concerns?
--
t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Interesting idea, but what does it gain you? Why not just use an
AES-CBC and CMAC ciphersuite?
--
t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy
Lakshminath Dondeti wrote:
I guess we agree to disagree. The addition integrity checksum is
spurious in my view and I
.
Is there general consensus on this part? There seems to be more
contention on which MAC should be used with an AES-based ciphersuite.
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
Joseph Salowey (jsalowey) wrote:
Hi Lakshminath,
I have not seen a lot of
I concur.
--
t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy
Joseph Salowey (jsalowey) wrote:
Here is my suggestion for resolving the ciphersuite issue:
We need to define a small set (preferably one, maybe two) of mandatory
to implement ciphersuites for GPSK. The
ven't protected against the
malleability attack.
--
t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy
Lakshminath Dondeti wrote:
I think this issue comes from:
o Entropy = RAND_Client || RAND_Server || ID_Client || ID_Server
First, a nit, none of the information i
It was originally added for channel binding purposes, for those in the
"add stuff to the KDF" camp of channel bindings. I'm personally not all
that attached to it, so if the consensus is to remove it, that's fine
with me.
--
t. charles clancy, ph.d. | [EMAIL PROTECTED
narios (i.e. something someone has actually encountered, and not a
hypothetical corner case) where this would be a *real* issue?
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
___
Emu mailing list
Emu@ietf
? Or
EAP-TLS-PKI and EAP-TLS-PSK? If we have both legacy issues AND footprint
issues, perhaps something like ...
EAP-TLS-v1
EAP-TLS-v2-PSK
EAP-TLS-v2-PKI
... might be appropriate.
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
On Mon, October
So, it sounds like defining an EAP type code for EAP-TLS with non-PKI
ciphersuites sounds like the best way to go. Would it be appropriate to
have IANA allocate a new EAP type code with 2716bis, or have a seperate
document discussing EAP-TLS with TLS-PSK ciphersuites?
--
t. charles clancy, ph.d
ty. Not a good thing.
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
On Sat, October 21, 2006 1:43 pm, Jouni Malinen wrote:
> On Wed, Oct 18, 2006 at 03:50:02PM -0400, [EMAIL PROTECTED] wrote:
>> Title : EAP Generalized Pre-Share
like these in the drafts.
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
Jouni Malinen wrote:
This version of EAP-GPSK draft seems to resolve the key derivation
questions I had apart from one detail: how is PL to be represented in
the "P
IPS 140-2 compliance. (I think this is a bad idea, but I'm just
throwing it out there.)
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
Tschofenig, Hannes wrote:
Hi all,
at the EMU working group meeting we received some feedback regarding the
bring them up to spec seems like a reasonable thing to do.
Engineering new standards around broken implementations of old standards
seems like a bad set of design constraints.
--
t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy
Hao Zhou (hzhou) wrote:
I pointed i
ailability, accessibility to visitors, guest Internet
connectivity, ability to provide lunch, and proximity to a major airport
and reasonably-priced hotels.
Thanks!
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
__
SK, then it has no business
executing a reauth. By executing a reauth, an implementation is
implicitly signaling that it can derive EMSKs for the originally-executed
method.
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
resolved ASAP.
--
t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy
Jouni Malinen wrote:
On Mon, Jan 08, 2007 at 03:50:02PM -0500, [EMAIL PROTECTED] wrote:
Title : EAP Generalized Pre-Shared Key (EAP-GPSK)
Author(s) : C. Clancy, H.
hat about RFC 4334?
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
EAP clients and servers" would be appropriate.
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
obably missing something but is the client allowed to send
> EAP-Failure ?
I don't see anything in RFC 3748 saying a peer CANNOT send an EAP-Failure,
but perhaps it would be better for GPSK to respond with another
GPSK-Failure message, and then have the sever send the EAP-Failure.
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
ted with a dialog box saying "by the
way, you're talking to CN=www.domain.net, not CN=aaa.domain.net". Oh, and
be sure to check the CRL to see if it's been revoked or not.
I definitely understand the deployment issues. I just wish there was some
way to fix this without cl
rther on the list.
You can find the latest version here, pending the I-D editor's release:
http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/draft-ietf-emu-eap-gpsk-04.txt
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
---
TECHNI
else have an
opinion?
--
t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
FIPS 140-2 defers to SP 800-38a, which includes ECB, CBC, CFB, OFB, and
CTR as allowable block cipher modes of operation.
The only RFC specifying AES-CTR (that I can find) is 3686, which uses it
with IPsec ESP.
OpenSSL includes support. See AES_ctr128_encrypt().
--
t. charles clancy, ph.d
he counter.
Considering EAP's MTU is 1024, we could only ever have 64 AES blocks
per packet. Use 1 byte of the IV for the counter, and the other 15 as
the IV.
--
t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy
Joseph Salowey (jsalowey) wrote:
Does the library provide cou
g with a hash is that it's in line with NISTs new set of key
derivation requirements, which use hashes rather than HMACs. I'd wager
the security is probably identical.
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
The problem is that the new KDF construction uses hashes instead of MACs.
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
On Sun, March 18, 2007 11:10 am, Jouni Malinen wrote:
> On Sun, Mar 11, 2007 at 11:22:15PM -0400, Charles Clancy wrote:
The problem with using a known key is that the function is invertable.
The KDF doesn't work unless you can't invert it.
See: http://tools.ietf.org/html/draft-dang-nistkdf
Sounds like we should talk to our new A-D, since he's a coauthor on the
document from NIST.
--
t. charl
For reference, in OpenSSL 0.9.8 on a Pentium M, AES-CBC requires roughly
18 Kb and AES-CTR requires 8 Kb. The CTR mode is half the size of CBC,
and only requires half the AES core code (i.e. not the decryption).
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd
gful to the
parties involved, and can serve as the basis for making authorization
decisions.
Perhaps you could abstract the definition of channel bindings even further
such that all three are subsets of some common terminology... but that
sounds painful.
--
t. charles clancy, ph.d. <> [EMAIL
Jouni,
Good catch -- 0x00 should be 16 octets long and MK should be generated
from GKDF-16 instead.
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
On Fri, April 6, 2007 2:25 pm, Jouni Malinen wrote:
> On Fri, Apr 06, 2007 at 09:07:11AM +0200, Ha
I guess I see EAP channel bindings as an EAP<->AAA binding, and the L2
secure association protocol as the EAP<->L2 binding.
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Sam Hartman wrote:
"Charles" == Charles Clancy <[EMAIL PROTECTED]> writes:
Charles> I don't think I'm convinced that EAP channel bindings are
Charles> doing this binding to the L2 channel. The identity used
Charles> in an EAP channel binding m
On Mon, April 9, 2007 6:38 pm, [EMAIL PROTECTED] wrote:
"Charles" == Charles Clancy <[EMAIL PROTECTED]> writes:
Charles> Sam Hartman wrote:
>>>>>>> "Charles" == Charles Clancy <[EMAIL PROTECTED]> writes:
>>
Char
n specified, but it is
likely that this channel would use endpoint channel bindings carried
in the EAP method exchange.
--
t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy
___
Emu mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/emu
0/0x/
s/0x01/0x0001/
s/24 bits/16 bits/
--
t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
x27;t the SMI space increasing to 4 bytes? I know we needed to recently
make changes to EAP-GPSK.
Section 4.11.7:
Again, I think inner methods, and also crypto-bindings, should go away.
Section 6.1:
I think we need a paragraph on each describing it in more detail.
Section 7:
Do we
PSK sizes and how they deal with different-length keys
--
t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy
Tschofenig, Hannes (NSN - DE/Germany - MiniMD) wrote:
Hi all,
What is the issue? The derivation of MK uses "0x00" as a key for the
KDF.
Here
ds with one stone.
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Jouni,
Thanks for your comments. They have been addressed in v08.
http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-08.txt
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
Jouni Malinen wrote:
On Mon, No
VPs within their protected channels. "chbind" then describes
how to use these AVPs for channel bindings. Certainly MUCH work still
needs to be done, but I think they provide a framework within which to
start the conversation.
--
t. charles clancy, ph.d. eng.umd
Hannes and I will have a revision out shortly.
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
Alan DeKok wrote:
While the charter updates are being formally approved, we can start
discussions about the new work i
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
Bernard Aboba wrote:
Overview
I have read this document and have found several major issues with it.
As a result,
I don't think it is currently suitable for adop
n-opaque processing
(i.e. requiring that the client MUST know ID_Server beforehand, and
MUST reject GPSK-1 if it does not contain identical ID_Server) would
be another.
ID_Server and ID_Peer must all be provisioned simultaneous to the PSK.
The formatting doesn't matter too much other than to per
GPSK-3.
All -- Does anyone in the WG object to this change?
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
[EMAIL PROTECTED] wrote:
Charles,
Thanks for the update! There's one change I'm slightly worried
a
EMU,
New versions of the EAP channel binding documents are now available:
http://www.ietf.org/internet-drafts/draft-clancy-emu-chbind-02.txt
http://www.ietf.org/internet-drafts/draft-clancy-emu-aaapay-01.txt
They address issues raised in the two reviews received so far.
--
t. charles clancy
ostly just a place holder. We need to know what types of things people
thing are appropriate for validation.
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
Tschofenig, Hannes (NSN - FI/Espoo) wrote:
* When I have to i
networks using AES for link-layer
security or with certain SSIDs, for example, while other users could
connect to any network.
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
Charles Clancy wrote:
Hannes,
Thanks for the comm
analysis? Do you mean a
monetary one? Cost to operators or cost to equipment providers?
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
Bernard Aboba wrote:
Overview: This version of the document still has some is
Alan,
Katrin and I are working on a revision based on Bernard's feedback.
There will be a new version posted before the submission deadline.
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
Alan DeKok wrote:
I
hopefully Katrin and I can meet offline with those who have specific
comments.
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
Bernard Aboba wrote:
Wow. The EMU WG mail exploder seems to have b
quot;aaapay"
defines the actual transport. It requests IANA allocations for TLVs or
protected payloads in GPSK, PSK, PAX, TTLS, and FAST, and defines a
container for carrying the channel binding information. For more
information, see:
http://tools.ietf.org/html/draft-clancy-emu-aaapay-
this question to the list after the last
IETF, and there weren't any responses.
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
___
Emu mailing list
Emu@ietf.org
https://www.ie
56 matches
Mail list logo
