headers
Robert Moskowitz | 1 Jul 2010 18:09

Fwd: New Version Notification for draft-moskowitz-hip-rfc5201-bis-02

For your reading pleasure!

-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission <at> ietf.org]
Sent: Thursday, July 01, 2010 11:59 AM
To: robert.moskowitz <at> icsalabs.com
Cc: petri.jokela <at> nomadiclab.com; thomas.r.henderson <at> boeing.com;
heer <at> cs.rwth-aachen.de
Subject: New Version Notification for draft-moskowitz-hip-rfc5201-bis-02

A new version of I-D, draft-moskowitz-hip-rfc5201-bis-02.txt has been
successfully submitted by Robert Moskowitz and posted to the IETF
repository.

Filename:	 draft-moskowitz-hip-rfc5201-bis
Revision:	 02
Title:		 Host Identity Protocol
Creation_date:	 2010-07-01
WG ID:		 Independent Submission
Number_of_pages: 112

Abstract:
This document specifies the details of the Host Identity Protocol
(HIP).  HIP allows consenting hosts to securely establish and
maintain shared IP-layer state, allowing separation of the identifier
and locator roles of IP addresses, thereby enabling continuity of
communications across IP address changes.  HIP is based on a SIGMA-
compliant Diffie-Hellman key exchange, using public key identifiers
from a new Host Identity namespace for mutual peer authentication.
The protocol is designed to be resistant to denial-of-service (DoS)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Moskowitz | 1 Jul 2010 18:12

Welcome to 5201-bis-02

Tobias Heer with my able assistance, has completed the lastest effort to 
move 5201 (and HIP!) to cryto agility and standards track.

Well I will say that Tobias did most of the writing, but I'll take the 
heat on where we went with the changes.  Tobias figured out how to add 
the crypto agility and avoid some downgrade attacks.  I spent time 
figuring out how to add ECDSA to the document and changes to KEYMAT.

There ARE a number of changes, we changed the version number.  HIP BEX 
still functions as in 5201, but we had to make the Hash negotiable, add 
ECDSA, and more Diffie-Hellman options (like ECDH).  This resulted in 
some interesting changes.

Tobias, Miika, and I have spent considerable time debating what crypto 
suites to include.  We are trying to balance agility and compactness. 
Should we drop SHA-1 like a hot potato and just specify SHA-256 and -384 
until SHA-3 comes out?  Or should SHA-1 still play and we downplay 
SHA_384?  Or is SHA-384 locked in to meet Suite-B needs?  Which ECDSA 
key sizes, P160, P256, and P384 seem to be the minimum (read why for 
P160).  And finally which AES modes (duo modes excluded for HIP 
payloads).  So please think on this and weigh in with your views.

First notice the change to the HIT.  We realized we need to encode a 
HIT_Suite_ID into the HIT.  Without this there were a number of 
complications and attack options.  But this cost us 4 bits from the 
hash.  We have a limited number of Suite ID slots and are concerned 
about how many we eat up right out the door.  Note that each hash eats 
TWO IDs, one for RSA/DSA and one for ECDSA (also HIP DEX will take one 
more).
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert Moskowitz | 1 Jul 2010 18:31

Re: Welcome to 5201-bis-02

At the end of this I have added the changelog that Tobias pointed me to...

