[Emu] EAP-GPSK comments
sed, a vendor-specific ciphersuite is encoded. In this case, the following six octets identify the ciphersuite. The first three octets are the vendor-specific OID, and the last three octets are vendor assigned. 7.2: s/indiciates/indicates/ 7.3: s/256-bit RAND_Server/32-octet RAND_Server/ in Figure 7 (GPSK-1) (to be consistent with other figures) s/PD_Payload_1/PD_Payload_2/ in Figure 9 (GPSK-3) 7.4: s/indiciation/indication/ -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP-GPSK comments
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 key SK.
>
>where Input refers to the following content:
>o Value of SEC_SK in message GPSK-2
This SEC_SK cannot be 'Input'.. Input would be Y in the SEC_X(Y)
definition, i.e., this Input is being passed into SEC function as Y..
> We could also write "... input should be the data following OP-Code in
> the message." It might be easier.
Yes.
> Do I miss the issue here?
Maybe. My main point was that SEC is a defined function and it does not
make sense to pass a function as an Input to AES-128-CMAC..
> Thanks for your review. Please find the updated draft at:
> http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/
Thanks. The changes looked fine ot me.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP-GPSK comments
On Sun, Jun 11, 2006 at 09:30:41PM +0200, Hannes Tschofenig wrote: > >>>Variable length ID_Server and ID_Client are concatenated in MK and > >>>KDF_out derivation. > I am not sure I have seen this type of construction. Maybe I just forgot > it. > > Wouldn't you then have to add a delimiter for each concatenation symbol? As far as I can tell, only the cases where a variable length data is used in a way that there is no clear boundary between two fields (e.g., two variable length fields concatenated together) would need this. Adding 16-bit length field before the variable length ID_Server and ID_Client would resolve this by making it explicit where the boundary between ID_Client and ID_Server is. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP-GPSK comments
On Sun, Jun 11, 2006 at 02:57:02PM -0400, Charles Clancy wrote: > 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. For -00 version, this was in quite good state. I was able to implement a functional server and peer without any major problems and the number of places needing "liberal interpretations" of the text was very small. > 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. As long as it is available at the same time as EAP-GPSK would be taken into use, I don't care that much whether it is included in the same document or not. However, I would like to avoid need for mandatory/optional selection and interoprability issues with some implementations implementing this or not. Making it mandatory for all cases (or not implement it at all, if that is preferred) would make implementations simpler. > 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. One option would be to add a GPSK-ERROR opcode that would be used to information peer of the error. In case the keys have already been derived, this could be used as a protected result indication for the failure case. Peer would reply with GPSK-ERROR and server would finish the negotiation with EAP-Failure. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP-GPSK comments
On Sun, Jun 11, 2006 at 11:37:56PM +0200, Hannes Tschofenig wrote: > >For -00 version, this was in quite good state. I was able to implement a > >functional server and peer without any major problems and the number of > >places needing "liberal interpretations" of the text was very small. > > Great. How long did it take you to get something implemented? Maybe a total of eight or so hours which includes reading the draft and writing the review comments. Implementation itself with quick tests took only couple of hours. Though, I had already implemented EAP-PSK/PAX/SAKE before and that certainly helped here since I had all the EAP framework and crypto routines available. > Will the code be made available? Server side is included in hostapd (integrated EAP server) and peer in wpa_supplicant. The current development branch snapshot includes the implementation (http://hostap.epitest.fi/releases/snapshots/). For testing, I'm using hostapd as a RADIUS server with EAP-GPSK server and eapol_test (test tool from wpa_supplicant) as a EAP-GPSK peer and IEEE 802.1X authenticator/RADIUS client. EAP-GPSK parts are in hostapd/eap_gpsk.c and wpa_supplicant/eap_gpsk*.[ch]. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP-GPSK comments
On Sun, Jun 11, 2006 at 08:58:41PM -0700, Lakshminath Dondeti wrote: > I am not a fan of MAC failed messages, to say the least. Those would > allow an adversary to start guessing the PSK and have the guesses > deterministically validated by the server. I would however send a > generic failure message, if it helps. I also agree with Bernard's > take on this. Based on the number of questions I see from end users wanting to know what exactly went wrong and how to diagnose authentication failures, it would be nice if there were a better mechanism for figuring out that PSK could have been wrong that just waiting for a timeout. Unfortunately, in the case of GPSK-2, there are no shared keys to authenticate this information. Any errors for GPSK-3 or 4 could be reported with a MAC. Generic error message can be faked since the peer has no way of knowing whether the server derived the same key as it did and would have to ignore MAC failure in the error message. Server could send some kind of error notification that the peer is free to ignore based on its security policy. That would allow a faster reaction on the client side and at least possibility of the peer implementation determining that the reason for failed authentication was in server not liking something about GPSK-2 instead of it being unclear whether the server even received GPSK-2. I don't want to open any security issues with this, but it would be nice to provide something to make it easier to report somewhat meaningful report to the user. Now, I can just report "possible PSK mismatch or server unreachable" after a (potentially long) timeout if GPSK-2 with incorrect MAC is silently ignored. Would there be any mechanism to make this report more informational for the user? -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Review of draft-clancy-emu-eap-shared-secret-01
On Wed, Jul 12, 2006 at 09:50:15AM -0700, M. Vanderveen wrote: > Personally I'm somewhat disappointed that AES-EAX was chosen, even though > it's fame is that is simpler than CCM, which is what 802.11i proposes. Not > having participated in the discussions on algorithm selection, I am wondering > if anybody have given thought to what can be done to help the power and > memory-limited mobile, who now has to have *hardware* to please everybody: > the EAP for network access, SAP 4-way handshake for link-layer access, > MobileIP for mobility, VPN to sooothe operator concerns, etc, to name a few > possibilities. Not all of these must be done in hw, of course. What do the > implementors have to say about these? It depends.. So far, I have only needed to implement AES-EAX because of EAP-PSK and now EAP-GPSK, i.e., I haven't needed it for anything else in IEEE 802.11/802.1X/EAP area. I did need to implement CCM for IEEE 802.11i. However, it is used only for data frame encryption/decryption (IEEE 802.11i uses AES key wrap algorithm, RFC 3394, in higher layer operations) and in many designs, it is not easily available for the EAP implementation. CCMP (AES-CCM) may be implemented in the hardware/ firmware/device driver and there may not be an interface for the EAP server/peer (usually, a user space application) to access the same implementation. Sure, it is possible to re-use the same code, but that may not be the most common solution. In addition, adding another mode of AES in software is not really taking that much space. In other words, I'm not too concerned from the view point of implementation size of EAX vs. CCM. However, I would have to admit that it would have been easier to implement EAP-PSK (and now GPSK) if CCM had been used instead of EAX since I first had to figure out what exactly EAX is doing whereas I was already familiar with CCM because of IEEE 802.11i background. -- Jouni MalinenPGP id EFC895FA ___ 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
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
Re: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-00.txt
On Thu, Oct 26, 2006 at 02:04:58PM -0400, Charles Clancy wrote: > Actually, the descriptions in chapter 6 are incorrect, and need be fixed > to reflect the changes in chapter 4. OK. > 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. Only with Ciphersuite 1.. Ciphersuite 2, i.e., HMAC-SHA256, should be able to handle arbitrary length keys. Does the following change match with your understanding? In 6.1.3, replace MK = GKDF-16 (PSK[0..15], RAND_Client || ID_Client || RAND_Server || ID_Server) with MK = GKDF-16 (Zero-String, PL || PSK || CSuite_Sel || RAND_Client || ID_Client || RAND_Server || ID_Server) (I did not find definition for how PL is to be represented here. Is it enough to limit to PSKs of up to 255 octets and define PL to be one octet?) In 6.2.3, replace MK = GKDF-32 (PSK, RAND_Client || ID_Client || RAND_Server || ID_Server) with MK = GKDF-32 (Zero-String, PL || PSK || CSuite_Sel || RAND_Client || ID_Client || RAND_Server || ID_Server) (Same comment about PL) As an alternative, this could be MK = GKDF-32 (PSK, CSuite_Sel || RAND_Client || ID_Client || RAND_Server || ID_Server) since HMAC-SHA256 should have no problems with variable length PSK. By the way, is the definition of Zero-String (KS octets of 0x00) really suitable for Ciphersuite 2? Why bother generating a sequence of 32 octets of 0x00 for HMAC-SHA256 key (which could as well be zero-length). -- Jouni MalinenPGP id EFC895FA ___ 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
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.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Re: [Hokeyp] [Emu] Re: MSK but no EMSK
(sorry for the duplicate; I sent this first with incorrect email address which did not go through to the mailing list) On Sat, Nov 18, 2006 at 09:43:40AM -0800, Bernard Aboba wrote: > While I would expect that RFC 3748-compliant implementations will take less > than 7 years to appear, we are still only at the beginning of the road. > For example, there are no RFC 3748-compliant implementations shipping yet; > we have not had an RFC 3748 bakeoff demonstrating interoperability between > two distinct implementations with respect to new RFC 3748 features > (including the EMSK); no open source RFC 3748-compliant implementations > exist yet. The current development branch for wpa_supplicant (EAP peer) and hostapd (EAP server) includes support for most of RFC 3748, including EMSK derivation in many of the EAP methods and use of expanded types. Sure, EMSK is not currently used for anything, but at least it is included in the EAP method interface and the programs are ready to start using it once suitable use of EMSK is specified. I would be interested in running interoperability tests for RFC 3748 features with other implementations. I haven't tested EMSK derivation with another implementation, but expanded types have been tested with other implementations. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] WG Last Call: draft-simon-emu-rfc2716bis-05
On Thu, Nov 30, 2006 at 10:28:51AM -0800, Joseph Salowey (jsalowey) wrote: > This is a working group last call for draft-simon-emu-rfc2716bis-05. 2.3. Key Hierarchy Session-Id = 0x0C || client.random || server.random Isn't Session-Id usually the concatenation of the EAP type and some session specific information? Is that 0x0C just a typo? EAP-TLS uses EAP type 13 (0x0D) and I would have expected to see 0x0D || ... here. -- Jouni MalinenPGP id EFC895FA ___ 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
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/ -- Jouni MalinenPGP id EFC895FA ___ 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
On Mon, Jan 08, 2007 at 07:39:06PM -0800, Jouni Malinen 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.. And one more.. 5. Ciphersuites GKDF-X(Y, Z) was modified to use "Hash-Function" instead of MAC_Y. However, there does not seem to be any definition on which hash function is used here.. SHA-1 is mentioned as a required function and "SHAs" are recommended (whatever that means; SHA-256 and friends?), but the ciphersuite does not include information on which hash function is to be used here. Previously, this was covered by the "Integrity" column of Figure 3. Should the ciphersuite table be extended to define the hash function for GKDF now? In addition, this "SHA-1" here is the only need use of SHA-1 for EAP-GPSK. Do we really need it? Was this done because of possible NIST issues with the use of AES-CMAC for KDF? -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D ACTION:draft-ietf-emu-eap-gpsk-03.txt
On Wed, Feb 07, 2007 at 03:50:02PM -0500, [EMAIL PROTECTED] wrote: > http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-03.txt This is starting to look quite good. Just couple of minor editorial comments at this point: 1. Introduction - s/I-D.vanderveen-eap-sake/RFC4763/ (and matching update for 14. References to move this into the normative list) 4. Key Derivation - s/needs to instantiated/needs to be instantiated/ -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC: Review of draft-ietf-emu-eap-gpsk-03
On Mon, Mar 05, 2007 at 06:03:18PM -0800, Narayanan, Vidya wrote: > 1. Overall, I'm looking for a compelling reason to have another EAP > method and I found none in the document. For instance, all the design > goals listed seem to be satisfied by EAP-TLS-PSK (inclusion of protected > payloads can be done as an extension to TLS as well). And, given that > EAP-TLS-PSK is an incremental change to EAP-TLS, it would be much more > compelling to use EAP-TLS-PSK than EAP-GPSK. So, is there at least one > design goal of GPSK that cannot be met by other methods? As far as I can tell, EAP-TLS-PSK would be yet another EAP method in the same sense as EAP-GPSK, so I don't see EAP-TLS-PSK in any way a better solution from the view point of not adding a new method. As far as comparison of EAP-GPSK vs. EAP-TLS-PSK is concerned, one major part is in EAP-GPSK being much simpler and smaller from implementation view point. In most cases, extending TLS seems to bring in a major extra cost of having to modify a TLS library which is not desirable in many cases. It may mean that the TLS implementation included in the system would not be suitable and the EAP implementation would need to bring in another TLS implementation with maintenance and memory/flash footprint concerns. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: TLS reuse (Re: [Emu] WGLC: Review of draft-ietf-emu-eap-gpsk-03)
On Fri, Mar 09, 2007 at 11:56:07AM -0800, Lakshminath Dondeti wrote: > I have a question. I have some experience with code reuse, but I was > hacking, err... prototyping. What is the general sense on using a piece > of TLS code to do things like EAP-TLS or EAP-TLS and EAP-TLS-PSK? I ask > because elsewhere people make the argument that TLS is already there on > a certain device and so DTLS is an incremental implementation etc. I think the answer is "it depends".. In many (most?) embedded client designs I've been involved with in one way or another, TLS library has been one of the key issues due to the possible overhead (e.g., OpenSSL can add almost 1 MB to the binary). It would be ideal, to be able to share the same TLS implementation for all uses on the device to save in size (both flash and RAM). In addition to size concerns, it would also be quite helpful if the native TLS implementation with the target platform could be used (if one is available) to benefit from existing integration with certificate store and private key access, including UI components. Providing a nice user experience with another TLS library can get difficult, if not impossible, in many cases. That said, it is not always possible to use the native TLS implementation. For example, one of the most difficult aspects of EAP-FAST from implementation view point is its requirement for TLS extensions (ClientHello extension and session ticket). Most existing TLS libraries do not support this, so whoever is implementing EAP-FAST may need to modify TLS implementation and this is something, that is often not feasible for OS/SDK provided implementation. Consequently, EAP-FAST (or EAP-TLS-PSK for that matter) may end up requiring the EAP server/peer implementation to include another TLS library. If whoever is working with EAP method implementation is also in control of the system TLS library, adding support for TLS extensions is less likely to be an issue (though, often the person working on EAP method is not the same as the one working on TLS library, so this adds some extra overhead, but anyway, still manageable). If EAP method is being implemented by someone who does not have any control on the system TLS library, things can get quite difficult. Convinsing TLS vendors to add some extensions may take time and effort; especially so, when they may not see much need for the requested extension as far as the "main uses" of the TLS from their and most of their customers view points are concerned (HTTPS? IMAPS?, etc.). I would say that reusing TLS implementations with functionality specified in TLSv1 (i.e., without any extensions) is fine in many cases since most TLS libraries include all the needed functionality. However, anything new (as in anything brought in during last few years) is going to make such reuse difficult at this point. Sure, in the future this can get easier should the TLS vendors like the new extensions enough to implement them, but until that, there is a risk of causing extra issues to vendors who work with EAP implementation and just rely on external TLS libraries.. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP-GPSK update
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
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
Re: [Emu] Thoughts on Password-based EAP Methods
On Mon, Apr 02, 2007 at 03:45:44PM -0700, Bernard Aboba wrote: > I would agree that "versioning" is not a good idea. However, as I > understand it, EAP-TTLSv0 is the only deployed version of TTLS; v1 has > never been implemented. So currently there is no versioning issue with > TTLS, and if possible, it would be best if the IETF would not create such a > problem. I'm aware of at least one, though maybe partial, implementation of TTLSv1. Anyway, I don't think it has been deployed anywhere. > It is not clear to me that EAP-TTLS needs "versioning" in order to enable > addition of new features in a backwards compatible way, since it already > supports a TLV-based extension mechanism. If this can be done in backwards compatible way, staying with the v0 sounds reasonable assuming features from TTLSv1 are not desired and I don't think would necessarily like to mandate TLS/IA support for the method to be standardized. In general, the PEAP version negotiation itself works fine, but one of the problems is that number of different implementations _within_ the same version number work differently.. The main issue for me from the implementation view point has been lack of clear description of the protocol and existance of differently behaving and already deployed implementations.. EAP-TTLSv0 is in better situation from the viewpoint of most implementation behaving more or less in the same way. However, this can get interesting if new extensions are added and if some of the implementations are not exactly prepared for this. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Thoughts on Password-based EAP Methods
On Mon, Apr 02, 2007 at 10:41:09PM -0400, Hao Zhou (hzhou) wrote: > > differently.. The main issue for me from the implementation > > view point has been lack of clear description of the protocol > > and existance of differently behaving and already deployed > > implementations.. > [HZ] That's not true. There are only two PEAP versions in deployment, > PEAPv0 and PEAPv1. They are different between them. But among PEAPv0 or > PEAPv1 implementations, they interoperate. Have you run interop tests with PEAPv0 and PEAPv1 using a large set of different server implementations? I've tested with ten or so servers that supported various combinations of PEAPv0 and PEAPv1. There were at least six different combinations on behaviors that required peer workarounds to handle.. PEAPv1 is more problematic on this front since there is more than one IETF draft describing a protocol that uses version 1 and these drafts differ on number of areas and none of these drafts actually describe the exact behavior that most servers uses.. For example, at least one server uses "client PEAP encryption" as the label for PRF whereas most use "client EAP encryption". That is clearly an interoperability issue (I've only seen this with PEAPv1 and one RADIUS server, but anyway that is the label described in some of the drafts). Another difference is in how the negotiation is terminated. Some implementations require protected success indication by use of a tunneled EAP-Success. Some use just plain EAP-Success outside the tunnel without any protected success indication. Yet another interoperability issue. One strange case was an implementation that uses incorrect version negotiation and in practice ends up always using v0 (which itself interoperates relatively well, so this is not a major problem). In other words, PEAPv1 is not exactly something I would consider a good example of an interoperable or well-defined EAP method. I think that EAP-PEAP has caused more interop issues in my tests than all other methods combined.. Sure, this is partly due to most implementations supporting PEAP in one form or another so there are more test cases, but still, EAP-TLS and EAP-TTLS have been more or less problem free from the view point of seeing different behavior from implementations. > [HZ] That's the problem. We cannot add or take away functionalities and > maintain interoperability without incrementing the version. If we do > that, then how is that different than creating a new EAP method. The > design team is looking at approach similar to TTLS/PEAP/EAP-FAST, with a > much simpler inner data representation. Whatever the argument made for > TTLS, we can make it for PEAP and EAP-FAST. I haven't went through the details of what would be needed for the changes while trying to maintain backwards compatibility within the same version number, so I cannot comment on the first part, but I can agree with the second. Anyway, I certainly support the idea of using something existing as a starting point whether the end result ends up using the same method number and version or not. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP-GPSK: Feedback Solicited
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
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
On Sat, Apr 07, 2007 at 04:44:54PM -0400, Charles Clancy wrote: > 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) This is something that IEEE 802.11r/D5.0 is doing. R0KH-ID is set to the identity of the NAS Client (e.g., NAS-Identifier if RADIUS is used as the backend protocol) and this identifier is sent to the peer during association (before EAP authentication). In addition, both the R0KH-ID (NAS-Identifier) and R1KH-ID (authenticator MAC address) are mixed in into the key derivation after the EAP authentication. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] updated EAP-GPSK
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/ -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
On Thu, Aug 16, 2007 at 11:39:31AM -0400, Alan DeKok wrote: > Gene Chang (genchang) wrote: > > There is an EAP-FAST implementation on FreeRADIUS from Jouni Malinan. > > If there was, I would have known about it. Yes, and I would assume I would also be aware of this should such a thing have happened ;-). > Jouni has added EAP-FAST to hostapd and to wpa_supplicant. While > hostapd is a RADIUS server, it's pretty minimal. i.e. not database > support, no policy language, etc. I added EAP-FAST support to hostapd mainly to make it (much) easier for me to test client side code in wpa_supplicant. Anyway, that means that there is an open source implementation available for both the server and peer side of EAP-FAST should someone be interested in testing them and was just waiting for broader set of available implementations or access to source code. I would obviously be interested in any feedback on the implementations, too. I try to run as complete interop tests with other implementations as feasible, but don't really have unlimited resources for doing this, so any additional testing would be welcome. Sure, hostapd as a RADIUS server is not meant for large and complex deployments, but I think it works well as a testbed component for testing various EAP methods, including EAP-FAST. In addition, based on past history, it looks like I have quite open view in adding support for new EAP methods regardless of their completeness, popularity, or even suitability for anything ;-). I see this as one of the best ways to evaluate protocol designs and specifications and more or less mandatory part of standard development. -- Jouni MalinenPGP id EFC895FA ___ 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
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. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1st round of comments)
On Tue, Jul 29, 2008 at 12:28:02PM -0400, Charles Clancy wrote: > 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? I would assume the validation was removed in order to allow peer implementation to not store RAND_Server after having derived the keys and sent GPSK-2. Peer will need to know CSuite_Sel for verifying the MIC in GPSK-3 and I would rather not rely on the value sent in GPSK-3 to do this, so that part of the change would not reduce any space in the peer implementation. Anyway, if the values in GPSK-3 are not verified, I don't see much point including them there.. Consequently, I would prefer to revert this change of removing validation of RAND_Server and CSuite_Sel in GPSK-3 and go back to -10 version of that text. By the way, I just noticed that there seems to be something even more seriously broken in this paragraph: For GPSK-3, a peer MUST silently discard messages where the RAND_Peer field does match the value transmitted in GPSK-2. The "discard where _does_ match" does not sound correct; it should be _does not_ match. ;-) This has been incorrect since the text was added in -02.. Clearly this have been too obvious for anyone to notice before (yes, I must have read that, too, and still, I ended up implementing the correct "does not" behavior, not the one specified here). This a text I would actually like to see here: For GPSK-3, a peer MUST silently discard messages where the RAND_Peer, the RAND_Server, or the CSuite_Sel fields do not match those transmitted in GPSK-2. An EAP peer MUST silently discard any packet whose MAC fails. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1st roundof comments)
On Tue, Aug 05, 2008 at 12:36:21PM -0700, Joseph Salowey (jsalowey) wrote: > If we make the change below then we also have to change section 12.9. I > think this is a bit problematic since at one point we had consensus to > address the issues on client state avoidance raised by folks at > Stanford. The goal was that the peer could store its nonce on a > per-server basis rather than on a per-message basis. Since the peer is > only going to have shared secrets for a limited number of servers this > could reduce the amount of state that needed to be kept. Hmm.. I don't know whether I would really see much point in client-side DoS protection for EAP-GPSK, so that part in 12.9 does not matter to me much. As far as peer implementations are concerned, I don't see any significant difference in storing (RAND_Peer,CSuite_Sel,RAND_Server) vs. (RAND_Peer,CSuite_Sel) between GPSK-2 and GPSK-3. > I don't see the value of matching the RAND_Server on the peer so I would > modify Jouni's text as follows: > >"For GPSK-3, a peer MUST silently discard messages where the >RAND_Peer or the CSuite_Sel fields do not match >those transmitted in GPSK-2. An EAP peer MUST silently discard any >packet whose MAC fails." I don't see real value in RAND_Server being included in GPSK-3, so in that sense I'm fine with this. > The text for section 12.9 the third paragraph needs to be clarified: > >"The client has to keep state information after receiving the GPSK-1 >message. To prevent a replay attack, all the client needs to do is >to ensure that the value of RAND_Peer is consistent between GPSK-2 >and GPSK-3. Message GPSK-3 contains all the material required to re- >compute the keying material. Thus, if a client chooses to implement >this client-side DoS protection mechanism it may manage RAND_Peer and >Csuite_Sel on a per-server basis for servers it knows instead of on a >per-message basis." s/Csuite_Sel/CSuite/Sel/ Doing this per-server sounds restricting to me and would mandate that there is never going to be two simultaneous EAP-GPSK authentication sessions going on. Do we really care about storage requirements for 32 octets of extra state when the peer would need to store some state anyway (38 octets vs. 70 octets)? I would rather optimize the packet sizes be removing 32 octets from GPSK-3.. Anyway, if there was consensus on this being something worth doing, I won't be against the text changes you propose here. I think the protocol would work either way and at this point, my main preference is just to get EAP-GPSK published rather sooner than later ;-). -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action:draft-ietf-emu-eap-gpsk-16.txt
On Tue, Oct 28, 2008 at 05:45:01AM -0700, [EMAIL PROTECTED] wrote: > Filename: draft-ietf-emu-eap-gpsk-16.txt This version adds the following text: "IEEE 802.1X as utilized by IEEE 802.11i". However, IEEE 802.11i (more formally IEEE Std 802.11i-2004) disappeared when it was merged into the main standard, i.e., this should now be IEEE Std 802.11-2007 instead of IEEE 802.11i. Neither of these references were listed in 16.1 or 16.2. Should this be added to 16.2? -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] idraft-arkko-eap-aka-kdf-09 and AT_CHECKCODE
It looks like draft-arkko-eap-aka-kdf-09.txt updates the RFC 4187
definition of AT_CHECKCODE by changing the length of Checkcode field to
be "0 or 32 bytes". This does not look correct since EAP-AKA continues
to use 20-byte Checkcode value and the same definition of the attribute
is shared by both EAP-AKA and EAP-AKA' (assuming I understood the draft
correctly). The updated version should include 20 bytes as a valid
length of the Checkcode field (i.e., something like "0, 20, or 32
bytes"). In addition, the following paragraph ("Second, the checkcode is
a hash value ..") should be modified to apply only for EAP-AKA' and only
when using AT_KDF Key Derivation Function value 1.
--
Jouni MalinenPGP id EFC895FA
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Suggestion: draft-arkko-eap-aka-kdf-09
On Tue, Nov 11, 2008 at 08:55:36AM +0200, Jari Arkko wrote: > Yes, that is the question. I do not myself have an implementation yet. I > know people are working on one, but without an implementation I'm not sure > I can provide test vectors. This may be a bit late for the RFC, but how about something like the following text? A small disclaimer is in order, though: I haven't checked the correctness of the implementation yet (i.e., these are the results from more or less the first developer test run when my own server and peer implementation managed to complete negotiation), so I would obviously appreciate it if someone could verify whether they get the same results. Likewise, I would be interested in running an interop test with another implementation to verify that I've interpreted the draft correctly for areas that do not show up that easily in just comparing test vectors. If I didn't miss anything, I think I now have most of the draft implemented apart from the use of AT_BIDDING in EAP-AKA since IANA does not appear to have allocated an attribute value for it yet. EAP-AKA' (draft-arkko-eap-aka-kdf-10.txt) Test USIM with parameters from 3GPP TS 35.208 v6.0.0 4.3.20 Test Set 20 (Milenage): IMSI="2320100" Ki=90dca4eda45b53cf0f12d7c9c3bc6a89 OPc=cb94b9258e6dca4760379fb82581 AMF=61df Full authentication --- Identity: "02320100" RAND=93919412b4f77039967312e67c8fa082 AUTN=b475f7abb53e61dfde33aa7e70a35faf IK=e0f3d116c8e47b7304aaa43847f240ad CK=0f894edd1b37b9f7fd52dbd1ac97986a RES=f28f28e92bd22166 AK=b475f7abb46a SQN=0154 (CK',IK') = F(CK, IK, ) (based on 33.402 CR 0033 to v8.1.1) CK: 0f894edd1b37b9f7fd52dbd1ac97986a IK: e0f3d116c8e47b7304aaa43847f240ad FC = 0x20 P0 = Access network identity: "WLAN" (574c414e) P1 = SQN xor AK: b475f7abb53e Key = CK || IK: 0f894edd1b37b9f7fd52dbd1ac97986ae0f3d116c8e47b7304aaa43847f240ad KDF output (CK' || IK'): 6836dd1eddcc8abd29ce2e664753ed7718105327f8a5c98bdc10360dc8ccef5b CK': 6836dd1eddcc8abd29ce2e664753ed77 IK': 18105327f8a5c98bdc10360dc8ccef5b Selected identity for MK derivation: "02320100" MK = PRF'(IK'|CK',"EAP-AKA'"|Identity) K_encr: 12c66e38118369dc388c08c9d8af2f73 K_aut: 53fcca89940b9a8802e19bde730cc4497d21a2070ca140b4fe0f018961b48337 K_re: e5cfeb09ad34f0b47c4c880dfd4958bd0a1d71aa682c319b9e91ddb86761 MSK: 9085aad974d3323a96fa68c0db54afdc538744f26f8c33869199d1e09bf081ed0d85bdd4b8136cff0f59ce83840587211d5988a69a60b3323e2bc8ecc46678e1 EMSK: 439a9fb8300f33628882f9d0ca101d34b0c1ffb7806c597ea37ac0f949efa59e2b10e4b6263893f98249ffcdcaef12ed4b6e24a498d019a5bb4b9e54f8989e37 NEXT_PSEUDONYM="28c179b81ab38747021e2" NEXT_REAUTH_ID="4ec9a95ae5b8deaceb0d8" Fast re-authentication -- Identity: "4ec9a95ae5b8deaceb0d8" COUNTER: 1 NONCE_S: 2a949450a95d31eaa2a4f6ea9faaa56c MK = PRF'(K_re,"EAP-AKA' re-auth"|Identity|counter|NONCE_S) MSK: c2ad95db83cfbd1b886d3c91f355d321903107f9e77377671d1b2772ed1c475c36b92a1d07dca082962b83ac7d6cd70ef024d4cf2f4ce97716e15f9fa4fb934c EMSK: 229a30ae81329be2516da975335a7d95956f8a9524548845b97a89778e18f98bd901cb33fa3389add3f29eb1b671af338744a8b9219715fbb96f8a20d724bd88 -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Suggestion: draft-arkko-eap-aka-kdf-09
On Sat, Dec 20, 2008 at 06:05:41PM +0530, yogendra pal wrote: > I hope Jouni can test the case-2, case-3, case-4 with his > implementation for further verification. I can confirm that I get the same key derivation results (IK', CK', K_encr, K_aut, K_re, MSK, EMSK) for these cases. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Potential Notes in EAP-FAST Documents
On Wed, Feb 11, 2009 at 09:26:14AM -0500, Tim Polk wrote: > Second, I will be offering the following text for IESG notes on both > documents. The > notes clearly state the drawbacks for EAP type code reuse and define an > acceptable > path for future protocol developers. This looks like an appropriate text to add. However, I would request a small clarification on the exact scope of the different EAP-MSCHAPv2 and EAP-GTC behavior. As far as EAP-FAST-MSCHAPv2 vs. EAP-MSCHAPv2 is concerned, I would expect that EAP-FAST-MSCHAPv2 is actually used both for unauthenticated (anonymous) and server-authenticated provisioning while the proposed note seemed to indicate that the different behavior is implied by the use of an anonymous tunnel. See below for suggested changes to resolve this. I'm assuming that the implicit challenges derived from the TLS handshake are not used in the EAP-FAST authentication, i.e., normal authentication would be using something that is closer to EAP-MSCHAPv2, not EAP-FAST-MSCHAPv2. However, I think that even that use of EAP-MSCHAPv2 differs a bit from the way it is used in other protocols, e.g., as far as key derivation is concerned, but this would have been more of a comment for RFC 4851 than these two drafts that are now discussed. Anyway, since the key derivation from inner method is used also during provisioning, it would be useful to specify the exact process used to derive ISK from EAP-FAST-MSCHAPv2 (especially the order of send/recv MS-MPPE keys which seems to differ from the way this is used in PEAPv0 with cryptobinding). > -- draft-cam-winget-eap-fast-provisioning - > The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type code assigned to > EAP-MSCHAPv2 (26) for authentication within an anonymous TLS tunnel. s/an anonymous TLS tunnel/the EAP-FAST tunnel during provisioning/ > In > order to minimize the risk associated with an anonymous tunnel, > changes > to the method were made that are not interoperable with EAP- > MSCHAPv2. This use of "anonymous tunnel" sounds fine. > Since EAP-MSCHAPv2 does not support method-specific version > negotiation, > the use of EAP-FAST-MSCHAPv2 is implied by the use of an anonymous > EAP-FAST tunnel. s/of an anonymous EAP-FAST tunnel/inside the EAP-FAST tunnel during provisioning/ > This behavior may cause problems in > implementations > where the use of unaltered EAP-MSCHAPv2 is needed inside an > anonymous > EAP-FAST tunnel. Since such support requires special case execution > of > a method within a tunnel, it also complicates implementations that > use > the same method code both within and outside of the tunnel > method. That "anonymous" should likely be replaced, too, but I don't have a good proposal for this one. Maybe s/an anonymous/the/ The implementation complexity comes both from different tunneling methods using different versions of EAP-MSCHAPv2 and from the different use within EAP-FAST depending on state (provisioning vs. authentication). > draft-zhou-emu-fast-gtc -- > Since > EAP-GTC does not support method-specific version negotiation, the > use of > EAP-FAST-GTC is implied when used inside the EAP-FAST tunnel during > authentication. s/ during authentication// I'm not sure whether this "during authentication" was referring to the case where EAP-FAST provisioning is not used (i.e., normal authentication after PAC has been previously provisioned). Anyway, it is probably clearer to just specify that EAP-FAST-GTC is used in all cases inside EAP-FAST tunnel since the draft seems to indicate that this is indeed the case (just note that EAP-FAST-GTC is not allowed in unauthenticated/anonymous provisioning, but it is allowed in server-authenticated provisioning). -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Key derivation differences
On Wed, Feb 11, 2009 at 01:29:34PM -0800, Bernard Aboba wrote: > Are you suggesting that the version of EAP-MSCHAPv2 described in the document > differs in terms > of the MSK/EMSK derivation? Or are you suggesting that further details are > needed on how padding > is accomplished with respect to ISK derivation? Former (for MSK part) as far as using EAP-MSCHAPv2 inside EAP-FAST is concerned (the document itself does not describe EAP-MSCHAPv2 MSK derivation). > In general, ISK derivation doesn't relate to an EAP method so much as the > tunneling method that > utilizes the keys exported by the inner method. So if the issue is purely in > the ISKs, then this > doesn't really relate to EAP-FAST-MSCHAPv2 or EAP-MSCHAPv2 so much as to > EAP-FAST > provisioning mechanism. What I noticed when implementing EAP-FAST and cryptobinding support for EAP-PEAPv0 is that I have to swap the order of MS-MPPE send/recv keys (i.e., swap octets 0..15 with 16..31) of the MSK from EAP-MSCHAPv2 between PEAPv0 and EAP-FAST uses in order to interoperate with other implementations. In other words, EAP-FAST and EAP-PEAPv0(with cryptobinding) seem to use different derivation of ISK when using EAP-MSCHAPv2 as the inner method. I do not see need for similar swapping of the ISK octets with EAP-TLS as the inner method, so I would assume the difference is indeed in how the EAP-MSCHAPv2 MSK derivation is defined. After reviewing the description of the MS-CHAPv2 key derivation, I think I ended up agreeing with the way this is done in PEAPv0+cryptobinding and the order used in deployed EAP-FAST implementations would thus not match with the EAP-MSCHAPv2 definition for MSK derivation. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Potential Notes in EAP-FAST Documents
On Wed, Feb 11, 2009 at 10:05:57PM -0500, Hao Zhou (hzhou) wrote: > To clarify, EAP-FAST-MSCHAPv2 is only being used during anonymous > provisioning mode, in other cases, the normal EAP-MSCHAPv2 is being > used. This is mentioned in draft-cam-winget-eap-fast-provisioning > Section 3.2.3 and reflects current implementations. The design is to > specifically minimize the risk associated with an anonymous tunnel, > which does not apply to an authenticated tunnel. Thanks. Apparently, I looked at my implementation bit too quickly and assumed it was using the implicit challenges for both provision cases, but you are correct, the draft does indeed state this only for anonymous provisioning and I now confirmed that that was also what my implementation was doing. In other words, the changes I asked for the note for draft-cam-winget-eap-fast-provisioning for the topic of when to use EAP-MSCHAPv2 vs. EAP-FAST-MSCHAPv2 should not be made and only the change request for draft-zhou-emu-fast-gtc would be suitable. > As for the ISK derivation from EAP-MSCHAPv2, a further clarification is > probably helpful. As discussed, EAP-MSCHAPv2 documentation doesn't > really describe how MSK is generated, only referencing RFC3079. RFC3079 > only describes how two 128-bit keys are generated, but leaves out how > these two keys are combined to form the MSK. This leaves it to be > defined in a tunnel method specific way. It seems that EAP-FAST may have > defined a combining algorithm different with the other method. I agree for the part that MSK derivation for EAP-MSCHAPv2 is not very well defined and it did require going through multiple documents to figure out the order. As far as MSK derivation for an inner method being tunnel method specific is concerned, I do not agree with that. It should be up to the inner method specification to define how MSK is derived and tunnel method ISK should just use that MSK. I do not remember anymore where exactly I found this, but probably based on the MSCHAPv2 documents and the way MS-MPPE keys are used in other methods, I ended up with EAP-MSCHAPv2 MSK = server MS-MPPE-Recv-Key | server MS-MPPE-Send-Key This is the order used in EAP-PEAPv0 cryptobinding derivation. In EAP-FAST, the opposite order is used: MSK = server MS-MPPE-Send-Key | server MS-MPPE-Recv-Key > Here is what we propose to add to draft-cam-winget-eap-fast-provisioning > Section 3.2.3 to clarify the issue. > > "The inner session key (ISK) generation for EAP-FAST-MSCHAPv2 and > EAP-MSCHAPv2 used inside EAP-FAST MUST follow the steps below. Two 128 > bit master keys MasterSendKey and MasterReceiveKey are generated > according to the RFC3079. They are combined to form the ISK, with > MasterSendKey taking the first 16 octets and MasterReceiveKey taking the > last 16 octets. " Taken into account that MasterSendKey in RFC 3079 is defined as the server MS-MPPE-Send-Key, this matches with the order I described above and including this note in the draft would indeed be a helpful clarification. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Key derivation differences
On Wed, Feb 11, 2009 at 03:56:08PM -0800, Bernard Aboba wrote: > You are saying that in addition to the interoperability issues described in > Tim's note with respect to the EAP-FAST-MSCHAPv2, that this document > also does not conform to the key derivation specified in EAP MS-CHAPv2, > and that as a result it can't interoperate with existing implementations of > EAP MS-CHAPv2, for regular non-provisioning uses? I'm not sure I would go as far as saying it does not conform to a specification taken into account the unclear situation on how MSK derivation for EAP-MSCHAPv2 is defined. More exact statement would be that EAP-FAST ISK and PEAPv0/cryptobinding ISK derivations use different order of MS-MPPE-Send-Key and MS-MPPE-Recv-Key in the EAP-MSCHAPv2 MSK. In other words, implementations that try to use the same EAP-MSCHAPv2 implementation (including the rules for MSK derivation) would not interoperate with both deployed EAP-FAST and EAP-PEAPv0/cryptobinding implementations. Depending on the Send/Recv key order in the MSK, one of the tunnel methods using the MSK from EAP-MSCHAPv2 would need to swap the keys. In my particular case, I ended up implementing EAP-FAST first and found the issue when trying to interoperate with EAP-PEAPv0 cryptobinding after that. As far as which use is correct is concerned, it is not exactly trivial thing to figure out, but my current interpretation of various specifications related to MS-MPPE keys is that the order used in PEAPv0 cryptobinding would match with the order used in other methods. Anyway, having a single document describing EAP-MSCHAPv2, including MSK derivation, would be a useful thing to have for anyone who wants to implement these things. The use of MS-MPPE Send/Recv keys that are different for server and peer side instead of defining the same derivation of full MSK for both server and peer make it very easy to get this wrong. I ended up having to figure this out by testing against deployed implementations and getting surprised that the same code does not work with both uses. Anyway, like I mentioned before, this EAP-MSCHAPv2 MSK difference is not strictly speaking an issue that would be specific to draft-cam-winget-eap-fast-provisioning; it would have been useful to describe it in RFC 4851. Anyway, it looks like the authors are willing to include the additional description in draft-cam-winget-eap-fast-provisioning and for the goal of describing a deployed protocol and allowing vendors to implement it in interoperable way, it is useful to get this described somewhere and this draft looks like the best place to do so at this point. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Key derivation differences
On Tue, Feb 24, 2009 at 09:59:02AM -0800, Bernard Aboba wrote: > Does the following more accurately describe what you are seeing? > At the end of successful authentication, EAP-MSCHAPv2 derives two 16-byte > > MPPE keys as specified in [RFC3079] Section 3.3. The Master Session Key > ([RFC3748]) > > is derived from the two MPPE keys as follows: > > MSK = 16-byte MPPE-Send-Key + 16 bytes zeroes (padding) + 16-byte > MPPE-Receive-Key + 16 bytes zeroes (padding) This does not match with the way ISK is generated in either EAP-FAST or EAP-PEAPv0 with cryptobinding. The main problem is in there being no clear description on how to derive a 64-octet MSK from EAP-MSCHAPv2. Anyway, ISK is only going to use up to 32 octets of MSK (the first octets; anything beyond that will be ignored). Consequently, the zero padding in the MSK must not occur in that part to match the current uses. In addition, the Send vs. Recv key concept is problematic since the EAP peer and server (or well, more likely authenticator and supplicant) have different directions for sending and receiving. If we want to define EAP-MSCHAPv2 MSK derivation in a way that matches with the normal ISK generation rules (take first 32 octets) in EAP-PEAPv0 with cryptobinding, we would get something like this: MSK = 16-byte server/authenticator MS-MPPE-Send-Key | 16-byte server/authenticator MS-MPPE-Recv-Key | 32 bytes of something (e.g., zeroes; ISK does not care, some other uses might, so likely better to use something else than zeroes..) On the peer, the first keys would be peer MS-MPPE-Recv-Key | peer MS-MPPE-Send-Key (i.e., reverse Recv/Send). If we want to define EAP-MSCHAPv2 MSK derivation in a way that matches with the normal ISK generation rules in EAP-FAST, we would have to swap Send and Recv in the above description for EAP-PEAPv0 due to the other order of Send/Recv MPPE keys used there. In other words, we cannot come up with a EAP-MSCHAPv2 MSK derivation rules that would cleanly fit into all deployed uses and there will unfortunately be need for tunnel method specific exception in either EAP-PEAP with cryptobinding or EAP-FAST. Either way, it would be useful to get this documented clearly so that all future uses of EAP-MSCHAPv2 would be able to refer to an existing specification instead of having to come up with their own MSK/ISK derivation rules as was done with EAP-PEAP cryptobinding and EAP-FAST. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] RFC5216 - L-Flag in the fragment packets (fwd)
> From: Murat Sezgin [msez...@ubicom.com] > In the “2.1.5 Fragmentation” section of the RFC5216, it is written that “The > L flag is set to indicate the presence of the four-octet TLS Message Length > field, and MUST be set for the first fragment of a fragmented TLS message or > set of messages”. Here, it is not clear that the other fragments must or must > not include this L-flag set. On the other hand, the RFC5281-- EAP-TTLS, > indicates that “Fragments other than the first MUST NOT have the L bit set”. > Is there a L-flag inconsistency between the EAP-TLS and EAP-TTLS fragments. > Do you think you need to explicitly put the same statement in the RFC5216? The situation with the L-Flag in EAP methods that use TLS (TLS, PEAP, TTLS, FAST) is actually even more confusing than this particular detail might suggest. For example, PEAPv0 seems to require that the TLS Message Length is included even in unfragmented frames in Phase 1 (however, it is not allowed to be included in Phase 2!) or at least a deployed and commonly used server requires such behavior to interoperate properly for certain cases. Taken into account that many implementations share code between EAP-TLS/PEAP/TTLS/FAST, it would be great if these methods were to use the same rules for fragmentation. Alas, I do not think that this would be feasible due to conflicting requirements in the specifications and/or deployed implementations.. Anyway, it would be great if all new RFCs touching this area have clear statements describing the exact and consistent (at least within the EAP method) use of the TLS Message Length field for all frames, so that we could hopefully avoid getting even more variance on how this needs to be processed in the future. > In the FreeRadius implementation, there is an option called “include_length” > in the tls module configuration section of eap.conf file, its default value > is set to “yes”, and with this configuration the server sends the L-flag in > each fragment, this is not consistent with the TTLS RFC. FreeRadius’s TTLS > implementation also uses this option in its TLS handshake phase. So far, I've never needed to include the TLS Message Length in any other frame than the first fragmented. However, I have had to implement workarounds to allow the non-fragmented frames to get special handling in some cases, i.e., to get the TLS Message Length added into them (both for all frames and also with the difference in Phase 1 vs. Phase 2 as described above). Obviously, this is not really a desired situation since it takes considerable amount of time to come up with all the needed workarounds to interoperate with existing implementations. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [Editorial Errata Reported] RFC5216 (2510)
On Fri, Sep 3, 2010 at 11:51 PM, RFC Errata System wrote: > http://www.rfc-editor.org/errata_search.php?rfc=5216&eid=2510 > Section: 3.1 Please note that similar language exists in other places of the document, too (2.1.5 and 3.2) and the same comments should apply to them. > Original Text > - > The L bit (length included) is set to indicate the presence of the > four-octet TLS Message Length field, and MUST be set for the first > fragment of a fragmented TLS message or set of messages. > > Corrected Text > -- > The L bit (length included) is set to indicate the presence of the > four-octet TLS Message Length field, and MUST be set for the first > fragment of a fragmented TLS message. The L bit MAY be included > in all fragments of a fragmented TLS message, but if included the > TLS Length MUST represent the entire length of the TLS message. This would still leave some potential uses of the L bit undefined. These two sentences cover only fragmented TLS messages. What about TLS messages that are not fragmented? It should also be noted that the proposed text would make RFC 5216 (EAP-TLS) inconsistent with RFC 5281 (EAP-TTLS) as far as fragmentation is concerned. I do not think that that would be a good idea since it is possible to share same implementation for handling fragmentation/reassembly of various TLS-based EAP methods (EAP-TLS, EAP-TTLS, EAP-PEAP, EAP-FAST). RFC 5281 disallows use of the L bit in the fragments other than the first one. In addition, it does actually cover the not fragmented message case, too: If there are multiple fragments, the first fragment MUST have the L bit set and include the length of the entire raw message prior to fragmentation. Fragments other than the first MUST NOT have the L bit set. Unfragmented messages MAY have the L bit set and include the length of the message (though this information is redundant). My preference would be for RFC 5216 to follow this design, but I don't think I would be willing to call this change "editorial".. Are there any known EAP-TLS implementations that actually use the L bit in fragments other than the first one? Would that interoperate with other EAP-TLS implementations? - Jouni ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Results of consensus call on tunnel method document
On Fri, May 13, 2011 at 6:29 PM, Alan DeKok wrote: > The reason for the name change is that there have been questions > raised about whether this document should be left as EAP-FASTv2, or > whether it should request allocation of a new EAP type. > > Since the document name (individual draft) currently reflects the EAP > type name, abstracting that would be useful. That way the document name > will not change no matter what the WG decides to do. > > Anyone with opinions either way is requested to discuss the pros and > cons of the issue. I would prefer to allocate a new EAP type for this method and do that as soon as possible to make it easier to run early interoperability testing without having to use vendors specific type or experimental type (of which there are only one) and to agree between various implementations what to use.. Allocating a new EAP type enables cleaner design options for implementations that only support the standard method and do not have support for the proprietary EAP-FAST method. In addition, it allows proprietary EAP-FAST extensions to be kept separate in case both methods are implemented. EAP-FAST requires various hacks in the EAP implementation, including modifying a phase 2 method (EAP-GTC) based on the phase 1 method. I do not really want to extend those hacks any further and just want to keep them conditional on the already allocated EAP-FAST type instead of having to figure out which EAP-FAST method version is being run in a method that is not really supposed to be in any way dependent on the tunnel method. As far as EAP method/version negotiation is concerned, I find it more likely that the EAP-NAK mechanism for selecting the EAP method has received much more testing than EAP-FAST version negotiation and as such, is more likely to interoperate with legacy implementations. - Jouni ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Looking for reviewers
On Tue, Sep 25, 2012 at 06:55:48PM +, Hao Zhou (hzhou) wrote: > Thanks for the review. Good catch on both. We will fix both of them. What is the new Label for TLS Keying Material Exporter? "teap session key seed"? If so, is there any reason to not follow the recommended prefix for new uses as defined in RFC 5705 (see the relevant text below)? Labels here have the same definition as in TLS, i.e., an ASCII string with no terminating NULL. Label values beginning with "EXPERIMENTAL" MAY be used for private use without registration. All other label values MUST be registered via Specification Required as described by RFC 5226 [RFC5226]. Note that exporter labels have the potential to collide with existing PRF labels. In order to prevent this, labels SHOULD begin with "EXPORTER". This is not a MUST because there are existing uses that have labels which do not begin with this prefix. I would have expected to see something like "EXPORTER: teap session key seed" used as the Label for EAP-TEAP. Should the IANA Considerations section have somewhat more formal language to request registration of the new exporter label? TEAP makes use of the TLS Keying Material Exporters defined in [RFC5705]. The Label used in the derivation as defined in Section 5.1 is "teap seesion key seed". Maybe something like this: TEAP registers the label "EXPORTER: teap session key seed" in the TLS Exporter Label Registry. This label is used in derivation as defined in Section 5.1. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] EAP-SIM/AKA and missing Session-Id derivation rules for fast reauth
It looks like EAP Session-Id derivation has not been defined for EAP-SIM, EAP-AKA, and EAP-AKA' when using the fast re-authentication exchange instead of full authentication. RFC 5247 defines Session-Id for these EAP methods, but that derivation is only applicable for the full authentication case. I filed an errata on RFC 4247 about a half a year ago, but have not received any kind of response to this so far: https://www.rfc-editor.org/errata_search.php?rfc=5247 Since it looks likely for the FILS authentication to get deployed in the near term and that needing Session-Id for ERP to work, it would be important to get this resolved with a clearly defined and agreed derivation rules to allow fast re-authentication cases to be used to derive ERP key hierarchy. Would someone on this list have sufficient interest to reviewing the filed errata and/or suggest ways on how to get this moving ahead? I'm copy-pasting that errata information below for easier access for reviewing/commenting: Status: Reported Type: Technical Reported By: Jouni Malinen Date Reported: 2017-05-07 Section Appendix A says: EAP-AKA EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the concatenation of the EAP Type Code (0x17) with the contents of the RAND field from the AT_RAND attribute, followed by the contents of the AUTN field in the AT_AUTN attribute: Session-Id = 0x17 || RAND || AUTN It should say: EAP-AKA EAP-AKA is defined in [RFC4187]. When using full authentication, the EAP-AKA Session-Id is the concatenation of the EAP Type Code (0x17) with the contents of the RAND field from the AT_RAND attribute, followed by the contents of the AUTN field in the AT_AUTN attribute: Session-Id = 0x17 || RAND || AUTN When using fast re-authentication, the EAP-AKA Session-Id is the concatenation of the EAP Type Code (0x17) with the contents of the NONCE_S field from the AT_NONCE_S attribute, followed by the contents of the MAC field from the AT_MAC attribute from EAP-Request/AKA-Reauthentication: Session-Id = 0x17 || NONCE_S || MAC Notes: RFC 5247 was supposed to define exported parameters for existing EAP methods in Appendix A. The way Session-Id was defined for EAP-AKA and EAP-SIM works only for the full authentication case, i.e., it cannot be used when the optional fast re-authentication case is used since the used parameters (RAND, AUTN, NONCE_MT) are not used in the fast re-authentication case. Based on RFC 4187 chapter 5.2 (and similar chapter in RFC 4186), NONCE_S corresponds to RAND and MAC in EAP-Request/AKA-Reauthentication corresponds to AUTN. That would seem to imply that the Session-Id could be defined using NONCE_S and MAC instead of RAND and AUTN/NONCE_MT. The corrected text in this errata shows the changes for EAP-AKA. Similar changes should be done for EAP-SIM (replace RAND || NONCE_MT with NONCE_S || MAC for fast re-authentication). It should be noted that EAP-AKA' (RFC 5448) specification did not follow the MUST requirement in RFC 5247, i.e., it did not define Session-Id derivation. That could be done in an update of RFC 5247 with a clone of EAP-AKA design. In addition, RFC 5247 did not define Session-Id definition for PEAP and there does not seem to exist any IETF RFC which such definition. That could also be included in RFC 5247 update and done similarly to EAP-TLS (Session-Id = EAP type || client.random || server.random). It would be good to have a clear IETF reference for these details since EAP Session-Id is needed for ERP (RFC 6696) and that is now seeing additional implementation and deployment interest as a component of FILS authentication (IEEE 802.11ai). Same definition of EAP Session-Id is needed to make FILS shared key authentication implementation interoperable. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New Version Notification for draft-ietf-emu-eap-tls13-00.txt
On Thu, May 31, 2018 at 2:45 PM, John Mattsson wrote: > Except editorials, the main change is that the Exporter labels has been > changes to conform with RFC 5705 and that the labels are now to be > registered by IANA as they should be. > > Review and comments are very welcome. Preferable so that they can be > included in a -01 version before Montreal. > Based on implementation experiment of this (or well, the previous draft, so with the old labels), the most inconvenient part of this design was the way the session resumption is handled in TLS v1.3. When that is mapped to EAP-TLS in the way it is in this draft, the peer has no idea whether the NewSessionTicket is delivered after ClientFinished. In other words, the next message in the sequence could be either continuation of EAP-TLS method or EAP-Success. This means that the peer cannot use methodState=DONE, decision=UNCOND_SUCC per RFC 4137 state machine whenever using TLS v1.3 (while being able to continue to use that combination with TLS v1.0, v1.1, and v1.2). Instead, for TLS v1.3, methodState=MAY_CONT, decision=COND_SUCC needs to be used. While this may not sound very critical, it was a bit inconvenient to have make that behavior conditional on the TLS version. Would there be any way of avoiding this uncertainty about the next message on the client side within the EAP-TLS method itself? If not, I might as well as bring up another comment regarding the extra round trip from this NewSessionTicket delivery. That does not look very efficient. If we would not care about layering between the EAP method and EAP peer/server implementation, NewSessionTicket could actually be piggybacked on top of the EAP-Success message.. Sure, that would require a change in the EAP-Success definition, but this would remove this undesired uncertainty about the next message in the sequence and would get rid of one extra roundtrip in the exchange which could be a significant reduction in overall latency for the handshake. Having to change the MSK/EMSK derivation just for the sake of getting a new label string into use based on the TLS version is also a bit inconvenient. This is obviously assuming that the previous implementation was already using TLS-Exporter interface. In general, it would have been nicer if existing EAP-TLS implementations would work simply by updating the TLS implementation from v1.2 to v1.3. Anyway, if any one of these change is going to be needed in the end, the EAP method implementation will need to be made aware of the negotiated TLS version and other changes are coming with somewhat reduced implementation complexity. - Jouni ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Session identifiers for fast re-authentication
On Mon, Jan 28, 2019 at 8:46 PM Alan DeKok wrote: > The EMU charter says: > > - Define session identifiers for fast re-authentication for > EAP-SIM, EAP-AKA, and EAP-AKA’. The lack of this definition > is a recently discovered bug in the original RFCs. > > I have recently uploaded a document which addresses this point. > > https://datatracker.ietf.org/doc/draft-dekok-emu-eap-session-id/ Thanks! As far as the [FILS] reference is concerned, it should be pointing to IEEE Std 802.11ai-2016. Which would be something like this in IETF RFC, I guess: IEEE, "IEEE Standard for Information technology--Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 1: Fast Initial Link Setup", IEEE Std 802.11ai-2016. And a small typo in Section 2.3.1: "[RFC5247] id not define" should be "[RFC5247] did not define" For Section 3, it might be clearer to talk about enabling FILS or ERP rather than fast re-authentication. EAP-SIM and EAP-AKA as currently defined do allow fast re-authentication (the one defined explicitly for those EAP methods to be used), i.e., the case that is being enabled here is establishment of the ERP key hierarchy (which is needed for FILS) when using EAP-SIM/EAP-AKA fast re-authentication. In other words, replace the last sentence with something like: It therefore enables ERP key hierarchy establishment using fast re-authentication with EAP-SIM and EAP-AKA. - Jouni ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] RFC 7170 (TEAP) errata
I've filed number of errata entries against RFC 7170. The email responses from rfc-editor seem to be cc'ed to this mailing list, but I don't receive them from the list or see them in the list archive. Anyway, if there are anyone here who would be interested in getting these reports reviewed and the issues addressed, that would be most helpful. Some of these items are significant technical issues that prevent me from implemented the protocol and would also make me question how any implementation of TEAP would actually be able to comply with the RFC I can figure out the most likely answers to some of the entries, but there is no straightforward way of resolving the issues related to (1) Crypto-Binding TLV format for the cases where the negotiated TLS cipher suite uses SHA256 (or SHA384, for that matter) instead of SHA-1 (and I'd hope all deployments of TEAP would be recent enough to avoid use of SHA-1..): https://www.rfc-editor.org/errata/eid5768 (2) S-IMCK[j] derivation when inner EAP methods in the sequence derive both MSK and EMSK (or even more complicated, if there are multiple inner EAP authentication methods that have difference in whether they derive MSK or EMSK): https://www.rfc-editor.org/errata/eid5770 I'd hope to avoid having to guess or make my own specification of how this is supposed to work before being able to implement this (and then have to re-implement everything if others disagree with that interpretation/guess on the design), so any feedback on these items would be very welcome so that there would be a general agreement on how the protocol is supposed to work to provide better chances for getting interoperable implementations. - Jouni ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05
On Wed, Jun 26, 2019 at 09:16:19PM -0700, Joseph Salowey wrote: > The Working Group last call has completed with no comments for > draft-ietf-emu-eap-tls13-05. I would like to confirm that some working > group members have reviewed the draft. If you have reviewed the draft > please respond to this thread. While the current design may work in theory, the use of an "empty TLS record" looks problematic from implementation and deployment view point. That terms itself is quite a bit confusing term since this is not really talking about an empty TLS record in the EAP-TLS message, but about a zero length TLSPlaintext structure that gets encrypted into a _non_-zero length TLSCiphertext structure that gets encoded in the TLS record that goes over EAP-TLS (and that is not empty since all ciphers add something to the payload length in practice). The main problem here is that at least OpenSSL is not willing to send such an empty TLSPlaintext structure. SSL_write() has following to say about this: https://www.openssl.org/docs/man1.1.1/man3/SSL_write.html "You should not call SSL_write() with num=0, it will return an error. SSL_write_ex() can be called with num=0, but will not send application data to the peer." In other words, there does not seem to be any convenient way of implementing this with the current version of one of the most commonly used TLS libraries. I can make this work by sending out a one-octet (0x00) TLSPlaintext as a workaround, but it does not look like I could make the implementation comply with the draft without changing the TLS library which is close to a complete showstopper for quick deployment. It would seem to make sense to me to allow the EAP-TLS 1.3 server to send out either an empty plaintext or a one octet plaintext to avoid this issue in a straightforward manner. This is referring to the following areas in the draft (-05): 2.1.1. In the case where EAP-TLS with mutual authentication is successful, the conversation will appear as shown in Figure 1. The EAP server commits to not send any more handshake messages by sending an empty TLS record, see Section 2.5. (that confusing use of "empty TLS record" and "TLS empty record" in the message exchange figures) 2.5. When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by appending an empty application data record (i.e. a TLS record with TLSPlaintext.type = application_data and TLSPlaintext.length = 0) to the last handshake record. After sending an empty application data record, the EAP server may only send an EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message. (this is where that TLSPlaintext.length = 0 should also allow 1 to make this easier to implement and deploy) -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05
On Sat, Jul 13, 2019 at 08:59:04AM +0200, Alan DeKok wrote: > On Jul 12, 2019, at 11:08 PM, Jouni Malinen wrote: > > It would seem to make sense to me to allow the EAP-TLS 1.3 server to > > send out either an empty plaintext or a one octet plaintext to avoid > > this issue in a straightforward manner. > > We may also want to later perform additional signalling at that phase of > the authentication. As such, it may be good to say: > > * a one octet plaintext of 0x00 should be sent > * on reception, any data received should be ignored > * non-zero octets, or more than one octet MAY indicate future extensions I'm not sure how I'd feel about EAP-TLS extension that uses actual application data when we have EAP-TEAP available for cases that need additional data to be exchanged in the tunnel. Anyway, this combination of server sending one octet (0x00) and peer decrypting the application data but ignoring its length and contents is what I ended up implementing now. This seems to work fine for the case where NewSessionTicket message(s) are used. I did see some issues when OpenSSL 1.1.1 when disabling sending of session tickets, though. The current draft indicates that the empty Application Data payload would be send out in the same EAP packet with the server's Finished message, i.e., before the server having authenticated the peer. And this would be done without the peer having used TLS early data (which is explicitly disallowed in the draft). That combination did not work with my experiments since OpenSSL was rejecting the SSL_write() operation after the server having written own Finished message, but before having received the Finished message from the peer. The OpenSSL documentation seemed to imply that SSL_write_early_data() could be used by the server _if_ the client first sent early data.. At least in my tests, OpenSSL rejected that call without early data from the client. I may have missed some other part of the OpenSSL API where the server could have sent out the Application Data message to the unauthenticated peer (if someone knows how to do that, please do let me know), but regardless, this design of the EAP-TLS v1.3 server depending on a mechanism that need actual application data (even if empty or known one octet value) to be sent before having completed authentication of the TLS client feels like something that can result in implementation complexities with various TLS libraries. Forcing a new session ticket to be sent out is a way to work around this, but I'm not sure I'd call this ideal. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] RFC 7170 (TEAP) errata
On Mon, Jul 22, 2019 at 01:50:26PM -0400, Joseph Salowey wrote: > On Mon, Jul 1, 2019 at 4:11 PM Jouni Malinen wrote: > > (1) Crypto-Binding TLV format for the cases where the negotiated TLS > > cipher suite uses SHA256 (or SHA384, for that matter) instead of SHA-1 (and > > I'd hope all deployments of TEAP would be recent enough to avoid use of > > SHA-1..): > > https://www.rfc-editor.org/errata/eid5768 > > [Joe] I'd like to hear if anyone has an implementation, and how they > implemented on a cipher suite that is not SHA-1. My feeling is that it > would be better to make the TLV length variable with the hash length. > However, I do not see why truncating would work as well. For now, I ended up implementing this with truncation to 20 octets since it was a bit simpler to do. I have an implementation with support for SHA-1, SHA-256, and SHA-384; and not allowing MD5 at all to avoid questions about shorter than 20 octets and use of obsolete algorithms. That said, I think it would be better to make the Compound MAC fields to be of variable length (i.e., be based on the output length of the negotiated MAC algorithm) so that the full MAC value can be exchanged. This would mean the Crypto-Binding TLV length would need to be marked variable. I'm ready to change my implementation to do this as soon as there is some clear indication on that being the direction TEAP should go to. This is a straightforward change in the implementation, but I don't want to be moving back and forth on this before seeing some signs of consensus on the TEAP specification side. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] RFC 7170 (TEAP) errata
On Mon, Jul 22, 2019 at 03:12:15PM -0400, Joseph Salowey wrote: > On Mon, Jul 1, 2019 at 4:11 PM Jouni Malinen wrote: > > (2) S-IMCK[j] derivation when inner EAP methods in the sequence derive > > both MSK and EMSK (or even more complicated, if there are multiple inner > > EAP authentication methods that have difference in whether they derive MSK > > or EMSK): > > https://www.rfc-editor.org/errata/eid5770 > [Joe] I'd like to hear from implementers on this one. My current implementation derives two copies of S-IMCK[i] values (one based on MSK and the other one based on EMSK from the inner EAP method). Both of these are initialized to session_key_seed. If the inner EAP method derives EMSK, EMSK Compound MAC gets included in crypto-binding. MSK is assumed to be derived for all cases where EMSK is derived. If neither MSK nor EMSK is derived, the "MSK" S-IMCK[j] is derived based on the all-zeros-IMSK and that is then used to calculate the MSK Compound MAC field. This implementation does not support a sequence of more than one inner EAP authentication method that derives keys, so the more complicated mixes do not show up. Or well, in theory, there is support for EAP-TNC, so that could show these cases (e.g., with EAP-MSCHAPv2 deriving MSK and that followed by EAP-TNC not deriving any keys), but I have not tested that combination yet. I'm currently deriving the TEAP MSK and EMSK based on the MSK-based S-IMCK[j], but that would be trivial to change to use EMSK-based S-IMCK[j] (if available) for TEAP EMSK derivation. However, this part would need to be done based on whether both ends actually claimed to derive EMSK from the inner EAP method(s) (and with even more complex rules if only a subset of the inner EAP methods derive EMSK while another subset does not and those subsets are different at each end). > I think the intent is that section 5.4 should say the S-IMCK is generated > as specified as described in section 5.2. > > Section 5.2 does provide a mechanism to derive the S-IMCK at the end of the > section. Each IMCK can be derived in one of 3 ways: > - MSK > - EMSK > - 0s if the method is not key generating Well, yes, but this is not very helpful now that TEAP added two Compound MAC values into crypto-binding. There is clearly an assumption that different IMSK[j] values (and from that, two different S-IMSK[j] values) are derived if the inner EAP method derives both an MSK and EMSK, but the sections describing derivations and use of these keys do not take into account that need for two independent values. > There is ambiguity on how to derive each IMSK in the case that both sides > do not have the same capability to export the EMSK. I think the steps > involving the compound MAC are meant to disambiguate this situation. They were probably meant to do that, but they did not really. > Is the problem that the section does not explicitly say how to use the > compound MAC sent to determine which IMCK derivation to use? No, the problem is in one of the design (crypto-binding construction/validation) assuming there are two values (MSK-based and EMSK-based) while the IMSK[j]/IMCK[j] derivation part assuming only one value (EMSK-based, if available, otherwise MSK-based) is derived. Furthermore, the TEAP MSK/EMSK derivation rules assumes there is only one S-IMCK[j]. This would have all worked fine if the crypto-binding design from EAP-FAST had not been extended to cover the EMSK case, but I'd guess that addition was done based on some review, but that did not end up getting fully baked into the TEAP design to make it work. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05
On Thu, Jul 25, 2019 at 10:49:40AM +, John Mattsson wrote: > Question: How will the use of Application data with TLSPlaintext.fragment = > 0x00 work with EAP-TTLS, PEAP, and TEAP when they start using TLS 1.3? I > assume they will need to send the same 0x00 to commit to not sending any more > handshake messages as well as using application data for other purposes. I do > not know exactly how the TLSPlaintext fragments look like in EAP-TTLS, PEAP, > and TEAP. The TLSPlaintext fragment for commit need to be chosen so that the > string does not collide with any other strings used. I don't see why TTLS, PEAP, or TEAP would need to use this specific 0x00 indication for this since they end up using the tunnel for Phase 2 (or at least protected result indication if Phase 2 authentication is skipped) and that can be implicitly used for the same purpose. EAP-TLS needs this workaround because without it, the NewSessionTicket message changes in TLS 1.3 are quite inconvenient for EAP. With TTLS and PEAP, it would seem fine to send out the NewSessionTicket before concluding Phase 2. With TEAP, there is some more discussion about use of the NewSessionTicket option for provisioning the new PAC (which seem a bit inconvenient for some use cases IMHO, but nevertheless, I don't see this needing any additional mechanism for indicating when the NewSessionTicket is not going to be showing up). -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Processing of TEWAP erratum 5127
On Fri, Nov 22, 2019 at 05:21:10PM +0800, Eliot Lear wrote: > I have been reviewing this erratum, and I think it is correct, but I have a > question: > > > Section 5.2. says: > > > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" | > > "\0" | 64) > > It should say: > > > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" | > > "\0", 64) > > Is that last parameter “seed” or “seed size”? Confusedly yours. It's neither.. The main problem here is in RFC 7170 not defining TLS-PRF() properly. All it says is "TLS-PRF is the PRF negotiated as part of TLS handshake" while RFC 5246 does not define PRF as a function with arguments that would be compatible with even a single instance of TLS-PRF() use in RFC 7170.. And the RFC 7170 uses are inconsistent with themselves like this erratum show, but this instance is not the only issue: TLS-PRF() is used with two, three, and even four arguments. This leaves the implementer guessing what exactly these maps to.. > > RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2 > > 5. HMAC and the Pseudorandom Function > > "TLS's PRF is created by applying P_hash to the secret as: > > PRF(secret, label, seed) = P_(secret, label + seed)" So this PRF(secret, label, seed) is what is available and RFC 5246 does not define that 64 part in the example above as an argument. That 64 is the number of octets of output that is fetched from the PRF. In other words, RFC 7170 should have defined TLS-PRF(secret, label, seed, output-len-in-octets) as taking output-len-in-octets of octets from the output of RFC 5246 PRF(secret, label, seed). With this, following fixes would be needed for the users for TLS-PRF() in RFC 7170: IMSK: This could be one of following (last two having identical outcome): TLS-PRF(EMSK, "teapbind...@ietf.org", "", 64) TLS-PRF(EMSK, "teapbind...@ietf.org", "\0", 64) TLS-PRF(EMSK, "teapbind...@ietf.org", "\0" | 0x00 | 0x40, 64) TLS-PRF(EMSK, "teapbind...@ietf.org", 0x00 | 0x00 | 0x40, 64) However, this TLS-PRF() instance is more strange.. The "Optional data parameter is not used in the derivation" part does not make any sense since I think "optional data parameter" is a reference to the seed value going into PRF. The following description is then clearly indicating that "\0" is 0x00 and length (that | 64) is "2-octet unsigned integer in network byte order". That seems to be talking about some binary data and the seed is the only place where such byte order and field size discussion would apply. I'm actually implementing that last one because of that discussion in the RFC. It should also be noted that the "First 32 octets of TLS-PRF(..., 64)" does not make much sense since "TLS-PRF(..., 32)" would cover same. This would seem to imply that "First 32 octets of TLS-PRF" could actually be trying to address that PRF argument mismatch. Anyway, maybe this should simply say: IMSK = TLS-PRF(EMSK, "teapbind...@ietf.org", 0x00 | 0x00 | 0x40, 32) (or with empty seed "" instead of that 3 octet seed) The "and the length is 64 octets" part just above this is a bit confusing with this, though. IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60) (this is actually unchanged) MSK = TLS-PRF(S-IMCK[j], "Session Key Generating Function", "", 64) (i.e., add the missing empty seed) EMSK = TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function", "", 64) (i.e., add the missing empty seed) -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt
On Tue, Mar 24, 2020 at 10:08:06AM -0400, Alan DeKok wrote: > On Mar 24, 2020, at 4:00 AM, Hannes Tschofenig > wrote: > >> For example, many EAP authenticator (access point) > >> implementations will drop an EAP session if it has not finished after > >> 40 - 50 round-trips. > > > > Is there a reference that could be included? > > References to hostap source code. hostapd has a limit in the EAP server role on the number of round trips (and wpa_supplicant in the EAP peer role). However, there is no such limit in the EAP authenticator role, i.e., hostapd as the access point forwarding EAP to an external RADIUS authentication server does not place such a constraint on the exchange. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] draft-dekok-emu-tls-eap-types discussion
On Wed, Apr 15, 2020 at 07:25:08PM +0300, Oleg Pekar wrote: > For TEAP errata 5770: > Technically TEAP RFC suggests the implicit method of taking the correct > IMSK[j] and all the subsequent keys after each inner method via negotiation > taking place in Crypto-Binding TLV exchange. What is "the correct IMSK[j]" and where is this defined? > Let's say we are on the inner method number j that supports both MSK and > EMSK and we are server which implementation generates both MSK and EMSK for > this inner method. We generated keys according to the rules below - two > sets, for IMSK[j] derived from inner method EMSK and for IMSK[j] equal to > inner method MSK. Because we don't know whether client implementation > supports both MSK and EMSK. > > S-IMCK[0] = session_key_seed > For j = 1 to n-1 do >IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", > IMSK[j], 60) >S-IMCK[j] = first 40 octets of IMCK[j] >CMK[j] = last 20 octets of IMCK[j] > > > So we have two CMK[j] and we create Crypto-Binding TLV with both Compound > MAC for MSK and EMSK. The client sends Crypto-Binding TLV in response and > we can understand from it whether it supports EMSK for this inner method or > not. And here we can decide which version of IMCK[j] to take for this inner > method - derived from EMSK or MSK. This is just not explicitly specified in > the RFC. Is this the proposed definition of "the correct IMSK[J]"? In other words, is this to be understood to have two (or three since we have the no MSK/EMSK case as well) variants of IMSK[j] during an execution of an internal AP authentication method and a single one of those variants is selected as _the correct_ IMSK[j] at the successful conclusion of this inner authentication method? Would this single "correct IMSK[j]" then be used for deriving the different variants of IMSK[j+1] instead of using EMSK-based-IMSK[j] when deriving EMSK-based-IMSK[j+1]? In other words, is this to work by having all following inner authentication rounds and MSK/EMSK derivation to behave as if the other variants of IMSK[j] never really existed? > Could this method work? Should we make it more clearly specified? Or should > we change the protocol to arrive explicitly to the understanding which type > (MSK/EMSK) of IMSK[j] to use? Regardless of what is done for the design, it will absolutely need to be specified more clearly. If I understood the proposed design correctly, this should be defined with something like following: For each successful inner EAP authentication method, derive IMCK-MSK[j] (if MSK was derived by the inner method), derive IMCK-EMSK[j] (if EMSK was derived by the inner method), derive IMSK-zero[j] (for all cases). Derive CMK-MSK[j] from IMCK-MSK[j] and CMK-EMSK[j] from IMCK-EMSK[j] (both: if available). Generate Crypto-Binding TLV with all available Compound MAC values. Also verify Crypto-Binding TLV with all available Compound MAC values. After both ends have transmitted and received Crypto-Binding TLV, set IMSK[j] to be IMCK-EMSK[j] if both ends included EMSK Compound MAC, or set IMSK[j] to be IMCK-MSK[j] if both ends included MSK Compound MAC but either end did not include EMSK Compound MAC, or . Set S-IMCK[j] based on this IMSK[j]. This results in there being only a single S-IMCK[j] and MSK/EMSK derivation being well defined. And focusing on that "what to do here.." part and the unused IMCK-zero[j] in the previous paragraph.. How is this supposed to work when an inner EAP authentication method does not derive either MSK or EMSK? Intermediate result indication of success needs to be done and that implies there needs to be Crypto-Binding TLV. But that TLV does not have option of indicating that neither EMSK Compound MAC nor MSK Compound MAC are present (Flags field has no value 0 defined to do so). So what are those fields (or one of them) supposed to be set to? And how is that selected for an inner EAP authentication method j? Does this depends on what happened with method j-1 (if one was present)? How would the correct IMCK[j] be determined by the peer and the server if one of them derived MSK/EMSK but the other one did not derive either for inner EAP method j? -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Proposed resolution for TEAP errata 5127
On Wed, Oct 21, 2020 at 09:30:33AM -0700, Joseph Salowey wrote: > Errata 5127: https://www.rfc-editor.org/errata/eid5127 > Proposed State: Verified > Revision: > Section 5.2. > OLD > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" | > "\0" | 64) > > NEW > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" | >'/0', 64) Why would this change "\0" to '/0'? How is that 64 supposed to be encoded if it is the "seed" argument to PRF(secret, label, seed) define in RFC 5246 Section 5? > Notes: > According to > > RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2 > > 5. HMAC and the Pseudorandom Function > > "TLS's PRF is created by applying P_hash to the secret as: > > PRF(secret, label, seed) = P_(secret, label + seed)" > > In this case the seed is the 2-byte length of the output as defined by RFC > 5295. In terms of P_ the derivation would look like: > > IMSK = P_(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40) Using P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40) looks correct, but it looks strange to me if we are trying to include the first 0x00 at the end of the "label" argument to PRF(secret, label, seed) especially when the label is define to be "an ASCII string. It should be included in the exact form it is given without a length byte or trailing null character". I would have expected "teapbind...@ietf.org" to be the "label" while 0x00 | 0x00 | 0x40 would be the "seed". In other words: IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org", 0x00 | 0x00 | 0x40). Please note that this is followed by this explanation: where "|" denotes concatenation, EMSK is the EMSK from the inner method, "teapbind...@ietf.org" consists the ASCII value for the label "teapbind...@ietf.org" (without quotes), "\0" = is a NULL octet (0x00 in hex), length is the 2-octet unsigned integer in network byte order, and TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246]. Using "64" as the seed would require the reader to interpret 64 to be the "length" and use the "2-octet unsigned integer in network byte order" from that to determine the exact encoding of the seed. And the first 0x00 as part of the label to TLS-PRF would be be confusing as well with this explanation that is clearly defining the label without including the explicitly noted "\0" after the label. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Proposed resolution for TEAP errata 5127
On Wed, Oct 21, 2020 at 02:14:45PM -0700, Joseph Salowey wrote: > On Wed, Oct 21, 2020 at 12:11 PM Jouni Malinen wrote: > > > On Wed, Oct 21, 2020 at 09:30:33AM -0700, Joseph Salowey wrote: > > > Errata 5127: https://www.rfc-editor.org/errata/eid5127 > > > Proposed State: Verified > > > Revision: > > > Section 5.2. > > > OLD > > > > > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" | > > > "\0" | 64) > > > > > > NEW > > > > > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" | > > >'/0', 64) > > > > Why would this change "\0" to '/0'? > > > > [Joe] that was my mistake should be "/0" > > > > How is that 64 supposed to be encoded if it is the "seed" argument to > > PRF(secret, label, seed) define in RFC 5246 Section 5? > > > > > [Joe] 7170 says "length is the 2-octet unsigned integer in network byte > order" It does, but how would one know that this particular 64 is "length"? This "64" argument is the "seed" argument to PRF and that could be any arbitrary data.. The length of TLS-PRF output is meta data that is not passed to the PSK() defined in RFC 5246 directly as an argument, i.e., inclusion of the output length in the seed is something that RFC 7170 is doing here for some reason and it could have included any other arbitrary seed value here for that matter.. IMHO, this is too vague and it would be better to spell out the exact contents of the seed value (0x00 | 0x40 im this particular case shown here or 0x00 | 0x00 | 0x40 if following the proposal below). > > Using P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40) looks > > correct, but it looks strange to me if we are trying to include the > > first 0x00 at the end of the "label" argument to PRF(secret, label, > > seed) especially when the label is define to be "an ASCII string. It > > should be included in the exact form it is given without a length byte > > or trailing null character". I would have expected > > "teapbind...@ietf.org" to be the "label" while 0x00 | 0x00 | 0x40 would > > be the "seed". In other words: > > > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org", > > 0x00 | 0x00 | 0x40). > > > > > [Joe] Yes I agree that is better how about this as the text change > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org", "\0" | 64) It looks quite strange to me to define a binary seed data as a concatenation of a string and an integer. I have the exact same question about the encoding of 64 here since this does not describe explicitly this instance of 64 to be the "length" which has the particular encoding described in RFC 7170. For me, using 0x00 | 0x00 | 0x40 and deleting that note about length encoding would be significantly clearer. If that is not acceptable, I would still replace "\0" with 0x00 in this context since this is not an ASCII string or label anymore, but binary data. And in addition to that, the "64" part would need to be replaced with something like "TLS-PRF output length" and then the "TLS-PRF output length" could be mentioned to be 64 in this instance and the encoding for that would be 2-octet unsigned integer in network byte order. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Proposed resolution for TEAP errata 5765
On Thu, Oct 22, 2020 at 05:44:33PM +0300, Oleg Pekar wrote: > The Authority-ID TLV is used by the client to identify the TEAP server it > is talking to. If the same client talks to more than one TEAP server - it > can keep PACs or cached data from all of them identified by > the Authority-ID. If we make it optional in TEAP start message but keep > mandatory in PAC-Info part of the PAC - TEAP servers can stop sending it > during TEAP start and then clients will need to fetch it from PAC, if there > is a PAC in the conversation. But if there's no PAC - then no way to > identify TEAP server. > > Maybe we should keep it mandatory? That would be in conflict with Section 4.3.1: "Outer TLVs MUST be marked as optional." Please note that this M flag does not define whether the attribute must be included in the message; it defines whether the recipient has to reject the message if it does not support the TLV. We can still require the Authority-ID TLV to be present in TEAP/Start while marking it optional for the receiver to understand it (M=0).. And Section 3.2 does indeed say that: The EAP server initiates the TEAP conversation with an EAP request containing a TEAP/Start packet. This packet includes a set Start (S) bit, the TEAP version as specified in Section 3.1, and an authority identity TLV. This is still valid with M=0 for that TLV.. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Proposed resolution for TEAP errata for 5128
There were so many messages in this thread that I'm not going try to address each point separately, but I think in general I do agree with the comments and it looks like all the identified implementation are doing the same thing here.. I don't see any strong need to encode the output length of the PRF into the input data especially since we are using hardcoded output lengths in these cases. That said, I'm not against keeping it there for the IMSK derivation since that particular case seemed to be explicitly defined as using a 2-octet field in network byte order (and all the known implementations doing exactly that). IMHO, the other cases should not be modified to try to be consistent with this. While I do understand the benefits of having an explicit fixed delimiter "\0" between the label and seed to enforce unique interpretation if two labels were to have same prefix, I don't see that as a critical issue in any of the instances used within TEAP due to no such common prefix case exist nor do we even use TLS-PRF with the same secret/key. Furthermore, RFC 5246 does not mandate or even discuss such delimiter. There is no need to convert an empty seed to 0x00 or anything else. TLS-PRF can be used with secret=something, label=ASCII string, seed=0-length data) without issues. If we want to define a new TEAP-PRF() function, I'd prefer it to be using consistent terminology with TLS-PRF in RFC 5246 (and well, to extend possible, also be as consistent as can be with the TLS-Exporter use in RFC 8446). This would also mean not trying to enforce some 0x00 delimiter or length in context data. At its simplest and only with TLS v1.2 in mind for clarity here, this could look something like TEAP-PRF(secret, label, seed, output length) = PRF(secret, label, seed) outputting "output length" octets label = ASCII string, no "\x0" termination seed = arbitrary binary data (including possibility of 0-length empty case) With this, we would have following: IMSK = First 32 octets of TEAP-PRF(EMSK, "teapbind...@ietf.org", 0x00 | 0x00 | 0x40, 64) IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60) MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function", , 64) EMSK = TEAP-PRF(S-IMCK[j], "Extended Session Key Generating Function", , 64) RFC 5295 rules about EMSK use for USRK/DSRK applies for the first one of these and it does seem to give justification for the seed to have "\0" and "length" (as 2-octet unsigned integer in network byte order). While one could claim that the rules for DSUSRK derivation applies to those other instances and as such, would require 0x00 and length to be added around the seed shown above, I'd note that there does not seem to be any MUST statement about that in RFC 5295 and as such, I think the versions described above (and the ones used in known implementations today) seem to be justifiable especially taken into account the unique label string prefixes and fixed length of output data. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] More TEAP issues
On Wed, Nov 30, 2022 at 03:01:08PM +, Alexander Clouter wrote: > On Tue, 29 Nov 2022, at 22:34, Alan DeKok wrote: > > Based on interoperability testing, it looks like implementations > > followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170: > EAP-FAST almost does not document this until you look at a latter RFC > covering the provisioning component: > > https://www.rfc-editor.org/rfc/rfc5422#section-3.2.3 And that section has a history of its own.. If you take a look at the latest draft (-10), that language is not there, i.e., it got added quite late in the process and the related discussions were not exactly considering this positively. If I remember correctly, this mismatch with how EAP-MSCHAPv2 was defined was seen as something that should not really have been done and the EAP-FAST-MSCHAPv2 was named such to be distinguished from EAP-MSCHAPv2 and also as a reminder not to use this variant for anything else than EAP-FAST (which had already been deployed with it). Nevertheless, here we are 15 years later hitting this exact same thing with TEAP having been deployed with the design that was not supposed to be repeated.. > Really easy to miss for an implementer, especially as when you start > implementing FAST (or TEAP) you begin with authentication and think you can > ignore the PAC component at first. While I started working on TEAP implementation by copying FAST implementation to be the starting point, one of my first steps was to try to remove all the hacks needed to get EAP-FAST interoperable since I was familiar with the history.. But yes, it would be next to impossible to implement either EAP-FAST or EAP-TEAP based on just the RFCs and get to something that interoperates with anything already deployed. > The other biggy is that it is easy to miss that for each EAP method in a > sequence, you need to include an EAP Identity response along with the > Identity-Type TLV to the peer. And that will hopefully not include another instance of Crypto-Binding for the EAP-Identity exchange. This is related to one of my errata comments on EAP method vs. EAP authentication method (the latter needs crypto binding; the former probably does not, but RFC 7170 is not clear). > > 3) declare 7170 irretrievably broken, and write 7170bis which > > documents how TEAP version 1 operates in practice. > > This is my preference too. While this might not result in the cleanest protocol design, I'd agree that this is likely the best approach from the view point of getting something useful out there and into wider use. Regarding a separate comment about new TLVs (and new functionality in general, I'd guess), I have no significant issues including that in a new RFC, but I do hope that the initial focus would be in addressing the existing areas and already identified issues to get to a point where there is a clearly identifiable Internet-Draft describing how one can successfully implement EAP-TEAP in a manner that interoperates with deployed implementations. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
