Subject: Re: [hiprg] Implementing DEX

From: Rodolfo Gallardo <[email-masked]>
Date: Mon, 7 Feb 2011 10:28:22 -0500

Hi,

I am studying HIP DEX, i would like to help implementing it, there is a
source code or any implementation available?

Regards

2011/2/4 <[email-masked]>

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.irtf.org/mailman/listinfo/hiprg
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send hiprg mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.irtf.org/mailman/listinfo/hiprg
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hiprg digest..."
>
> Today's Topics:
>
>   1. hip-rg-dex-04 (Andrei Gurtov)
>   2. Re: hip-rg-dex-04 (Robert Moskowitz)
>   3. Fwd: About the HIP DEX draft (draft-moskowitz-hip-rg-dex-04)
>      (Robert Moskowitz)
>
>
> ---------- Mensaje reenviado ----------
> From: Andrei Gurtov <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Date: Fri, 04 Feb 2011 10:06:16 +0200
> Subject: [hiprg] hip-rg-dex-04
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I read through the latest -04 version of draft-moskowitz-hip-rg-dex-04,
> nice to see that it's progressing towards completeness.
>
> We're trying to implement it at the moment, if anyone is interested in
> collaborating on DEX please let me know.
>
> Andrei
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1Ls3gACgkQP7jp0uceFkTKJwCgqt+wiOMmPssNKnHX1CfYhrPA
> HpMAoNvATboB9lHmV4c45s3XW9lGaHQ3
> =oGNv
> -----END PGP SIGNATURE-----
>
>
>
> ---------- Mensaje reenviado ----------
> From: Robert Moskowitz <[email-masked]>
> To: Andrei Gurtov <[email-masked]>
> Date: Fri, 04 Feb 2011 16:24:17 +0100
> Subject: Re: [hiprg] hip-rg-dex-04
> On 02/04/2011 09:06 AM, Andrei Gurtov wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I read through the latest -04 version of draft-moskowitz-hip-rg-dex-04,
>> nice to see that it's progressing towards completeness.
>>
>
> I have some comments I am reviewing. I hope to have a -05 week of Feb 14.
>
> I will forward one set of comments.
>
>  We're trying to implement it at the moment, if anyone is interested in
>> collaborating on DEX please let me know.
>>
>> Andrei
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk1Ls3gACgkQP7jp0uceFkTKJwCgqt+wiOMmPssNKnHX1CfYhrPA
>> HpMAoNvATboB9lHmV4c45s3XW9lGaHQ3
>> =oGNv
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> hiprg mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/hiprg
>>
>>
>
>
> ---------- Mensaje reenviado ----------
> From: Robert Moskowitz <[email-masked]>
> To: [email-masked]
> Date: Fri, 04 Feb 2011 16:26:12 +0100
> Subject: [hiprg] Fwd: About the HIP DEX draft
> (draft-moskowitz-hip-rg-dex-04)
> From Juho:
>
> -------- Original Message --------
>
> MAJOR QUESTIONS
> ---------------
>
> 3.2. Generating a HIT from an HI
>
> It is said in 3.2. that the DEX HIT is generated from the HI by
> left-truncating the HI into 96 bits. Except the problem that I have
> discussed with Nie Pin before that the OGA 4-bit field is not defined in
> the ORCHID specification, I am also confused by which 96 bits are
> actually used.
>
> According to 5.2.2. the HIT does not provide the HOST_ID key size and
> the HOST_ID key size will be selected by the responder according to
> DH_GROUP_LIST. My understanding is that the responder needs to have
> multiple HOST_IDs and select the one matching the key size the initiator
>  is requesting. Now, which one of the HOST_IDs will be used for the HIT
>  generation? How can the initiator confirm that HOST_ID matches the HIT
>  it is requesting. (if it cannot, this can result in a serious MITM,
> because R1 is not CMAC'ed)
>
>
> 5.1. HIP Parameters
>
> It is said in 5.2. that "For the BEX parameters ... HOST_ID, only the
> ECC values are valid in DEX.". I went to see RFC5201-bis-02 to see
> possible values for HOST_ID and the only ECC value for it was marked as
> ECDSA. This seems plain wrong, because the HOST_ID used in DEX is
> actually a static ECDH public/private keypair. Now it's possible to use
> ECDSA value to represent ECDH curve, but even the ECC Curve values are
> named confusingly as NIST-ECDSA-256 and NIST_ECDSA-384, even though they
> are basically the same P-256 and P-384 curves used in Diffie-Hellman.
>
> Just as a side note, why is there no value defined for the P-521 curve,
> which is also commonly used and included in the RFC4754?
>
>
> 5.1.2. ENCRYPTED_KEY
>
> I understand that this section is made as generic as possible, but to me
>  it simply sounds very confusing. First of all it says that "some
> encryption algorithms require an IV" and "for example the puzzle value,
> I, can be used as an IV". Why not simply define the puzzle value I as an
>  IV? I know it's good to give some freedom to the implementor, but
> since  the ENCRYPTED_KEY is only used in I2 and R2 and both of them
> define the puzzle value I explicitly as the IV, why confuse the
> implementor here?
>
> The same chapter also says that AES uses the PKCS5 padding scheme, which
>  leads me to think that PKCS5 is somehow defined by AES. In fact it
> seems  to be defined by the HIP DEX draft, and it should be explicitly
> said so  to avoid confusion. The same sentence says "may specify padding
> bytes  other than zero", but the padding in itself is not defined as
> zero, so  that sentence sounds confusing. I know the padding is defined
> as zero in  RFC5201 Section 5.2.1. TLV Format, but it still seems a bit
> out of the context.
>
> The last problem I have with this chapter is the note that "the length
> of the cipher suite output may be smaller or larger than the length of
> the value and nonce to be encrypted". This is combined with "extra
> padding added to the set of parameters to satisfy the cipher block
> alignment rules is not counted in HIP TLV length fields" and "If
> necessary, additional Padding for 8-byte alignment is then added
> according to the rules of the TLV Format in [RFC5201-bis]". Let's take a
> completely hypothetical example:
>
> 1) I have a cipher that has an input and output block size of 16 bytes,
> but in the last block it adds a checksum of 8 bytes
> 2) I have input data of 14 bytes, which means that the HIP TLV length
> field is 14 bytes as well
> 3) I will pad the input data to the cipher block size of 16 and encrypt
> it, this will result in 24 bytes of output data from the cipher
> 4) The total length of TLV is now 28 bytes and I need to pad it with
> zeros to 32 bytes to satisfy the 8-byte alignment
> 5) Now I have a TLV with length field of 14 bytes, TLV padding of 4
> bytes, 24 bytes to feed to the decryptor and 2 bytes of cipher suite
> padding
> 6) Question is, how do I know how many bytes to feed to the decryptor,
> when I cannot calculate the TLV padding size from the TLV length field?
> I can always just use a hardcoded value (8) for the checksum length and
> add it to the TLV length, but what if the checksum length varies? I
> don't think HIP DEX implementation should know too much about the cipher
>  internals.
>
>
> FEEDBACK REQUESTED
> ------------------
>
> 1.1. The HIP Diet EXchange (DEX)
>
> It is said that the initiator should wait for some delta time after it
> received the R2 packet until it can start sending the actual data
> because of the aggressive retransmission. I think it would be useful to
> explain this a bit more, for example what would happen if the data is
> transmitted too early or how it can be detected that the receiver has
> finished handling I2 packets.
>
>
> 4.1.1. HIP Puzzle Mechanism
>
> It's a good thing that the puzzle mechanism is defined as pretty generic
>  and free for the implementor to decide. However, personally I would
> make  the reference to Appendix A much stronger. The algorithm used in
> Appendix A uses both IP address of the initiator and IP address of the
> responder in generating the I. If the IP addresses (or some other lower
>  layer addresses) are not used in the generation of I, it results in a
>  situation where an attacker can solve the puzzle once and start a DDoS
>  attack of I2 packets that can last 3*lifetime of the puzzle if
> implemented as suggested in the draft.
>
> I think it would be safer and much more clear to note that not using the
>  method presented in Appendix A to generate the puzzle might have some
>  serious security considerations. I agree it should be free for the
> implementor to decide what kind of puzzle to use, but he should at least
> be aware of the consequences.
>
>
> 5.2. HIP Packets
>
> Why is DH_GROUP_LIST sent in R1 at all? The draft says it can be
> manipulated by an attacker and therefore is sent in R2 again, but
> sending it in R1 seens to be completely redundant. Another question is
> why is the DH_GROUP_LIST repeated so many times to begin with? It might
> make sense in BEX where the key exchange is ephemeral and the attacker
> could select a very weak key length and therefore be able to calculate
> the private key. But in DEX the initiator should only support safe
> Diffie-Hellman keys, since they work as its HOST_ID as well. If the
> server sends a smaller key length than requested, the attack is very
> easy to detect anyway.
>
> Also what I already mentioned earlier, I understand the HOST_ID is used
> as the public key for encrypting the secret-x. How does HIP DEX defend
> against an attacker that modifies the HOST_ID in the R1 packet, since R1
>  packet is not protected by the CMAC? Does HIP DEX assume that client
> has  received the full HIs of all key lengths from some other secure
> channel and not just the HIT? If it does, I think it should be said more
> clearly.
>
>
> EDITORIAL CORRECTIONS
> ---------------------
>
> Section 1:
> "A simple trunctation function for HIT generation."
>
> Suggestion:
> "A simple truncation function for HIT generation."
>
> Section 1.1:
> "As such the Intiator should take care to NOT send the first data packet
> until some delta time after it received the R2 packet."
>
> Suggestion:
> "As such the Initiator should take care to NOT send the first data
> packet until some delta time after it received the R2 packet."
>
> Section 3:
> "The HIT DEX hit is not generated via a cryptographic hash."
>
> Suggestion:
> "The HIP DEX HIT is not generated via a cryptographic hash."
>
> Section 4.1:
> "The term "key" refers to the Host Identity public key, "secret" refers
> to a random value encrypted by a public key, and "sig" represents a
> signature using such a key."
>
> Suggestion:
> "The term "PK" refers to the Host Identity public key and "secret"
> refers to a random value encrypted by a public key."
>
> Section 5.1:
> "For the BEX parameters, DIFFIE_HELMAN, DH_GROUP_LIST, and HOST_ID, only
>  the ECC values are valid in DEX."
>
> Suggestion:
> "For the BEX parameters, DIFFIE_HELLMAN, DH_GROUP_LIST, and HOST_ID,
> only the ECC values are valid in DEX."
>
> Appendix B. seems to be missing, I expect this to be a known issue. It
> would be nice to know a bit more about what is to be included there though.
>
>
>
>
>
> _______________________________________________
> hiprg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hiprg
>
>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 7 Feb 2011 23:18:33 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rodolfo Gallardo
> Sent: Monday, February 07, 2011 7:28 AM
> To: [email-masked]
> Subject: Re: [hiprg] Implementing DEX
> 
> Hi,
> 
> I am studying HIP DEX, i would like to help implementing it, there is a source code or any 
> implementation available?
> 
> Regards
> 

Rodolfo,
Please see the post from Andrei Gurtov on February 4, in which he mentioned implementation plans.

- Tom

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 08 Feb 2011 08:25:36 +0100

On 02/07/2011 04:28 PM, Rodolfo Gallardo wrote:
> Hi,
>
> I am studying HIP DEX, i would like to help implementing it, there is 
> a source code or any implementation available?

Currently none, though much should be the same as for BEX.

[email-masked] has indicated that he is working on an implementation.

>
> Regards
>
> 2011/2/4 <[email-masked] <mailto:[email-masked]>>
>
>     [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>
>     From: Andrei Gurtov <[email-masked]
>     <mailto:[email-masked]>>
>     To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     From: Robert Moskowitz <[email-masked]
>     <mailto:[email-masked]>>
>     To: Andrei Gurtov <[email-masked]
>     <mailto:[email-masked]>>
>         [email-masked] <mailto:[email-masked]>
>     From: Robert Moskowitz <[email-masked]
>     <mailto:[email-masked]>>
>     To: [email-masked] <mailto:[email-masked]>
>     bytes, 24 bytes to feed to the decryptor and 2 bytes of cipher
>     suite padding
>     [email-masked] <mailto:[email-masked]>