On 07/01/2010 12:12 PM, Robert Moskowitz wrote:
> Tobias Heer with my able assistance, has completed the lastest effort 
> to move 5201 (and HIP!) to cryto agility and standards track.
>
> Well I will say that Tobias did most of the writing, but I'll take the 
> heat on where we went with the changes.  Tobias figured out how to add 
> the crypto agility and avoid some downgrade attacks.  I spent time 
> figuring out how to add ECDSA to the document and changes to KEYMAT.
>
> There ARE a number of changes, we changed the version number.  HIP BEX 
> still functions as in 5201, but we had to make the Hash negotiable, 
> add ECDSA, and more Diffie-Hellman options (like ECDH).  This resulted 
> in some interesting changes.
>
> Tobias, Miika, and I have spent considerable time debating what crypto 
> suites to include.  We are trying to balance agility and compactness. 
> Should we drop SHA-1 like a hot potato and just specify SHA-256 and 
> -384 until SHA-3 comes out?  Or should SHA-1 still play and we 
> downplay SHA_384?  Or is SHA-384 locked in to meet Suite-B needs?  
> Which ECDSA key sizes, P160, P256, and P384 seem to be the minimum 
> (read why for P160).  And finally which AES modes (duo modes excluded 
> for HIP payloads).  So please think on this and weigh in with your views.
>
> First notice the change to the HIT.  We realized we need to encode a 
> HIT_Suite_ID into the HIT.  Without this there were a number of 
> complications and attack options.  But this cost us 4 bits from the 
> hash.  We have a limited number of Suite ID slots and are concerned 
> about how many we eat up right out the door.  Note that each hash eats
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Moskowitz | 1 Jul 2010 18:32

Ooops Re: Welcome to 5201-bis-02

I hit Enter, rather then End...

At the end of this I have added the changelog that Tobias pointed me to...

On 07/01/2010 12:12 PM, Robert Moskowitz wrote:
> Tobias Heer with my able assistance, has completed the lastest effort
> to move 5201 (and HIP!) to cryto agility and standards track.
>
> Well I will say that Tobias did most of the writing, but I'll take the
> heat on where we went with the changes.  Tobias figured out how to add
> the crypto agility and avoid some downgrade attacks.  I spent time
> figuring out how to add ECDSA to the document and changes to KEYMAT.
>
> There ARE a number of changes, we changed the version number.  HIP BEX
> still functions as in 5201, but we had to make the Hash negotiable,
> add ECDSA, and more Diffie-Hellman options (like ECDH).  This resulted
> in some interesting changes.
>
> Tobias, Miika, and I have spent considerable time debating what crypto
> suites to include.  We are trying to balance agility and compactness.
> Should we drop SHA-1 like a hot potato and just specify SHA-256 and
> -384 until SHA-3 comes out?  Or should SHA-1 still play and we
> downplay SHA_384?  Or is SHA-384 locked in to meet Suite-B needs?
> Which ECDSA key sizes, P160, P256, and P384 seem to be the minimum
> (read why for P160).  And finally which AES modes (duo modes excluded
> for HIP payloads).  So please think on this and weigh in with your views.
>
> First notice the change to the HIT.  We realized we need to encode a
> HIT_Suite_ID into the HIT.  Without this there were a number of
> complications and attack options.  But this cost us 4 bits from the
(Continue reading)

Permalink | Reply | 0 comments |
headers
René Hummen | 4 Jul 2010 00:36
Picon
Picon
Favicon

Comments on 5201-bis-02

Hi everyone,

here are my comments/questions regarding RFC 5201-bis-02:

- 4.6 Certificate Distribution
While I understand the informational reason of having the section "4.5.2 Sending Data on HIP Packets", I
fail to see the reason why section 4.6 is included in 5201. Specifically, why is there a need to define the
parameter type CERT (768) without further length and value definitions?

- 5.2.16 ACK
The representation of the parameter only lists a single peer Update ID, whereas the transmission of
multiple IDs is possible.

- 5.2.19 - 5.2.22 ECHO_*
The definition of these parameters misses eventually required Padding.

- 5.3.5 UPDATE
Since working on HIPL I am wondering why HIP only defines a single UPDATE packet. From the perspective of
5201, I can see a conceptually compelling argument behind this approach, as it allows for a general
purpose packet for the transmission of maintenance information. However, most extensions using UPDATE
that I know of (most noteworthy, ESP rekeying and mobility and multi-homing) require a 3-way message
exchange to complete their corresponding task. The packets thereby have a specific order and each of them
has specific semantics. Let's take mobility as an example:
	(1) notify the peer of an address change,
	(2) challenge the peer to confirm his new address, and
	(3) satisfy the challenge.
Still, with the current specifications protocol developers are forced to distinguish between these 3
packets by checking the contained parameter combinations. This is, in my opinion, more complex than
necessary and error-prone, especially, with respect to the extensibility of the HIP parameters that can
be included in UPDATE packets. So, is there a reason that prevents us from specifying different
(Continue reading)

