Re: [hiprg] Implementing DEX

[Nerea Toledo Gandarias <[e-mail]>]

Hi,

I am also interested in the status of the DEX implementation.
Is it already available?

I would really appreciate this information.

Best Regards,
Nerea

El 08/02/2011 8:25, Robert Moskowitz escribió:
> 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.
>
> [e-mail] has indicated that he is working on an implementation.
>
>>
>> Regards
>>
>> 2011/2/4 <[e-mail] <mailto:[e-mail]>>
>>
>>     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
>>     [e-mail] <mailto:[e-mail]>
>>
>>     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
>>     [e-mail] <mailto:[e-mail]>
>>
>>     You can reach the person managing the list at
>>     [e-mail] <mailto:[e-mail]>
>>
>>     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 <[e-mail]
>>     <mailto:[e-mail]>>
>>     To: "[e-mail] <mailto:[e-mail]>" <[e-mail]
>>     <mailto:[e-mail]>>
>>     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 <[e-mail]
>>     <mailto:[e-mail]>>
>>     To: Andrei Gurtov <[e-mail]
>>     <mailto:[e-mail]>>
>>     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
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.irtf.org/mailman/listinfo/hiprg
>>
>>
>>
>>
>>     ---------- Mensaje reenviado ----------
>>     From: Robert Moskowitz <[e-mail]
>>     <mailto:[e-mail]>>
>>     To: [e-mail] <mailto:[e-mail]>
>>     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
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.irtf.org/mailman/listinfo/hiprg
>>
>>
>>
>> _______________________________________________
>> hiprg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/hiprg
>
>
> _______________________________________________
> hiprg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/hiprg


-- 
Nerea Toledo Gandarias
Departament of Expression Graphic and Project Engineering
University of The Basque Country
EUITU Bilbao              Tel: [phone]
UPV / EHU
Plaza de la Casilla, 3
48012 - Bilbao (Spain)