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

[Benjamin Kaduk <[e-mail]>]

On Tue, Feb 04, 2020 at 02:22:23PM +0000, Pascal Thubert (pthubert) wrote:
> This was truncated when I received the echo, retrying...

It appears different here as well; interesting.
I will remove a layer of quoting to make it easier for me to write a reply.

> 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 think I did expect something else; I thought I wrote:

% It's probably better to cite RFC 7696 as BCP 201 directly.                          
I guess maybe there was a copy/paste glitch.

> 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

Understood; this looks good.

> 
> > > >
> > > > 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.

I was just thinking a field in the CIPO to indicate the length to truncate
the hash output at, which would still be chosen by the 6LN.  Which I see
you already did per below; great :)

> > > >    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.

I was just commenting about "enables the use of SHA-256" since it also
allows other hashes.  But the words as written are true, so I have no real
objection.

> > > 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.
> 
> "

Thanks!

> 
> > > >
> > > >    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.

I think just having this length in the CIPO suffices; we would not
necessarily need to also include it in the signature input separtaely.
(But it does no harm to do so.)

>   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.

It sounds like it does go without saying :)
Thanks for confirming.

> 
> > >
> > > 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.
> "

Thanks!

-Ben