Permalink | Reply | 5 comments |
headers
Pekka Nikander | 4 Jul 2010 09:14

Re: Comments on 5201-bis-02

> - 5.3.5 UPDATE
> Since working on HIPL I am wondering why HIP only defines a single UPDATE packet. From the perspective of
5201, I can see a conceptually compelling argument behind this approach, as it allows for a general
purpose packet for the transmission of maintenance information. However, most extensions using UPDATE
that I know of (most noteworthy, ESP rekeying and mobility and multi-homing) require a 3-way message
exchange to complete their corresponding task. The packets thereby have a specific order and each of them
has specific semantics. Let's take mobility as an example:
> 	(1) notify the peer of an address change,
> 	(2) challenge the peer to confirm his new address, and
> 	(3) satisfy the challenge.
> Still, with the current specifications protocol developers are forced to distinguish between these 3
packets by checking the contained parameter combinations. This is, in my opinion, more complex than
necessary and error-prone, especially, with respect to the extensibility of the HIP parameters that can
be included in UPDATE packets. So, is there a reason that prevents us from specifying different
maintenance packet types instead of a single one?

The original idea was that UPDATEs would just be a "carrier" for upper level protocols, allowing upper
level protocols to be mixed and matched on individual packets.  E.g. so that you could run a mobility
exchange and ESP rekeying at the same time, with the same packets.  E.g.

    A->B:  Notify address change
    B->A:  Challenge address; Initiate ESP rekeying
    A->B:  Send the challenge response; Continue ESP rekeying
           etc.

But since I haven't been involved in implementation efforts for the last N years, I don't know if the current
implementations support such behaviour

--Pekka
(Continue reading)

Permalink | Reply | 4 comments |
headers
Miika Komu | 4 Jul 2010 12:12
Picon
Picon

Re: Comments on 5201-bis-02

On 07/04/2010 10:14 AM, Pekka Nikander wrote:

Hi Pekka and Rene,

>> - 5.3.5 UPDATE
>> Since working on HIPL I am wondering why HIP only defines a single UPDATE packet. From the perspective of
5201, I can see a conceptually compelling argument behind this approach, as it allows for a general
purpose packet for the transmission of maintenance information. However, most extensions using UPDATE
that I know of (most noteworthy, ESP rekeying and mobility and multi-homing) require a 3-way message
exchange to complete their corresponding task. The packets thereby have a specific order and each of them
has specific semantics. Let's take mobility as an example:
>> 	(1) notify the peer of an address change,
>> 	(2) challenge the peer to confirm his new address, and
>> 	(3) satisfy the challenge.
>> Still, with the current specifications protocol developers are forced to distinguish between these 3
packets by checking the contained parameter combinations. This is, in my opinion, more complex than
necessary and error-prone, especially, with respect to the extensibility of the HIP parameters that can
be included in UPDATE packets. So, is there a reason that prevents us from specifying different
maintenance packet types instead of a single one?
>
> The original idea was that UPDATEs would just be a "carrier" for upper level protocols, allowing upper
level protocols to be mixed and matched on individual packets.  E.g. so that you could run a mobility
exchange and ESP rekeying at the same time, with the same packets.  E.g.
>
>      A->B:  Notify address change
>      B->A:  Challenge address; Initiate ESP rekeying
>      A->B:  Send the challenge response; Continue ESP rekeying
>             etc.
>
> But since I haven't been involved in implementation efforts for the last N years, I don't know if the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henderson, Thomas R | 5 Jul 2010 06:07
Picon
Favicon

Re: Comments on 5201-bis-02


