Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-04.txt

[Mohit Sethi M]

Hi all,

I am not a crypto expert and my knowledge of public key encodings is 
based on my work with Rene Struik for a different draft.

The current text in draft-ietf-emu-aka-pfs-04 says "For P-256, the 
length of this value is 32 bytes, encoded in binary". Shouldn't this be 
33 bytes? And wouldn't it make sense to explicitly say that this is an 
octet string in the compressed format while referencing "SEC 1: Elliptic 
Curve Cryptography, Version 2.0" for the point to octet string 
conversion rules?

--Mohit

On 5/26/20 9:57 AM, internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the EAP Method Update WG of the IETF.
>
>  Title   : Perfect-Forward Secrecy for the Extensible 
> Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' 
> PFS)
>  Authors : Jari Arkko
>Karl Norrman
>Vesa Torvinen
>   Filename: draft-ietf-emu-aka-pfs-04.txt
>   Pages   : 26
>   Date: 2020-05-25
>
> Abstract:
> Many different attacks have been reported as part of revelations
> associated with pervasive surveillance.  Some of the reported attacks
> involved compromising smart cards, such as attacking SIM card
> manufacturers and operators in an effort to compromise shared secrets
> stored on these cards.  Since the publication of those reports,
> manufacturing and provisioning processes have gained much scrutiny
> and have improved.  However, the danger of resourceful attackers for
> these systems is still a concern.
>
> This specification is an optional extension to the EAP-AKA'
> authentication method which was defined in [I-D.ietf-emu-rfc5448bis].
> The extension, when negotiated, provides Perfect Forward Secrecy for
> the session key generated as a part of the authentication run in EAP-
> AKA'.  This prevents an attacker who has gained access to the long-
> term pre-shared secret in a SIM card from being able to decrypt any
> past communications.  In addition, if the attacker stays merely a
> passive eavesdropper, the extension prevents attacks against future
> sessions.  This forces attackers to use active attacks instead.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-emu-aka-pfs-04
> https://datatracker.ietf.org/doc/html/draft-ietf-emu-aka-pfs-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-aka-pfs-04
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-dekok-emu-tls-eap-types discussion

[Joseph Salowey]

On Mon, Jun 22, 2020 at 9:06 PM Jorge Vergara 
wrote:

> >[Joe] (catching up) With respect to the case that the method is an MSK
> generating mechanism and and MSK is not generated/used.  I think the
> original intention was that this case would be a protocol violation, ie if
> a method generates an MSK it should be available for crypto-binding.   I'm
> concerned that allowing the fallback to 0 MSK actually will cause a
> security vulnerability in compound binding.  Do we know if this method
> mismatch is a problem in practice?
>
>
>
> [jovergar] I agree that if a method generates an MSK it should generally
> be used for crypto-binding. But this does not eliminate the need for a
> mechanism for each party (client/server) to communicate what kind of
> crypto-binding they are sending. The client/server is free to reject the
> crypto-binding if the peer is unable to produce a crypto-binding that
> satisfies the minimum policy of the implementation.
>
>
>
For example, if EAP-TLS is used as an inner method, and a client sends a
> zero-MSK, I would fully expect the server to reject the connection – not
> fallback to zero-MSK. I would expect a client to have similar minimum
> security policies it would accept for each method.
>
>
>
[Joe] I agree that there will be some policy needed on the client and
server, but I think the policy for this specific case (method supports MSK
but it is not used)  could be built into the protocol and simplify things.


> As to whether method mismatch is a problem in practice – yes, to an
> extent. Windows does not generate EMSK for EAP-TLS despite it being
> specified in the RFC, so the crypto-binding sent to the server is MSK
> based. If a server’s policy requires EMSK, then Windows can’t connect. This
> is certainly a Windows feature gap – but servers are free to decline the
> connection if they do not want to downgrade to an MSK based crypto binding.
>

[Joe] Yes, and I'm sure this is not the only case where EMSK is defined for
a method but not implemented.  While it would be better if everyone
implemented and used the EMSK, the MSK is better than using 0.   I agree
clients and servers will need some policy in this case.  The policy does
complicate the protocol and implementation.


>
> *From:* Joseph Salowey 
> *Sent:* Monday, June 22, 2020 8:53 PM
> *To:* Oleg Pekar 
> *Cc:* Jorge Vergara ; Jouni Malinen ;
> EMU WG 
> *Subject:* Re: [Emu] draft-dekok-emu-tls-eap-types discussion
>
>
>
>
>
>
>
> On Tue, Apr 21, 2020 at 11:02 AM Oleg Pekar 
> wrote:
>
> >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).
> I agree the 0 value should be explicitly listed for this purpose. Given
> the design of the flags I think it is clear this was the intended usage and
> its omission was likely an oversight.
> >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?
> Assuming we use the value 0 to indicate the state where one of the peers
> did not derive either MSK or EMSK, then I believe the RFC addresses this as
> MSKi = 32 octets of 0x00s. So if one side calculated neither MSK nor EMSK,
> and both sides decided to continue the conversion, then both sides would
> use the zero-MSK for that IMSK[j],
>
> Jorge, Jouni, agree with the approach.
>
>
>
> Jorge, please note that the same problem exists in PEAP Crypto-Binding TLV
> as specified in its documentation
> 
> - when one side has an inner method that provided MSK and another side has
> this inner method that didn't provide MSK.
>
>
>
> [Joe] (catching up) With respect to the case that the method is an MSK
> generating mechanism and and MSK is not generated/used.  I think the
> original intention was that this case would be a protocol violation, ie if
> a method generates an MSK it should be available for crypto-binding.   I'm
> concerned that allowing the fallback to 0 MSK actually will cause a
> security vulnerability in