Subject: [Hipsec] Re: Last Call: 'Host Identity Protocol' to Experimental RFC (draft-ietf-hip-base)

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Sep 2006 09:55:06 +0300 (EEST)

On Thu, 31 Aug 2006, The IESG wrote:
> The IESG has received a request from the Host Identity Protocol WG to
> consider the following document:
>
> - 'Host Identity Protocol '
>   <draft-ietf-hip-base-06.txt> as an Experimental RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2006-09-14.

Sorry for being late with comments.  I mainly reviewed the first 
sections of the spec.  I think there are some major issues with IANA 
considerations section and the use of IPv6-compatible addresses (at 
least) which require revising the specification.  R1 generation 
counter design should also be (IMHO) reconsidered. See below.

substantial
-----------

    Finally, HIP is designed as an end-to-end authentication and key
    establishment protocol, to be used with Encapsulated Security Payload
    (ESP) [24] and other end-to-end security protocols.  The base
    protocol lacks the details for security association management and
    much of the fine-grained policy control found in Internet Key
    Exchange IKE RFC2409 [7] that allows IKE to support complex gateway
    policies.  Thus, HIP is not a replacement for IKE.

==> I do not think this paragraph is entirely clear about the role of HIP
wrt. IKE.  Does this mean that as "base protocol lacks the details for SA
management..." that IKE must be used on conjuntion with HIP to manage the
SAs?  Or that if additional SA management features are deemed necessary, IKE
must be used in addition to HIP?  I suspect you mean the latter, but the
language should be more explicit on this.  Current wording raises a question
whether the SA management in HIP has been adequately specified if it "lacks
the details".

==> s/IKE/(IKE)/

4
    The protocol number for Host Identity Protocol will be assigned by
    IANA.  For testing purposes, the protocol number 253 is currently
    used.  This number has been reserved by IANA for experimental use
    (see [19]).

but IANA considerations section says:

    This document specifies the IP protocol number 253 to be used with
    Host Identity Protocol during the experimental phase.  This number
    has been reserved by IANA for experimental use (see [19].

==> 'reserving' 253 out of the experimental space.  I think the experimental
values are supposed to be used in pre-RFC trials, and codifying a value in
an RFC goes goes against [19].  IMHO, you should request a new protocol
value (using IESG Approval process) and give proper instructions to IANA.

4.1.4
    The R1 generation counter is a monotonically increasing 64-bit
    counter that may be initialized to any value.  The scope of the
    counter MAY be system-wide but SHOULD be per host identity, if there
    is more than one local host identity.  The value of this counter
    SHOULD be kept across system reboots and invocations of the HIP base
    exchange.

==> What if the R1 generation counter is NOT kept across system reboots? 
I'd generally expect that to be the case, and I'd be happier if this was
downgraded to a MAY so that this mode of interoperability would also be
better tested.

    Also, the R1 generation counter MUST NOT roll over; if
    the counter is about to become exhausted, the corresponding HI must
    be abandoned and replaced with a new one.

==> So, you're required to create a new public key if R1 rolls over, you
don't store it in the disk during reboot, etc.?  As this creates
requirements on the use of HIs, this would need to be spelled out better. 
I'd also actively encourage against this kind of design per above.

    A host may receive more than one R1, either due to sending multiple
    I1s (Section 6.6.1) or due to a replay of an old R1.  When sending
    multiple I1s, an initiator SHOULD wait for a small amount of time
    after the first R1 reception to allow possibly multiple R1s to
    arrive, and it SHOULD respond to an R1 among the set with the largest
    R1 generation counter.

==> "a small amount of time" is very subjective; it could be milliseconds to
some, dozens of seconds or even minutes to others.  Does this have
implementation/interoperability implications?

5.2.1
The parameters MUST be
    included in the packet such that their types form an increasing
    order.  If the order does not follow this rule, the packet is
    considered to be malformed and it MUST be discarded.

==> does "increasing order" allow you to send the same option number
multiple times or not?   This was discussed at the IETF list some months
ago... :-)

    All of the TLV parameters have a length (including Type and Length
    fields) which is a multiple of 8 bytes.  When needed, padding MUST be
    added to the end of the parameter so that the total length becomes a
    multiple of 8 bytes.  This rule ensures proper alignment of data.  If
    padding is added, the Length field MUST NOT include the padding.

