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

[marcelo bagnulo braun <[e-mail]>]

Hi Jari, all,

thanks for the review...

I have some questions about the points you make in order to proceed  
with the new version of the draft

se reply in-line

El 03/09/2007, a las 14:24, Jari Arkko escribió:

> Marcelo,
>
> I have made my AD review of this document. Please
> find comments below. There are a few substantial
> issues, but I think they can be corrected fairly
> easily. I noted also a number of editorial
> issues. I will expect a new revision before we
> move forward with this.
>
> This is part 1 of my Shim6-related AD reviews.
> The protocol draft is in my queue to be read next;
> this will probably take a week or two. Mark will
> review the failure detection draft, and I have
> also asked him to handle any IPR related discussions,
> should they come up during IETF Last Call. We will
> wait with the Last Call until all three drafts
> can proceed to it.
>
> Here are the comments:
>
> Substantial:
>
>>    Ext Type:  16-bit type identifier of the Multi-Prefix Extension  
>> (TBD
>>       IANA) (Meanwhile, the 0x12 value is recommended for trails)
>
> A better recommendation would probably be "... the
> 0xFFFF value, reserved for experimental usage in [RFC 4581],
> is recommended for trials before the official IANA
> allocation has been granted."
>

I am not sure it is worth to change the value recommended for trials  
at this stage, since i would expect we are close to publication.

OTOH, I guess that once IANA allocate the final value, we should  
simply drop this sentence, don't you think?

Perhaps we should simply move this sentence to the IANA  
considerations section and add a not "Remove prior publications",  
what do you think?

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

Agree.

>
>>    P flag:  Set if a public key is included in the Public Key  
>> field of
>>       the CGA Parameter Data Structure.  Reset if a additional  
>> Modifier
>>       bits are included in the CGA Parameter Data Structure.
>
> This is unclear. I think you mean that instead of the public key,
> some additional random bits can also appear. But the above two
> conditions (if ... if ...) make it hard for the reader to know
> whether the two conditions are actually always the reverse of
> each other. I think they are. But I would rewrite the above as:
>
>
> P flag:  Set if a public key is included in the Public Key field of
>       the CGA Parameter Data Structure, reset otherwise.
>

ok

>
>> Second, in the
>> case that the address being generated is an HBA-only address, a
>> random nonce (encoded in DER as an ASN.1 structure of the type
>> SubjectPublicKeyInfo) will have to be used as input instead of a
>> valid public key.
>
> Which value would AlgorithmIdentifier take in the ASN.1 structure?
> Is the nonce a legal value for that identifier?

good point

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?



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


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.

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.

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.

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.

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


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?



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



> Editorial:
>

will correct.

thanks, marcelo