Re: [hiprg] Implementing DEX
Miika Komu <mkomu@cs.hut.fi> Tue, 03 April 2012 15:37 UTC
Return-Path: <mkomu@cs.hut.fi>
X-Original-To: hiprg@ietfa.amsl.com
Delivered-To: hiprg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B278221F853E for <hiprg@ietfa.amsl.com>; Tue, 3 Apr 2012 08:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV5X-YqlFrQu for <hiprg@ietfa.amsl.com>; Tue, 3 Apr 2012 08:37:05 -0700 (PDT)
Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1C521F8548 for <hiprg@irtf.org>; Tue, 3 Apr 2012 08:37:04 -0700 (PDT)
Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1SF5n2-0002Sj-Eq for hiprg@irtf.org; Tue, 03 Apr 2012 18:37:00 +0300
Message-ID: <4F7B191C.6030208@cs.hut.fi>
Date: Tue, 03 Apr 2012 18:37:00 +0300
From: Miika Komu <mkomu@cs.hut.fi>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: hiprg@irtf.org
References: <AANLkTi=UnBH41AW4id--3-GYQ_PpS_3HoOETOg_Zeb3i@mail.gmail.com> <4D50EFF0.5020309@htt-consult.com> <4F7B0982.5070503@ehu.es>
In-Reply-To: <4F7B0982.5070503@ehu.es>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [hiprg] Implementing DEX
X-BeenThere: hiprg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <hiprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/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, 03 Apr 2012 15:37:06 -0000
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. >> >> 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 >> >> >> _______________________________________________ >> hiprg mailing list >> hiprg@irtf.org >> 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: +34 94 601 7396 > UPV / EHU > Plaza de la Casilla, 3 > 48012 - Bilbao (Spain) > > > > _______________________________________________ > hiprg mailing list > hiprg@irtf.org > https://www.irtf.org/mailman/listinfo/hiprg
- Re: [hiprg] Implementing DEX Rodolfo Gallardo
- Re: [hiprg] Implementing DEX Henderson, Thomas R
- Re: [hiprg] Implementing DEX Robert Moskowitz
- Re: [hiprg] Implementing DEX Nerea Toledo Gandarias
- Re: [hiprg] Implementing DEX Miika Komu