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--