Re: [Emu] EAP-GPSK comments
Jouni,
Thanks for your comments. This is quite obviously a -00 document. Many
of the inconsistencies you've pointed out are editorial, and certainly
not intentional. We redesigned large parts of the protocol a couple
times, and unfortunately there are artifacts of previous designs throughout.
We defined the format for "protected results indication" as out of
scope, mostly to get -00 out. If the WG wants to define it in the
draft, then that's fine with me. However, it might be useful to define
it in a seperate document, since like channel bindings, it could apply
to any method that supports a protected data exchange.
Sections 6.1.3 and 6.2.3 are definitely in error, and should include the
KDFData fields.
Adding length fields to ID_Server and ID_Client in the KDF can't hurt.
Not doing so won't introduce any practical attacks, but it 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
Laboratory for Telecommunications Sciences
[EMAIL PROTECTED]
Jouni Malinen wrote:
On Sun, Jun 11, 2006 at 02:17:28PM +0200, Hannes Tschofenig wrote:
ID Server/Client in key derivation:
Variable length ID_Server and ID_Client are concatenated in MK and
KDF_out derivation. This means that there is no explicitly specified
boundary between these fields
Do you see an attack if we don't use a delimiter?
http://www.tschofenig.com:8080/eap-gpsk/issue4
I did not look for a concrete attack, but I've seen this kind of
explicit field delimiters being added as a fix to number of this kind of
constructions and since this does not really add much extra cost in
processing, I would add one here, too.
Failure reporting:
What is the server/peer to do when something fails? For example, what
if GPSK-1 does not include a supported ciphersuite.
There is a mandatory to implement ciphersuite (i.e., Ciphersuite 1) and
hence this case cannot happen.
Do you have other failure cases in mind?
Yes, I just listed the first one. If PSK does not match, server will
find an incorrect MAC in GPSK-2. What should it do? Just send
EAP-Failure? This is related to how protected result reporting is
implemented. In perfect world, there would be no other error cases, but
implementation error or an attacker could trigger some other failure
cases in GPSK-3 or GPSK-4. I did not find clear instructions on what the
implementation should do in such a case.
Now I just had to assume that client will drop these silently and server
will send EAP-Failure. If protected result protection will be added,
that change could also cover a mechanism for reporting any error in the
messages (though, error reports for GPSK-1 and GPSK-2 may not really be
protected since a shared key is not yet available).
GKDF-X(Y, Z) definition (Chap. 5):
s%n = int( X / size ) + 1%n = int( (X + size - 1) / size)%
(previous version would have one extra operation if X mod size = 0)
Need to define how many octets are used for i and X in input to MAC_Y.
Is this two octets in network byte order?
I am not so sure to what text you are referring.
This is in GKDF-X(Y, Z) definition of chapter 5 (Ciphersuites):
GKDF-X (Y, Z)
{
n = int( X / size ) + 1; /* determine number of
output blocks */
M_0 = "";
result = "";
for i=1 to n {
M_i = MAC_Y (M_{i-1} || Z || i || X);
result = result || M_i;
}
return truncate (result; X)
}
The fir part is for determining n. If X=16 and size=16,
n = int(16/16)+1 = 2 even though only one MAC_Y operation would have
been needed (and n = int(16 + 16 - 1) / 16 = 1). This is just a small
rounding off-by-one cleanup.
The more important change is in adding explicit definition of how i and
X are represented in input to MAC_Y in MAC_Y(M_{i-1} || Z || i || X)
construction. This needs added text to specify that i and X are used as
16-bit values in network byte order (assuming that is the intent here; I
used that assumption while implementing this since 8-bit X might not
have been long enough to cover all needs and 16-bit values seemed large
enough for this protocol).
Input to Integrity MAC (6.1.2 and 6.2.2):
We could make the definition of SEC more clear, namely:
"
SEC_X(Y):
SEC is a function that provides integrity protection based on the
chosen ciphersuite. The function SEC uses the algorithm defined by the
selected ciphersuite and applies it to the message content Y with key X.
As an output the message returns Y concatenated with MAC_X(Y).
"
This is fine in itself, but..
Regarding the text in 6.2.2:
The following instantiation is used: AES-128-CMAC(SK, Input) denotes
the MAC of Input under the
Re: [Emu] EAP-GPSK comments
Bernard Aboba wrote: >> Yes, I just listed the first one. If PSK does not match, server will >> find an incorrect MAC in GPSK-2. What should it do? Just send >> EAP-Failure? > > I would recommend silent discard for packets with MAC failures, since > that is most resilient against forgery. Otherwise, an attacker only > needs to correctly guess the Identifier (not hard, there are only 256 > choices) and it can abort the EAP conversation. If the EAP Server silently drops EAP-Response/GPSK-2, then how would the client know the PSK is incorrect? Would 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 Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP-GPSK comments
Bernard Aboba wrote: If the EAP Server silently drops EAP-Response/GPSK-2, then how would the client know the PSK is incorrect? Would the conversation just time out? Yes. Perhaps we should add a "MAC Failed" message as Jouni suggested? Sending it would leave the server state unchanged. What is the peer supposed to do with this? If it isn't authenticated, then an attacker can forge it and cause the peer to abort the conversation. If it is authenticated, then if the PSK is incorrectly configured, the peer will drop it. Since an attacker can send a forged packet and to cause this message to be sent, about all the peer could do with it is log it and leave its own state unchanged. What sort of attacker are we trying to stop here? A non-MitM, eavesdropping DoS attacker? Certainly a MitM attacker can just drop all our packets. If the MAC in GPSK-2 fails, the server can certainly send an authenticated response. He has all the necessary information to compute the proper session keys. The client jsut wouldn't be able to verify the MAC. Do the following cases sound right according to normal EAP behavior? Case 1: received one MAC-failed message with invalid MAC = PSK incorrect Case 2: received two or more MAC-failed messages with differing invalid MAC = PSK incorrect, and being DoS'd The timeout approach works too. In that case, we can distinguish "invalid PSK" from "EAP Server unreachable". 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
Re: [Emu] Review of draft-clancy-emu-eap-shared-secret-01
>> So I am drawing from the experience of IKEv2 and ESPv3. The idea is >> purely based on document maintenance process. > > 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. I think one document makes the most sense. -- 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
Re: [Emu] Duplicate integrity protection on Protected Payload data in GPSK
> My reading of the GPSK draft is that the Protected Payload data will > be integrity protected using the MAC from the combined mode and there > is the integrity checksum over the entire GPSK-Message. I think we > should avoid the multiple MACs. ... > I am curious about others' 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
Re: [Emu] EAP-GPSK: Ciphersuites
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 believe we can define things so that combined modes can be employed without encrypting anything, so I am somewhat confused here. What's your opinion on the latter part of my email? thanks, Lakshminath At 05:12 PM 8/22/2006, Hannes Tschofenig wrote: Hi Lakshminath, Lakshminath Dondeti schrieb: At the expense of generating some confusion, here is my take on this: The objection is to having to carry multiple integrity checksums in GPSK, if we used the combined mode *and* an integrity algorithm. I don't agree with you. There is no reason to optimize a few bits in a pre-shared secret method. Note that we are not talking about a protocol for data transfer. We wanted the flexibility to use different cipher suites. We do not only want to use cipher suites that provide authenticated encryption (since we almost have nothing to encrypt; currently 1 bit and almost no EAP method provides this functionality). Ciao Hannes I think CCM is fine for instance, the only catch is that we need to make sure and define AAD for CCM carefully to include appropriate data into the integrity checksum calculation. So, once we define CCM as the mode, we shouldn't need AES-CMAC-128 if encryption is being used. I would suggest using CCM and specifying the use of it fully so it can be used without misunderstandings. If you want me to put some time into writing that up, let me know. cheers, Lakshminath At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: Hi all, the current version of the document http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt still supports AES-EAX: +---++-+---++ | CSuite/ | KS | Encryption | Integrity | Key Derivation | | Specifier || | | Function | +---++-+---++ | 0x01 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 | +---++-+---++ At the IETF#66 EMU meeting AES CCM was suggested. Later, it got the impression that AES-CBC was more appreciated. Should we update the draft with AES-CBC? Ciao Hannes ___ 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 ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP-GPSK: Ciphersuites
Lots of interesting conversation... Being ciphersuite-modular doesn't mean we have to give up all control or write a protocol that would work in every possible case. I don't see any reason to add optimizations to support CCM/EAX-like primitives when there's no reason to use them in the first place. Both supporting them and using them adds unnecessary complexity. IMHO, the ciphersuites should be AES-CBC with a suitable MAC (I'm flexible here) and HMAC-256, with HMAC-256 mandatory to implement because it would most easily achieve FIPS140-2 certification. 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 support for use of CCM/EAX with or without the optimization of eliminating additional MAC algorithm on the list. I think it would be useful to understand what the impact is on the current specification to support ciphers that provide both integrity protection and encryption without requiring additional MAC algorithms. Would the current spec need to be modified to support this? If so, what modifications are needed? Thanks, Joe -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Sunday, August 20, 2006 12:23 AM To: Hannes Tschofenig; emu@ietf.org Subject: Re: [Emu] EAP-GPSK: Ciphersuites At the expense of generating some confusion, here is my take on this: The objection is to having to carry multiple integrity checksums in GPSK, if we used the combined mode *and* an integrity algorithm. I think CCM is fine for instance, the only catch is that we need to make sure and define AAD for CCM carefully to include appropriate data into the integrity checksum calculation. So, once we define CCM as the mode, we shouldn't need AES-CMAC-128 if encryption is being used. I would suggest using CCM and specifying the use of it fully so it can be used without misunderstandings. If you want me to put some time into writing that up, let me know. cheers, Lakshminath At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: Hi all, the current version of the document http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secr et-01.txt still supports AES-EAX: +---++-+---++ | CSuite/ | KS | Encryption | Integrity | Key Derivation | | Specifier || | | Function | +---++-+---++ | 0x01 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 | +---++-+---++ At the IETF#66 EMU meeting AES CCM was suggested. Later, it got the impression that AES-CBC was more appreciated. Should we update the draft with AES-CBC? Ciao Hannes ___ 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 ___ 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
Re: [Emu] GPSK Open Issues - mandatory ciphersuites
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 mandatory to implement ciphers should exercise the features of GPSK. This would suggest that it should be a block cipher based ciphersuite. It seems a reasonable choice is AES-CBC with AES-CMAC. This makes use of a single base algorithm using relatively simple modes of operation. The HMAC-SHA256 ciphersuite should also be described, but is not mandatory to implement. Does this seem reasonable? Any objections? Thanks, Joe ___ 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
Re: [Emu] GPSK Issue - Identity in key derivation
Sure, it can be renamed. I vote for simply prepending the identities with 16-bit lengths. It's consistent with the rest of the protocol payload formatting. Inserting NULLs could work in theory, but a poor implementation might accept an identity "a\0b" in which case we haven'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 in there qualifies as entropy, so let's call it something else, please. How about we define the above asRAND_Client || ID_Client || RAND_Server || ID_Server ? Lakshminath At 03:37 PM 10/3/2006, Joseph Salowey \(jsalowey\) wrote: There currently is no separator between the identities in the GPSK key derivation which means that 'a || bc' and 'ab || c' would produce same keys. It seems this can be addressed by including the length as part of the identity or inserting a delimiter between identities. It seems that including the lengths as part of the identity would be fine. Any objections? Thanks, Joe ___ 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 ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] GPSK issue - KDF Data
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] | www.cs.umd.edu/~clancy Bernard Aboba wrote: Can you be a bit more specific? Are you talking about mixing of client and server nonces or something else? From: "Joseph Salowey (jsalowey)" <[EMAIL PROTECTED]> To: Subject: [Emu] GPSK issue - KDF Data Date: Tue, 3 Oct 2006 15:18:49 -0700 The current GPSK draft includes the capability for the client and server to combine data into the KDF. This is currently incompletely described in the GPSK draft. The question has been raised as to whether we need this functionality. Unless there is a reason to support this it should be removed from the specification. Is there a good reason to keep this? Thanks, Joe ___ 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 ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Tying EAP-TLS method type to specific ciphersuites
> Do people see the need to limit the types of ciphersuites that can be > negotiated within EAP-TLS? In general, no. > If so what would be the appropriate way to divide up the ciphersuites > with method types? When going down this road, it's difficult to tell where you should stop. The first step would be splitting PSK and PKI into two different EAP types. The problem is that the argument for doing the first split can be recursively applied until we have a different EAP type code for every EAP-TLS ciphersuite. I think the point of EAP-level vs TLS-level credential negotiation is valid from a protocol standpoint, but of insignificant importance in real-world deployments. For example, I've yet to encounter an 11i network that supports more than a single EAP type for authentication. Are we trying to solve a non-existant problem? Are there *real-world* scenarios (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.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Tying EAP-TLS method type to specific ciphersuites
So that answers the questions from my last email. It sounds like PKI vs PSK is a reasonable split, but for reasons somewhat unrelated to EAP vs TLS credential negotiation, which I don't see as a big problem, personally. Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2 (PKI and PSK)? 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 23, 2006 12:17 pm, Bernard Aboba wrote: > During the EMU BOF we talked about the high cost that would be imposed on > customers by introducing new non-certificate ciphersuites during EAP-TLS. > > EAP-TLS is now ten years old, and has a very large installed base. > Virtually all of these installations only support certificate-based > authentication, since that is a requirement of RFC 2716, which states: > >If the EAP server is not resuming a previously established >session, then it MUST include a TLS server_certificate handshake >message, and a server_hello_done handshake message MUST be the last >handshake message encapsulated in this EAP-Request packet > >If the EAP server sent a certificate_request message in the preceding > EAP-Request packet, then >the peer MUST send, in addition, certificate and certificate_verify > handshake messages. > > As a result of these and other specification requirements, an > implementation > that does not support certificate authentication is non-compliant with RFC > 2716. > > During the BOF we also talked about the drawbacks of attempting to support > both certificate and non-certificate modes in a single EAP method. Such > an > approach would require embedded systems to take on the footprint of > certificate handling even when all they really needed to do was to support > pre-shared keys. It would also add new potential security vulnerabilities > to one of the few EAP methods that has provable security properties. > > In addition adding new non-certificate modes would impose large costs on > customers. Today there are interoperability and conformance test suites > for > EAP-TLS that assume that only certificate-based authentication is > supported. > In addition, EAP-TLS has been approved for use within FIPS 140-2 > installations, based on support for certificate-base ciphersuites. > Introducing new non-certificate modes would introduce confusion, and would > force existing test suites to be re-written. > > For customers, deployment of EAP is difficult enough without introducing > confusion, interoperability problems and new security vulnerabilities into > the one EAP method that today is synonmous with high security. > > > > ___ > 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
RE: [Emu] Tying EAP-TLS method type to specific ciphersuites
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. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy On Mon, October 23, 2006 9:07 pm, Bernard Aboba wrote: >>Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2 (PKI and PSK)? >> Or >>EAP-TLS-PKI and EAP-TLS-PSK? If we have both legacy issues AND footprint >>issues, perhaps something like ... > > So far, we've talked about handling PSK support by creating a new EAP > method > with a distinct name: "EAP-TLS-PSK".That approach enables embedded > devices to implement only PSK ciphersuites, reducing footprint. It also > avoids impacting the interoperability and security of existing EAP-TLS > implementations. > > Given that EAP-TLS already supports PKI, I'm not sure why a distinct EAP > method called "EAP-TLS-PKI" would be needed. > > Creating "versions" of EAP-TLS would potentially confuse customers and > cause > problems with existing test suites and certification programs. Witness > the > confusion that was created by PEAP versioning, where PEAPv0 and PEAPv1 did > not interoperate. So I'd stay away from versioning if at all possible. > > > > ___ > 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
Re: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-00.txt
Jouni, Actually, the descriptions in chapter 6 are incorrect, and need be fixed to reflect the changes in chapter 4. The KDF in chapter 4 was changed to allow PSKs of variable length and entropy. Using the PSK to directly key the KDF to generate the MK has problems because most KDFs have fixed-length inputs for keys. Imagine someone who uses a 50-character passphrase (English text has around 2.5 bits of entropy per character, so that's roughly a 128-bit secure key). If we follow what's currently in chapter 6, we truncate that to 16 bytes, which would only be 40 bits of security. 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-Shared Key (EAP-GPSK) >> Author(s) : C. Clancy, H. Tschofenig >> Filename: draft-ietf-emu-eap-gpsk-00.txt > > While updating my implementation to the new draft, I noticed couple of > conflicts in how the key derivation is defined. Chapter 4 uses > KDF_Zero-String(PL || PSK | ...) to derive MK whereas 6.1.8 and 6.2.8 > use GKDF-#(PSK, ...). I would assume that the version in 6.1.8 and 6.2.8 > is the correct one and chapter 4 should be updated to match with this. > > Another difference is in whether CSuite_Sel is to be included in the > GKDF data field. Chapter 4 seems to include it (just before > inputString), but 6.1.8 and 6.2.8 do not. Should it be there or not? > > > The new draft is trying to fix the GKDF-X n (number of output blocks) > calculation, but that seems to have a typo of some sort. > > Now: n = int( X / size - 1 ) + 1; > > That doesn't make any sense since -1 and +1 are are cancelling eachother > and we are left with n = int( X / size ). > > I would assume that this was supposed to be taken into account rounding > up (ceiling) by using n = int( (X + size - 1) / size ) which could be > written as n = int( (X - 1) / size ) + 1. > > -- > Jouni MalinenPGP id EFC895FA > > ___ > 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
Re: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-01.txt
Jouni,
PL is two octets. Specifying that will be in the next revision. The
1/7 octets is left over from a previous revision -- we'll definitely fix
that in the next revision too.
Thanks for all your work implementing EAP methods. Your efforts are
very helpful for bringing out bugs 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 "PL || PSK || CSuite_Sel || ..." construction? As a single octet? As
two octets in network byte order? For now, I just assumed it is only a
single octet.
In addition, I noticed that chapter 2 is defined CSuite_Sel incorrectly:
CSuite_Sel:
Ciphersuite selected by the client (1 octet or 7 octets)
This should be replaced with
Ciphersuite selected by the client (6 octets)
to match with chapter 7.2 ("Ciphersuites are encoded as 6-octet
arrays").
In addition, CSuite_SEL in 6.1.3 and 6.2.3 should have been CSuite_Sel
to remain consistent with the spelling in rest of the draft.
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] NIST KDF & EAP-GPSK
The one mentioned during the session was SP 800-56A, if I recall correctly. See: http://csrc.nist.gov/publications/nistpubs/800-56A/sp800-56A_May-3-06.pdf The title, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", seems to indicate applicability might be limited; however, section 5.8 addresses KDFs based on shared secrets. Two KDFs are presented in the document, along with some requirements on how keys are handled and how a keying hierarchy should be implemented. I think the KDF in section 5.8.1 seems appropriate. It requires the use of a hash function, and not a MAC function, so only our HMAC-SHA256 ciphersuite would be compliant, provided we tweaked the KDF. For the AES ciphersuite, we could always define the KDF as a "key push" distribution system using AES keywrap, if we were super-worried about FIPS 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 usage of the NIST KDF in EAP-GPSK. In order to make progress with the document we would like to get some more information about the suggested change to the document. Some NIST documents have been mentioned. Could someone point us to them? Ciao Hannes ___ 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
Re: [Emu] Re: [Hokeyp] MSK but no EMSK
Hao, I think you meant to say it would require replacing all existing EAP *method* implementations. EAP implementations will have to change anyway to support derivation of keys within the hierarchy. If you're updating clients and servers already, rev-ing the method implementations to 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 in the meeting that even EAP RFC mandates EMSK, however I don't know any existing EAP implementation actually generates and exports EMSK (especially the popular ones, like EAP-TLS, PEAP, EAP-FAST, EAP-TTLS, etc.) So if we build our key hierarchy on top of EMSK, we will require replacing all existing EAP implementations, both from the server and client side. If we cold use MSK, then we only need to replace EAP lower layer that wants to support handover. -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 12:38 PM To: Yoshihiro Ohba; Alper Yegin Cc: [EMAIL PROTECTED]; emu@ietf.org Subject: Re: [Emu] Re: [Hokeyp] MSK but no EMSK At 06:27 AM 11/16/2006, Yoshihiro Ohba wrote: I made one comment around this in the HOKEY session. The intent of my comment was that use of EMSK is optional. Hi Yoshi, Which document says that the "use" of EMSK is optional? There would be an interoperability issue if peer and server do not negotiate on the use of EMSK before actually using it. The interoperability issue would only come up if there is ambiguity or options. Lakshminath Yoshihiro Ohba On Thu, Nov 16, 2006 at 11:01:15AM +0200, Alper Yegin wrote: I remember someone in Hokey WG meeting mentioned that not all methods generate EMSK (even though they generate MSK). Is that accurate? Despite this RFC 3748 text? In order to provide keying material for use in a subsequently negotiated ciphersuite, an EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets. Alper ___ Hokeyp mailing list [EMAIL PROTECTED] http://www.opendiameter.org/mailman/listinfo/hokeyp ___ 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 ___ 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
[Emu] CAPWAP and HOKEY interim meetings
CAPWAP and HOKEY WGs, The chairs of both CAPWAP and HOKEY feel an interim meeting between IETF 67 and 68 is necessary in order to meet their respective milestones. Due to a likely overlap in some participants, consecutive, co-located meetings are suggested. The chairs propose to hold a 3-day event (1 day for HOKEY followed by 2 days for CAPWAP) in the San Francisco Bay area the week of January 22. Due to a preference of not traveling on weekends, meeting Tue-Thu (Jan 23-25) is suggested. Please send comments to the lists on the proposed schedule, area, preference on dates, and which meeting(s) you're likely to attend. Also please indicate any possible overlooked conflicts with conferences and other events. If your organization would be interested in providing a venue to host the event, please let us know. In particular, we are interested in your site's space availability, 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 ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Hokeyp] [Emu] Re: MSK but no EMSK
On Wed, November 22, 2006 9:07 am, Yoshihiro Ohba wrote: > A HOKEY compliant implementation should be able to revert to the > legacy mode of operation (i.e., use of MSK in the current way) so that > it still interoperates with a HOKEY non-compliant implementation > without ending up with a communication failure or changing the HOKEY > non-compliant implementation. Note that a HOKEY non-compliant > implementation is still RFC3748 compliant as long as it generates MSK > and EMSK even if it does not use EMSK. Let me point this out again. In order to support HOKEY, EAP implementations MUST change to implement the reauth protocols. Thus, I don't understand why fixing broken methods to export the EMSK at the same time is such a big deal. I'm not convinced by the certification arguments. EAP implementations will all have to be recertified by whomever to check HOKEY compatability anyway. Proper use of the EMSK would be tested then. I'm also not convinced by the versioning arguments, since you'd never need to use the EMSK if you weren't executing some HOKEY reauth protocol. If an implementation didn't derive/export the EMSK, 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 ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-02.txt
Jouni, In the last draft I tried to make all the terminology consistent by using octets for everything instead of bits and bytes. Apparently I can't properly divide by 8, and introduced a bunch of inconsistencies. Thanks for all your additional comments. We'll try to get them all 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. Tschofenig Filename: draft-ietf-emu-eap-gpsk-02.txt Some comments.. General - How long are the random values? 16 octets? 32 octets? * I assumed they were 32 octets (256 bits), but the draft is in conflict with itself.. * 2. Terminology: 16 octets (this was 256 bits in -00) * 7.3. Payload Formatting: 32 octets * 9.4. Replay Protection: 16 octets * 9.8. Denial of Service Resistance: 16 octets 2. Terminology - MSK and EMSK were changed from 512 bits (64 octets) to 32 octets * Why? * Other EAP methods use 64 octet MSK and EMSK, so I hope this was just an accident and the purpose was only to move from bits to octets: s/32 octets/64 octets/ * Similar change in 4. Key Derivation (though, that section is also using 64 octets.. only Figure 2 is incorrect; s/32-octet/64-octet/) 3. Overview - Order of CSuite_Sel and CSuite_List in GPSK-2 was reversed * Why? * 7.3. Payload Formatting is still using the previous order, i.e., CSuite_List before CSuite_Sel; in other words, there is now conflict between sections 3 and 7.3 on the order of these fields 5. Ciphersuites - definitions of GKDF-X(Y, Z) was changed, but some cleanup missing * 'X' is not used anymore as an input to hash function and because of this, there is no need to say that it is repredsented as a 2-octet value in network byte order: s/'i' and 'X' in M_i are represented as 2-octet values/ 'i' is represented as 2-octet value/ 6.1.1. Encryption - CBC is mentioned to require an IV * However, there is no definition on where this IV is coming from or how it is to be transmitted to the other party * How exactly is this supposed to work? 8. Packet Processing Rules - typo: s/receving/receiving/ - "(i.e. an EAP client receiving GPSK-3 before receving GPSK-1 or before transmitting GPSK-2)" * isn't that more of an example (e.g.) than the only possible case (i.e.)? * s/i.e./e.g./ - "GPSK-1 contains no MAC protection, so provided it properly parses, it MUST be accepted by the client." * MUST?? * What if CSuite_List in GPSK-1 does not include any supported cipher? - s/EAP-NACK/EAP-Nak/ to match with "Nak" spelling in RFC 3748 - "A client receiving a GPSK-Fail or GPSK-Protected-Fail message in response to a GPSK-2 message MUST either transmit an EAP-Failure message and end the session" * Success and Failure messages are sent by authenticator, not peer * This should probably be changed to say that client (peer) is sending back GPSK-Fail / GPSK-Protected-Fail, not EAP-Failure, to acknowledge failure; this will be followed by the authenticator sending EAP-Failure - "For GPSK-3, a client MUST silently discard any packet containing whose RAND_Client, RAND_Server, or CSuite_Sel fields do match those transmitted in GPSK-2." * There's something wrong with this sentence.. s/whose // s/do match/that do not match/ 9.4. Replay Protection - typo: s/RAND_P/RAND_Client/ 9.8. Denial of Service Resistance - typo: s/RAND_S/RAND_Server/ ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt
Bernard Aboba wrote: How about including: "Some deployments may require the presence of client and server authentication extended key usage extensions in certificates. Client implementations wishing to interoperate in these environments SHOULD check the server's certificate for an Extended Key Usage field implementations id-kp-serverAuth (1.3.6.1.5.5.7.3.1) or the special keyPurposeID anyExtendedKeyUsage. Server implementations wishing to interoperate in this environment SHOULD check the client's certificate for an Extended Key Usage field containing id-kp-clientAuth (1.3.6.1.5.5.7.3.2) or the special keyPurposeID anyExtendedKeyUsage. Note that these key usage extension identifiers for server and client authentication are somewhat generic and may not be sufficient to authorize an entity's role specifically as an EAP-TLS client or server." Looks good. What 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
Re: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt
On Sun, January 21, 2007 12:30 pm, Bernard Aboba wrote: >>What about RFC 4334? > > The OIDs defined in RFC 4334 do not correspond to values of the > NAS-Port-Type attribute, so the backend authentication server certificate > handling code would need to be updated everytime a new value were to be > assigned; the AAA server can't just check that the NAS-Port-Type attribute > includes a value that matches one of the OIDs in the client certificate. > Similarly, client code would need to be updated every time a new EAP lower > layer was defined, since the client would need to check if the server > certificate contained an OID allowing it to be used to authorize a given > EAP > lower layer. So your objection is that essentially different lower layers have been hard-coded into 4334 (PPP and EAPoL), and consequently into the cert handling code, such that new RFCs and new code would be required to support EAP over different L2/L3 technologies? I can see that as an objection to the fundamental approach, and a reason to possibly not support future EKUs for other lower layers, but not as a reason to not support the currently-defined EKUs. If implementers are rev-ing their EAP-TLS code for 2716bis compliance, this would be a good time to roll in these changes. I'd think a statement like "When EAP-TLS is used with WLANs, support for WLAN-specific EKUs [RFC 4334] is RECOMMENDED to improve certificiate-based authorization of 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
Re: [Emu] Questions on draft-ietf-emu-eap-gpsk-02.txt
On Thu, January 18, 2007 3:39 pm, Victor Fajardo wrote: > Hi Tom/Hannes, > > I just have a couple of questions/comments regarding > draft-ietf-emu-eap-gpsk-02.txt: > > o In the terminology section, the last sentence of SEC_X(Y) definition > is "SEC_X(Y) = Y|MAC_X(Y)". Maybe it should be "SEC_X(Y) = Y || > MAC_X(Y)" instead. Yes. > o In Sec 8., 3rd paragraph: > > "GPSK-1 contains no MAC protection, so provided it properly parses, it > MUST be accepted by the client. If the EAP client decides the > ID_Server is that of a AAA server to which it does not wish to > authenticate, the EAP client should respond with an EAP-NACK." > > Should this also provision for the case where the client is unable to > support any of the ciphers in CSuite_List of GPSK-1 ? In such a case > is it proper for the client to just send an EAP-NACK ? There is a mandatory-to-implement cipher, so this should never happen. > o In Sec 8., 4th paragraph: > > "For GPSK-2, if ID_Client is for an unknown user, the EAP server MUST >send either a "PSK Not Found" GPSK-Fail message, or an >"Authentication Failure" GPSK-Fail, depending on its policy, and >discard the received packet. If the MAC validation fails, the server >MUST transmit a GPSK-Fail message specifying "Authentication >Failure". and discard the received packet. If the RAND_Server or >CSuite_List field in GPSK-2 does not match the values in GPSK-1, the >server MUST silently discard the packet. If server policy determines >the client is not authorized and the MAC is correct, the server MUST >transmit a GPSK-Protected-Fail message indicating "Authorization >Failure" and discard the received packet." > > In the case of "Authentication Failure" where the user is unknown or MAC > is not correct maybe EAP_FAILURE is better (???) rather than GPSK-Fail > since the failure is severe enough to warrant a method failure ? See the paragraph immediately after the one you quoted: A client receiving a GPSK-Fail or GPSK-Protected-Fail message in response to a GPSK-2 message MUST either transmit an EAP-Failure message and end the session, or retry transmission of GPSK-2, attempting to correct whatever failure occured. If MAC validation on a GPSK-Protected-Fail packet fails, then the received packet MUST be silently discarded. The client has the option to send an EAP Failure to end the session and try another EAP type, or retry EAP-GPSK. > Should the CSuite_List in GPSK-2 be equivalent to CSuite_List in GPSK-1 ? > Maybe I have the wrong impression but I thought the idea is auth sends > a CSuite_List to peer and peer selects a supported CSuite denoted by > CSuite_Sel. If this is the case we may not need CSuite_List in GPSK-2. > Also, if CSuite_Sel does not match any value in CSuite_List in GPSK-1 > then auth can send GPSK-Fail. The reason for sending CSuite_List in GPSK-2 is to authenticate it. GPSK-1 has no MAC protection, while GPSK-2 does. This way the server knows that the CSuite_List sent in GPSK-1 wasn't altered in transit, which allows it to detect downgrade attacks. > o In Sec 8, 5th paragraph: > > "A client receiving a GPSK-Fail or GPSK-Protected-Fail message in >response to a GPSK-2 message MUST either transmit an EAP-Failure >message and end the session, ... " > > I'm probably 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
Re: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt
> In terms of server authorization, the benefit is unclear to me. Assuming > a server is authenticated and appears authorized along other dimensions > (chains to a trust anchor, has an appropriate name), should a client > reject it because it lacks the OIDs for the particular form of access > involved? From an architectural point of view, EAP-TLS implementations > typically leave certificate selection to the TLS implementation. RFC > 4334 support could require changes to the certificate selection code. I don't care about client authorization -- there should be server-side ACLs for this. I guess for EAP-TLS, server authorization isn't a huge deal. If an unauthorized server is giving you access to the network, what difference does it make to a client? The only compromise is maybe that of user confidentiality. What worries me are improperly authorized servers for something like PEAP+MSCHAPv2, where a dictionary attack against a client's password might be possible. My biggest worry is that someone, for example, hacks a web server, steals the key pair, fires up a rogue AP+AAA, and starts stealing client passwords. The user is never presented 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 client-side ACLs for server authorization. -- 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
[Emu] EAP-GPSK update
All, We've put together an update to the GPSK draft to address the last call comments. Below is a list of the identified issues and their solutions. For a variety of issues we recommended no change with a brief description. If more detail is desired, we can certainly discuss them further 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 --- TECHNICAL --- Issue: why not use EAP-TLS-PSK instead (narayanan) Resolution: no change -- WG consensus was to do GPSK Issue: MAC does not cover the EAP or GPSK header (Dondeti, Narayanan) Resolution: no change -- protecting the EAP header is pointless, since the EAP engine would not be able to validate the MAC. The GPSK header only includes an op-code, which can be implicitly checked by validating the MAC on the rest of the packet contents. Issue: use of SHA-1 (Aboba) Resolution: switched AES ciphersuite to use SHA256 Issue: KDFs do not appear compliant with draft-dange-nistkdf-01 (Aboba) Resolution: no change, NIST reviewed our KDF, and the current one is based specifically on their recommendations Issue: Why doesn't the MK derviation use the PSK as it's keying input, instead of all zeros? (Dondeti) Resolution: no change -- The PSK can be of arbitrary length, and therefore may not be the correct length to use as the KDF input key. Issue: revert to previous KDF based on MACs (Dondeti, Narayanan) Resolution: no change -- the KDF changes from MAC to Hash were proposed by NIST Issue: Use of CTR instead of CBC to avoid implementing AES decryption code (Dondeti) Resolution: no change -- we discussed this at length, CTR does its own integrity protection, which would be redundant, hence the decision to use CBC instead Issue: dropping nonparsable packets is EAP behavior (Narayanan) Resolution: changed to talk about parsing EAP-GPSK packets, rather than EAP packets Issue: derive keys individually rather than deriving a big block and then split it up (Narayanan) Resolution: no change -- places fewer restrictions on the KDF, and guarantees cryptographic independence Issue: derivation of PK when not using an encryption Ciphersuite (Narayanan) Resolution: removed PK from hash ciphersuite discussion, added other comments indicating it's lack of necessity for non-encrypting ciphersuites --- EDITORIAL --- Issue: citing old drafts (Malinen) Resolution: moot, as references were removed Issue: s/needs to instantiated/needs to be instantiated/ (Malinen) Resolution: text edited Issue: discussion of other protocols and deficiencies (Aboba) Resolution: section removed Issue: quick availability as a design goal (Aboba) Resolution: text edited Issue: design goal s/Wide Applicability/Security Model/ (Aboba) Resolution: text edited Issue: efficiency design goal, mention round trips (Aboba) Resolution: text edited Issue: efficiency design goal, mention Privacy not supported (Aboba) Resolution: no change -- privacy supported if AES ciphersuite is used Issue: define peer/server/session-ID (Aboba) Resolution: defined Issue: ambiguous definition of KS with respect to hashes (Dondeti) Resolution: removed ambiguous text Issue: erronious references to multiple protected payload blocks (Dondeti) Resolution: fixed some references -- others referred to them as plural as you can have a total 3 in the entire protocol exchange Issue: order of key definitions in terminology section (Dondeti) Resolution: changed the order to be alphabetical -- not quite what was proposed, but logical IMHO Issue: precision of some of the protocol specification (Dondeti) Resolution: made some minor edits Issue: GPSK-4 is needed only as a filler, specify that (Dondeti) Resolution: no change, GPSK-4 can contain a PD_Payload_Block Issue: Text involving validation of keys after GPSK-4 (Dondeti) Resolution: text revised Issue: discussion of MACs in KDF section (Dondeti) Resolution: text replaced Issue: instead of length(Csuites_List) use NumberOf_CSuites to save one byte (Dondeti) Resolution: no change -- using a 2-byte length makes parsing code consistent across all length-prefixed data blocks Issue: EAP terminology renamed (Narayanan) Resolution: s/client/peer/g ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
[Emu] Re: On my suggestion to use CTR mode instead of CBC
> CTR mode encryption does not include integrity protection. There are > what are known as combined modes, e.g., CCM, OCB, GCM, which use CTR > mode for encryption. I am not talking about using CCM or something like > that. I have no objection to switching from CBC to CTR. Anyone 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
Re: [Emu] Re: On my suggestion to use CTR mode instead of CBC
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. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy Clint Chaplin wrote: What does NIST (FIPS) have to say? On 3/12/07, Charles Clancy <[EMAIL PROTECTED]> wrote: > CTR mode encryption does not include integrity protection. There are > what are known as combined modes, e.g., CCM, OCB, GCM, which use CTR > mode for encryption. I am not talking about using CCM or something like > that. I have no objection to switching from CBC to CTR. Anyone 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 ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Re: On my suggestion to use CTR mode instead of CBC
I think the code sizes for the different modes of operation are negligible, but the openssl implementation does indeed manage the counter. See: http://www.srcdoc.com/openssl_0.9.7g/aes__ctr_8c-source.html OpenSSL assumes the lower "num" bytes of the IV are used as the 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 counter management or is that up to the implementation? -Original Message- From: Charles Clancy [mailto:[EMAIL PROTECTED] Sent: Monday, March 12, 2007 2:27 PM To: Clint Chaplin Cc: emu@ietf.org Subject: Re: [Emu] Re: On my suggestion to use CTR mode instead of CBC 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. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy Clint Chaplin wrote: What does NIST (FIPS) have to say? On 3/12/07, Charles Clancy <[EMAIL PROTECTED]> wrote: > CTR mode encryption does not include integrity protection. There are > what are known as combined modes, e.g., CCM, OCB, GCM, which use CTR > mode for encryption. I am not talking about using CCM or something like > that. I have no objection to switching from CBC to CTR. Anyone 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 ___ 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
RE: [Emu] EAP-GPSK update
On Mon, March 12, 2007 8:01 pm, Narayanan, Vidya wrote: > > Well, I didn't really ask why not use EAP-TLS-PSK instead of GPSK :) I > was asking if there could be an explanation of some design goal that > really justified the use of GPSK over the other listed PSK-based > methods. The design goals for EAP-GPSK are specified in the introduction. GPSK vs TLS-PSK isn't discussed, because it seems generally taboo to point out other protocols' shortcomings and claim your superiority in an RFC. I think TLS-PSK's man shortcoming is that it wasn't the direction indicated by the WG consensus. > But, my question is - are all things equal? The > design goals listed in the draft led me to believe that all things are > equal - but, I may be missing something. Probably more or less equal. Method implementers have indicated that GPSK is easier to implement. > Specifically in GPSK, the GPSK-Fail message seems to be the same in > either direction (peer to server or vice-versa). The EAP code seems to > be the only differentiating factor in it. If the EAP code is not > integrity protected, an entity can simply reflect the message back. With > GPSK-Fail, the effect of such reflection may be questionable, but, do we > have other cases like this that I might have missed? According to the draft, GPSK-Fail messages MUST be reflected, but only because EAP is a request/response protocol. The server's state machine doesn't change due to the response. >> Issue: revert to previous KDF based on MACs (Dondeti, Narayanan) >> Resolution: no change -- the KDF changes from MAC to Hash were >> proposed by NIST > > I couldn't find a discussion of this on the EMU list. Could you please > provide a summary of the advantages of going with Hash? I don't think there was a discussion. At the last IETF meeting Russ suggested we talk to NIST about our KDF. We did, they recommend changes, and the draft was updated to reflect those changes. The main advantage of going 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
Re: [Emu] EAP-GPSK update
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: > >> We've put together an update to the GPSK draft to address the last call >> comments. Below is a list of the identified issues and their solutions. > >> Issue: use of SHA-1 (Aboba) >> Resolution: switched AES ciphersuite to use SHA256 > > While I understand the desire not to use SHA-1, use of SHA256 with AES > ciphersuite is somewhat unfortunate due to the added requirement for a > new crypto primitive. Would you be willing to consider using > AES-128-CMAC here instead? That would make ciphersuite #1 depend only on > AES-based constructions and SHA256 would only be used for ciphersuite > #2 (which is optional). > > > PS. > > With PK derivation removed from 6.2.3, there is no need for the last 32 > octets of GKDF-192(MK, inputString) data and GDF-192 could be replaced > with GKDF-160 here. Since the requested length of the GDFK output is not > mixed into the Hash-Function input (should it?), this does not change > the derived keys, but is just a cleanup and small speed improvement > (drop one SHA256 operation). > > -- > Jouni MalinenPGP id EFC895FA > ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP-GPSK update
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. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy On Sun, March 18, 2007 1:52 pm, Jouni Malinen wrote: > On Sun, Mar 18, 2007 at 01:24:20PM -0400, Charles Clancy wrote: >> The problem is that the new KDF construction uses hashes instead of >> MACs. > > Would use of CMAC with zero-key be acceptable to generate a hash > function for a KDF? Is there any publicly available document describing > why hashes should be used instead of MACs? I've only seen a comment > saying that this is because NIST says so for this particular > construction, but I have not seen any more details. > > Getting more details on this would be interesting for other reasons, > too, since there are new designs (e.g., IEEE 802.11r) which are using > HMAC-SHA256 -based KDF. Since the 802.11r KDF construction is also > claimed to be compliant to NIST recommendations, it is somewhat odd to > see EAP-GPSK take the other direction with the reasoning that this came > from NIST.. > > -- > Jouni MalinenPGP id EFC895FA > ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
[Emu] AES CBC vs CTR
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.edu/~clancy ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
Sam, In skimming through Nico's draft, it looks like EAP's crypto bindings look something like GSS channel bindings. EAP's channel bindings, on the other hand, don't really look like GSS channel bindings. In order for EAP's channel binding to look like GSS channel binding, EAP channel binding would have to cryptographically bind an L2 security association to EAP keys -- but that's not what it's doing. It's binding L2 identities to EAP keys. In fact, there's no reason it has to be an L2 identity. It can be any identity that's meaningful 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 PROTECTED] <> www.cs.umd.edu/~clancy On Fri, April 6, 2007 1:43 pm, Sam Hartman wrote: > > > > Hi. > > For the last couple of years, we've been believing that EAP and GSS > used the term channel bindings inconsistently. For those of us > dealing with both, it's been a bit annoying. > > I've been thinking about EAP a lot lately. and have come to the > conclusion that actually the terms are used consistently. > > I'd like to see if people agree with the following change to Nico's > channel binding draft: > > old: > >Also unfortunately there is a conflict with the Extensible >Authentication Protocol (EAP) [RFC3748] which uses "channel binding" >to refer to a facility that is subtly different from the one >described here. (It does not seem feasible to adopt new terminology >to avoid these problems now. The GSS-API, NFSv4 and other >communities have been using the terms "channel binding" and "channel >bindings" in these ways for a long time, sometimes with variations >such as "channel binding facility" and so on.) > > new: > > The Extensible Authentication Protocol (EAP) [RFC3748] includes two > facilities related to channel binding. The first, called channel > binding, is used to bind the lower-layer channel created between the > peer and the authenticator to the authentication performed using EAP. > Specific detials of this facility have not been specified, but it is > likely that this channel would use endpoint channel bindings carried > in the EAP method exchange. The endpoint channel bindings would be > defined for the specific lower layer. EAP also has a facility called > cryptographic binding, which is another instance of channel binding. > Cryptographic binding refers to binding the channel created by a > tunneling EAP method to an inner authentication performed within that > method. Cryptographic binding will likely use unique channel > bindings. > > Do these changes make sense to people? Am I telling any lies or > conflating two architectures in a bad way? > > > ___ > 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
Re: [Emu] EAP-GPSK: Feedback Solicited
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, Hannes Tschofenig wrote: > >> http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/draft-ietf-emu-eap-gpsk-05.txt >> ChangeLog: >> - replaced Hash with MAC > > If I understood the change correctly, GKDF-X(Y, Z) is now using > AES-128-CMAC if ciphersuite #1 is used. This would require 16-octet key > (Y), but the values passed into GKDF in 6.1.3 are of 1 octet (0x00) and > 32 octets (MK). How is this supposed to work? > > -- > Jouni MalinenPGP id EFC895FA > > ___ > 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
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
>> to be an L2 identity. It can be any identity that's meaningful to the >> parties involved, and can serve as the basis for making authorization >> decisions. > > As long as it's cryptographically bound to the L2 channel and that > channel provides suitable protection for the EAP method doing the EAP > channel binding, THEN Sam's observation is correct: "EAP channel > binding" uses what I termed "end-point channel binding" and "EAP > cryptographic binding" uses what I termed "unique channel binding." I don't think I'm convinced that EAP channel bindings are doing this binding to the L2 channel. The identity used in an EAP channel binding must be bound to the AAA security association between the authenticator and the peer in order for everything to work, so it would be more likely a NAS-ID than a MAC address. That's not to say there isn't an L2 binding happening -- but I think it's being performed by the L2 secure association phase that uses the EAP key to derive L2 keys. Then during that handshake, a MAC address may be involved, binding in an L2 identity. 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
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
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 must be bound to the AAA Charles> security association between the authenticator and the Charles> peer in order for everything to work, so it would be more I'm not sure I'd describe the association between the peer and authenticator as an AAA association. I agree with the rest. Ah, I mistyped. I meant AAA security association between the authenticator and EAP server. Charles> likely a NAS-ID than a MAC address. > Are you sure that the binding happens between the mac address and NAS ID? I don't understand how the peer ever confirms the NAS ID at layer two unless it also happens to be a MAC address. This is one of the fundamental issues with EAP channel bindings. The NAS ID is bound to the AAA security association between the authenticator and the EAP server. The MAC address is visible to the client. Thus the peer and EAP server each know a different identity for the authenticator. Whatever identity is used must be channel-bound to the AAA security association, otherwise the authenticator could lie to the EAP server about its identity. I see two solutions: 1. The NAS ID is broadcast to the peer before EAP authentication (e.g. in an 802.11 beacon) 2. The EAP server maintains a static mapping between NAS IDs and MAC addresses, manually binding MAC addresses to AAA security associations I do agree with you though that EAP channel bindings include the peer's lower layer identity and the identity of the authenticator that the peer will later be able to verify. Right -- but there needs to be some way for the EAP server to know the authenticator's lower-layer information in such a way that the authenticator can't lie about its lower-layer information to the EAP server. Charles> I guess I see EAP channel bindings as an EAP<->AAA Charles> binding, and the L2 secure association protocol as the Charles> EAP<->L2 binding. The L2 secure association protocol cannot be an eap->anything binding: it does not typically use EAP level identifiers. It uses EAP keys though. If from a higher layer we know EAP keys could have only been delivered to a particular EAP/AAA identity, and those keys are exported to the lower layer, then I'd think you have a binding from the EAP identity to the EAP keys to the lower-layer keys to the lower-layer identity. -- 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
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
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: >> 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 must be bound to the AAA Charles> security association between the authenticator and the Charles> peer in order for everything to work, so it would be more >> I'm not sure I'd describe the association between the peer and >> authenticator as an AAA association. I agree with the rest. Charles> Ah, I mistyped. I meant AAA security association between Charles> the authenticator and EAP server. I'd define the EAP channel binding problem as follows. There are two sets of identities that the peer and authenticator use: one at the EAP layer and one at a lower layer. There is an additional identity that the authenticator may use to authenticate to the AAA server. The channel binding problem is to make sure that the EAP server authorizes the authenticator's use of the lower layer identity to the peer and the peer's use of a given lower layer identity. In performing this authorization the EAP server must authorize that the authenticator is actually allowed to claim the lower layer identity it wants to claim. I think this is implicit -- you gave the MSK to an authenticator, therefore that authenticator's lower layer (regardless of its identity) is authorized to use that key. Of course, this assumes an authenticator has a single lower layers. I'm not sure the case of multiple lower layers been addressed. EAP could simply forbid it (i.e. one lower layer per authenticator), or say that giving a key to an authenticator authorizes it for all lower layers. > In doing that it will have to make an authorization decision about whether the identity the authenticator uses to authenticate to the AAA server is authorized to claim the given lower layer identity. Currently there's no AAA mechanism for an authenticator to "claim" a lower-layer identity to an EAP server. Lower layer identities would have to be statically provided to the EAP server if the EAP server is going to use them for channel bindings. However that identity--between the NAS and the AAA server doesn't inherently appear anywhere else. It sounds like 802.11R does plan to expose that identity, but that's a design decision for that lower layer. I guess the point of all my commentary is that the SAP needs to be involved in your discussion of EAP channel bindings. Most cryptographically binds an L2 identities to an EAP key, and some new ones (11r) even bind AAA identities to an EAP key. If EAP channel bindings could include AAA identities, then the peer would actually have enough information to start doing identity comparisons and catch lying NASes. -- t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy ___ Emu mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
Sam Hartman wrote: > The more I > read what you, Bernard and Charles say, the more I'm convinced that I > agree with your description of EAP and that my text is correct. The > more I talk, the more you're convinced that my text is wrong. > We're talking past each other somehow. I think your text was correct, but incomplete. I think the SAP needs to be included, as it does channel bindings under Nico's broader definition. The SAP does an EAP lower-layer to EAP layer binding -- it just doesn't provide the authorization you're looking for, hence why we need EAP channel bindings to prevent the lying NAS problem. Sam's suggested text: The first, called channel binding, is used to bind the lower-layer channel created between the peer and the authenticator to the authentication performed using EAP. Specific detials of this facility have not been specified, but it is likely that this channel would use endpoint channel bindings carried in the EAP method exchange. My suggestion for Sam's suggested text: The first, called channel binding, is used to bind the lower-layer channel created between the peer and the authenticator to the authentication performed using EAP. The Secure Association Protocol (SAP) defined by the EAP lower layer often binds lower-layer identities and sometimes even AAA identities into the key derivation, serving to bind EAP keys to the EAP lower layer. However, as this binding is done by the lower layer, and not EAP, there is no explicit authorization by the EAP server for the lower layer to use the EAP keys. Consequently, EAP channel bindings are defined in RFC 3748 to perform the binding at the EAP layer. Specific details of this facility have not been 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
Re: [Emu] updated EAP-GPSK
Nice catches. Also 2nd paragraph in section 5 needs to be updated with the proper OID field size. Jouni Malinen wrote: On Mon, Jul 09, 2007 at 11:30:01PM +0200, Hannes Tschofenig wrote: http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/draft-ietf-emu-eap-gpsk-06.txt * fixed the description of flexibility in the introduction section * added terms to the terminology section * minor update to the key derivation section * clarified the vendor-specific ciphersuite usage * modified the length of the CSuite/Vendor and CSuite/Specifier format * added reference to AES * fixed minor bugs in the examples * updated IANA Considerations section Looks good. Couple of editorial comments about missed edits for PData/Vendor,Specifier size change: 7.4. Protected Data "Type values are encoded as a 6-octet string and represented by a 4-octet vendor and 2-octet specifier field. The vendor field indicates the type as either standards-specified or vendor-specific. If these three octets are 0x, then the value is standards-" s/these three octets/these four octets/ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PData/Vendor| ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PData/Specifier| PData/Length | should be replaced with 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PData/Vendor| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PData/Specifier| PData/Length | "For PData/Vendor field 0x00, the following PData/Specifier fields are defined:" s/0x00/0x/ 11. IANA Considerations "The following is the initial protected data PData/Specifier registry setup: o 0x00 : Reserved o 0x01 : Protected Results Indication The PData/Specifier field is 24 bits long and all other values are available via IANA registration." s/0x00/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
[Emu] review of PP-EAP
cified. What should the server do if it receives a NACK for a TLV? Is that a catostrophic error? Should each TLV detail what should happen if a NACK is received in response? Section 4.11.3: (editorial) indenting issues Section 4.11.6: This statement needs help: "Vendor TLVs may be optional or mandatory." What are the implications of a mandatory vendor-specific TLV? Isn'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 need IANA space for the error codes? Are they extensible? Section 10: I think 3748 should be a normative reference. -- t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> eng.umd.edu/~tcc adjunct professor, electrical engineering, university of maryland ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP-GPSK & Key Derivation Function
All, My suggestion is adding the following to the GPSK document: - For AES ciphersuite say keys MUST be 128 bits in length or longer, and longer keys be truncated to 128 bits for use - For HMAC ciphersuite say keys MUST be 256 bits in length or longer, and longer keys be truncated to 256 bits for use - RECOMMEND that 256 bit keys be provisioned in all cases to provide enough entropy for all current and many possible future ciphersuites - Add a new section describing requirements on future ciphersuites that addresses necessary security requirements and describes their need to specify 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 is the key derivation step: MK = GKDF-16 (zero, PL || PSK || CSuite_Sel || inputString) ^ Here is the problem. Here is what Charles recognized during the discussion: " I just looked though the definition of CMAC, the MAC used in one of our two ciphersuites, and the zero key looks like it might cause some problems. Unlike the HMAC ciphersuites, it doesn't simply concatenate the key with the data input. The first step is to compute: k0=E_k(0x00) k1=k0*x mod p(x) k2=k1*x mod p(x) These values would always be fixed. During the CBC operation, they are XOR'd with the final message block. k1 is XOR'd if the final message block's length matches the encryption block length. k2 is used otherwise on a message padded with 1000...b. I think what using an all-zero key does is reduce the security of CMAC to the security of CBC-MAC with an all-zeros IV. While the ramifications of this are debatable for our applications, it's still probably not a great idea. Currently we can't use the PSK as the input to the first KDF because its length may not match the selected ciphersuite's block length. We wanted to try to do was have a ciphersuite that could be implemented using only AES. " Do you agree that the problem is real? If yes, then we believe that there are the following solution steps: 1) We would need some way to normalize the length of the PSK for the selected ciphersuite. We could define an additional cryptographic primitive in every ciphersuite that does this derivation, such as SHA256-128 for the AES ciphersuite and SHA256 for the HMAC ciphersuite. 2) We could switch to a different KDF, for example to the one used for IKEv2. Can you come up with other solution approaches? Which solution approach should we pick? Ciao Hannes ___ 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
Re: [Emu] RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls
The requirements for this emergency services EAP method look a lot like a method that would be really useful for hotspots. Most hotspots authenticate via a web portal, and perform admission control based on a MAC address. In many deployments it's fairly easy to find the MAC address of someone who has already authenticated, and then run "ifconfig wlan0 hwaddr " to usurp their session without paying for it. Often switching to a mutually-authenticated EAP method is not viable, because there is no enrollment capabilities, i.e. you can't sign up new users without giving them a web GUI to type in their credit card information. If hotspot deployers had a server-authenticated EAP method that tied a client's MAC address to a particular set of keys, they could then decide whether that user could access the Internet based on whether or not they had signed in to a web portal or not. This approach would go a long way toward improving security in many wireless networks. I think it would be extremely useful in hotels, universities, coffee shops, etc. It might be useful to think about some requirements for these scenarios too, and kill two birds 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
Re: [Emu] I-D Action:draft-ietf-emu-eap-gpsk-07.txt
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, Nov 19, 2007 at 03:50:02AM -0500, [EMAIL PROTECTED] wrote: Title : EAP Generalized Pre-Shared Key (EAP-GPSK) Filename: draft-ietf-emu-eap-gpsk-07.txt Minor editorial comments: It looks like the general description of MK derivation in '4. Key Derivation' was not updated to match with the ciphersuite specific changes in 7.1.3 and 7.2.3. The following lines: o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server o zero = 0x00 || 0x00 || ... || 0x00 (KS times) o MK = KDF-KS(zero, PL || PSK || CSuite_Sel || inputString)[0..KS-1] would need to be changed to: o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server o MK = KDF-KS(PSK[0..KS-1], PL || PSK || CSuite_Sel || inputString)[0..KS-1] 7.1.3 and 7.2.3: MK = GKDF-16 (PSK[0..127], PL || PSK || CSuite_Sel || inputString) MK = GKDF-32 (PSK[0..255], PL || PSK || CSuite_Sel || inputString) The 0..127 and 0..255 are clearly usings bits, but these should be bytes to be consistent with the 0..KS-1 style used elsewhere, i.e., these lines should be MK = GKDF-16 (PSK[0..15], PL || PSK || CSuite_Sel || inputString) MK = GKDF-32 (PSK[0..31], PL || PSK || CSuite_Sel || inputString) Now that definition of 'zero' was removed from MK derivation, Method-ID derivation is using implicitly defined 'zero'. Even though it is relatively obvious what length will be used here, it would be better to state this explicitly: Add following line to 7.1.3 before Method-ID derivation: zero = 0x00 || 0x00 || ... || 0x00 (16 times) Add following line to 7.2.3 before Method-ID derivation: zero = 0x00 || 0x00 || ... || 0x00 (32 times) Especially the ciphersuite 2 case would benefit from explicit statement since HMAC-SHA256 could use any key length. I don't see any particular need for this to be 32 octets, but that would be consistent with other uses of GKDF and anyway, this matches with the KS-octet 'zero' used in Ch. 4. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
[Emu] EAP Channel Bindings Drafts
EMU, Here are some rough -00 docs describing channel bindings for EAP. http://www.ietf.org/internet-drafts/draft-clancy-emu-aaapay-00.txt http://www.ietf.org/internet-drafts/draft-clancy-emu-chbind-00.txt "aaapay" defines bindings to existing EAP methods for them to carry Diameter AVPs 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.edu/~tcc electrical & computer engineering, university of maryland ___ Emu mailing list Emu@ietf.org http://www.ietf.org/mailman/listinfo/emu
Re: [Emu] GPSK (Current WG Work item status)
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 items. Please respond with comments, queries, or feedback on the items listed below. Work item: - A mechanism based on strong shared secrets. This mechanism should strive to be simple and compact for implementation in resource constrained environments. Status: - GPSK (http://tools.ietf.org/html/draft-ietf-emu-eap-gpsk-08) Waiting on revision from authors to address AD comments. Alan DeKok ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Review of draft-clancy-emu-chbind-00
Bernard, 00 was an extremely preliminary version. 01 has been completed for a while now, just not posted. I just posted it. We'll go through your comments and see which of them are addressed in the new version (I suspect many of them will be). Regardless, thank you for your review. -- 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 adoption of an EMU WG work item. Issues: a. Mistatement of the 'Lying NAS' problem. The 'Lying NAS' problem does not just concern the issue of whether the authenticator gives different information to the peer and the server; it also relates to the ability of the server to verify that the information is actually correct. The document does not refer to the necessity of first-hop verification of the information provided by the authenticator, such as the mapping between the NAS-Identification attributes and the source address. The need for verification impacts the trust model in some major ways, since not only does the authentication server need to trust that the authenticator attributes have not been modified along the path -- it also needs to trust that the first hop was configured to check the validity of attributes that only it can check. For example, it's not much help for the AAA Server to verify that the RSN IE provided to the STA is the same one it got from the AP if there is no way of verifying whether the AP actually was configured to emit that RSN IE. b. Lack of applicability to the roaming case. The document states that Channel Bindings only apply to the non-roaming case. I'm not sure why this restriction is mentioned because the issue of verification is present even within a single domain. c. Discussion of 'fuzzy' comparisions. By their nature, Channel Bindings may include information that may be opaque to the AAA server, such as the RSN IE. Given that the AAA server may not be capable of understanding the contents of the attributes, I question whether the concept of 'fuzzy comparisons' makes sense. Rather, I think we need to assume that a AAA server will probably only be capable of 'byte by byte' comparisons in most cases. This is an important issue, because it affects the structure of data that needs to be provided by the client, and avoid potential 'canonicalization' issues that could greatly complicate the successful implementation of channel bindings. d. Discussion of lower layer channel bindings. The document does not discuss the potential use of channel bindings in lower layers such as IEEE 802.11r. I think that this is important since lower layers such as 11r do bind EAP keying material to lower layer parameters (such as the peer and authenticator MAC address). Thus, lower layer channel bindings is an alternative that should be discussed. e. Development of requirements. If this document is going to include an evaluation of alternative approaches, then it needs to clearly articulate the requirements for such an evaluation. f. Clear distinction between RFC 5056 and 3748 channel binding concepts. The current document is not as clear as it could be on this. The RFC 5056 channel binding concept is closer to that of 'cryptographic binding' than it is to EAP channel bindings. This should be made clear. g. Exploration of operations implications. There are a number of barriers to successful implementation of channel bindings that need to be explored, including: 1. Required configuration for first-hop AAA clients. 2. Potential changes to drivers and AAA servers. 3. Potential impacts on authentication reliability. h. Motivation. Why should we care about Channel Bindings? Given the operational costs I'd suggest that the document needs to make a case that there is a potentially serious security vulnerability here. Such a case probably involves some kind of financial fraud issue which is most likely in a roaming situation - which is unfortunately a scenario that the document rules out of scope. Some specific comments. Abstract This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods. [BA] I'd add a definition of the problem to the abstract goals. Section 1 A well-documented problem with the current Extensible Authentication Protocol (EAP) architecture [RFC3748] when used in pass-through authenticator mode is the so-called 'lying NAS' problem. Here, a Network Access Server (NAS), or pass-through authenticator, may authenticate to the backend AAA infrastructure using one set of credentials, while representing contrar
Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1st round of comments)
strator/user deploying this, it needs significantly more detailed instructions. Changed to SHOULD. S11.8, 1st para: third form of DoS that should be relevant is preventing valid peer and authenticator from communicating (and there's plenty of text about silently discarding things etc. that attempts to address this) Added. S11.8, the description about client not having to keep state seems wrong -- client needs to keep state to verify that RAND_Peer is fresh (i.e. RAND_Peer in GPSK-1 and GPSK-3 are the same), right? This analysis was added after some reviews from Mitchell's group at Stanford. This text actually could introduce vulnerability to a replay attack. S11.10, perhaps some other word than "Exposition" would be better here? Replaced with "Compromise". S11.10, "In particular, this PSK must not be shared by a group of peers communicating with the same server." One literal interpretation of this sentence would be that ID_Peer can't identify a user account if the user can have multiple devices (EAP Peers). That's probably not exactly what was intended. Addressed. S11.11, should explain what limitations this brings (since in theory EAP-GPSK packets can be longer than minimum EAP MTU) Fixed. S11.16, "Although EAP-GPSK provides confidentiality in its protected data payloads, it cannot claim to do so as per Section 7.2.1 of [RFC3748]". Better explanation needed. Fixed. S11 should include a "security claims" summary (see other EAP method RFCs for examples) Added. S11 does not discuss key strenth (required by RFC 3748) Added. S12 needs to give names for the new registries to be created (e.g. "EAP-GPSK Ciphersuite Registry" , etc.) Added. S12, "IANA is furthermore instructed to add the specified ciphersuites, protected data types, failure codes and op-codes to these registries as defined in this document." -> "The initial contents of these registries are specified below" ? Fixed. S12, "Values can be added or modified with informational RFCs..." Strongly suggest using one of the policies defined in RFC2434. (For example, current text prevents Standards Track RFCs from defining new values!) Swithced to "IETF CONSENSUS". S12, needs some paragraph breaks (e.g. "The Failure-Code field is 32 bits long and all other values are available via IANA registration. The following layout represents the initial OP-Code registry setup:" is very confusing). Fixed. S15, there are several references that should be normative. At the very least: RFC4634, AES, CMAC, CBC. Possibly also eap-keying (as the concepts of EAP "Method-ID", "Session-ID", etc. are not defined anywhere else). Done. Interoperability requires the ability to enter same PSK in both client and server. See e.g. RFC4306 S2.15 and RFC4279 S5.4 for examples of management interface requirements. Added. The OP-Code field is not included in the MAC; if you're sure this is OK, perhaps slightly better explanation in e.g. S11.5. would be good to convince others about this. Added. Defining ID_Server just as an "opaque blob" does not really allow interoperability -- and the spec doesn't really forbit using it in non-opaque ways. Even if we specified that ID_Server MUST NOT be processed in any other way than bytewise comparison, interoperability still requires entering the same ID_Server in both ends (and thus similar management interface requirements as PSK). And e.g. picking client identity "[EMAIL PROTECTED]" when seeing ID_Server "aaa.example.com" wouldn't mean opaque any more. I'm open to suggestions how to handle this, and there probably isn't just one right alternative. Specifying that ID_Server is a domain name, and some kind of simple rules how it could be processed, is one option. Explicitly forbidding any kind of non-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 perhaps help the parties efficiently search a list of PSKs. I've added text in the management interface section (see "Key Management") to discuss this. Document needs more text about leaking information via different failures codes (this is sort of implied in S9 when talking about "depending on its policy", but what exactly the policy and its implications are is not described). Added text to section 11.2. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1st round of comments)
Pasi, This state-minimization approach was proposed by the Stanford security review. In earlier versions of the draft, CSuite_Sel and RAND_Server were not included in GPSK-3, and were not verified. I'm not sure why the language you referenced below got updated after they were added to 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 about: Version -10: For GPSK-3, a peer MUST silently discard messages where the RAND_Peer, the RAND_Server, or the CSuite_Sel fields do match those transmitted in GPSK-2. Version -11: For GPSK-3, a peer MUST silently discard messages where the RAND_Peer field does match the value transmitted in GPSK-2. I guess the security analysis of GPSK was performed assuming the peer does check RAND_Server and CSuite_Sel? While I can't come up with any attack even if this check is omitted (e.g., RAND_Server and CSuite_Sel are still included in MK derivation), is the whole WG comfortable with this change? (I didn't see any discussion about this topic yet.) Best regards, Pasi -Original Message- From: ext Charles Clancy [mailto:[EMAIL PROTECTED] Sent: 29 July, 2008 14:42 To: Eronen Pasi (Nokia-NRC/Helsinki) Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; emu@ietf.org Subject: Re: Review of draft-ietf-emu-eap-gpsk-08 (1st round of comments) Pasi, I've submitted an update that addresses the ASCII text garbling, PL encoding, packet validation inconsistencies, and IANA policies. All that remains is the key/MAC-length issue. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland [EMAIL PROTECTED] wrote: Hannes Tschofenig wrote: As Dan Harkins already pointed out, NIST 800-38B does define CMAC for 256-bit AES, with 256-bit key and 128-bit output. So hardcoding this assumption in EAP-GPSK seems to limit the future algorithm agility somewhat -- is the WG sure this is an acceptable limitation? (If this limitation is kept, I'd suggest mentioning in Section 2 that "KS" is not only the key size, but also MAC output length.) This seems to require a separate discussion on the list. Ok -- please let me know once you think the discussion has concluded. The text (Section 5) should probably say something about non-ASCII characters, especially since NAIs can contain them (and IETF policies usually require dealing with non-ASCII in strings handled by ordinary users -- RFC4306/4279 are probably mostly for admins). Maybe "SHOULD support non-ASCII", with pointer to detailed instructions in Section 2.4 of RFC 4282? Fixed. It seems this update got garbled somehow -- at least I have some difficulties in parsing the new text: Thus the management interface SHOULD support non-ASCII to allow entering values for the ID_Peer and ID_Server as ASCII strings up to 254 octets in length. S4, how is PL encoded when input to KDF? (1 octet, 2 octets?) 2 octets. The text in Section 4 should say so. S12.9: the text about minimal state (only RAND_Peer) seems inconsistent with S10, which requires discarding GPSK-3 if the RAND_Server and CSuite_Sel fields are not the same as in GPSK-2. To make that comparison, it seems you need to store the values after sending GPSK-2? I added text on this issue. I am not fully sure whether it resolves the aspect entirely though. Not really -- the text in Section 12.9 seems to say that doing the comparison (of RAND_Server and CSuite_Sel) can be omitted, but it's a MUST in Section 10. These two sections need to be consistent. >From idnits: Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Ok. The names of the pre-defined IANA policies were also slightly changed, so Section 13 needs some small updates. Best regards, Pasi ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] update channel binding documents
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, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments for draft-clancy-emu-chbind-02.txt
Hannes, Thanks for the comments. I'm working on a revision that addresses the "fuzzy comparison" issue. Certainly there's a cost to implementing channel bindings. EAP methods already support carrying the information, so the only changes would be to their implementations, which could be done incrementally. Having the authenticator send information to the EAP server for comparison doesn't work. The authenticator could simply provide the same false information to both the peer and server. The server needs some way to know whether the information the authenticator is sending is consistent with network policy. Therefore it needs a policy database. If it has the policy database, it no longer needs the authenticator to send this information to it during every transaction. The exact AVPs exchanged are still open for debate. The text there is mostly 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 introduce this work to our AAA server folks then they will obviously ask me the following question: What is the benefit and what does it cost? As you mentioned in the operational considerations section there is cost associated with updating the EAP methods, putting new information into the AAA server database, providing additional policies into the AAA server to accomplish the authorization check. Now, the question really is whether folks are so concerned about the attack. I know the Lying NAS problem but the current text isn't scary enough. Have you ever seen some data that this attack is a real issue? In case you do then it would certainly be valuable information to convey this to the reader. * Reading the operational consideration section I get the impression that you consider that the AAA server database is populated with information about the access points and what information they are going to send to their peers. That might be one way of doing it. Another way would be for the AAA client to send the same set of parameters to the AAA server for comparison. * I am not sure how this fuzzy comparison would look like and how one would do that in practice. Does it mean that you just compare some parameters? Incorporating channel binding information into the key derivation functions would, for sure, get things to break even if the operator running the AAA server decides not to enforce it. It is good that you did not go for that approach. * Figure 1 I think that there is a possible information exchange missing in Figure 1. Shouldn't you also include an arrow between the Authenticator and the EAP server? * You write: " The server MAY send the Cost-Information AVP from the Diameter Credit-Control Application [RFC4006] to the peer indicating how much peers will be billed for service. " To my knowledge, this is not done for network access. This may be done for higher layer applications but AoC isn't really something that you find quite often... * IEEE 802.16 The case is somewhat different here since the access network can actually be authenticated. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments for draft-clancy-emu-chbind-02.txt
Hannes, Another quick comment on the value derived by operators for deploying channel bindings -- channel bindings will give operators the ability to apply detailed authorization policies to EAP-based network access. Right now EAP is primarily just an authentication facility, and authorization is based on only information about the peer. Now authorization can also be based on information about the NAS, and the properties of the network to which the peer is connecting. Using channel bindings, for example, an EAP server could ensure that certain users only connect to 802.11 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 comments. I'm working on a revision that addresses the "fuzzy comparison" issue. Certainly there's a cost to implementing channel bindings. EAP methods already support carrying the information, so the only changes would be to their implementations, which could be done incrementally. Having the authenticator send information to the EAP server for comparison doesn't work. The authenticator could simply provide the same false information to both the peer and server. The server needs some way to know whether the information the authenticator is sending is consistent with network policy. Therefore it needs a policy database. If it has the policy database, it no longer needs the authenticator to send this information to it during every transaction. The exact AVPs exchanged are still open for debate. The text there is mostly 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 introduce this work to our AAA server folks then they will obviously ask me the following question: What is the benefit and what does it cost? As you mentioned in the operational considerations section there is cost associated with updating the EAP methods, putting new information into the AAA server database, providing additional policies into the AAA server to accomplish the authorization check. Now, the question really is whether folks are so concerned about the attack. I know the Lying NAS problem but the current text isn't scary enough. Have you ever seen some data that this attack is a real issue? In case you do then it would certainly be valuable information to convey this to the reader. * Reading the operational consideration section I get the impression that you consider that the AAA server database is populated with information about the access points and what information they are going to send to their peers. That might be one way of doing it. Another way would be for the AAA client to send the same set of parameters to the AAA server for comparison. * I am not sure how this fuzzy comparison would look like and how one would do that in practice. Does it mean that you just compare some parameters? Incorporating channel binding information into the key derivation functions would, for sure, get things to break even if the operator running the AAA server decides not to enforce it. It is good that you did not go for that approach. * Figure 1 I think that there is a possible information exchange missing in Figure 1. Shouldn't you also include an arrow between the Authenticator and the EAP server? * You write: " The server MAY send the Cost-Information AVP from the Diameter Credit-Control Application [RFC4006] to the peer indicating how much peers will be billed for service. " To my knowledge, this is not done for network access. This may be done for higher layer applications but AoC isn't really something that you find quite often... * IEEE 802.16 The case is somewhat different here since the access network can actually be authenticated. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Review of draft-clancy-emu-chbind-02.txt
Bernard, The recently-submitted -03 addresses most of your comments. You suggested two additional sections which are TBD -- an appendix describing how channel bindings addresses a number of specific attacks, and a cost-benefit analysis. Can you be more specific about the cost-benefit 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 issues remaining. Section 1 The so-called "lying NAS" problem is a well-documented problem with the current Extensible Authentication Protocol (EAP) architecture [RFC3748] when used in pass-through authenticator mode. Here, a Network Access Server (NAS), or pass-through authenticator, may represent one set of information (e.g. identity, capabilities, configuration, etc) to the backend Authentication, Authorization, and Accounting (AAA) infrastructure, while representing contrary information to EAP clients. [BA] As noted in the review of -00, the issue isn't just whether the NAS is sending different information to the EAP peer and AAA server. It also is possible that the NAS will send the same information to the peer and AAA server, but that both could be wrong. Section 3 There are two different types of networks to consider: enterprise networks and service provider networks. In enterprise networks, we assume a single administrative domain, making it feasible for an EAP server to have information about all the authenticators in the network. In service provider networks, global knowledge is infeasible due to indirection via roaming. When a client is outside its home administrative domain, the goal is to ensure that the level of service received by the client is consistent with the contractual agreement between the two service providers. [BA] While the AAA server might have information about all the authenticators in the enterprise case, if it is more than one hop removed from the NAS, then it might not be able to check the validity of the AAA attributes. For example, a first hop AAA server can check if the NAS-IP-Address/NAS-IPv6-Address attributes match the IP source address corresponding to the shared secret. A AAA server multiple hops away cannot verify this. o Service Provider Network: An EAP-enabled mobile phone provider operating along a geo-political boundary could boost their cell towers' transmission power and advertise the network identity of the neighboring country's indigenous provider. This would cause unknowing handsets to associate with an unintended operator, and consequently be subject to high roaming fees without realizing they had roamed off their home provider's network. [BA] This seems like a good example. My understanding is that power boosting actually does occur. It might be worthwhile to consider adding an Appendix to talk about how channel bindings might address this or other potential examples. o It allows for fuzzy comparisons of network properties, rather than requiring absolute comparisons. This allows for a broader definition of consistency, rather than bitwise equality. [BA] As discussed during the EMU WG meeting, a term other than "fuzzy" would probably be better. Also, there probably needs to be more discussion on why enabling bit-by-bit comparisons is undesirable or not important. Section 4 o Given it doesn't affect the key derivation, exact use of the results can be subject to policy, to facilitate debugging, incremental deployment, and backward compatibility. [BA] I think the major issue with the key derivation approach is that in practice, "canonicalization" and formatting issues are highly likely in a channel bindings implementation, even if formats are well specified. The implication of this is that requiring enforcement may not be practical; rather logging, or evidence gathering may be all that can be achieved. The key derivation approach can't support such a "logging only" mode; enforcement is required. The scope of EAP channel bindings differs somewhat depending on the type of deployment in which they are being used. In enterprise networks, they can be used to authenticate very specific properties of the authenticator (e.g. MAC address, supported link types and data rates, etc), while in service provider networks they can generally only authenticate broader information about a roaming partner's network (e.g. network name, roaming information, link security requirements, etc). The reason for the difference has to do with the amount of information you expect your home EAP server to know about the authenticator and/
Re: [Emu] EAP Channel bindings (Current WG Work item status)
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: IETF 73 is approaching soon, and we need to ensure that make progress on the current WG activities. To that end, I am repeating previous posts about WG status items. Additional reviews and comments have been posted recently: http://www.ietf.org/mail-archive/web/emu/current/msg00963.html Are there additional reviews / reviewers before IETF 73? Alan DeKok wrote: While the charter updates are being formally approved, we can start discussions about the new work items. Please respond with comments, queries, or feedback on the items listed below. Work items: - A document that defines EAP channel bindings and provides guidance for establishing EAP channel bindings within EAP methods. - Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will extend EAP-TLS and/or the above tunnel method. Status: Potential drafts for consideration by the working group: http://www.ietf.org/internet-drafts/draft-clancy-emu-chbind-00.txt http://tools.ietf.org/html/draft-arkko-eap-service-identity-auth-04 Are there additional comments or updates on these drafts? There has been little activity on the list recently. These drafts would be a good basis for discussion. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Review of draft-clancy-emu-chbind-03
Bernard, Version v04 was just submitted and should address most of your comments. We added some clarifications to discuss the "lying NAS" vs "lying provider" problems. Really all we can reasonably validate is the last hop in a AAA proxy chain. In an enterprise network, that's the NAS. In a service provider network, it's either the proxy for your roaming partner, or a gateway like IPass. If anything down your proxy chain is malicious, we consider the entire chain malicious, as we cannot determine the origin of an attack within the chain. We also added a lot more text about AAA attributes received by the EAP server by the NAS / last-hop AAA proxy, and which can be validated and how. Unfortunately I won't be at the EMU meeting -- Katrin will present the changes since the last meeting. I'll in Minneapolis starting Wednesday, so 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 badly mangled this email, so let's try again. snip snip = Food for the exploder snip snip = Thanks for the improvements in -03. Some additional comments: Section 1 " A concrete example of this may be an IEEE 802.11 access point with a security association to a particular AAA server. While there may be some identity tied to that security association, there's no reason the access point needs to advertise a consistent identity to clients. In fact, it may include whatever information in its beacons (e.g. different SSID or security properties) it desires. This could lead to situations where, for example, a client joins one network that is masquerading as another." I think there is also a potential MITM attack that channel bindings can address. In IEEE 802.11r, the SSID is bound to the TSK calculation, so that the TSK needs to be consistent with the SSID advertised in the Beacon. This would seem to preclude an external attacker from spoofing a Beacon and then modifying an Association-Request, but would not avoid a "lying NAS" from sending an intentionally bogus Beacon (and calculating the TSKs accordingly). In IEEE 802.11i, there is no SSID/TSK binding, so both a spoofing and a "lying NAS" attack are possible. For example, an attacker could spoof a Beacon and then modify an unauthenticated Association-Request, so as to cause a client to think it's connecting to a network other than the one it's actually connected to. This will work as long as the credentials and method provisioned for the spoofed and actual network are the same. In a "lying NAS" attack, the NAS can provide an incorrect Called-Station-Id), to the AAA server, which will authorize it as long as it is one of the networks that could conceivably be authorized via the proxy from which the request came (e.g. the NAS can also impersonate another NAS from an entirely different network or even a different provider). This could cause the AAA server to believe it had granted access to a different network or even provider than the one the client got access to. However, typically both the network the client actually got on and the one the AAA server authorized need to be provisioned on the client, right? Section 3 " A compromised access point connected to the guest network could advertise the SSID of the corporate network in an effort to lure clients to connect to a network with a false sense of security regarding their traffic. " This scenario also would appear to assume that the corpnet and the guest network utilize the same credentials and EAP method. Otherwise, the AAA server wouldn't provide keys and grant access, right? " This would cause unknowing handsets to associate with an unintended operator, and consequently be subject to high roaming fees without realizing they had roamed off their home provider's network. " This scenario (variants of which have actually occurred in practice) seems to go beyond the "lying NAS" to the "lying provider" issue. That seems worth highlighting, since it influences the degree to which the AAA server can depend on the local proxy. If the local proxy can't be trusted, then this throws doubt on whether channel bindings should be included in cleartext AAA attributes modifiable by the proxy. There might be some even nastier attacks worth mentioning. For example, a compromised NAS might send a Beacon known to generate a buffer overflow within certain (unpatched) drivers. This Beacon might reflect a correct SSID, but might include other bugs IEs.
[Emu] request to adopt aaapay as WG item
EMU, In conjunction with Alan's consensus call for adopting draft-clancy-emu-chbind as a WG item, I'd like to request its supporting document, draft-clancy-emu-aaapay, also be adopted as a WG item. The "chbind" document defines what data should be transported, and "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-01 -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] channel binding document progress
EMU, After recent discussions, the following are proposed changes to the channel bindings document. The changes below don't make any architectural or technical changes, but they break up the somewhat free-form text into specific subsections, consolidating ideas and improving the flow and readability of the document. Section 4: split into multiple sections, one detailing the decision about the type of channel bindings to use, and another that elaborates on the architecture and its implications (with appropriate forward references) Section 5: split into multiple sections, one detailing the protocol itself, and the other describing evaluation of policy consistency (including wildcard policies, use of permissive vs enforcing modes for incremental rollout, etc) Section 6: break into subsections for different system components, e.g. a separate subsection of requirements on EAP method transport Section 7: only define bindings for 802.11, and add a new section that provides requirements for future documents that define lower-layer bindings for other EAP lower layers Lastly, are there any comments on adoption of draft-clancy-emu-aaapay as a working group item? I posted 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.ietf.org/mailman/listinfo/emu
