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

[Russ Housley <[e-mail]>]

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=[e-mail]> wrote:
> 
> 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, [e-mail] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/emu
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu