[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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