Re: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00

Hi Samu,

Thanks for your comments. See my comments inline.

Am 23.01.2008 um 10:26 schrieb Samu Varjonen:

> Hi,
>
> Miika Komu wrote:
>
>> As a conclusion, I think the middlebox draft from Tobias makes a
>> lot of sense for replay protection for middleboxes.
>
> I agree with Miika that replay protection makes sense but I have
> few comments about the draft.
>
> Here is some comments on the draft-heer-hip-middle-auth-00
> ==========================================================
> First some small nitpicks. Then something more interesting.
>
> 1) Fig.1 says that R2 is sent from Initator to Responder. (arrows
> point to wrong direction)

Thanks for pointing that out. I'll fix this with the next version.

>
> 2) Section 1.1. where it discusses about X and Y. It could be clearer
> in form
> "Middlebox has no way to distinguish legimate users X and Y from
> attackers A and B..."
> or
> "Middlebox has no way to distinguish X and Y from A and B"
Ok, I agree that should be expressed in a clearer form.

> 3) Section 2.1.1. discusses about the maximum size of total length
> of the packets (R1, I2, R2 and UPDATE affected). should not exceed
> ove 1280 bytes, because of IPv6 fragmentation. This statement uses
> capitalized SHOULD and I think that in practise this contradicts
> with base-10, which says the following:
>

The should here comes from the IPv6 fragmentation. I wouldn't want to burden the middlebox with packet assembly. Therefore I have put the SHOULD there. If the SHOULD if the contradiction to the base draft is problematic we can change it to a lowercase "should" or refer to the base draft.

> "the maximum length of the HIP Parameters field is (255*8)-32 =
> 2008
> bytes"
>
> And added to this the HIP header its about twice the size suggested
> in middle-auth-00. If "SHOULD" is changed to "should", then it
> would
> just say it would be preferred that the size would not exceed 1280.
> This is a valid concern, but i think "should" was meant and not
> carefully weighted maybe i'll do otherwise. And continuing with
> this
> thought I think the fragmentation and packet size limits should be
> handled in base-10.
>
> 4) One request-response parameter pair can do the same job as two
> pairs.
> PUZZLE_M and SOLUTION_M already have the opaque value in them. If
> longer opaque is needed then something similar to the following
> would
> suffice.
>
> PUZZLE_M:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | K, 1 byte | Reserved | Opaque length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Opaque (variable len) | Padding (var.len.)|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Random # I, 8 bytes |
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> SOLUTION_M:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | K, 1 byte | Reserved | Opaque length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Opaque (variable len) | Padding (var.len.)|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Random # I, 8 bytes |
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Puzzle solution #J, 8 bytes |
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Now if K is zero then there is no puzzle in the parameter.
> Similarly
> if opaque length is zero there is no opaque number in the
> parameter.
> Either or both should be present when sending PUZZLE_M and answer
> should be constructed accordingly. If needed padding added to
> the end
> of opaque number. Opaque number + padding modulus 32 should result
> into zero.
>

I agree that the two parameters could be condensed to just one parameter. However, the reason why I chose that thwo parameters would be beneficial is that I suspect that the puzzle will only be needed rarely (i.e under attack conditions). Using the puzzle even for normal operation requires transmit 9 additional bytes for the puzzle and 17 additional bytes for the solution. With regard to the restricted space in the HIP packets and the possibility of having cascaded middleboxes, I thought separating the puzzle form the echo_request to save space would be a good idea.

