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

From: Mohit Sethi M <[email-masked]>
Date: Wed, 24 Jun 2020 05:10:23 +0000

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, [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Russ Housley <[email-masked]>
Date: Wed, 24 Jun 2020 16:04:39 -0400

The ECDH public value in RFC 5480 is an OCTET STRING, which means that the value is exactly 32 bytes.  When this gets carried as a subject public key in a certificate, there is an extra byte only because the type is a BIT STRING.

My conclusion is that the current draft is correct:

      *  For P-256, the length of this value is 32 bytes, encoded in
         binary as specified in [FIPS186-4].

Russ

> On Jun 24, 2020, at 1:10 AM, Mohit Sethi M <mohit.m.sethi=[email-masked]> wrote:
> 
> Hi all,
>