Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with DISCUSS and COMMENT)

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Benjamin

Whao, that was quick. Many thanks again!

I got a comment on the change to BCP201 and looked it up. Seems there was a confusion, BCP 201 is RFC 7696 not RFC 7748. So I rolled back the overload. Did you expect something else?

I'm publishing 17 for the delta below, we still have the 3 open points. Please check the diffs at 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-17.txt

More below:

> > Why do we need to allow ambiguity/flexibility as to the point
> representation
> > > within a given Crypto-Type value (as opposed to fixing the representation
> as a
> > > parameter of the Crypto-Type)?  Alternately, what does
> "(un)compressed"
> > > mean, as it's not really clarified directly?  Furthermore, Table 2 lists an
> > > "(un)compressed" representation for type 0 (over P-256), but RFC 7518
> notes
> > > that the compressed representation is not supported for P-256 (Section
> > > 6.2.1.1).  I also am not finding the needed codepoints registered in the
> JOSE
> > > registries to use ECDSA25519 (crypto-type 2) -- do we need to register
> > > anything there?
> >
> > Let us take this one separately in a thread with the co authors

I keep this item in the thread, to track that it's progressing separately


> > Clarifying questions:
> > - This spec is authoritative for listing the elliptic curves and the hash
> functions that it supports, correct?
> > - The registry is authoritative for the setting of values, which may change if
> this draft is obsoleted, is that your point?
> 
> I think we have different interpretations.
> I was assuming (based more on general practices than the specific text in
> this document, to be clear) that the idea is that new Crypto-Types could be
> specified and added to the registry, and implementations incorporate them,
> without needing to revise or update this specification: the registered
> Crypto-Type would contain all the information needed to integrate with the
> mechanisms specified here.  In that mindset, any list of algorithms in this
> document becomes out of date once the first additional Crypto-Type is
> registered, and the question of what algorithms the specification supports
> is more open-ended than just the literal words on the page.

Makes sense to me

 
> > From there I'm unsure what to do. The goal is to keep the focus on the bill
> of material of what needs to be implemented.
> > If that helps I can add (values to be confirmed by IANA) as follows?
> >
> > "   The elliptic curves and the hash functions that can be used with this
> >    specification are listed in Table 2 in Section 8.3.  The signature
> >    scheme that specifies which combination is used is signaled by a
> >    Crypto-Type (values to be confirmed by IANA) in a new IPv6 ND Crypto-
> >    ID Parameters Option (CIPO, see Section 4.3) that contains the
> >    parameters that are necessary for the proof, a Nonce option
> >    ([RFC3971]) and a NDP Signature option (Section 4.4).
> > "
> 
> To make a more concrete question: suppose I wanted to use SHAKE256/256
> as a
> hash function paired with ECDSA on curve25519.  What would need to
> happen
> to enable that?  The text above implies that, since SHAKE256/256 is not
> listed in the table, it's not allowed for use with this specification, and
> thus that I'd need to Update this specification in order to allow its use.

The registry has "Specification Required" or "IESG Approval". The "IESG Approval" path is for the case where the IES approves using the new hash with the draft as is. 
So yes, the spirit is that if the IESG determines that your case can happen without a change in the spec, the registry could be extended and the spec applied.
In that context, how does the following work:

"
   The elliptic curves and the hash functions listed in Table 2 in
   Section 8.3 can be used with this specification; more may be added in
   the future to the IANA registry.  The signature scheme that specifies
   which combination is used (including the curve and the representation
   conventions) is signaled by a Crypto-Type in a new IPv6 ND Crypto-ID
   Parameters Option (CIPO, see Section 4.3) that contains the
   parameters that are necessary for the proof, a Nonce option
   ([RFC3971]) and a NDP Signature option (Section 4.4).  The NA(EARO)
   is modified to enable a challenge and transport a Nonce option.
"

Note that this incorporate text to cover the discussion between Rene and Jim that different representation conventions imply different crypto-ids and cannot reuse the same keypair


