Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt

[Miika Komu]

Hi,

On 06/03/2016 02:20 PM, René Hummen wrote:

This is part 3 of 3.


I am fine with your fixes. Some comments below.


On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu > wrote:

> [...]

 > 6.2.1.  CMAC Calculation
 >
 > [...]
 >
 >
 > 5.  Set Checksum and Header Length fields in the HIP header to
 > original values.  Note that the Checksum and Length fields
 > contain incorrect values after this step.

I guess also the values following HIP_MAC should be restored since
they were wiped in the step 2.


I also found this description a bit imprecise, but it is taken from
RFC7401. Step 2 already hints at the fact that parameters following
HIP_MAC may still be of interest:
"Remove the HIP_MAC parameter, as well as all other parameters
that follow it with greater Type value, saving the contents if
they will be needed later."

The question is whether we want to fix the description for HIP DEX or to
keep things as they are for consistency reasons. In the former case, I
would prefer to completely rewrite the verification procedure to work on
the received packet without removing any parameters. However, we should
then probably also post an errata to RFC7401. If there are no stong
opinions about that, I would go for the latter option.


Latter option works for me too.


 > The CKDF-Extract function is the following operation:
 >
 > CKDF-Extract(I, IKM, info) -> PRK

What does the arrow operator signify? I thought that it produces PRK,
but PRK is actually defined below.


The arrow is part of a basic mathematical function definition. So yes,
PRK is the output (domain), but we still need to give it a proper name.
I changed the artwork to clearly point out the inputs and outputs.


Thanks, it is now better.


Please check this section again in the updated version and get back to
me if the above changes do not sufficiently help your understanding.


It is good now, thanks!


 > Llength of output keying material in octets
 >  (<= 255*RHASH_len/8)
 > |denotes the concatenation
 >
 > The output keying material OKM is calculated as follows:
 >
 > N   =  ceil(L/RHASH_len/8)
 > T   =  T(1) | T(2) | T(3) | ... | T(N)
 > OKM =  first L octets of T
 >
 > where
 >
 > T(0) = empty string (zero length)
 > T(1) = CMAC(PRK, T(0) | info | 0x01)
 > T(2) = CMAC(PRK, T(1) | info | 0x02)
 > T(3) = CMAC(PRK, T(2) | info | 0x03)
 > ...

The Expand was a bit more clear, but still didn't understand how to
get to the
Expanded key material due the arrow notation.


Ok, let's clarify this as several comments are related to the arrow
notation. For the function definition we use the mathematical arrow
notation (same as RFC 5869) and for the actual opertation we use the
equals sign (same as RFC 5869). In the end, they denote the same thing:
"assign X to Y".


Ok, this is what I guessed too.


 > (where the constant concatenated to the end of each T(n) is a
 > single octet.)

Is there a max value?


I am not sure what you mean here. If you refer to the N in T(N) then it
is defined above as N = ceil(L/RHASH_len/8).


Yes, I asked about the maximum value for N (which depends on L), but 
never mind.



 > 8.   The R1 packet may have the A-bit set - in this case, the system
 > MAY choose to refuse it by dropping the R1 packet and returning
 > to state UNASSOCIATED.  The system SHOULD consider dropping the
 > R1 packet only if it used a NULL HIT in the I1 packet.

I didn't understand the logic in the last sentence.


Someone must have had a reason for this recommendation, but that someone
wasn't me. This is text from RFC7401. Any suggestions how to proceed?


Fix similarly as the other RFC7401 issue in the beginning of this email.


 > 6.7.  Processing Incoming I2 Packets
 >
 > [...]
 >
 > 5.   If the system's state machine is in the I2-SENT state, the
 > system MUST make a comparison between its local and sender's
 > HITs (similarly as in Section 6.3).  If the local HIT is smaller
 > than the sender's HIT, it should drop the I2 packet, use the
 > peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce
 > #I from the R1 packet received earlier, and get the local
 > Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J
 > from the I2 packet sent to the peer earlier.  Otherwise, the
 > system should process the received I2 packet and drop any
 > previously derived Diffie-Hellman keying material Kij and
 > ENCRYPTED_KEY keying material it might have generated upon
 > sending the I2 packet previously.  The peer Diffie-Hellman key,
 > ENCRYPTED_KEY, and the nonce #J are taken from the just arrived
 > I2 packet.  The local Diffie-Hellman key, ENCRYPTED_KEY keying
 > material, and the nonce 

Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt

[Miika Komu]

Hi Rene,

On 06/01/2016 03:08 PM, René Hummen wrote:

This is part 2. More to come...


I am fine with your fixes for part 2.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

[Hipsec] I-D Action: draft-ietf-hip-rfc4423-bis-14.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Host Identity Protocol of the IETF.

Title   : Host Identity Protocol Architecture
Authors : Robert Moskowitz
  Miika Komu
Filename: draft-ietf-hip-rfc4423-bis-14.txt
Pages   : 40
Date: 2016-06-07

Abstract:
   This memo describes a new namespace, the Host Identity namespace, and
   a new protocol layer, the Host Identity Protocol, between the
   internetworking and transport layers.  Herein are presented the
   basics of the current namespaces, their strengths and weaknesses, and
   how a new namespace will add completeness to them.  The roles of this
   new namespace in the protocols are defined.

   This document obsoletes RFC 4423 and addresses the concerns raised by
   the IESG, particularly that of crypto agility.  It incorporates
   lessons learned from the implementations of RFC 5201 and goes further
   to explain how HIP works as a secure signaling channel.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc4423-bis-14


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec