Re: AD review of draft-ietf-shim6-hba

[Jari Arkko <jari.arkko@piuha.net>]

Marcelo,


>> Alternatively, do you want to recommend value 0x12 for the IANA,
>> *if* implementations have already started to use it?
>
> Agree.

Lets do that, then.

> The bottom line is that we are including a random number that is not a
> public key in a field originally reserved for a public key, so at some
> point we will have a semantic problem.
>
> I have checked RFC3280 and RFC3279 and i haven't found values reserved
> for experiments or other usages that could be useful for this (but i
> am not familiar with these specs, so i may be wrong)
>
> At this point, i think it makes little sense to encode the random
> number as SubjectPublicKeyInfo, since as you mention, we will need to
> include an invalid AlgorithmIdentifier. I guess, it is better to
> simply put the 384 random bits of the Extended Identifier directly in
> the Public Key Field in the CGA PDS, than encoding them as public key
> info, since it is less effort for the generation procedure and the
> result is likely to b the same.
>
> So, my suggestion is simply to remove the request to encode the random
> nonce as a SubjectPublicKeyInfo, with a phrasing as follows:
>
>    Second, in the
>    case that the address being generated is an HBA-only address, a
>    random nonce will have to be used as input instead of a
>    valid public key.
>
>
> Also in the HBA genration procedure, the following change is needed
>
>  2. Modifier generation.  Generate a Modifier as a random or
>       pseudorandom 128-bit value.  If a public key has not been provided
>       as an input, generate the Extended Modifier as a 384-bit random or
>       pseudorandom value.  Encode the Extended Modifier value as a RSA
>       key in a DER-encoded ASN.1 structure of the type
>       SubjectPublicKeyInfo defined in the Internet X.509 certificate
>       profile [4].
>
> The last sentence needs to be removed
>
> makes sense?

Hm. I would rather use the same syntax to avoid breakage, but
the random bits inside. I would suggest finding a suitable
algorithm ID. It really does not matter what the values are,
but you need to describe what the encoding is.

>>
>>>    3. Concatenate from left to right the Modifier, 9 zero octets, the
>>>       encoded public key or the encoded Extended Modifier (if no public
>>>       key was provided) and the Multi-Prefix Extension.  Execute the
>>>       SHA-1 algorithm on the concatenation.  Take the 112 leftmost bits
>>>       of the SHA-1 hash value.  The result is Hash2.
>>>
>>>    4. Compare the 16*Sec leftmost bits of Hash2 with zero.  If they are
>>>       all zero (or if Sec=0), continue with step (5).  Otherwise,
>>>       increment the modifier by one and go back to step (3).
>>
>> RFC 4982 should be referenced here, as it updates the above procedure,
>> and the words about SHA-1 should be changed accordingly. I.e., SHA-1
>> is used only for some small Sec values, and other algorithms, to be
>> defined in the future, could be used for others.
>
> Good point, but i think that the implication of RFC4982 is broader
> than just hash2 generation, since it implies the usage of a different
> hash function for the whole CGA/HBA generation process and also the
> Sec protection mechanism.

Yes.

> I would suggest including a reference to RFC4982 in the beginning of
> the HBA generation and verification procedure. Something like the
> following
>
> 6.  HBA-Set Generation
>
>    The HBA generation process is based on the CGA generation process
>    defined in section 4 of [2].  The goal is to require the minimum
>    amount of changes to the CGA generation process. It should be noted
>    that the following procedure is only valid for Sec values of 0, 1
> and 2.
>    For other Sec values, RFC4982 has defined a CGA SEC registry which
> will
>    contain the specifications used to generate CGAs. The generation
>    procedures defined in such specifications must be used for Sec values
>    other than 0,1 or 2.

Ok.

>
> Similarly for the HBA verification procedure
>
> 7.  HBA verification
>
>    The following procedure is only valid for Sec values of 0, 1 and 2.
>    For other Sec values, RFC4982 has defined a CGA SEC registry which
> will
>    contain the specifications used to verify CGAs. The verification
>    procedures defined in such specifications must be used for Sec values
>    other than 0,1 or 2.

Ok.

