From gurtov@cs.helsinki.fi Fri Feb 4 00:02:55 2011 Return-Path: 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 072323A6902 for ; Fri, 4 Feb 2011 00:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 mAQIXLggl9Is for ; Fri, 4 Feb 2011 00:02:54 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id E75633A6889 for ; Fri, 4 Feb 2011 00:02:53 -0800 (PST) Received: from [62.237.154.40] (unknown [62.237.154.40]) by argo.otaverkko.fi (Postfix) with ESMTP id 06FB825ED17 for ; Fri, 4 Feb 2011 10:06:17 +0200 (EET) Message-ID: <4D4BB378.2010601@cs.helsinki.fi> Date: Fri, 04 Feb 2011 10:06:16 +0200 From: Andrei Gurtov User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "hiprg@irtf.org" X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [hiprg] hip-rg-dex-04 X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 08:02:55 -0000 -----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----- From rgm@htt-consult.com Fri Feb 4 07:21:39 2011 Return-Path: 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 9D4DA3A6980 for ; Fri, 4 Feb 2011 07:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 sldR3qEW-u0V for ; Fri, 4 Feb 2011 07:21:38 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 79B2E3A69A6 for ; Fri, 4 Feb 2011 07:21:38 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 53B6962A94; Fri, 4 Feb 2011 15:24:37 +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 7FDMj7lxddOm; Fri, 4 Feb 2011 10:24:27 -0500 (EST) Received: from nc2400.htt-consult.com (sd44007fb.adsl.wanadoo.nl [212.64.7.251]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id CA09162BF0; Fri, 4 Feb 2011 10:24:19 -0500 (EST) Message-ID: <4D4C1A21.3080503@htt-consult.com> Date: Fri, 04 Feb 2011 16:24:17 +0100 From: Robert Moskowitz 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: Andrei Gurtov References: <4D4BB378.2010601@cs.helsinki.fi> In-Reply-To: <4D4BB378.2010601@cs.helsinki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "hiprg@irtf.org" Subject: Re: [hiprg] hip-rg-dex-04 X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 15:21:39 -0000 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 > From rgm@htt-consult.com Fri Feb 4 07:23:23 2011 Return-Path: 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 C3EA53A699C for ; Fri, 4 Feb 2011 07:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 lPpV+S1u5yrH for ; Fri, 4 Feb 2011 07:23:22 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 2B91A3A6997 for ; Fri, 4 Feb 2011 07:23:22 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 49A0562A94; Fri, 4 Feb 2011 15:26:26 +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 YW8aNVqPTwjC; Fri, 4 Feb 2011 10:26:15 -0500 (EST) Received: from nc2400.htt-consult.com (sd44007fb.adsl.wanadoo.nl [212.64.7.251]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 7A2BE62B7F; Fri, 4 Feb 2011 10:26:14 -0500 (EST) Message-ID: <4D4C1A94.3010908@htt-consult.com> Date: Fri, 04 Feb 2011 16:26:12 +0100 From: Robert Moskowitz 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: hiprg@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: juho.vaha-herttua@tkk.fi Subject: [hiprg] Fwd: About the HIP DEX draft (draft-moskowitz-hip-rg-dex-04) X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 15:23:23 -0000 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. From juho.vaha-herttua@tkk.fi Sat Feb 5 14:10:33 2011 Return-Path: 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 BCA693A6A65 for ; Sat, 5 Feb 2011 14:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.119 X-Spam-Level: ** X-Spam-Status: No, score=2.119 tagged_above=-999 required=5 tests=[MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.819] 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 DLFC1R135NCm for ; Sat, 5 Feb 2011 14:10:33 -0800 (PST) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by core3.amsl.com (Postfix) with ESMTP id C46713A696F for ; Sat, 5 Feb 2011 14:10:28 -0800 (PST) Received: from smtp.vaha-herttua.fi (88.192.254.58) by kirsi2.inet.fi (8.5.133) id 4D073504029A7BBE; Sun, 6 Feb 2011 00:10:23 +0200 Received: from [85.78.163.28] (GZYKMMMCMXXVIII.gprs.sl-laajakaista.fi [85.78.163.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.vaha-herttua.fi (Postfix) with ESMTPSA id D04051FD01; Sun, 6 Feb 2011 00:10:53 +0200 (EET) References: <15612_1296833191_ZZ0LG300AOYMW5I9.00_4D4C1A94.3010908@htt-consult.com> In-Reply-To: <15612_1296833191_ZZ0LG300AOYMW5I9.00_4D4C1A94.3010908@htt-consult.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Date: Sun, 6 Feb 2011 00:10:12 +0200 To: Robert Moskowitz X-Mailman-Approved-At: Sun, 06 Feb 2011 05:41:23 -0800 Cc: "hiprg@irtf.org" Subject: Re: [hiprg] About the HIP DEX draft (draft-moskowitz-hip-rg-dex-04) X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 08:05:02 -0000 On 4.2.2011, at 17.26, Robert Moskowitz wrote: > Section 5.1: > "For the BEX parameters, DIFFIE_HELMAN, DH_GROUP_LIST, and HOST_ID, only > the ECC values are valid in DEX." >=20 > Suggestion: > "For the BEX parameters, DIFFIE_HELLMAN, DH_GROUP_LIST, and HOST_ID, > only the ECC values are valid in DEX." Correction to this, the suggestion should be: "For the BEX parameters, DH_GROUP_LIST, and HOST_ID, only the ECC values are= valid in DEX." I suppose the DIFFIE_HELLMAN was supposed to be removed earlier together wit= h the parameter, but it was missed because of the typo. Any comments and corrections to my misunderstandings are welcome. Please kee= p me in cc since I'm not on the list. Juho From rodolfo.gallardo@gmail.com Mon Feb 7 07:28:42 2011 Return-Path: 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 ; 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 ; 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 ; Mon, 7 Feb 2011 07:28:38 -0800 (PST) Received: by wwi17 with SMTP id 17so3008092wwi.1 for ; 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 Date: Mon, 7 Feb 2011 10:28:22 -0500 Message-ID: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:28:42 -0000 --20cf30025cc2077e7d049bb2e3c9 Content-Type: text/plain; charset=ISO-8859-1 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 > 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 > To: "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 > To: Andrei Gurtov > 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 > 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 > > --20cf30025cc2077e7d049bb2e3c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I am studying HIP DEX, i would like to help implementing it, the= re is a source code or any implementation available?

Regards

=
2011/2/4 <hiprg-request@irtf.org>
If you have recei= ved this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

h= ttps://www.irtf.org/mailman/listinfo/hiprg

Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
MIME or Plain Text Digests?" to MIME. =A0You can set this option
globally for all the list digests you receive at this point.



Send hiprg mailing list submissions to
=A0 =A0 =A0 =A0hiprg@irtf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0https://www.irtf.org/mailman/listinfo/hiprg
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0hiprg-request@irt= f.org

You can reach the person managing the list at
=A0 =A0 =A0 =A0hiprg-owner@irtf.or= g

When replying, please edit your Subject line so it is more specific
than "Re: Contents of hiprg digest..."

Today's Topics:

=A0 1. hip-rg-dex-04 (Andrei Gurtov)
=A0 2. Re: hip-rg-dex-04 (Robert Moskowitz)
=A0 3. Fwd: About the HIP DEX draft (draft-moskowitz-hip-rg-dex-04)
=A0 =A0 =A0(Robert Moskowitz)


---------- Mensaje reenviado ----------
From:=A0Andrei Gurtov &l= t;gurtov@cs.helsinki.fi>To:=A0"hiprg@irtf.org" <= ;hiprg@irtf.org>
Date:=A0Fri, 04 Feb 2011 10:06:16 +0200
Subject:=A0[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<= br> 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
=3DoGNv
-----END PGP SIGNATURE-----



---------- Mensaje reenviado ----------
From:=A0Robert Moskowitz= <rgm@htt-consult.com>
= To:=A0Andrei Gurtov <gurtov@cs.= helsinki.fi>
Date:=A0Fri, 04 Feb 2011 16:24:17 +0100
Subject:=A0Re: [hiprg] hip-rg-de= x-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<= br> 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
=3DoGNv
-----END PGP SIGNATURE-----
_______________________________________________
hiprg mailing list
hiprg@irtf.org
h= ttps://www.irtf.org/mailman/listinfo/hiprg




---------- Mensaje reenviado ----------
From:=A0Robert Moskowitz= <rgm@htt-consult.com>
= To:=A0hiprg@irtf.org
Date:=A0Fri, = 04 Feb 2011 16:26:12 +0100
Subject:=A0[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 =A0is requesting. Now, which one of the HOST_IDs will be used for the HIT =A0generation? How can the initiator confirm that HOST_ID matches the HIT =A0it 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<= br> 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 =A0it 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
=A0IV? I know it's good to give some freedom to the implementor, but since =A0the 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 =A0leads me to think that PKCS5 is somehow defined by AES. In fact it
seems =A0to be defined by the HIP DEX draft, and it should be explicitly said so =A0to avoid confusion. The same sentence says "may specify pad= ding
bytes =A0other than zero", but the padding in itself is not defined as=
zero, so =A0that sentence sounds confusing. I know the padding is defined as zero in =A0RFC5201 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 "extr= a
padding added to the set of parameters to satisfy the cipher block
alignment rules is not counted in HIP TLV length fields" and "If<= br> 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 paddin= g
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 ciphe= r
=A0internals.


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 generi= c
=A0and free for the implementor to decide. However, personally I would
make =A0the 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
=A0layer addresses) are not used in the generation of I, it results in a =A0situation where an attacker can solve the puzzle once and start a DDoS =A0attack 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 =A0method presented in Appendix A to generate the puzzle might have some =A0serious 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 =A0packet is not protected by the CMAC? Does HIP DEX assume that client
has =A0received 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 pack= et
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, &quo= t;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 &q= uot;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, on= ly
=A0the 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
h= ttps://www.irtf.org/mailman/listinfo/hiprg


--20cf30025cc2077e7d049bb2e3c9-- From thomas.r.henderson@boeing.com Mon Feb 7 23:18:40 2011 Return-Path: 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 7C6A33A6AE3 for ; Mon, 7 Feb 2011 23:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ZUgz+MfPqwTv for ; Mon, 7 Feb 2011 23:18:39 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id B83523A67B6 for ; Mon, 7 Feb 2011 23:18:37 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p187IYrN018382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 01:18:34 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p187IYxd024409; Tue, 8 Feb 2011 01:18:34 -0600 (CST) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p187IXlb024403 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 8 Feb 2011 01:18:34 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Mon, 7 Feb 2011 23:18:33 -0800 From: "Henderson, Thomas R" To: "'Rodolfo Gallardo'" Date: Mon, 7 Feb 2011 23:18:33 -0800 Thread-Topic: [hiprg] Implementing DEX Thread-Index: AcvG27s+Zi7e04FPRNqXH7q+wyl8VwAhGB2w Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25AE05@XCH-NW-10V.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.500.1024-17942.005 x-tm-as-result: No--50.154600-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 07:18:40 -0000 > From: hiprg-bounces@irtf.org [mailto:hiprg-bounces@irtf.org] On Behalf Of= Rodolfo Gallardo > Sent: Monday, February 07, 2011 7:28 AM > To: hiprg@irtf.org > Subject: Re: [hiprg] Implementing DEX >=20 > Hi, >=20 > I am studying HIP DEX, i would like to help implementing it, there is a s= ource code or any=20 > implementation available? >=20 > Regards >=20 Rodolfo, Please see the post from Andrei Gurtov on February 4, in which he mentioned= implementation plans. - Tom From thomas.r.henderson@boeing.com Mon Feb 7 23:25:25 2011 Return-Path: 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 8CFDC3A6AE3 for ; Mon, 7 Feb 2011 23:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 P7gZeSyo9pFC for ; Mon, 7 Feb 2011 23:25:24 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 7B7113A67B6 for ; Mon, 7 Feb 2011 23:25:24 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p187PKEd019321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Feb 2011 01:25:21 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p187PJvj026122; Mon, 7 Feb 2011 23:25:19 -0800 (PST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p187PI1b026113 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 7 Feb 2011 23:25:19 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Mon, 7 Feb 2011 23:25:18 -0800 From: "Henderson, Thomas R" To: "hiprg@irtf.org" Date: Mon, 7 Feb 2011 23:25:17 -0800 Thread-Topic: document actions, and meeting in Prague Thread-Index: AcvHYVXmbCWrRYovRwu8Vu9Zo0UE8g== Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25AE06@XCH-NW-10V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.500.1024-17942.003 x-tm-as-result: No--56.512200-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hiprg] document actions, and meeting in Prague X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 07:25:25 -0000 Hi all, I am planning to request a HIP research group meeting for Prague. Please l= et us know about your slot requests and plans for this meeting. We would like to take the following actions on our research group documents= : 1) draft-irtf-hiprg-dht-02.txt (HIP DHT interface) has been in a stable sta= te since last fall's RG last call for comments, so we will start the IRSG r= eview process on it. 2) draft-irtf-hip-experiment-10.txt (HIP Experiment Report) was recently re= vised, thanks to additional comments from Miika Komu. We'd like to call fo= r any final comments over the next two weeks, and then move to also start t= he IRSG review process on it. 3) we have three other research group drafts - draft-irtf-hiprg-revocation-01.txt (Host Identifier Revocation) - draft-irtf-hiprg-proxies-01.txt (Investigation in HIP Proxies) - draft-irtf-hiprg-rfid-01.txt (HIP Support for RFID) I would like to encourage spending time before Prague to try to discuss the= se drafts on the list and determine what additional work may be needed to c= omplete the research group work on them, so that we can plan to discuss rem= aining open issues at the Prague meeting. Additionally, I would like to remind that we have a few more drafts that ha= ve seen publication since the beginning of November: - draft-yuan-hiprg-failure-detection-recovery-01.txt (HIP-based Failure Det= ection...) - draft-zhang-hip-privacy-protection-02.txt (Identity Privacy) - draft-pellikka-hiprg-certreq-00.txt (HIP Certificate Requests) - draft-moskowitz-hip-rg-dex-04.txt (HIP Diet Exchange) - Tom From rgm@htt-consult.com Mon Feb 7 23:26:23 2011 Return-Path: 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 ; 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 ; 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 ; 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 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 References: In-Reply-To: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 07:26:24 -0000 This is a multi-part message in MIME format. --------------010104030209020902080808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 > > > 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 > > To: "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 > > To: Andrei Gurtov > > 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 > > 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 > > > > _______________________________________________ > hiprg mailing list > hiprg@irtf.org > https://www.irtf.org/mailman/listinfo/hiprg --------------010104030209020902080808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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>
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



_______________________________________________
hiprg mailing list
hiprg@irtf.org
https://www.irtf.org/mailman/listinfo/hiprg
--------------010104030209020902080808-- From rgm@htt-consult.com Wed Feb 9 14:13:36 2011 Return-Path: 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 842423A6826 for ; Wed, 9 Feb 2011 14:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 TKIhKfsl8Wr3 for ; Wed, 9 Feb 2011 14:13:35 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 919CA3A67F6 for ; Wed, 9 Feb 2011 14:13:35 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 6EFDB62ABF for ; Wed, 9 Feb 2011 22:13:24 +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 FAA3hRiRx8+b for ; Wed, 9 Feb 2011 17:13:14 -0500 (EST) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 530B762AB9 for ; Wed, 9 Feb 2011 17:13:14 -0500 (EST) Message-ID: <4D531179.1030404@htt-consult.com> Date: Wed, 09 Feb 2011 17:13:13 -0500 From: Robert Moskowitz 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: "hiprg@irtf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [hiprg] A more byte efficient ESP suite X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 22:13:36 -0000 I have been pushed by a number of engineers working in resource constrained networks to 'fix' the ESP per IP packet overhead. Many just want to use dTLS, as (in theory) it could be spaning multiple IP datagrams (though I wonder if that is frequently true in these use scenarios). So please help me with my analysis: ESP takes at most 12 bytes: 4 SPI 4 Seq# 4 padding (though I would really like to get a better understanding of padding overhead) CCM (the primary candidate) takes: 8 IV 8-16 ICV So ESP-CCM is 28-36 bytes. But if your IV for CCM is a counter, and not a LFSR, and you use the ESP ESN, you 'compress' out the 8 byte IV from CCM for 20-28 bytes. Now note that when we were first doing CCM for ESP, I proposed this and actually did a rough draft, but Steve Kent insisted that LFSR be supported as well and that the IV always be explicit, giving us the CCM cipher for ESP we have today. 8 bytes IS a big deal to constrained networks (10% of the datapayload on 802.15.4). Has there been any discussions anywhere on this sort of optimization? From thomas.r.henderson@boeing.com Tue Feb 15 20:46:53 2011 Return-Path: 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 0EABF3A6B8E for ; Tue, 15 Feb 2011 20:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 VBvhpvUmboNX for ; Tue, 15 Feb 2011 20:46:51 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id C74163A6A86 for ; Tue, 15 Feb 2011 20:46:51 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1G4lBSX017894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 15 Feb 2011 22:47:16 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1G4lB74012396 for ; Tue, 15 Feb 2011 22:47:11 -0600 (CST) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1G4lARw012390 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Tue, 15 Feb 2011 22:47:10 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Tue, 15 Feb 2011 20:47:10 -0800 From: "Henderson, Thomas R" To: "hiprg@irtf.org" Date: Tue, 15 Feb 2011 20:47:08 -0800 Thread-Topic: clarification of identity privacy properties of HIP base exchange Thread-Index: AcvNlJCBUejaJYxoSfSJxdGfYgk4wA== Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25AE6E@XCH-NW-10V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hiprg] clarification of identity privacy properties of HIP base exchange X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 04:46:53 -0000 There is a paragraph in the HIP experiment report, Section 8: http://tools.ietf.org/html/draft-irtf-hip-experiment-10 for which I am wondering whether it is completely correct. All two-round-trip variations of the Diffie Hellman key exchange using public keys for authentication are vulnerable to identity theft. The Responder must not generate the shared session key before receiving two messages from the Initiator, to avoid DoS attacks. If the Responder sends its public key in the first reply message (R1) to the Initiator, the Responder's identity will be revealed to third parties. The Initiator cannot determine the identity of the Responder until after receiving the last message (R2) of the key exchange. As a result, an active attacker can find out the public key and identity of the Initiator by pretending to be a trusted correspondent host. The Initiator's public key is sent encrypted in the third message of the Diffie Hellman key exchange and can be decrypted by an attacker based on the established session key. Some questions: 1) (fourth sentence) The R1 sends HOST_ID and is signed, so can't the Initi= ator learn the identity in the first reply message? Or is this referring t= o possible R1 replay by an adversary? 2) (fifth and sixth sentence) In what situations can an active attacker lea= rn the key and identity of the Initiator (if the Initiator chooses to encry= pt HOST_ID)? Opportunistic mode may be one, but are there others? Tom From thomas.r.henderson@boeing.com Tue Feb 15 21:28:46 2011 Return-Path: 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 DC18C3A6D56 for ; Tue, 15 Feb 2011 21:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 eWJ3QN-Li47L for ; Tue, 15 Feb 2011 21:28:44 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 2B36A3A6D3F for ; Tue, 15 Feb 2011 21:28:44 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1G5TAX1023798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 15 Feb 2011 23:29:11 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1G5TAuq018488 for ; Tue, 15 Feb 2011 21:29:10 -0800 (PST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1G5T9a3018482 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Tue, 15 Feb 2011 21:29:10 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Tue, 15 Feb 2011 21:29:09 -0800 From: "Henderson, Thomas R" To: "hiprg@irtf.org" Date: Tue, 15 Feb 2011 21:29:08 -0800 Thread-Topic: document actions, and meeting in Prague Thread-Index: AcvHYVXmbCWrRYovRwu8Vu9Zo0UE8gGN72Uw Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25AE70@XCH-NW-10V.nw.nos.boeing.com> References: <7CC566635CFE364D87DC5803D4712A6C4CED25AE06@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CED25AE06@XCH-NW-10V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hiprg] document actions, and meeting in Prague X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 05:28:46 -0000 > -----Original Message----- > From: hiprg-bounces@irtf.org [mailto:hiprg-bounces@irtf.org] On Behalf > Of Henderson, Thomas R > Sent: Monday, February 07, 2011 11:25 PM > To: hiprg@irtf.org > Subject: [hiprg] document actions, and meeting in Prague >=20 > Hi all, >=20 > I am planning to request a HIP research group meeting for Prague. > Please let us know about your slot requests and plans for this meeting. >=20 > We would like to take the following actions on our research group > documents: >=20 > 1) draft-irtf-hiprg-dht-02.txt (HIP DHT interface) has been in a stable > state since last fall's RG last call for comments, so we will start the > IRSG review process on it. >=20 As part of this process: http://trac.tools.ietf.org/group/irtf/trac/wiki/IRTF-RFCs#ResearchGroupPrep= aration we have to clarify the level of support for this draft from the RG, and als= o note the breadth of review of the document. I propose to state that "The= HIP research group reached consensus that this interface specification sho= uld be published as an experimental RFC, based on document review by at lea= st six RG members including the chairs, and based on implementation experie= nce." Please let me know if there are any concerns with this statement. I will t= ake care to address the other bullet points and provide Jeff with the neces= sary changes to publish as version -03 before we submit it to IRSG review. - Tom From gurtov@hiit.fi Wed Feb 16 00:23:05 2011 Return-Path: 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 99CE93A6C6A for ; Wed, 16 Feb 2011 00:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 TsfbkTI98JAH for ; Wed, 16 Feb 2011 00:23:04 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 2AFAF3A68A3 for ; Wed, 16 Feb 2011 00:23:03 -0800 (PST) Received: from [10.20.208.12] (gw1.panoulu.net [212.50.147.101]) by argo.otaverkko.fi (Postfix) with ESMTP id D9F7425ED06; Wed, 16 Feb 2011 10:23:29 +0200 (EET) Message-ID: <4D5B8982.6040306@hiit.fi> Date: Wed, 16 Feb 2011 10:23:30 +0200 From: Andrei Gurtov User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Henderson, Thomas R" References: <7CC566635CFE364D87DC5803D4712A6C4CED25AE6E@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CED25AE6E@XCH-NW-10V.nw.nos.boeing.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "hiprg@irtf.org" Subject: Re: [hiprg] clarification of identity privacy properties of HIP base exchange X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 08:23:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Henderson, Thomas R wrote: > There is a paragraph in the HIP experiment report, Section 8: > http://tools.ietf.org/html/draft-irtf-hip-experiment-10 > for which I am wondering whether it is completely correct. > > > All two-round-trip variations of the Diffie Hellman key exchange > using public keys for authentication are vulnerable to identity > theft. The Responder must not generate the shared session key before > receiving two messages from the Initiator, to avoid DoS attacks. If > the Responder sends its public key in the first reply message (R1) to > the Initiator, the Responder's identity will be revealed to third > parties. The Initiator cannot determine the identity of the > Responder until after receiving the last message (R2) of the key > exchange. As a result, an active attacker can find out the public > key and identity of the Initiator by pretending to be a trusted > correspondent host. The Initiator's public key is sent encrypted in > the third message of the Diffie Hellman key exchange and can be > decrypted by an attacker based on the established session key. > > Some questions: > 1) (fourth sentence) The R1 sends HOST_ID and is signed, so can't the Initiator learn the identity in the first reply message? Or is this referring to possible R1 replay by an adversary? - From the content of R1 packet it indeed looks like Initiator can identify the Responder based on the public key. Replays are a possibility, but still the attacker wouldn't be able to alter the packet or misuse the responder's identity, just resend the same packet. A related question is how R1s can be pre-generated (I think RFC5201 refers to this possibility). R1 includes at least the destination HIT so how the signature can be constructed in advance? Also the puzzle can have expiration lifetime. > 2) (fifth and sixth sentence) In what situations can an active attacker learn the key and identity of the Initiator (if the Initiator chooses to encrypt HOST_ID)? Opportunistic mode may be one, but are there others? I guess in any case when the public key of the recipient is not authenticated (e.g. by DNSSEC) and when the initiator attempts connecting without taking the ID of Responder from a trusted source. (e.g. someone storing own public key in DHT under domain name google.com) Andrei -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1biYIACgkQP7jp0uceFkTznwCg1dshsXsepBvi3skKwzOfcxm+ Pv4AoL0hb12mgvYcZQ5hu8w6wcYPOfD4 =djBX -----END PGP SIGNATURE----- From heer@informatik.rwth-aachen.de Wed Feb 16 00:51:08 2011 Return-Path: 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 7F7623A6ABA for ; Wed, 16 Feb 2011 00:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] 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 2b+2yPAVj2DJ for ; Wed, 16 Feb 2011 00:51:07 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 160923A6B5F for ; Wed, 16 Feb 2011 00:51:06 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LGP00MFXCLXTJ10@mta-1.ms.rz.RWTH-Aachen.de> for hiprg@irtf.org; Wed, 16 Feb 2011 09:51:33 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,479,1291590000"; d="scan'208";a="49070337" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Wed, 16 Feb 2011 09:51:34 +0100 Received: from umic-i4-137-226-45-197.nn.rwth-aachen.de ([unknown] [137.226.45.197]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LGP008JQCLX7N20@relay-auth-1.ms.rz.rwth-aachen.de> for hiprg@irtf.org; Wed, 16 Feb 2011 09:51:33 +0100 (CET) From: Tobias Heer In-reply-to: <4D5B8982.6040306@hiit.fi> Date: Wed, 16 Feb 2011 09:51:29 +0100 Message-id: References: <7CC566635CFE364D87DC5803D4712A6C4CED25AE6E@XCH-NW-10V.nw.nos.boeing.com> <4D5B8982.6040306@hiit.fi> To: hiprg@irtf.org X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Subject: Re: [hiprg] clarification of identity privacy properties of HIP base exchange X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 08:51:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Am 16.02.2011 um 09:23 schrieb Andrei Gurtov: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Henderson, Thomas R wrote: >> There is a paragraph in the HIP experiment report, Section 8: >> http://tools.ietf.org/html/draft-irtf-hip-experiment-10 >> for which I am wondering whether it is completely correct. >> >> >> All two-round-trip variations of the Diffie Hellman key exchange >> using public keys for authentication are vulnerable to identity >> theft. The Responder must not generate the shared session key before >> receiving two messages from the Initiator, to avoid DoS attacks. If >> the Responder sends its public key in the first reply message (R1) to >> the Initiator, the Responder's identity will be revealed to third >> parties. The Initiator cannot determine the identity of the >> Responder until after receiving the last message (R2) of the key >> exchange. As a result, an active attacker can find out the public >> key and identity of the Initiator by pretending to be a trusted >> correspondent host. The Initiator's public key is sent encrypted in >> the third message of the Diffie Hellman key exchange and can be >> decrypted by an attacker based on the established session key. >> >> Some questions: >> 1) (fourth sentence) The R1 sends HOST_ID and is signed, so can't the Initiator learn the identity in the first reply message? Or is this referring to possible R1 replay by an adversary? > > - From the content of R1 packet it indeed looks like Initiator can > identify the Responder based on the public key. Replays are a > possibility, but still the attacker wouldn't be able to alter the packet > or misuse the responder's identity, just resend the same packet. > For what I can say, the Responder cannot stay anonymous during the exchange. This is mentioned in RFC5201 and there is text on policies: some hosts may not act as responders because of this issue. RFC5201 says, that the BEX can be reversed. The Responder would become the Initiator then -- with a possible deadlock situation of both hosts would implement that policy. > A related question is how R1s can be pre-generated (I think RFC5201 > refers to this possibility). R1 includes at least the destination HIT so > how the signature can be constructed in advance? Also the puzzle can > have expiration lifetime. There is SIGNATURE_2 the HITs as well as Puzzle I and K are excluded from the signature. I quote: "Within the R1 packet that contains the HIP_SIGNATURE_2 parameter, the Initiator's HIT, the checksum field, and the Opaque and Random #I fields in the PUZZLE parameter MUST be set to zero while computing the HIP_SIGNATURE_2 signature." > >> 2) (fifth and sixth sentence) In what situations can an active attacker learn the key and identity of the Initiator (if the Initiator chooses to encrypt HOST_ID)? Opportunistic mode may be one, but are there others? > > I guess in any case when the public key of the recipient is not > authenticated (e.g. by DNSSEC) and when the initiator attempts > connecting without taking the ID of Responder from a trusted source. > (e.g. someone storing own public key in DHT under domain name google.com) > The anonymous bit and the concept of pseudonym HIs is useful here. If these are not used, the Initiator authenticates to the public key/ host identity of the host, and thus, knows the HI. An interesting question is what the "identity" of the Initiator is. Is it its real-word identity? You need more information to figure this out? Is it the HOST identity? This one is revealed without pseudonyms. BR, Tobias -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) iEYEARECAAYFAk1bkBgACgkQf4eSaa7spb8DegCfWV6bCoDfVyj9bPauPBEaXpWV dj0AoKAFLezZHvHxmcbiC/444GV8oBeV =1mX5 -----END PGP SIGNATURE----- From heer@informatik.rwth-aachen.de Wed Feb 16 00:59:51 2011 Return-Path: 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 EAC863A6ABA for ; Wed, 16 Feb 2011 00:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] 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 rXscfrcPvi3X for ; Wed, 16 Feb 2011 00:59:50 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 9072B3A6DE4 for ; Wed, 16 Feb 2011 00:59:50 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LGP00MO5D0ITF10@mta-1.ms.rz.RWTH-Aachen.de> for hiprg@irtf.org; Wed, 16 Feb 2011 10:00:18 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,479,1291590000"; d="scan'208";a="94630478" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 16 Feb 2011 10:00:18 +0100 Received: from umic-i4-137-226-45-197.nn.rwth-aachen.de ([unknown] [137.226.45.197]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LGP008Q5D0H7N20@relay-auth-1.ms.rz.rwth-aachen.de> for hiprg@irtf.org; Wed, 16 Feb 2011 10:00:17 +0100 (CET) From: Tobias Heer In-reply-to: Date: Wed, 16 Feb 2011 10:00:20 +0100 Message-id: <8E135455-32E3-4425-BF6D-09F4010F29DE@cs.rwth-aachen.de> References: <7CC566635CFE364D87DC5803D4712A6C4CED25AE6E@XCH-NW-10V.nw.nos.boeing.com> <4D5B8982.6040306@hiit.fi> To: hiprg@irtf.org X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Subject: Re: [hiprg] clarification of identity privacy properties of HIP base exchange X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 08:59:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There was a fatal flaw in my punctiation.... Am 16.02.2011 um 09:51 schrieb Tobias Heer: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > >> >>> 2) (fifth and sixth sentence) In what situations can an active attacker learn the key and identity of the Initiator (if the Initiator chooses to encrypt HOST_ID)? Opportunistic mode may be one, but are there others? >> >> I guess in any case when the public key of the recipient is not >> authenticated (e.g. by DNSSEC) and when the initiator attempts >> connecting without taking the ID of Responder from a trusted source. >> (e.g. someone storing own public key in DHT under domain name google.com) >> > The anonymous bit and the concept of pseudonym HIs is useful here. If these are not used, the Initiator authenticates to the public key/ host identity of the host, and thus, knows the HI. > An interesting question is what the "identity" of the Initiator is. > Is it its real-word identity? You need more information to figure this out? This questionmark should certainly be a fullstop. The meanong of the sentence is: > Is it its real-word identity? You need more information to figure this out. I meant that one needs some separate register or some knowledge from previous communication for mapping a HI to an identity. Sorry for any confusion. Tobias - -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://www.comsys.rwth-aachen.de/team/tobias-heer/ blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) iEYEARECAAYFAk1bkiQACgkQf4eSaa7spb92NQCeI8R3mYdpSX0wCwHORViR95vC sywAn1Zzs2cv3PM4wXNsO5G2SLQq73Tp =Af+W -----END PGP SIGNATURE----- From thomas.r.henderson@boeing.com Thu Feb 17 18:20:04 2011 Return-Path: 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 4ED3F3A6DE4 for ; Thu, 17 Feb 2011 18:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 xRJEVLCAvvGa for ; Thu, 17 Feb 2011 18:20:01 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 3D9F33A6D23 for ; Thu, 17 Feb 2011 18:19:58 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1I2KMxL016182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Feb 2011 18:20:23 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1I2KLfq024624; Thu, 17 Feb 2011 20:20:21 -0600 (CST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1I2KJ6l024618 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 17 Feb 2011 20:20:20 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Thu, 17 Feb 2011 18:20:19 -0800 From: "Henderson, Thomas R" To: "'Tobias Heer'" , "hiprg@irtf.org" Date: Thu, 17 Feb 2011 18:20:18 -0800 Thread-Topic: [hiprg] clarification of identity privacy properties of HIPbase exchange Thread-Index: AcvNuF4EAe2/CtLRRWiSlW3rIYyXZwBWVqzw Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25AE86@XCH-NW-10V.nw.nos.boeing.com> References: <7CC566635CFE364D87DC5803D4712A6C4CED25AE6E@XCH-NW-10V.nw.nos.bo eing.com><4D5B8982.6040306@hiit.fi> <8E135455-32E3-4425-BF6D-09F4010F29DE@cs.rwth-aachen.de> In-Reply-To: <8E135455-32E3-4425-BF6D-09F4010F29DE@cs.rwth-aachen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hiprg] clarification of identity privacy properties of HIPbase exchange X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 02:20:05 -0000 Thanks for the attempted clarifications, but I am not sure that these types= of attacks (binding between a host name and HI, as Andrei suggested, or di= fferent concepts of identity) are what is being referred to in this paragra= ph. Does anyone have a reference to substantiate this statement?: > > All two-round-trip variations of the Diffie Hellman key exchange > using public keys for authentication are vulnerable to identity > theft. =20 If I understood more clearly the general attacks being referred to here, I = could try to relate that to the existing base exchange and better describe = the vulnerabilities. =20 - Tom From thomas.r.henderson@boeing.com Fri Feb 25 14:32:15 2011 Return-Path: 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 EE64F3A683F for ; Fri, 25 Feb 2011 14:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 3Nlrx4i5o5sA for ; Fri, 25 Feb 2011 14:32:14 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id EF8413A6A65 for ; Fri, 25 Feb 2011 14:32:13 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1PMWpxo007435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Feb 2011 14:32:51 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1PMWpb7005533; Fri, 25 Feb 2011 14:32:51 -0800 (PST) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1PMWoOC005510 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 25 Feb 2011 14:32:51 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Fri, 25 Feb 2011 14:32:50 -0800 From: "Henderson, Thomas R" To: "hiprg@irtf.org" Date: Fri, 25 Feb 2011 14:32:49 -0800 Thread-Topic: HIPRG - Requested session has been scheduled for IETF 80 Thread-Index: AcvUdFFCQZn63EKVSzCr8/qdGl6T/wAxugNA Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25AEEE@XCH-NW-10V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [hiprg] HIPRG - Requested session has been scheduled for IETF 80 X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 22:32:15 -0000 RllJLCB3ZSBjdXJyZW50bHkgaGF2ZSBhIFJHIHNsb3Qgc2NoZWR1bGVkIGFzIGZvbGxvd3M6DQoN CkhJUFJHIFNlc3Npb24gMSAoMiBob3VycykNClR1ZXNkYXksIEFmdGVybm9vbiBTZXNzaW9uIEkg MTMwMC0xNTAwDQpSb29tIE5hbWU6IEthcmxpbiBJDQoNClRoZSBISVAgd29ya2luZyBncm91cCBp cyBzY2hlZHVsZWQgZm9yIFRodXJzZGF5IGFmdGVybm9vbi4gIFNvbWUgbWVldGluZyB0aW1lcyBt YXkgbW92ZSBhcm91bmQgaW4gdGhlIG5leHQgd2VlayBvciBzbyAoZmluYWwgYWdlbmRhIHNob3Vs ZCBiZSBwb3N0ZWQgaW4gYSB3ZWVrKSBidXQgSSBkb24ndCBwbGFuIHRvIHJlcXVlc3QgYSBjaGFu Z2UuICBQbGVhc2Ugc2VuZCBtZSBhbnkgc2xvdCByZXF1ZXN0cyB0aGF0IHlvdSBtYXkgaGF2ZSwg aWYgeW91IGhhdmVuJ3QgZG9uZSBzbyBhbHJlYWR5Lg0KDQotIFRvbQ0K From rgm@htt-consult.com Sat Feb 26 19:52:39 2011 Return-Path: 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 DC5283A69AB for ; Sat, 26 Feb 2011 19:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 kuUCd7ZhKqgK for ; Sat, 26 Feb 2011 19:52:38 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 0525E3A69AA for ; Sat, 26 Feb 2011 19:52:38 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 1BE4A62BA8 for ; Sun, 27 Feb 2011 03:53:08 +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 GQ8FWkwzxEDs for ; Sat, 26 Feb 2011 22:52:39 -0500 (EST) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 1AC4762A79 for ; Sat, 26 Feb 2011 22:52:39 -0500 (EST) Message-ID: <4D69CA86.7030705@htt-consult.com> Date: Sat, 26 Feb 2011 22:52:38 -0500 From: Robert Moskowitz 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: "hiprg@irtf.org" References: <7CC566635CFE364D87DC5803D4712A6C4CED25AEEE@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CED25AEEE@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hiprg] HIPRG - Requested session has been scheduled for IETF 80 X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 03:52:40 -0000 On 02/25/2011 05:32 PM, Henderson, Thomas R wrote: > FYI, we currently have a RG slot scheduled as follows: > > HIPRG Session 1 (2 hours) > Tuesday, Afternoon Session I 1300-1500 > Room Name: Karlin I > > The HIP working group is scheduled for Thursday afternoon. To those here that are Europe based... What's the best way to get from Prague to Amsterdam Thursday evening? Continua is meeting there that week, and I committed to attending a session Friday morning... Is train practical or should I go plane? Respond privately. No need to fill the list. > Some meeting times may move around in the next week or so (final agenda should be posted in a week) but I don't plan to request a change. Please send me any slot requests that you may have, if you haven't done so already. > > - Tom > _______________________________________________ > hiprg mailing list > hiprg@irtf.org > https://www.irtf.org/mailman/listinfo/hiprg > From ari.keranen@nomadiclab.com Mon Feb 28 08:54:52 2011 Return-Path: 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 DF4723A6C35 for ; Mon, 28 Feb 2011 08:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 6PlP4Xzs+OJz for ; Mon, 28 Feb 2011 08:54:51 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id A08CB3A6C2E for ; Mon, 28 Feb 2011 08:54:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 3416A4E6E5; Mon, 28 Feb 2011 18:55:49 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4as+mim9oSw; Mon, 28 Feb 2011 18:55:48 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id A02DF4E6E4; Mon, 28 Feb 2011 18:55:48 +0200 (EET) From: Ari Keranen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2011 18:55:48 +0200 Message-Id: To: hiprg@irtf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [hiprg] draft-irtf-hip-experiment-10 review X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 16:54:53 -0000 Hi, I finally managed to have look at the experiment report doc. Here's some = comments and nits: 1.1. What is HIP? Could mention that Standards Track work has been started (in the end of = the section). 1.2. Scope During the timeframe of this report (2004-09),=20 s/09/2011/ 2.3.8. Interactions with host firewalls When using HIP over UDP, the host needs to open just port 10500 in practice. This seems to imply that inbound unsolicited packets to 10500 would be = needed, which is not the case as long as ICE is used (except for the HIP = relay server). I'd rather say something like "the firewall needs to = allow outbound UDP packets and responses to them". Cheers, Ari= From thomas.r.henderson@boeing.com Mon Feb 28 21:31:48 2011 Return-Path: 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 5D4CF3A6B12 for ; Mon, 28 Feb 2011 21:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.2 X-Spam-Level: X-Spam-Status: No, score=-106.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] 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 ED33DAvaNJgP for ; Mon, 28 Feb 2011 21:31:47 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 3D8A73A6A5A for ; Mon, 28 Feb 2011 21:31:47 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p215Wbem020333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Feb 2011 23:32:37 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p215Wbc7012890; Mon, 28 Feb 2011 23:32:37 -0600 (CST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p215WaOD012878 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 28 Feb 2011 23:32:36 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Mon, 28 Feb 2011 21:32:36 -0800 From: "Henderson, Thomas R" To: "'Ari Keranen'" , "hiprg@irtf.org" Date: Mon, 28 Feb 2011 21:32:34 -0800 Thread-Topic: draft-irtf-hip-experiment-10 review Thread-Index: AcvXaFzAs+hKfgHVT2qVZEy2nKWmvwAZsR1g Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25AF20@XCH-NW-10V.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hiprg] draft-irtf-hip-experiment-10 review X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 05:31:48 -0000 > -----Original Message----- > From: Ari Keranen [mailto:ari.keranen@nomadiclab.com] > Sent: Monday, February 28, 2011 8:56 AM > To: hiprg@irtf.org > Cc: Henderson, Thomas R > Subject: draft-irtf-hip-experiment-10 review >=20 > Hi, >=20 > I finally managed to have look at the experiment report doc. Here's > some comments and nits: >=20 >=20 > 1.1. What is HIP? >=20 > Could mention that Standards Track work has been started (in the end of > the section). >=20 >=20 > 1.2. Scope >=20 > During the timeframe of this report (2004-09), >=20 > s/09/2011/ >=20 >=20 > 2.3.8. Interactions with host firewalls >=20 > When using HIP over UDP, the host needs to open > just port 10500 in practice. >=20 > This seems to imply that inbound unsolicited packets to 10500 would be > needed, which is not the case as long as ICE is used (except for the > HIP relay server). I'd rather say something like "the firewall needs to > allow outbound UDP packets and responses to them". >=20 >=20 Ari, thanks for the review. The reason that the document still says 2009 i= s that it mainly stopped receiving substantial inputs since that time, so t= o avoid confusion, I propose to rephrase: "During the period of time in wh= ich the bulk of this report was drafted (2004-2009), ..." I'll make the other two changes suggested above in the next revision (-11),= and I have a few more changes to add that Miika suggested. I am waiting to receive inputs on the question I posed recently about priva= cy and identity theft vulnerability of the DH exchange, before revising tha= t section and publishing the -11 version. Yesterday I posed a question on = the crypto-forum research group list (http://www.ietf.org/mail-archive/web/= cfrg/current/msg02919.html) and I've received some feedback there. Pekka a= lso pointed me to the 2004 paper on BLIND, which I'll review again. - Tom