> 5) As an suggestion or an answer to the following
>
> "- Andrew McGregor raised concern about having responders solve
> puzzles, but otherwise voiced support for developing this further"
>
> I suggest two possible ways to delegate the Responders middlebox
> puzzle to the Initiator to be solved.
>
> Original:
> Figure 1: Middlebox authentication of a HIP base exchange.
>
> Main path:
>
> Initiator Middlebox Responder
> .-----------------.
> I1 | | I1
> -------------------> | |
> ---------------------------->
> | |
> R1, + EQ1, [PM1] | Add EQ1, PM1 | R1
> <------------------- | |
> <----------------------------
> | |
> I2, {ER1, SM1} | Verify SM1, EQ1 | I2, {ER1, SM1} + EQ2,
> [PM2]
> -------------------> | Add EQ2, PM2 |
> --------------------------->
> | |
> | |
> R2, {ER2, SM2} | Verify SM2, ER2 | R2, {ER2, SM2}
> -------------------> | |
> ---------------------------->
> '-----------------'
>
> EQ: Middlebox Echo reQuest
> ER: Middlebox Echo Response
> PM: Puzzle of the Middlebox
> SM: Solution of Middlebox puzzle
>
> How Responder could move the puzzle to the Initiator.
> In the extended version 1, I show how you could utilize the fact
> that
> the Initiator will process second R1 received in I2-SENT state and
> send a second I2. This second R1 is used to carry the puzzle
> given by
> the middlebox to the Initiator of the BEX.
>
> Copy-paste from base-10
> ...
> System behaviour in state I2-SENT, Table 4.
>
> +---------------------
> +---------------------------------------------+
> | Trigger |
> Action |
> +---------------------
> +---------------------------------------------+
> | Receive I1 | Send R1 and stay at I2-
> SENT |
> |
> | |
> | Receive R1, process | If successful, send I2 and cycle at I2-
> SENT |
> ...
>
> Extended 1:
> Figure 1: Middlebox authentication of a HIP base exchange.
>
> Main path:
>
> Initiator Middlebox Responder
> .-----------------.
> I1 | | I1
> -------------------> | |
> ---------------------------->
> | |
> R1, + EQ1, PM1 | Add EQ1, PM1 | R1
> <------------------- | |
> <----------------------------
> | |
> I2, {ER1, SM1} | Verify SM1, EQ1 | I2, {ER1, SM1} + EQ2, PM2
> -------------------> | Add EQ2, PM2 |
> --------------------------->
> | |
> R1, {EQ2, PM2} | Verify EQ2, PM2 | R1, {EQ2, PM2}
> <------------------- | |
> <----------------------------
> | |
> I2, {ER2, SM2} | Verify SM2, PM2 | I2, {ER2, SM2}
> -------------------> | |
> ---------------------------->
> | |
> R2 | | R2
> <------------------- | |
> <----------------------------
> '-----------------'
>
> EQ: Middlebox Echo reQuest
> ER: Middlebox Echo Response
> PM: Puzzle of the Middlebox
> SM: Solution of Middlebox puzzle
>
> On the other hand Initiator, Responder and the Middlebox could
> use the
> registration extension (draft-ietf-hip-registration-02), for service
> ESP on the middlebox. But this needs firewall on middlebox to set
> the
> ESP ports open for the HIT pair.
>
> Extended 2:
> Figure 1: Middlebox authentication of a HIP base exchange.
>
> Main path:
>
> Initiator Middlebox Responder
> .-----------------.
> I1 | | I1
> -------------------> | |
> ---------------------------->
> | |
> R1, RN(ESP) | Add EQ1, PM1 | R1, RN(ESP)
> <------------------- | |
> <----------------------------
> | |
> I2, RR(ESP) + | | I2, RR(ESP) + {ER1, SM1} +
> {ER1, SM1} | Verify SM1, EQ1 | EQ2, PM2
> -------------------> | Add EQ2, PM2 |
> --------------------------->
> | |
> R2, RF({EQ2, PM2}) | Verify PM2, EQ2 | R2, RF({EQ2, PM22})
> <------------------- | |
> <----------------------------
> | |
> UPDATE, RR(ESP) + | | UPDATE, RR(ESP) +
> {ER2, SM2} | Verify ER2, SM2 | {ER2, SM2}
> -------------------> | |
> --------------------------->
> | |
> UPDATE, RQ(OK) | Open ports for | UPDATE, RQ(OK)
> <------------------- | ESP traffic |
> <----------------------------
> '-----------------'
>
> EQ: Middlebox Echo reQuest
> ER: Middlebox Echo Response
> PM: Puzzle of the Middlebox
> SM: Solution of Middlebox puzzle
> RN: Registry iNfo
> RQ: Registry reQuest
> RR: Registry Responde
> RF: Registry Failed
>
> In my opinion the Extended 2 is a cleaner way to do the
> delegation of
> Responders middlebox puzzle to the Initiator. Its not a novel idea,
> but it should work. In both of these ways the Responder at least has
> to sign the puzzle so verifying that it owns the secret key to this
> identity.
>

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related listserv.cybertrust.com Links hipsec-rg Request more information about Pantek

I believe that pushing the puzzle to the initiator is a good workaround for the problem. I'm just not sure if it wouldn't be easier to let the middlebox hand over two puzzles to the initiator of which the initiators solves both and sends one solution to the responder. Having all these additional HIP messages during the handshake seems to be overkill.

BR,

Tobias

> BR,
> Samu Varjonen
> samu.varjonen@hiit.fi

--
Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group
RWTH Aachen University, Germany
http://ds.cs.rwth-aachen.de/members/heer