[Emu] Francesca Palombini's No Objection on draft-ietf-emu-aka-pfs-11: (with COMMENT)

[Francesca Palombini via Datatracker]

Francesca Palombini has entered the following ballot position for
draft-ietf-emu-aka-pfs-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/



--
COMMENT:
--

Thank you for the work on this document.

Many thanks to Sean Turner for his ART ART review:
https://mailarchive.ietf.org/arch/msg/art/Aua-Uh5CRr9oDEIanfD6qw8WqVM/.

I only have two very minor comments.

Section 6.1: AT_PUB_ECDHE. The way Length is defined in RFC4187 (specifying the
length of the attribute in multiple of 4 bytes), and given the length of the
ECDHE public key in the attribute value (currently 32 or 33 bytes), you
probably should mention something about padding. I expect something analogous
to what RFC4187 defines for AT_IDENTITY "Because the length of the attribute
must be a multiple of 4 bytes, the sender pads the identity with zero bytes
when necessary."

Section 8: IANA Considerations. The section doesn't spell out the fields of the
"EAP-AKA' AT_KDF_FS Key Derivation Function Values" registry (Value,
Description, Reference), although those are pretty obvious from the table
itself. What I think is really missing is the expert guidelines - as RFC8126
specifies, the policy "Specification required" still requires review and
approval by a designated expert. "As with Expert Review, clear guidance to the
designated expert should be provided when defining the registry". What criteria
is the expert supposed to base their decision on when deciding if a new value
should be registered?



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Francesca Palombini's Discuss on draft-ietf-emu-eap-noob-04: (with DISCUSS and COMMENT)

[Francesca Palombini]

Hi Mohit! 

Thanks for your answer and for addressing my DISCUSS, I will go ahead and 
remove the block now. All the rest of the comments also look good, however I am 
not convinced by 7: see my answer below. However this is minor and 
non-blocking, so I will let you and Roman decide if and how to implement a 
change.

Thanks,
Francesca

>
>Hi Francesca,
>
>We have submitted a new version ( 
>https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05 ) which 
>hopefully addresses your comments. Here is the diff for your 
>convenience: 
>https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-05.txt
>
>See our answers below.
>
>--Mohit
>
>On 4/20/21 1:37 AM, Francesca Palombini via Datatracker wrote:
>> Francesca Palombini has entered the following ballot position for
>> draft-ietf-emu-eap-noob-04: Discuss
>>

...

>> 7. -
>>
>> and truncated to the 16 leftmost bytes of the output.  The message
>>
>> FP: please mention that network byte order is used (either here or in the
>> terminology).
>The byte order is relevant when encoding/decoding things like integers 
>etc. While cryptographic hash functions may use integers or 32- or 
>64-bit words internally, their output is a byte string, and the order of 
>the bytes in that output is defined by each individual hash function 
>specification (e.g. RFC 6234). We don’t think we should say anything 
>that could lead to a programmer mistakenly reordering the bytes in the 
>hash output.

FP: But the fact that you talk about "leftmost" bytes means that you are 
already implying ordering. Talking about leftmost without talking about 
ordering seems imprecise. Maybe you want to talk about the 16 most significant 
bytes instead.


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Francesca Palombini's Discuss on draft-ietf-emu-eap-noob-04: (with DISCUSS and COMMENT)

[Francesca Palombini via Datatracker]

Francesca Palombini has entered the following ballot position for
draft-ietf-emu-eap-noob-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/



--
DISCUSS:
--

Thank you for the work on this document. I have a couple of blocking comments
related to the IANA section, which should be easy to fix, plus some minor non
blocking comments below.

Francesca

1. -

Section 5.

FP: IANA is requested to create a sub registry to the EAP registry, but there
is no actual "Nimble out-of-band authentication for EAP Parameters" registry
defined, nor values registered in it. Either this is a new page or (I would
suggest) the subregistries are just created directly under the EAP page.

2. -

Section 5.1 and following

FP: This document defines several new registry with policy Specification
required, which will need designated experts.
https://tools.ietf.org/html/rfc8126#section-5.3 states that:

   When a designated expert is used, the documentation should give clear
   guidance to the designated expert, laying out criteria for performing
   an evaluation and reasons for rejecting a request.  In the case where

I believe designated expert guidance should be added to this document.


--
COMMENT:
--

3. -

   document are to be interpreted as described in [RFC2119].

FP: Please update as indicated by RFC 8174.

4. -

   it supports, an indicator of the OOB channel directions it supports
   (Dirs), and a ServerInfo object.  The peer chooses one of the

FP: Please add a reference to where the ServerInfo object is defined, as this
is its first occurrence.

5. -

  |  (Type=3,PeerId,PKs,Ns,[SleepTime])  |

FP: SleepTime appear in the figure without having been introduced in the
previous paragraph, as the other parameters. I would suggest adding a sentence
about it, including a fw reference to where it is explained in detail (3.2.5).

6. -

   use this serve-assigned NAI.  When the peer moves to the Registered

FP: nit - s/serve/server

7. -

   and truncated to the 16 leftmost bytes of the output.  The message

FP: please mention that network byte order is used (either here or in the
terminology).

8. -

   reasons.  New EAP output values MSK and EMSK may be needed because of

FP: MSK and EMSK appear here for the first time, please expand.

9. -

  Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos
  uitep,Dirp,[NewNAI],PeerInfo,0,PKs,Ns,PKp,Np,Noob).

  ...

  MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C
  ryptosuitep,Dirp,[NewNAI],PeerInfo,0,PKs,Ns,PKp,Np,Noob).

FP: I would suggest to add a sentence explicitly stating that H and HMAC are
the hash function and HMAC specified in this paragraph:

   The fingerprint Hoob and the identifier NoobId are computed with the
   cryptographic hash function specified in the negotiated cryptosuite
   and truncated to the 16 leftmost bytes of the output.  The message
   authentication codes (MACs, MACp, MACs2, MACp2) are computed with the
   HMAC function [RFC2104] based on the same cryptographic hash function
   and truncated to the 32 leftmost bytes of the output.

10. -

   |  | integer. The registration of cryptosuites is   |
   |  | specified in Section 5.1. Example values are   |
   |  | "[1]" and "1", respectively.   |

FP: not only registration, but also MTI and examples.

11. -

   for EAP Parameters" registry.  Cryptosuites are identified by an
   integer.  EAP-NOOB request and response pairs are identified by an

FP: "Cryptosuite ... integer." I don't understand the point of having this
sentence in this section, is this copy paste? (sections 5.2, 5.3)

12. -

  | 1007   | Invalid ECDHE key  |

FP: Out of curiosity, any special reason why this is not 1005?

13. -

Appendix E.

FP: are the examples generated with any of the implementations mentioned? It
would be good to state that in the first paragraph of the appendix. Also I am
curious if the JSON examples were validated.



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu