Re: [hiprg] Implementing DEX

Robert Moskowitz <rgm@htt-consult.com> Tue, 08 February 2011 07:26 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hiprg@core3.amsl.com
Delivered-To: hiprg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E151D3A6AE3 for <hiprg@core3.amsl.com>; Mon, 7 Feb 2011 23:26:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApyidWY1SkDz for <hiprg@core3.amsl.com>; Mon, 7 Feb 2011 23:26:21 -0800 (PST)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 01FDA3A7043 for <hiprg@irtf.org>; Mon, 7 Feb 2011 23:26:19 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id F3B5162C22; Tue, 8 Feb 2011 07:26:03 +0000 (UTC)
X-Virus-Scanned: amavisd-new at localhost
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xtm2A7DIMCil; Tue, 8 Feb 2011 02:25:39 -0500 (EST)
Received: from nc2400.htt-consult.com (ip212-238-50-177.hotspotsvankpn.com [212.238.50.177]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 73E0D62BA6; Tue, 8 Feb 2011 02:25:38 -0500 (EST)
Message-ID: <4D50EFF0.5020309@htt-consult.com>
Date: Tue, 08 Feb 2011 08:25:36 +0100
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7
MIME-Version: 1.0
To: Rodolfo Gallardo <rodolfo.gallardo@gmail.com>
References: <AANLkTi=UnBH41AW4id--3-GYQ_PpS_3HoOETOg_Zeb3i@mail.gmail.com>
In-Reply-To: <AANLkTi=UnBH41AW4id--3-GYQ_PpS_3HoOETOg_Zeb3i@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------010104030209020902080808"
Cc: hiprg@irtf.org
Subject: Re: [hiprg] Implementing DEX
X-BeenThere: hiprg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <hiprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/hiprg>
List-Post: <mailto:hiprg@irtf.org>
List-Help: <mailto:hiprg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Feb 2011 07:26:24 -0000

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.

pin.nie@aalto.fi has indicated that he is working on an implementation.

>
> Regards
>
> 2011/2/4 <hiprg-request@irtf.org <mailto:hiprg-request@irtf.org>>
>
>     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
>     hiprg@irtf.org <mailto:hiprg@irtf.org>
>
>     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
>     hiprg-request@irtf.org <mailto:hiprg-request@irtf.org>
>
>     You can reach the person managing the list at
>     hiprg-owner@irtf.org <mailto:hiprg-owner@irtf.org>
>
>     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 <gurtov@cs.helsinki.fi
>     <mailto:gurtov@cs.helsinki.fi>>
>     To: "hiprg@irtf.org <mailto:hiprg@irtf.org>" <hiprg@irtf.org
>     <mailto:hiprg@irtf.org>>
>     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 <rgm@htt-consult.com
>     <mailto:rgm@htt-consult.com>>
>     To: Andrei Gurtov <gurtov@cs.helsinki.fi
>     <mailto:gurtov@cs.helsinki.fi>>
>     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
>         hiprg@irtf.org <mailto:hiprg@irtf.org>
>         https://www.irtf.org/mailman/listinfo/hiprg
>
>
>
>
>     ---------- Mensaje reenviado ----------
>     From: Robert Moskowitz <rgm@htt-consult.com
>     <mailto:rgm@htt-consult.com>>
>     To: hiprg@irtf.org <mailto:hiprg@irtf.org>
>     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
>     hiprg@irtf.org <mailto:hiprg@irtf.org>
>     https://www.irtf.org/mailman/listinfo/hiprg
>
>
>
> _______________________________________________
> hiprg mailing list
> hiprg@irtf.org
> https://www.irtf.org/mailman/listinfo/hiprg