>
> In addition, as you mention below, the attack analysis applies only to
> those sec values, so the following rephrassing is proposed (adding
> last couple of sentences)
>
>    The protection against brute force attacks can be improved increasing
>    the Sec parameter.  A non zero Sec parameter implies that steps 3-4
>    of the generation process will be repeated O(2^(16*Sec)) times
>    (expected number of times).  If we assimilate the cost of repeating
>    the steps 3-4 to the cost of generating the HBA address, we can
>    estimate the number of times that the generation is to be repeated in
>    O(2^(59+16*Sec)) in the case of Sec values of 1 and 2. For other
> values,
>    Sec protection mechanisms will be defined by the specifications
> pointed
>    by the CGA SEC registry defined in RFC 4982.

Ok.

>
> Finally, i guess that the 11.4.  SHA-1 Dependency Considerations. need
> also to be updated.
>
> In particular, i would suggest the folllowing rephrasing:
>
> 11.4.  SHA-1 Dependency Considerations.
>
>    Recent attacks to currently used hash functions have motivated a
>    considerable amount of concern in the Internet community.  The
>    recommended approach [13] [14] to deal with this issue is first to
>    analyze the impact of these attacks on the different Internet
>    protocols that use hash functions and second to make sure that the
>    different Internet protocols that use hash functions are capable of
>    migrating to an alternative (more secure) hash function without a
>    major disruption in the Internet operation.
>
>    The aforementioned analysis for CGAs and its extensions (including
>    HBAs) is performed in RFC4982.  The conclusion of the analysis is that
>    the security of the protocols using CGAs and its extensions is not
>    affected by the recently available attacks against hash functions.
>    In spite of that, the CGA specification [2] was updated by RFC4982
>    to enable the support of alternative hash functions.

Ok.

>>
>>>    HBA sets can be generated using any prefix set.  Actually, the only
>>>    particularity of the HBA is that they contain information about the
>>>    prefix set in the interface identifier part of the address in the
>>>    form of a hash, but no assumption about the properties of prefixes
>>>    used for the HBA generation is made.  This basically means that
>>>    depending on the prefixes used for the HBA set generation, it may or
>>>    may not be recommended to publish the resulting (HBA) addresses in
>>>    the DNS.
>>
>> I am not sure how the third sentence follows from the second.
>
>> But more importantly, this seems to simplify the issues
>> related to DNS implications. Basically, you must be able
>> to tell the DNS network manager what your IP addresses
>> are; its not possible for the manager to configure your
>> DNS entries and addresses.
>>
>
> i see your point.
> actually, this paragraph was aimed for the case where ULAs prefixes or
> other form of prefixes that is not clear thy should be published in
> the DNS are included in the HBA set... makes sense? do you think we
> need to reword the paragraph to make it more explicit?

Ok, but perhaps you should reword it because I did not
get your initial meaning when I did my review. Others may
have the same problem.

>
> In addition, we can add a paragraph with you point:
>
> something like:
>
>    In addition, it should be noted that the actual HBA values are
>    a result of the HBA generation procedure meaning that they cannot
>    be arbitrarily chosen. This has an implication with respect to DNS
> management,
>    because the party that generates the HBA address set needs to
> convey the
>    address information to the DNS manager, so that the addresses are
> published
>    and not the other way round. The situation is similar to regular
> CGA addresses and
>    even to the case where stateless address autoconfiguration is used.
>
> makes sense?

Ok.

>>>    In the case that both IPSec and CGA/HBA address are used
>>>    simultaneously, it is possible that two public keys are available in
>>>    a node, one for IPSec and another one for the CGA/HBA operation.  In
>>>    this case, an improved security can be achieved by verifying that
>>> the
>>>    keys are related somehow, (in particular if the same key is used for
>>>    both purposes).
>>
>> Yes, but please state that such verification is outside the
>> scope of this spec.
>>
>
> ok, will include the additional sentence:
>
> The actual verification procedure is outside the scope of this
> specification.

Ok.

>
>
>> Editorial:
>>
>
> will correct.
>
> thanks, marcelo
>
>
>

Thanks for your quick response.

Jari