> > >
> > > Section 4.1
> > >
> > >    The Crypto-ID is derived from the public key and a modifier as
> > >    follows:
> > >
> > >    1.  The hash function indicated by the Crypto-Type is applied to the
> > >        CIPO.  Note that all the reserved and padding bits MUST be set to
> > >        zero.
> > >    2.  The leftmost bits of the resulting hash, up to the size of the
> > >        ROVR field, are used as the Crypto-ID.
> > >
> > > This construction seems to allow for some malleability, in that an
> attacker who
> > > observes a given Crypto-ID and CIPO could produce a related, valid,
> Crypto-ID
> > > by reducing the ROVR length and truncating what was received.  I haven't
> > > attempted to explore what (if any) potential consequences there are of
> such
> > > malleability, and would like to know if anyone else has already done so.
> It
> > > looks like the NDPSO construction includes the length of the Crypto-ID,
> so it
> > > would be hard for an attacker to do much with such a truncated Crypto-
> ID, but
> > > attacks only get better...
> >
> > The point is that the Crypto-ID remains in the 6LBR is its original form, size
> and value. A shorted Crypto-ID is a different Crypto-ID even if bits match.
> Truncated per se does not help vs. any other change.
> > Also, the attacker would have to be on path of the initial registration. If
> that is so, and it wants to update the ROVR, it can do that a lot more.
> > Now, the crypto-ID dictates the size of the ROVR not the other way
> around, so I fixed:
> > "
> > The leftmost bits of the resulting hash, up to the desired size, are used as
> the Crypto-ID.
> > "
> > Anything else I should consider doing?
> 
> The only other thing I would *consider* doing (which is not to say that
> it's clear it should be done) is to include the desired size as input to
> the hash.  But I don't have any specific reason to do that or attack that
> would be stymied by doing so.
> 

With RFC 8505 the 6LN decides the parameters of the registration without an indication from the router. So at the moment I cannot figure how to do that apart from config. We  are missing a mechanism to signal the expected format of the ROVR and other parameters such as recommended lifetimes for types of addresses, etc..., in the RA messages. That's also in the long term plan and I'm considering whether to do that at 6lo or 6MAN. 6MAN would be better but it is slow/reluctant to adopt RFC 8505 for general purpose.

> > >    The implementation of multiple hash functions in a constrained
> > >    devices may consume excessive amounts of program memory.
> > >
> > > But multiple signature algorithm implementations will not?
> >
> > draft-ietf-lwig-curve-representations discussed in the next section enables
> to factorize code, if I understand well.
> > But to your point, what about the following clarification:
> >
> > "
> >    The implementation of multiple hash functions in a constrained
> >    devices may consume excessive amounts of program memory.  This
> >    specification enables the use of SHA-256 [RFC6234] for all the
> >    supported ECC curves.
> 
> Hmm, but Table 2 lists SHA-512 (not SHA-256) for crypto-type 1 (though I
> guess type 2 is SHA-256 on the same curve).
 
Yes, I understand that type 2 is less classical but enables the reuse of the SHA 256 hash.
I defer to Rene on this.

> > Per your comment we recommend 128 bits minimum. Keeping it at 64 bits
> was not the intention.
> > Not sure why you meant by sibling; the text would become
> >
> > "
> >    As opposed to the RSA Signature Option (RSAO) defined in section 5.2.
> >    of SEND [RFC3971], the NDPSO does not have a key hash field.
> >    Instead, the leftmost 128 bits of the ROVR field in the EARO are used
> >    to retrieve the CIPO that contains the key material used for signature
> >    verification, left-padded if needed.
> >
> > "
> 
> I think "sibling" was intended to be the case when the EARO and the CIPO
> appear in the same NS as "sibling options" within the NS.  (Though as you
> note the CIPO could have been previously received in a different message.)
> This text is probably okay, though I guess the reader has to know that
> there's an EARO associated with the NDPSO.
> 

You right, does not hurt to be more specific. In section 4.4:

"
   An ND message that carries an NDPSO MUST have one and only one EARO.
   The EARO MUST contain a Crypto-ID in the ROVR field, and the Crypto-
   ID MUST be associated with the keypair used for the Digital Signature
   in the NDPSO.

"


> > >
> > >    The 6LR on receiving the NDPSO and CIPO options first regenerates the
> > >    Crypto-ID based on the CIPO option to make sure that the leftmost
> > >    bits up to the size of the ROVR match.  If and only if the check is
> > >
> > > In the vein of my previous questions about where the Crypto-ID appears
> and
> > > truncation/malleability, this text seems to leave some room for
> confusion
> > > about how many bits of output are being compared, and compared to
> what.
> >
> > I'm unsure what you mean here. Based on my response above, can you
> please reopen is needed, with some clarification?
> 
> I was trying to get at how the NDPSO includes the Crypto-ID length in the
> signed data, but the 6LR has to determine what length to use from the
> length of the ROVR in the NS.  This is in general not terribly interesting
> since an on-path attacker could change "anything" that would be input to the
> signature validation, but seemed a little more interesting to me because of
> the way that an attacker could truncate the Crypto-ID, and the truncation
> would not be directly detectable in the EARO/ROVR but would only be
> detected during signature validation.  That is, the 6LR would replicate the
> Crypto-ID calculation from the CIPO, and the Crypto-ID would *appear* to
> match up, but the signature in the NDPSO would fail to validate.  I have in
> general a preference to make the reason for failure apparent closer to the
> error, if possible, but in this specific case the system as a whole seems
> to work okay even though the error is detected "one step later" than it
> could be.  (Adding the target output length into the hash input for
> Crypto-ID calculation as I mentioned above as an option would make this
> error detected at the first possible point, when validating the Crypto-ID
> calculation.)

This could be achieved by placing the length of the ROVR in the CIPO. Making this change.
We already had the ROVR size in the signature. Note that in the signature the format of that size is not given. Would need 2 bytes if expressed in bytes.
I'd reword to use the option length of the EARO, which is expressed in units of 8 bytes and is stored in one octet. 
Works?

This leads to sparse changes, but mostly:




"


The signature generated by the 6LN to provide proof-of-ownership of
   the private-key is carried in the NDP Signature Option (NDPSO).  It
   is generated by the 6LN in a fashion that depends on the Crypto-Type
   (see Table 2 in Section 8.3) chosen by the 6LN as follows:

   *  Concatenate the following in the order listed:

   1.  The 128-bit Message Type tag [RFC3972] (in network byte order).
       For this specification the tag is 0x8701 55c8 0cca dd32 6ab7 e415
       f148 84d0.  (The tag value has been generated by the editor of
       this specification on random.org).

<snip>

  6.  1-byte Option Length of the EARO containing the Crypto-ID.
  7.  1-byte Crypto-Type value sent in the CIPO.

<snap>

   The 6LR on receiving the NDPSO and CIPO options first checks that the
   EARO Length in the CIPO matches the length of the EARO.  If so it
   regenerates the Crypto-ID based on the CIPO to make sure that the
   leftmost bits up to the size of the ROVR match.

   If and only if the check is successful, it tries to verify the
   signature in the NDPSO option using the following:

   *  Concatenate the following in the order listed:

   1.  128-bit type tag (in network byte order)

<snoop>

  6.  1-byte EARO Length received in the CIPO.
  7.  1-byte Crypto-Type value received in the CIPO.

"



> 
> Perhaps it goes without saying (as part of DAD), but the 6LBR has to
> consult its database of ROVR/IP address to determine what response to give
> in the DAC.  Part of my question above was about what state the 6LBR needs
> and what verification the 6LBR does as part of the process -- am I correct
> that it's just checking whether (1) the requested address is already
> registered and (if so) (2) that the ROVR in the EARO matches the one
> registered with the requested address?

Yes, per RFC 8505, inherited from RFC 6775. I'd say that DAD expressed as you did is the core function of RFC 6775.
This draft does not really change the 6LBR, just adds the capability to stimulate a revalidation by the 6LR.


> >
> > All together we get:
> > "
> >    Replay Attacks  Using Nonces (NonceLR and NonceLN) generated by both
> >       the 6LR and 6LN ensure a contributory behavior that provides an
> >       efficient protection against replay attacks of the challenge/
> >       response flow.  A nonce should never repeat for a same key.  The
> >       protection depends on the quality of the Nonce computation, e.g.,
> >       of a random number generator when used to compute the Nonce.
> > "
> 
> I'd consider "A nonce should never repeat for a single key, but nonces do
> not need to be unpredictable for secure operation".
> 
Which leads to:
"

   Replay Attacks  A nonce should never repeat for a single key, but
      nonces do not need to be unpredictable for secure operation.
      Using nonces (NonceLR and NonceLN) generated by both the 6LR and
      6LN ensure a contributory behavior that provides an efficient
      protection against replay attacks of the challenge/response flow.
      The quality of the protection by a random nonce depends on the
      random number generator and its parameters (e.g., sense of time).
"


> >
> > Twisted the text to
> > "
> >    With this specification the 6LN can freely form its IPv6 address(es)
> >    in any fashion, thereby enabling either 6LoWPAN compression for IPv6
> >    addresses that are derived from Layer-2 addresses, or temporary
> >    addresses, e.g., formed pseudo-randomly and released in relatively
> >    short cycles for privacy reasons [RFC8064][RFC8065], that cannot be
> >    compressed.
> >
> > "
> 
> This text is good.  I would suggest changing the Section-1 text, though, as
> the current "requires a device [...] to enable a better compression" reads
> as if the requirement is always present, and that the reason for the
> requirement is to get the compression; instead, the situation is (IIUC)
> that in order to get that compression, the node is required to choose its
> address based on the L2 address.
> 
Which  gives

"
   With the 6lo adaptation layer in [RFC4944] and [RFC6282], a 6LN can
   obtain a better compression for an IPv6 address with an Interface ID
   (IID) that is derived from a Layer-2 address.  As a side note, this
   is incompatible with Secure Neighbor Discovery (SeND) [RFC3971] and
   Cryptographically Generated Addresses (CGAs) [RFC3972], since they
   derive the IID from cryptographic keys, whereas this specification
   separates the IID and the key material. 
"


> >
> > Text in the main spec has
> > "
> >   The assumption is that the 6LR and the 6LBR maintain a security
> association, so there is no need to propagate the proof of ownership to the
> 6LBR.
> > "
> > But I'm not aware of people using anything beyond Layer-2 security. The
> EDAR/EDAC are unicast ICMPv6 messages; what would be your
> recommendation to protect them at L3?
> 
> At L3?  I don't know of much other than IPsec (or some tunneling solution).
> But by "details" I meant more about whether confidentiality protection is
> required or "merely" integrity protection and source-authentication.

In this case the merely is enough. The EDAR has the ROVR and the registered address. Those will appear later in ND flows anyway.
In the main text, :

"
   The assumption is that the 6LR and the 6LBR maintain a security
   association to authenticate and protect the integrity of the EDAR and
   EDAC messages, so there is no need to propagate the proof of
   ownership to the 6LBR.  The 6LBR implicitly trusts that the 6LR
   performs the verification when the 6LBR requires it, and if there is
   no further exchange from the 6LR to remove the state, that the
   verification succeeded.
"

Many more thanks!

Pascal