> -----Original Message-----
> From: hipsec-bounces <at> ietf.org
> [mailto:hipsec-bounces <at> ietf.org] On Behalf Of Pekka Nikander
> Sent: Sunday, July 04, 2010 12:15 AM
> To: René Hummen
> Cc: HIP WG
> Subject: Re: [Hipsec] Comments on 5201-bis-02
>
> > - 5.3.5 UPDATE
> > Since working on HIPL I am wondering why HIP only defines a
> single UPDATE packet. From the perspective of 5201, I can see
> a conceptually compelling argument behind this approach, as
> it allows for a general purpose packet for the transmission
> of maintenance information. However, most extensions using
> UPDATE that I know of (most noteworthy, ESP rekeying and
> mobility and multi-homing) require a 3-way message exchange
> to complete their corresponding task. The packets thereby
> have a specific order and each of them has specific
> semantics. Let's take mobility as an example:
> >     (1) notify the peer of an address change,
> >     (2) challenge the peer to confirm his new address, and
> >     (3) satisfy the challenge.
> > Still, with the current specifications protocol developers
> are forced to distinguish between these 3 packets by checking
> the contained parameter combinations. This is, in my opinion,
> more complex than necessary and error-prone, especially, with
> respect to the extensibility of the HIP parameters that can
> be included in UPDATE packets. So, is there a reason that
> prevents us from specifying different maintenance packet
(Continue reading)

Permalink | Reply | 2 comments |
headers
Miika Komu | 5 Jul 2010 08:49
Picon
Picon

Re: Comments on 5201-bis-02

On 07/05/2010 07:07 AM, Henderson, Thomas R wrote:

Hi Tom,

>> -----Original Message-----
>> From: hipsec-bounces <at> ietf.org
>> [mailto:hipsec-bounces <at> ietf.org] On Behalf Of Pekka Nikander
>> Sent: Sunday, July 04, 2010 12:15 AM
>> To: René Hummen
>> Cc: HIP WG
>> Subject: Re: [Hipsec] Comments on 5201-bis-02
>>
>>> - 5.3.5 UPDATE
>>> Since working on HIPL I am wondering why HIP only defines a
>> single UPDATE packet. From the perspective of 5201, I can see
>> a conceptually compelling argument behind this approach, as
>> it allows for a general purpose packet for the transmission
>> of maintenance information. However, most extensions using
>> UPDATE that I know of (most noteworthy, ESP rekeying and
>> mobility and multi-homing) require a 3-way message exchange
>> to complete their corresponding task. The packets thereby
>> have a specific order and each of them has specific
>> semantics. Let's take mobility as an example:
>>>      (1) notify the peer of an address change,
>>>      (2) challenge the peer to confirm his new address, and
>>>      (3) satisfy the challenge.
>>> Still, with the current specifications protocol developers
>> are forced to distinguish between these 3 packets by checking
>> the contained parameter combinations. This is, in my opinion,
>> more complex than necessary and error-prone, especially, with
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jan Melen | 6 Jul 2010 15:37

Re: Comments on 5201-bis-02


On Jul 5, 2010, at 9:49 AM, Miika Komu wrote:

> On 07/05/2010 07:07 AM, Henderson, Thomas R wrote:
> 
> Hi Tom,
> 
>>> -----Original Message-----
>>> From: hipsec-bounces <at> ietf.org
>>> [mailto:hipsec-bounces <at> ietf.org] On Behalf Of Pekka Nikander
>>> Sent: Sunday, July 04, 2010 12:15 AM
>>> To: René Hummen
>>> Cc: HIP WG
>>> Subject: Re: [Hipsec] Comments on 5201-bis-02
>>> 
>>>> - 5.3.5 UPDATE
>>>> Since working on HIPL I am wondering why HIP only defines a
>>> single UPDATE packet. From the perspective of 5201, I can see
>>> a conceptually compelling argument behind this approach, as
>>> it allows for a general purpose packet for the transmission
>>> of maintenance information. However, most extensions using
>>> UPDATE that I know of (most noteworthy, ESP rekeying and
>>> mobility and multi-homing) require a 3-way message exchange
>>> to complete their corresponding task. The packets thereby
>>> have a specific order and each of them has specific
>>> semantics. Let's take mobility as an example:
>>>>     (1) notify the peer of an address change,
>>>>     (2) challenge the peer to confirm his new address, and
>>>>     (3) satisfy the challenge.
>>>> Still, with the current specifications protocol developers
(Continue reading)

Permalink | Reply | 0 comments |

Gmane