==> I must be missing something.  If padding is added according to the
abovementioned text, adding the padding (up to the next 64 bit boundary)
doesn't change the Length field -- so I'm not sure what the last sentence is
saying ?  I think protocol design shouldn't be such that there is more data
(even if it's padding) that goes beyond the length field.

8
    Denial-of-service attacks take advantage of the cost of start of
    state for a protocol on the Responder compared to the 'cheapness' on
    the Initiator.

==> insert "often" before "take advantage".  By definition, DoS attack does
not need to rely on the cost at the start.  Above attack was commonplace 5
years ago, now with botnets the evolution has been towards more classical
"flash crowd" attacks.

9
       The type codes 32768 through 49141 are reserved for
       experimentation and private use.  Types SHOULD be selected in a
       random fashion from this range, thereby reducing the probability
       of collisions.  A method employing genuine randomness (such as
       flipping a coin) SHOULD be used.

==> randomization is not good enough here.  Remember that half of the values
imply Critical bit being set.  So, the requestor should indicate whether
(s)he wants a value that has a critical bit set or not, right?  There should
be some IANA guidance on this.
==> By the way, do we even want to allow non-reviewed critical bit usage?

Appendix C.  Example Checksums for HIP Packets

    The HIP checksum for HIP packets is specified in Section 6.1.2.
    Checksums for TCP and UDP packets running over HIP-enabled security
    associations are specified in Section 3.5.  The examples below use IP
    addresses of 192.168.0.1 and 192.168.0.2 (and their respective IPv4-
    compatible IPv6 formats), and HITs with the first two bits "01"
    followed by 124 zeroes followed by a decimal 1 or 2, respectively.

C.1.  IPv6 HIP Example (I1)

       Source Address:                 ::192.168.0.1
       Destination Address:            ::192.168.0.2
...

==> first of all, section 6.1.2 does not exist (anymore), maybe you were
referring to 5.1.1 ?

==> second, I don't think I found in 5.1.1 or elsewhere any specification
why you used IPv4-compatible IPv6 format here.  Is that a pseudo-header
representation of an IPv4 address?  If so, it should probably be a mapped
address (::ffff:a.b.c.d) instead as the compatible address has been
deprecated and was used in tunneling.

editorial
---------

abstract
    Discussion related to this document
    is going on at the IETF HIP Working Group mailing list.

==> this should probably be removed prior to RFC publication.

1.1
    There are two main representations of the Host Identity, the full
    Host Identifier (HI) and the Host Identity Tag (HIT The HI is a
    public key and directly represents the Identity.

==> missing ")." after HIT ?

    Exchange Complete (EC):  Time that the host spends at the R2-SENT
       before it moves to ESTABLISHED state.  The time is n * I2
       retransmission timeout, where n ~ I2_RETRIES_MAX.

==> what do you mean by "n ~ .." notation ?

For example, if ESP is used to protect data traffic, the
    Security Parameter Index (SPI) carried in the ESP header, can be used
    to map the encrypted data packet to the correct HIP association.

==> s/header,/header/

4.1.2
    Responder remembers an old puzzle at least 2*lifetime seconds after
    it has been deprecated.

==> does 'lifetime' refer to the field defined in 5.2.4?  If so, maybe it
should be written as "Lifetime" or the like..

    | HMAC             | 61505 | variable | HMAC based message          |
    |                  |       |          | authentication code, with   |
    |                  |       |          | key material from           |
    |                  |       |          | HIP_TRANSFORM               |
    |                  |       |          |                             |
    | HMAC_2           | 61569 | variable | HMAC based message          |
    |                  |       |          | authentication code, with   |
    |                  |       |          | key material from           |
    |                  |       |          | HIP_TRANSFORM               |

==> you should probably note the HMAC/HMAC_2 difference in this table (i.e.,
HMAC_2 includes HOST_ID) to aid readability.

9
    This document also creates a set of new name spaces.  These are
    described below.

    Packet Type

==> should this be called "HIP Packet Type" ?

In the early
    times of this draft, John Gilmore kept Bob Moskowitz challenged to
    provide something of value.

==> reword "draft" to "document" or some such ?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 22 Sep 2006 10:45:18 +0300

Pekka,

Thanks for your review.

I am responding only to your concerns about R1 generation counter
design and private parameter types.  I cannot comment your IANA
considerations since I am not familiar enough with IANA considerations.
Finally, IMHO, most of your comments seem to be caused by the text
not being clear enough and mainly requiring only rewordings or
clarifications.

> downgraded to a MAY so that this mode of interoperability would  

If you don't keep your R1 generation counter, your open up your peers to
R1 replay attacks.  What an R1 replay attack may cause is that under an
active attack the Initiator may solve a wrong puzzle, causing the
communication to fail.  I would not consider that a big problem, though.
The idea of generation counters is to plug that problem to those hosts
that do have stable storage.

So, basically, the reason for the current wording is that we wanted to
allow devices that have no stable storage at all, i.e., ROM-only  
devices.
If that was not the concern, the second SHOULD would be a MUST.

> don't store it in the disk during reboot, etc.?

No, or at least that is not the intention.  The intention is to only
require a new public key to be created if you do keep the generation
counter on the disk and it does roll over.  Again, this is related to
the desire to support ROM-only devices.

> As this creates requirements on the use of HIs, this would need to be
> spelled out better. I'd also actively encourage against this kind of
> design per above.

I don't understand how it creates requirements to the use of HIs.

Personally, I would not care too much about ROM-only devices, and
therefore I'd be willing to change the spec to require the gen
counter to be always committed to stable storage.  On the other
hand, opening one's peers to R1 replay attacks may not be that big a
problem.  Besides, IIRC, the spec allows the peers to protect themselves
iff they know that a given host does implement genuinely increasing
generation counter.

> implementation/interoperability implications?

"small amount of time" depends your expected RTT and other network
considerations.  Basically, how long would you expect it take to any
replies to arrive.  Maybe a sentence stating something like "A  
reasonable
value may be 2 * expected RTT."  However, that would still have the
problem of estimating the RTT, which may be very hard.

On the other hand, I don't see any direct interoperability implications.
Having a small value (even zero) only increases the probability that
the receiver may solve a stale puzzle.  Having a too large value  
increases
the probability that the puzzle may become stale while being solved.

> ==> randomization is not good enough here.

Why?

> Remember that half of the values imply Critical bit being set.
> So, the requestor should indicate whether (s)he wants a value
> that has a critical bit set or not, right?

Yes.  If the sender wants the receiver to abandon the negotiation
if it doesn't understand the parameter, the design should pick
a critical parameter.

> There should be some IANA guidance on this.

Why?

> ==> By the way, do we even want to allow non-reviewed critical bit  

Now I don't understand your thinking at all.

--Pekka Nikander

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Sep 2006 11:06:55 +0300 (EEST)

> that do have stable storage.

To clarify, I didn't see this attack as a big problem, hence I do not 
see the sufficiently clear justification for stable storage 
requirement and related complexity.  Very few IETF protocols require 
or recommend (in uppercase) stable storage and IMHO such protocol 
design choices need more careful examination.

...
> I don't understand how it creates requirements to the use of HIs.

So, if you happen to have an implementation bug, for example, which 
would jump the generation counter forward too much so that it would 
need to be rolled over, you'd need to regenerate your keys.

This doesn't sound too userfriendly.  I keep wondering why a typical 
counter that can roll over could not sufficiently protect from a 
replay attack.

>> There should be some IANA guidance on this.

The IANA cannot just randomize a number.  It at the very least, it 
needs to randomize a number, and then to keep it as it is or add or 
subtract one, depending on whether the requestor wants a Critical bit 
to be set or not.

> Now I don't understand your thinking at all.

As the lack of support for the critical bit option stops the HIP 
exchange, those option numbers should be designed and deployed with 
more care than non-critical options.  Whether IETF review helps (or is 
the right way) to ensure this is probably a matter of opinion (and I 
don't have a strong one myself).

---

From: Petri Jokela <[email-masked]>
Date: Fri, 22 Sep 2006 11:27:01 +0300

Hi,

and thanks Pekka (S) for reviewing the document!

> if it doesn't understand the parameter, the design should pick

The randomization (in my mind) would mean that implementor selects first if 
the new parameter is critical or not and then selects the type value randomly 
from the available (half of the original) area. Maybe this requires a small 
clarification in the text.

> Now I don't understand your thinking at all.

If I understand correctly, the HIP document is currently in line with the 
following:

http://ietfreport.isoc.org/idref/rfc3692/

When using the type values from the area reserved for testing there should be 
no restrictions. These parameter type values are not used in standards 
compliant implementations in the network and implementations in general should 
not accept parameters with these values. If this parameter area for testing is 
not specified (including critical parameter values), implementors will then 
pick other values for testing anyway (which is bad).

Once these new parameters have gone through the normal IETF process (with 
discussions about critical/non-critical issues), a "real" parameter type value 
is reserved for them.

Petri

-- 
Petri Jokela				e-mail: [email-masked]
Research Scientist			phone:  +358 9 299 2413
Ericsson Research, NomadicLab		mobile: +358 44 299 2413

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 22 Sep 2006 13:39:34 +0300

> To clarify, I didn't see this attack as a big problem, hence I do  
> not see the sufficiently clear justification for stable storage  
> requirement and related complexity.  Very few IETF protocols  
> require or recommend (in uppercase) stable storage and IMHO such  
> protocol design choices need more careful examination.

IIRC, we discussed in length at the WG if the generation counter was  
a good idea at all.  The additional protection it provides is not  
that large; that is clear.  My memory may fail here, but IIRC in the  
end of the day we felt that the actual added complexity is small  
enough compared to the potential benefit.  In practical terms, it is  
just that you store the generation counter in the same file than the  
private key, or next to it.  And we felt that in this way we make the  
design "complete", i.e., provide all the protection that we "can".   
(I can spell out the qualified "can" if you want to -- it basically  
refers to the engineering trade-off between the various conflicting  
forces in this space.  But it is a long story.)

Anyway, we only recommend using stable storage if you have it, and  
still allow the operation without it.  The reason why it is a SHOULD  
and not a MAY is that leaving it out has security implications to  
others, basically leaving your *peers* slightly more vulnerable to a  
potential security problem.  Hence, to overcome the economic  
asymmetry here (you pay to protect your peers), we thought that  
encouragement from the IETF side is needed.

> need to be rolled over, you'd need to regenerate your keys.

IMHO that is pretty far fetched.  Why should you imagine to have such  
a bug and go unnoticed for the at least few years that is needed to  
roll over the counter even at the fastest speeds I can imagine?

> This doesn't sound too userfriendly.  I keep wondering why a  
> typical counter that can roll over could not sufficiently protect  
> from a replay attack.

It may be that I don't remember all the design considerations here,  
but rolling a 64-bit counter takes quite a lot of time, and you may  
initialise it to zero.  At the rate of one generation per minute,  
rolling a 64-bit counter takes about 2300 times the current estimate  
for the age of the universe.  At the rate of a new generation each  
second, it just takes 38 times the current age of the universe to  
roll it over.  Hence, if you do your math, you may not even need to  
include any code to cover that situation, as it will never happen.

Furthermore, it seems unwise to rely on the same public keys for  
longer than perhaps a decade or two.  Hence, I don't quite understand  
what you are objecting.

(A comparison point that we had in mind was that in IPsec, if you  
roll over your 64-bit replay protection, which gets updated at a much  
faster rate, you need to recreate your SAs.  And that is not seen as  
a problem.)

> subtract one, depending on whether the requestor wants a Critical  
> bit to be set or not.

I don't understand how you get the impression that IANA should  
generate and/or register them?  They are explicitly told to be for  
experimentation and private use.  Perhaps the wording is unclear?

> more care than non-critical options.  Whether IETF review helps (or  
> is the right way) to ensure this is probably a matter of opinion  
> (and I don't have a strong one myself).

If you are worried about running out HIP parameter types, IMHO you  
should be more worried about the ordering requirement.  That is far  
more likely to cause local shortages than that we might run out by  
any other means.

I'm sorry for being dense, but I still fail to see your point.  I  
just don't understand why there should be any more care with critical  
options than non-critical ones.  As far as I can see, which one to  
use is a design choice.  In general, by using a critical option you  
basically want a fast-stop feature.  You could as well use a non- 
critical option that requires a reply if implemented, but you just  
save yourself the burden of checking that by making the option  
critical.  The reason to include is that there are certain types of  
crypto protocols that become somewhat easier to implement and/or make  
secure with such fast-stop feature.

So, are you calling for clarification of the (IMHO pretty obvious)  
thinking behind, or what is your concern?  Have you looked at the  
advice in 5.2.2?

--Pekka Nikander

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Sep 2006 22:24:56 +0300 (EEST)

On Fri, 22 Sep 2006, Pekka Nikander wrote:
>> The IANA cannot just randomize a number.  It at the very least, it needs to 
>> randomize a number, and then to keep it as it is or add or subtract one, 
>> depending on whether the requestor wants a Critical bit to be set or not.
>
> I don't understand how you get the impression that IANA should generate 
> and/or register them?  They are explicitly told to be for experimentation and 
> private use.  Perhaps the wording is unclear?

Sorry, I misread the text as calling these out to be registered with 
IANA.  It seems clear enough.  Maybe it could have something about the 
user deciding whether it wants to have a critical bit or not (e.g., a 
pointer to some other part of the draft) but that doesn't seem 
strictly necessary.