Re: [hiprg] Implementing DEX

Rodolfo Gallardo <rodolfo.gallardo@gmail.com> Mon, 07 February 2011 15:28 UTC

Return-Path: <rodolfo.gallardo@gmail.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 298283A6946 for <hiprg@core3.amsl.com>; Mon, 7 Feb 2011 07:28:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.739
X-Spam-Level:
X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 XzFThNE1xasF for <hiprg@core3.amsl.com>; Mon, 7 Feb 2011 07:28:39 -0800 (PST)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id EF0963A6941 for <hiprg@irtf.org>; Mon, 7 Feb 2011 07:28:38 -0800 (PST)
Received: by wwi17 with SMTP id 17so3008092wwi.1 for <hiprg@irtf.org>; Mon, 07 Feb 2011 07:28:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=HZGMqvfuJ+DVCrkb8atuBX+pdBnOXMdSCdNx5RZV5Jw=; b=XIDoCWyp6IrtvLAA/dqPppKAgpTb457aMJeKGN8MdB3Z4XbmB/8JzhhQFVqTbiFVv0 dRTcew5EhoOK/bDYx7AspuRJI0cpn0xhGwda/7k0qhmwa6AjvLGLTzqlX8zPFz/kTOL2 KoarH/4FlGjg5lD0mpdLD7JrlHIQfu68UBN/s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=RTjJe4HTpPYy863srdbv/s5VB7ojRs7OICfMGotFuI041pqghbBy6bH0si8jJ4X+Xq 6E0BvbVdZn91S629hxrLFKrCfrAG1+QmOlI9cckrBZVde06ZlFd9wU/tNA4Siv0dgzte g3VmqIWXkbedqFNQUl8OrDa2fKBHCK4aXCICI=
Received: by 10.227.164.70 with SMTP id d6mr2491090wby.167.1297092522245; Mon, 07 Feb 2011 07:28:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.227.157.131 with HTTP; Mon, 7 Feb 2011 07:28:22 -0800 (PST)
From: Rodolfo Gallardo <rodolfo.gallardo@gmail.com>
Date: Mon, 7 Feb 2011 10:28:22 -0500
Message-ID: <AANLkTi=UnBH41AW4id--3-GYQ_PpS_3HoOETOg_Zeb3i@mail.gmail.com>
To: hiprg@irtf.org
Content-Type: multipart/alternative; boundary=20cf30025cc2077e7d049bb2e3c9
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: Mon, 07 Feb 2011 15:28:42 -0000

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 <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
>
> 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
>
> You can reach the person managing the list at
>        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>
> To: "hiprg@irtf.org" <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>
> To: Andrei Gurtov <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
>> https://www.irtf.org/mailman/listinfo/hiprg
>>
>>
>
>
> ---------- Mensaje reenviado ----------
> From: Robert Moskowitz <rgm@htt-consult.com>
> To: 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
> https://www.irtf.org/mailman/listinfo/hiprg
>
>