Re: [hiprg] Implementing DEX

[Miika Komu <[e-mail]>]

Hi,

the code is here:

http://code.google.com/p/hip-dex/

AFAIK, only base exchange is supported (no data plane or mobility).

On 04/03/2012 05:30 PM, Nerea Toledo Gandarias wrote:
> 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)
>
>
>
> _______________________________________________
> hiprg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/hiprg