Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
From: heer at cs.rwth-aachen.de (Tobias Heer)
Date: Fri, 25 Jan 2008 13:18:38 +0100

Hi everyone,

After a jabber chat discussion with Miika and Julien, we agreed that  
the three of us will continue to work on the presented problem  
discussed in draft-heer-hip-middle-auth-00.

Julien's main concern is that the threat model is not obvious from  
the draft. Because of the missing threat model, the security  
properties of the proposed solutions are not as clear as they should be.

We will continue the work by improving the positioning of the  
solution with requirements and threat model. Once that is done we  
will come back to the list for further comments.

Thanks for all the comments so far.

Tobias

--  
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
http://ds.cs.rwth-aachen.de/members/heer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20080125/5d4b9706/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2448 bytes
Desc: not available
Url : https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20080125/5d4b9706/attachment.bin 

From: julien.IETF at laposte.net (Julien Laganier)
Date: Thu, 24 Jan 2008 16:58:42 +0100
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thursday 24 January 2008, Miika Komu wrote:
> Hi Julien,
>
> may I ask why? If what we want is to public key-based filtering for
> HIP control packets? I think the draft specifies such behaviour and
> avoids replay attacks on HIP control packets as well. (HIT-only-based
> filtering does not tell us whether the HIT is owned by the end-host)

For my own curiosity, what would be the security service provided by HIP 
control packet filtering?

If this is really what you want to do, write it down in the draft. This 
is for sure different that admission/access control, accounting, etc.

--julien

From: miika at iki.fi (Miika Komu)
Date: Thu, 24 Jan 2008 17:26:06 +0200 (EET)
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu, 24 Jan 2008, Julien Laganier wrote:

> Hello Tobias,
>
> On Thursday 24 January 2008, Tobias Heer wrote:
>> Am 24.01.2008 um 09:26 schrieb Julien Laganier:
>>> On Thursday 24 January 2008, Julien Laganier wrote:
>>>> On Wednesday 23 January 2008, Miika Komu wrote:
>>>>> Hi Julien,
>>>>>
>>>>> I didn't get the point with statefull firewalls, can you clarify?
>>>>> The SPI field is integrity protected. Also, a fake base exchange
>>>>> (to create a fake ESP channel) can pass all ACL checks in the
>>>>> firewall if the firewall does not check signatures in a mobile
>>>>> environment.
>>
>> I also did not get how a stateful HIP firewall would do
>> authentication based on HIs without verifying them. Maybe we are
>> talking about different scenarios with different assumptions here.
>> Let's see if we can get us synchronized :-)
>
> Let's talk about a security service which is packet filtering.
>
> Let's assume we have no requirement that the decision to let a packet
> thru or not to be based on a strong (cryptographic) verification of
> data origin. Rather, we only have the requirement that the specific
> fields of a packet (e.g. src and dst IPs, SPI) respect some
> constraints, which are derived from state established by looking at
> other packets.
>
> In that case a statefull firewall provide the service:
>
> - For a TCP connection, it can follow the SYN/SYN-ACK/ACK three way
> handshake, and then let thru only TCP segments that 'belong' to that
> TCP connection, in terms of source and destination IP addresses,
> sequence number and acknowledgment.
>
> - For HIP association, it can follow the HIP BEX SPIs, and then let thru
> only ESP packets that 'belong' to that HIP association, in terms of
> source and destination IP addresses, sequence number and SPI.
>
> Both of the above are not base on strong verification of data origin but
> they do satisfy our requirements.
>
> On the other hand, if we do have requirements that the decision to let a
> packet thru or not to be based on a strong (cryptographic) verification
> of data origin, then we need a mechanism for the midbox to verify which
> packets really come from then endpoints that participated in the base
> exchange. In that situation it would make sense for the midbox to
> verify the identities of parties involved in the base exchange, and
> avoid replay attacks. This is not the case AFAICS.

Hi Julien,

may I ask why? If what we want is to public key-based filtering for HIP 
control packets? I think the draft specifies such behaviour and avoids 
replay attacks on HIP control packets as well. (HIT-only-based filtering 
does not tell us whether the HIT is owned by the end-host)

-- 
Miika Komu                                       http://www.iki.fi/miika/

From: julien.IETF at laposte.net (Julien Laganier)
Date: Thu, 24 Jan 2008 14:24:55 +0100
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello Tobias,

On Thursday 24 January 2008, Tobias Heer wrote:
> Am 24.01.2008 um 09:26 schrieb Julien Laganier:
> > On Thursday 24 January 2008, Julien Laganier wrote:
> >> On Wednesday 23 January 2008, Miika Komu wrote:
> >>> Hi Julien,
> >>>
> >>> I didn't get the point with statefull firewalls, can you clarify?
> >>> The SPI field is integrity protected. Also, a fake base exchange
> >>> (to create a fake ESP channel) can pass all ACL checks in the
> >>> firewall if the firewall does not check signatures in a mobile
> >>> environment.
>
> I also did not get how a stateful HIP firewall would do
> authentication based on HIs without verifying them. Maybe we are
> talking about different scenarios with different assumptions here.
> Let's see if we can get us synchronized :-)

Let's talk about a security service which is packet filtering.

Let's assume we have no requirement that the decision to let a packet 
thru or not to be based on a strong (cryptographic) verification of 
data origin. Rather, we only have the requirement that the specific 
fields of a packet (e.g. src and dst IPs, SPI) respect some 
constraints, which are derived from state established by looking at 
other packets.

In that case a statefull firewall provide the service:

- For a TCP connection, it can follow the SYN/SYN-ACK/ACK three way 
handshake, and then let thru only TCP segments that 'belong' to that 
TCP connection, in terms of source and destination IP addresses, 
sequence number and acknowledgment.

- For HIP association, it can follow the HIP BEX SPIs, and then let thru 
only ESP packets that 'belong' to that HIP association, in terms of 
source and destination IP addresses, sequence number and SPI.

Both of the above are not base on strong verification of data origin but 
they do satisfy our requirements.

On the other hand, if we do have requirements that the decision to let a 
packet thru or not to be based on a strong (cryptographic) verification 
of data origin, then we need a mechanism for the midbox to verify which 
packets really come from then endpoints that participated in the base 
exchange. In that situation it would make sense for the midbox to 
verify the identities of parties involved in the base exchange, and 
avoid replay attacks. This is not the case AFAICS.

--julien

> >> The midbox cannot verify that the ESP packet originates from a
> >> node that participated in the BEX. It only verify that the ESP SPI
> >> was included in the base exchange, but there is no strong
> >> (cryptographic) validation of data origin at the midbox for ESP.
> >>
> >> Since in the end no strong guarantee on the ESP data origin is
> >> provided, IMHO it seems that the (strong) validation of BEX
> >> signatures by midboxes hasn't much value. Security strength is
> >> determined by the strength of each element of the chain. Here the
> >> last element is weak (looking at SPI without verifying data
> >> origin) thus I'm not convinced about the strength of the
> >> mechanism.
> >
> > ...and consequently I don't see a need to make BEX inspection
> > security even stronger (Tobia's proposal) since the weak admission
> > control of ESP packets will remain.
>
> It's right that you cannot determine the origin of the ESP packets in
> a cryptographically strong way. However, you can enforce that all
> packets that are forwarded by a certain middlebox fulfill the
> criteria that have been negotiated in the BEX. You can, for example,
> only allow traffic between network identifiers that have been used to
> successfully establish a HIP association. I admit that this does not
> prevent an attacker from  sending packets with the same destination
> IP address, the same source IP address, and the same SPI. However,
> this will only enable an attacker to send invalid ESP packets to an
> authentic HIP host (which will probably just drop the packets). I
> further have to admit that there is a loophole in this scheme.  A
> pair of attackers that can use the same network-level identifiers as
> the authentic peers could inject packets into the payload stream and
> communicate across it. However, such an attack only works in the
> presence of authentic HIP hosts and it will only stay unnoticed if
> the receiving attacker can delete the forged packets before they
> reach the authentic HIP host. Additionally, inconsistencies in the
> IPsec sequence numbers aid the middlebox to identify such injections.
> However, these measures are all payload channel specific. My main
> concern is that HIP does not even support secure authentication of
> the HIP hosts (and the control channel) by middleboxes without
> explicitly performing a HIP handshake with them.
>
> > Again, I think we should discuss first what is the security service
> > we want to provide (e.g. admission control), and requirements we
> > place, before entering solution space.
>
> I guess admission control and access control are two services that
> could benefit from using HIP. I would like to see a system that
> identifies hosts based on their HIs and then decides whether to
> allocate certain resources for the payload stream or to determine
> whether the payload stream will be permitted at all. Mechanisms for
> reverting the resource allocation and for closing the payload stream
> would also be nice.

From: heer at cs.rwth-aachen.de (Tobias Heer)
Date: Thu, 24 Jan 2008 11:43:14 +0100
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Julien,

Am 24.01.2008 um 09:26 schrieb Julien Laganier:

> On Thursday 24 January 2008, Julien Laganier wrote:
>> On Wednesday 23 January 2008, Miika Komu wrote:
>>> Hi Julien,
>>>
>>> I didn't get the point with statefull firewalls, can you clarify?
>>> The SPI field is integrity protected. Also, a fake base exchange
>>> (to create a fake ESP channel) can pass all ACL checks in the
>>> firewall if the firewall does not check signatures in a mobile
>>> environment.
>>
I also did not get how a stateful HIP firewall would do  
authentication based on HIs without verifying them. Maybe we are  
talking about different scenarios with different assumptions here.  
Let's see if we can get us synchronized :-)

>> Hi Miika,
>>
>> The midbox cannot verify that the ESP packet originates from a node
>> that participated in the BEX. It only verify that the ESP SPI was
>> included in the base exchange, but there is no strong (cryptographic)
>> validation of data origin at the midbox for ESP.
>>
>> Since in the end no strong guarantee on the ESP data origin is
>> provided, IMHO it seems that the (strong) validation of BEX
>> signatures by midboxes hasn't much value. Security strength is
>> determined by the strength of each element of the chain. Here the
>> last element is weak (looking at SPI without verifying data origin)
>> thus I'm not convinced about the strength of the mechanism.
>
> ...and consequently I don't see a need to make BEX inspection security
> even stronger (Tobia's proposal) since the weak admission control of
> ESP packets will remain.
>
It's right that you cannot determine the origin of the ESP packets in  
a cryptographically strong way. However, you can enforce that all  
packets that are forwarded by a certain middlebox fulfill the  
criteria that have been negotiated in the BEX. You can, for example,  
only allow traffic between network identifiers that have been used to  
successfully establish a HIP association. I admit that this does not  
prevent an attacker from  sending packets with the same destination  
IP address, the same source IP address, and the same SPI. However,  
this will only enable an attacker to send invalid ESP packets to an  
authentic HIP host (which will probably just drop the packets). I  
further have to admit that there is a loophole in this scheme.  A  
pair of attackers that can use the same network-level identifiers as  
the authentic peers could inject packets into the payload stream and  
communicate across it. However, such an attack only works in the  
presence of authentic HIP hosts and it will only stay unnoticed if  
the receiving attacker can delete the forged packets before they  
reach the authentic HIP host. Additionally, inconsistencies in the  
IPsec sequence numbers aid the middlebox to identify such injections.  
However, these measures are all payload channel specific. My main  
concern is that HIP does not even support secure authentication of  
the HIP hosts (and the control channel) by middleboxes without  
explicitly performing a HIP handshake with them.

> Again, I think we should discuss first what is the security service we
> want to provide (e.g. admission control), and requirements we place,
> before entering solution space.
>
I guess admission control and access control are two services that  
could benefit from using HIP. I would like to see a system that  
identifies hosts based on their HIs and then decides whether to  
allocate certain resources for the payload stream or to determine  
whether the payload stream will be permitted at all. Mechanisms for  
reverting the resource allocation and for closing the payload stream  
would also be nice.

BR,

Tobias

> --julien

--  
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
http://ds.cs.rwth-aachen.de/members/heer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20080124/aaf2b4e5/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2448 bytes
Desc: not available
Url : https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20080124/aaf2b4e5/attachment-0001.bin 

From: julien.IETF at laposte.net (Julien Laganier)
Date: Thu, 24 Jan 2008 09:26:01 +0100
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thursday 24 January 2008, Julien Laganier wrote:
> On Wednesday 23 January 2008, Miika Komu wrote:
> > Hi Julien,
> >
> > I didn't get the point with statefull firewalls, can you clarify?
> > The SPI field is integrity protected. Also, a fake base exchange
> > (to create a fake ESP channel) can pass all ACL checks in the
> > firewall if the firewall does not check signatures in a mobile
> > environment.
>
> Hi Miika,
>
> The midbox cannot verify that the ESP packet originates from a node
> that participated in the BEX. It only verify that the ESP SPI was
> included in the base exchange, but there is no strong (cryptographic)
> validation of data origin at the midbox for ESP.
>
> Since in the end no strong guarantee on the ESP data origin is
> provided, IMHO it seems that the (strong) validation of BEX
> signatures by midboxes hasn't much value. Security strength is
> determined by the strength of each element of the chain. Here the
> last element is weak (looking at SPI without verifying data origin)
> thus I'm not convinced about the strength of the mechanism.

...and consequently I don't see a need to make BEX inspection security 
even stronger (Tobia's proposal) since the weak admission control of 
ESP packets will remain.

Again, I think we should discuss first what is the security service we 
want to provide (e.g. admission control), and requirements we place, 
before entering solution space.

--julien

From: julien.IETF at laposte.net (Julien Laganier)
Date: Thu, 24 Jan 2008 09:26:01 +0100
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thursday 24 January 2008, Julien Laganier wrote:
> On Wednesday 23 January 2008, Miika Komu wrote:
> > Hi Julien,
> >
> > I didn't get the point with statefull firewalls, can you clarify?
> > The SPI field is integrity protected. Also, a fake base exchange
> > (to create a fake ESP channel) can pass all ACL checks in the
> > firewall if the firewall does not check signatures in a mobile
> > environment.
>
> Hi Miika,
>
> The midbox cannot verify that the ESP packet originates from a node
> that participated in the BEX. It only verify that the ESP SPI was
> included in the base exchange, but there is no strong (cryptographic)
> validation of data origin at the midbox for ESP.
>
> Since in the end no strong guarantee on the ESP data origin is
> provided, IMHO it seems that the (strong) validation of BEX
> signatures by midboxes hasn't much value. Security strength is
> determined by the strength of each element of the chain. Here the
> last element is weak (looking at SPI without verifying data origin)
> thus I'm not convinced about the strength of the mechanism.

...and consequently I don't see a need to make BEX inspection security 
even stronger (Tobia's proposal) since the weak admission control of 
ESP packets will remain.

Again, I think we should discuss first what is the security service we 
want to provide (e.g. admission control), and requirements we place, 
before entering solution space.

--julien

From: julien.IETF at laposte.net (Julien Laganier)
Date: Thu, 24 Jan 2008 09:06:15 +0100
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday 23 January 2008, Miika Komu wrote:
> On Wed, 23 Jan 2008, Julien Laganier wrote:
> > Hello Tobias,
> >
> > On Wednesday 23 January 2008, Tobias Heer wrote:
> >> Am 23.01.2008 um 15:24 schrieb Julien Laganier:
> >>> On Wednesday 23 January 2008, Tobias Heer wrote:
> >>>>> I am actually unclear about the goal of BEX inspection by
> >>>>> middlebox (e.g. signature verification). What kind of security
> >>>>> service does it offer?
> >>>>
> >>>> The goal is that the middlebox can verify the Identity of the
> >>>> hosts that communicate across it unambiguously.
> >>>
> >>> This is ambiguous in itself :)
> >>>
> >>> AFAIU, 'communicate' refers only the BEX. The middlebox doesn't
> >>> verify identity of the hosts sending payload packets (e.g., ESP).
> >>
> >> The "communicate" refers to the HIP control packets, e.g. BEX and
> >> ? UPDATE and the payload channel associated with the HIP control
> >> channel. The middlebox can derive some expected properties for the
> >> payload channel from the HIP control messages (e.g. IP address
> >> pairs and SPIs). It can use these properties to block certain
> >> payload that does not belong to an authenticated HIP association.
> >
> > Verifying IP addresses and SPIs does not provide a strong insurance
> > that the payload packets are indeed exchanged by the parties that
> > participated in the BEX.
> >
> > If no strong insurance is present, what's the value of verifying
> > signatures in HIP BEX since in the end payload packets are allowed
> > in based on unprotected packet fields (IPs and SPIs). A statefull
> > firewall would provide the same level of protection without
> > verifying signatures.
>
> Hi Julien,
>
> I didn't get the point with statefull firewalls, can you clarify? The
> SPI field is integrity protected. Also, a fake base exchange (to
> create a fake ESP channel) can pass all ACL checks in the firewall if
> the firewall does not check signatures in a mobile environment.

Hi Miika,

The midbox cannot verify that the ESP packet originates from a node that 
participated in the BEX. It only verify that the ESP SPI was included 
in the base exchange, but there is no strong (cryptographic) validation 
of data origin at the midbox for ESP.

Since in the end no strong guarantee on the ESP data origin is provided, 
IMHO it seems that the (strong) validation of BEX signatures by 
midboxes hasn't much value. Security strength is determined by the 
strength of each element of the chain. Here the last element is weak 
(looking at SPI without verifying data origin) thus I'm not convinced 
about the strength of the mechanism.

--julien

From: miika at iki.fi (Miika Komu)
Date: Thu, 24 Jan 2008 00:41:32 +0200 (EET)
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 23 Jan 2008, Julien Laganier wrote:

> Hello Tobias,
>
> On Wednesday 23 January 2008, Tobias Heer wrote:
>> Am 23.01.2008 um 15:24 schrieb Julien Laganier:
>>> On Wednesday 23 January 2008, Tobias Heer wrote:
>>>>> I am actually unclear about the goal of BEX inspection by
>>>>> middlebox (e.g. signature verification). What kind of security
>>>>> service does it offer?
>>>>
>>>> The goal is that the middlebox can verify the Identity of the
>>>> hosts that communicate across it unambiguously.
>>>
>>> This is ambiguous in itself :)
>>>
>>> AFAIU, 'communicate' refers only the BEX. The middlebox doesn't
>>> verify identity of the hosts sending payload packets (e.g., ESP).
>>
>> The "communicate" refers to the HIP control packets, e.g. BEX and ?
>> UPDATE and the payload channel associated with the HIP control
>> channel. The middlebox can derive some expected properties for the
>> payload channel from the HIP control messages (e.g. IP address pairs
>> and SPIs). It can use these properties to block certain payload that
>> does not belong to an authenticated HIP association.
>
> Verifying IP addresses and SPIs does not provide a strong insurance that
> the payload packets are indeed exchanged by the parties that
> participated in the BEX.
>
> If no strong insurance is present, what's the value of verifying
> signatures in HIP BEX since in the end payload packets are allowed in
> based on unprotected packet fields (IPs and SPIs). A statefull firewall
> would provide the same level of protection without verifying
> signatures.

Hi Julien,

I didn't get the point with statefull firewalls, can you clarify? The SPI 
field is integrity protected. Also, a fake base exchange (to create a fake 
ESP channel) can pass all ACL checks in the firewall if the firewall does 
not check signatures in a mobile environment.

However, just including signatures is not enough because an authentic base 
exchange can replayed to create a fake ESP channel. Thus, we need the 
middlebox to ensure the uniqueness of the base exchange with middlebox 
nonces that are signed by the end-hosts.

What I am not sure is that what happens with the old middleboxes when both 
of the end-hosts move behind new middleboxes. I guess the old middboxes 
have to expire the state using timers, but attackers working at both ends 
could reuse the ESP channel until it expires. Anyway, this attack does not 
seem very realistic to me.

-- 
Miika Komu                                       http://www.iki.fi/miika/

From: julien.IETF at laposte.net (Julien Laganier)
Date: Wed, 23 Jan 2008 16:50:52 +0100
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello Tobias,

On Wednesday 23 January 2008, Tobias Heer wrote:
> Am 23.01.2008 um 15:24 schrieb Julien Laganier:
> > On Wednesday 23 January 2008, Tobias Heer wrote:
> >>> I am actually unclear about the goal of BEX inspection by
> >>> middlebox (e.g. signature verification). What kind of security
> >>> service does it offer?
> >>
> >> The goal is that the middlebox can verify the Identity of the
> >> hosts that communicate across it unambiguously.
> >
> > This is ambiguous in itself :)
> >
> > AFAIU, 'communicate' refers only the BEX. The middlebox doesn't
> > verify identity of the hosts sending payload packets (e.g., ESP).
>
> The "communicate" refers to the HIP control packets, e.g. BEX and ?
> UPDATE and the payload channel associated with the HIP control
> channel. The middlebox can derive some expected properties for the
> payload channel from the HIP control messages (e.g. IP address pairs
> and SPIs). It can use these properties to block certain payload that
> does not belong to an authenticated HIP association.

Verifying IP addresses and SPIs does not provide a strong insurance that 
the payload packets are indeed exchanged by the parties that 
participated in the BEX.

If no strong insurance is present, what's the value of verifying 
signatures in HIP BEX since in the end payload packets are allowed in 
based on unprotected packet fields (IPs and SPIs). A statefull firewall 
would provide the same level of protection without verifying 
signatures.

--julien

From: heer at cs.rwth-aachen.de (Tobias Heer)
Date: Wed, 23 Jan 2008 15:39:42 +0100
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Julien,

Am 23.01.2008 um 15:24 schrieb Julien Laganier:

> On Wednesday 23 January 2008, Tobias Heer wrote:
>>> I am actually unclear about the goal of BEX inspection by middlebox
>>> (e.g. signature verification). What kind of security service does
>>> it offer?
>>
>> The goal is that the middlebox can verify the Identity of the hosts
>> that communicate across it unambiguously.
>
> This is ambiguous in itself :)
>
> AFAIU, 'communicate' refers only the BEX. The middlebox doesn't verify
> identity of the hosts sending payload packets (e.g., ESP).
The "communicate" refers to the HIP control packets, e.g. BEX and  
UPDATE and the payload channel associated with the HIP control channel.
The middlebox can derive some expected properties for the payload  
channel from the HIP control messages (e.g. IP address pairs and  
SPIs). It can use these properties to block certain payload that does  
not belong to an authenticated HIP association.

>
>> Practical usecases could be middleboxes that enforces certain
>> policies based on the identities of two hosts. The middlebox could
>> perform access control (only certain hosts may communicate across the
>>   middlebox), or it may perform accounting (e.g. based on traffic
>> volume or connection duration). Every usecase in which a middlebox
>> needs to know who is communicating would apply.
>
> Agree that in every such usecase the middlebox needs to know who is
> communicating.
>
:-)

> The point is that the current HIP middlebox story where midboxes are
> verifying signatures in the BEX doesn't achieve that (see above).  
> Thus,
> we cannot use the BEX inspection in any of these usecase...
>
See above. I would like to allow and deny payload packets based on a  
previous HIP authentication.

> Let's first discuss what is (are?) the security service(s) offered by
> midbox BEX inspection.
>

BR,
Tobias

> --julien

--  
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
http://ds.cs.rwth-aachen.de/members/heer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20080123/04f0a28c/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2448 bytes
Desc: not available
Url : https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20080123/04f0a28c/attachment-0001.bin 

From: samu.varjonen at helsinki.fi (Samu Varjonen)
Date: Wed, 23 Jan 2008 16:36:20 +0200
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
Message-ID: <[email-masked]>

Hi,

Ups, my mistake. By it I meant puzzle or opaque #.

Quoting Tobias Heer <heer at cs.rwth-aachen.de>:
-> >
-> > Would the second AP just pass it to the Responder or what?
-> What would the AP pass to the responder? (I can't resolve the "it"  
-> here, sorry).
-> 

But then again how could the second AP trust the puzzle or opaque # sent by
the other AP, which it does not(?) trust. So in this case the first AP would
need a possibility to forward the puzzle from the second AP to the
initiator. Also possibly the responders puzzle too.

Samu Varjonen
samu.varjonen at hiit.fi

 ........................
 . Resistance is futile .
 .     (if < 1 Ohm)     .
 ........................

From: heer at cs.rwth-aachen.de (Tobias Heer)
Date: Wed, 23 Jan 2008 15:15:59 +0100
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Samu,

Am 23.01.2008 um 14:57 schrieb Samu Varjonen:

> Tobias Heer wrote:
>
>>>
>> I agree that the two parameters could be condensed to just one  
>> parameter. However, the reason why I chose that thwo parameters  
>> would be beneficial is that I suspect that the puzzle will only be  
>> needed rarely (i.e under attack conditions). Using the puzzle even  
>> for normal operation requires transmit 9 additional bytes for the  
>> puzzle and 17 additional bytes for the solution.  With regard to  
>> the restricted space in the HIP packets and the possibility of  
>> having cascaded middleboxes, I thought separating the puzzle form  
>> the echo_request to save space would be a good idea.
>
> If K = 0 then it would be just 1 byte for K and there would not be  
> need to send those last 8 bytes or in solution 2 * 8 bytes. So in  
> case where there would be only opaque # then the total len of the  
> parameter would be just 1 byte more.
>
Well, when operating in that mode, it makes sense to unify puzzle and  
echo_request/response.

>> I believe that pushing the puzzle to the initiator is a good  
>> workaround for the problem. I'm just not sure if it wouldn't be  
>> easier to let the middlebox hand over two puzzles to the initiator  
>> of which the initiators solves both and sends one solution to the  
>> responder. Having all these additional HIP messages during the  
>> handshake seems to be overkill.
>
> Why not then let the Initiator solve a bigger puzzle and let the  
> Responder just sign the opaque #. Would there really be need to  
> send the solution of the second puzzle to the Responder?
This is also an option. The middlebox would have to keep track of the  
puzzles but as the Initiator would present the difficult solution  
first I don't see a reason why it shouldn't work. However, I've gotta  
think about it a bit more.

>
> What about if there is multiple middleboxes on the way?
>
> For example:
> Wifi-Initiator<-->AP<-->Wired network<-->AP<-->Wifi-Responder
I think every middlebox would want to a puzzle because it cannot  
trust the other middleboxes by default.

> 	
>
> Would the second AP just pass it to the Responder or what?
What would the AP pass to the responder? (I can't resolve the "it"  
here, sorry).

BR,
Tobias

>

> BR,
> Samu

--  
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
http://ds.cs.rwth-aachen.de/members/heer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20080123/ede11df2/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2448 bytes
Desc: not available
Url : https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20080123/ede11df2/attachment.bin 

From: samu.varjonen at helsinki.fi (Samu Varjonen)
Date: Wed, 23 Jan 2008 15:57:08 +0200
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Tobias Heer wrote:

>>
> I agree that the two parameters could be condensed to just one 
> parameter. However, the reason why I chose that thwo parameters would be 
> beneficial is that I suspect that the puzzle will only be needed rarely 
> (i.e under attack conditions). Using the puzzle even for normal 
> operation requires transmit 9 additional bytes for the puzzle and 17 
> additional bytes for the solution.  With regard to the restricted space 
> in the HIP packets and the possibility of having cascaded middleboxes, I 
> thought separating the puzzle form the echo_request to save space would 
> be a good idea.
> 

If K = 0 then it would be just 1 byte for K and there would not be need 
to send those last 8 bytes or in solution 2 * 8 bytes. So in case where 
there would be only opaque # then the total len of the parameter would 
be just 1 byte more.

> I believe that pushing the puzzle to the initiator is a good workaround 
> for the problem. I'm just not sure if it wouldn't be easier to let the 
> middlebox hand over two puzzles to the initiator of which the initiators 
> solves both and sends one solution to the responder. Having all these 
> additional HIP messages during the handshake seems to be overkill.
> 

Why not then let the Initiator solve a bigger puzzle and let the 
Responder just sign the opaque #. Would there really be need to send the 
solution of the second puzzle to the Responder?

What about if there is multiple middleboxes on the way?

For example:
Wifi-Initiator<-->AP<-->Wired network<-->AP<-->Wifi-Responder	

Would the second AP just pass it to the Responder or what?

BR,
Samu

From: julien.IETF at laposte.net (Julien Laganier)
Date: Wed, 23 Jan 2008 14:40:37 +0100
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello Tobias,

On Wednesday 23 January 2008, Tobias Heer wrote:
> The scope of the draft is to illustrate a possible replay attack ?
> towards the middlebox and proposes a solution that enables the ?
> middlebox to interact with the BEX.
>
> > I think the draft should more accurately state what is the goal,
> > security-wise. E.g. authentication alone is vague and prone to
> > ambiguous interpretation. Once that is done, relevance of the
> > solution can be assessed.
>
> Do you think the title is misleading or do you believe we should be ?
> more specific in the abstract and text?

I am actually unclear about the goal of BEX inspection by middlebox 
(e.g. signature verification). What kind of security service does it 
offer?

Once we have a good understanding of that, we can discuss about what 
your draft tries to achieve, and how.

Thanks.

--julien

From: heer at cs.rwth-aachen.de (Tobias Heer)
Date: Wed, 23 Jan 2008 14:10:27 +0100
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Samu,

Thanks for your comments. See my comments inline.

Am 23.01.2008 um 10:26 schrieb Samu Varjonen:

> Hi,
>
> Miika Komu wrote:
>
>> As a conclusion, I think the middlebox draft from Tobias makes a  
>> lot of sense for replay protection for middleboxes.
>
> I agree with Miika that replay protection makes sense but I have  
> few comments about the draft.
>
> Here is some comments on the draft-heer-hip-middle-auth-00
> ==========================================================
> First some small nitpicks. Then something more interesting.
>
> 1) Fig.1 says that R2 is sent from Initator to Responder. (arrows
>    point to wrong direction)
Thanks for pointing that out. I'll fix this with the next version.

>
> 2) Section 1.1. where it discusses about X and Y. It could be clearer
>    in form
>    "Middlebox has no way to distinguish legimate users X and Y from
>    attackers A and B..."
>    or
>    "Middlebox has no way to distinguish X and Y from A and B"
Ok, I agree that should be expressed in a clearer form.

> 3) Section 2.1.1. discusses about the maximum size of total length
>    of the packets (R1, I2, R2 and UPDATE affected). should not exceed
>    ove 1280 bytes, because of IPv6 fragmentation. This statement uses
>    capitalized SHOULD and I think that in practise this contradicts
>    with base-10, which says the following:
>
The should here comes from the IPv6 fragmentation. I wouldn't want to  
burden the middlebox with packet assembly. Therefore I have put the  
SHOULD there. If the SHOULD if the contradiction to the base draft is  
problematic we can change it to a lowercase "should" or refer to the  
base draft.

>    "the maximum length of the HIP Parameters field is (255*8)-32 =  
> 2008
>    bytes"
>
>    And added to this the HIP header its about twice the size suggested
>    in middle-auth-00. If "SHOULD" is changed to "should", then it  
> would
>    just say it would be preferred that the size would not exceed 1280.
>    This is a valid concern, but i think "should" was meant and not
>    carefully weighted maybe i'll do otherwise. And continuing with  
> this
>    thought I think the fragmentation and packet size limits should be
>    handled in base-10.
>
> 4) One request-response parameter pair can do the same job as two  
> pairs.
>    PUZZLE_M and SOLUTION_M already have the opaque value in them. If
>    longer opaque is needed then something similar to the following  
> would
>    suffice.
...
>    into zero.
>
I agree that the two parameters could be condensed to just one  
parameter. However, the reason why I chose that thwo parameters would  
be beneficial is that I suspect that the puzzle will only be needed  
rarely (i.e under attack conditions). Using the puzzle even for  
normal operation requires transmit 9 additional bytes for the puzzle  
and 17 additional bytes for the solution.  With regard to the  
restricted space in the HIP packets and the possibility of having  
cascaded middleboxes, I thought separating the puzzle form the  
echo_request to save space would be a good idea.

> 5) As an suggestion or an answer to the following
>
>    "- Andrew McGregor raised concern about having responders solve
>    puzzles, but otherwise voiced support for developing this further"
>
>   I suggest two possible ways to delegate the Responders middlebox
>   puzzle to the Initiator to be solved.
>
>
...
>
>   In my opinion the Extended 2 is a cleaner way to do the  
> delegation of
>   Responders middlebox puzzle to the Initiator. Its not a novel idea,
>   but it should work. In both of these ways the Responder at least has
>   to sign the puzzle so verifying that it owns the secret key to this
>   identity.
>

I believe that pushing the puzzle to the initiator is a good  
workaround for the problem. I'm just not sure if it wouldn't be  
easier to let the middlebox hand over two puzzles to the initiator of  
which the initiators solves both and sends one solution to the  
responder. Having all these additional HIP messages during the  
handshake seems to be overkill.

BR,

Tobias

> BR,
> Samu Varjonen
> samu.varjonen at hiit.fi

-- Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
http://ds.cs.rwth-aachen.de/members/heer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2448 bytes
Desc: not available
Url : https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20080123/88c741c8/attachment-0001.bin 

From: heer at cs.rwth-aachen.de (Tobias Heer)
Date: Wed, 23 Jan 2008 14:05:57 +0100
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Julien,

Thanks for your comments, find my comments in-line.

Am 23.01.2008 um 11:43 schrieb Julien Laganier:

> Hello Miika,
>
> On Tuesday 22 January 2008, Miika Komu wrote:
>> On Mon, 21 Jan 2008, Henderson, Thomas R wrote:
>>> Questions or comments raised during the RG presentation:
>>> - Philip Matthews raised some questions about the relevance of the
>>> use case described (access point sharing, and the assumptions on
>>> the location of the attackers) and whether HIP was the right
>>> solution for this (versus, for example, WPA).  He also suggested to
>>> look at other work in IETF on how to talk to middleboxes
>>
>> WPA is used wireless networks and it does not solve the problem for
>> wired networks.
>
> WPA is a specification of the Wi-Fi Alliance that implements (most)  
> IEEE
> 802.11i specification.
>
> IEEE 802.11i specifies security for 802.11 wireless media, and  
> relies on
> IEEE 802.1x which is a network access control/authentication  
> mechanisms
> for 802 style media.
>
> Thus, IEEE 802.1x is not limited to wireless or wired, and can  
> perfectly
> be used with IEEE 802.3 media, a.k.a. Ethernet.
>
>> I am not an wireless expert, but I believe you need
>> something like RADIUS to create individual WPA keys for each host,
>> right? Otherwise hosts can snoop each others traffic and do the
>> attack described in the draft.
>
> IEEE 802.1x does not require a AAA infrastructure per se, it is an
> underlying layer for EAP. However, for scalability reasons you might
> want to centralize credentials in a AAA server so that credentials  
> need
> not be distributed to all access points.
>
>> Also, WPA is usually used at the edge and it does not solve the
>> problem when the multiple middleboxes on the path.
>
> W.r.t. edge vs. multiple midboxes on-path, if network access
> control/authentication is the goal, it is sufficient to perform it
> once, at the edge.
>
Thank you for the clarifications on WI-Fi protection.
However, I would like to move away from this Wi-Fi protection  
discussion because it is not part of the draft.
The usecase of Wi-Fi sharing was only used to highlight one possible  
application of HIP. This application
demands that a middlebox can verify the identities of communicating  
hosts by observing the HIP handshake.
This scenario is not limited to Wi-Fi sharing but is also relevant  
for other usecases.
The scope of the draft is to illustrate a possible replay attack  
towards the middlebox and proposes a solution that enables the  
middlebox to interact with the BEX.

> I think the draft should more accurately state what is the goal,
> security-wise. E.g. authentication alone is vague and prone to
> ambiguous interpretation. Once that is done, relevance of the solution
> can be assessed.
Do you think the title is misleading or do you believe we should be  
more specific in the abstract and text?

Thanks for your comments,

Tobias

>
>> I don't think that we should force dependencies to some other
>> protocols in a *HIP* middlebox... does not make much sense to me.
>>
>> As a conclusion, I think the middlebox draft from Tobias makes a lot
>> of sense for replay protection for middleboxes.
>
> I think we should first determine what's the goal pursued. Then we can
> decide if the specific solution makes sense.
>

> My 2 cents.
>
> --julien
>
>

--  
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
http://ds.cs.rwth-aachen.de/members/heer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20080123/865a18b9/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2448 bytes
Desc: not available
Url : https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20080123/865a18b9/attachment.bin 

From: heer at cs.rwth-aachen.de (Tobias Heer)
Date: Wed, 23 Jan 2008 13:48:36 +0100
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Samu,

Thanks for your comments. See my comments inline.

Am 23.01.2008 um 10:26 schrieb Samu Varjonen:

> Hi,
>
> Miika Komu wrote:
>
>> As a conclusion, I think the middlebox draft from Tobias makes a  
>> lot of sense for replay protection for middleboxes.
>
> I agree with Miika that replay protection makes sense but I have  
> few comments about the draft.
>
> Here is some comments on the draft-heer-hip-middle-auth-00
> ==========================================================
> First some small nitpicks. Then something more interesting.
>
> 1) Fig.1 says that R2 is sent from Initator to Responder. (arrows
>    point to wrong direction)
Thanks for pointing that out. I'll fix this with the next version.

>
> 2) Section 1.1. where it discusses about X and Y. It could be clearer
>    in form
>    "Middlebox has no way to distinguish legimate users X and Y from
>    attackers A and B..."
>    or
>    "Middlebox has no way to distinguish X and Y from A and B"
Ok, I agree that should be expressed in a clearer form.

> 3) Section 2.1.1. discusses about the maximum size of total length
>    of the packets (R1, I2, R2 and UPDATE affected). should not exceed
>    ove 1280 bytes, because of IPv6 fragmentation. This statement uses
>    capitalized SHOULD and I think that in practise this contradicts
>    with base-10, which says the following:
>
The should here comes from the IPv6 fragmentation. I wouldn't want to  
burden the middlebox with packet assembly. Therefore I have put the  
SHOULD there. If the SHOULD if the contradiction to the base draft is  
problematic we can change it to a lowercase "should" or refer to the  
base draft.

>    "the maximum length of the HIP Parameters field is (255*8)-32 =  
> 2008
>    bytes"
>
>    And added to this the HIP header its about twice the size suggested
>    in middle-auth-00. If "SHOULD" is changed to "should", then it  
> would
>    just say it would be preferred that the size would not exceed 1280.
>    This is a valid concern, but i think "should" was meant and not
>    carefully weighted maybe i'll do otherwise. And continuing with  
> this
>    thought I think the fragmentation and packet size limits should be
>    handled in base-10.
>
> 4) One request-response parameter pair can do the same job as two  
> pairs.
>    PUZZLE_M and SOLUTION_M already have the opaque value in them. If
>    longer opaque is needed then something similar to the following  
> would
>    suffice.
>
>    PUZZLE_M:
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |             Type              |             Length            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | K, 1 byte     |    Reserved   |        Opaque length          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Opaque (variable len)                     | Padding (var.len.)|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Random # I, 8 bytes                                           |
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    SOLUTION_M:
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |             Type              |             Length            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | K, 1 byte     |    Reserved   |        Opaque length          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Opaque (variable len)                     | Padding (var.len.)|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Random # I, 8 bytes                                           |
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Puzzle solution #J, 8 bytes                                   |
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    Now if K is zero then there is no puzzle in the parameter.  
> Similarly
>    if opaque length is zero there is no opaque number in the  
> parameter.
>    Either or both should be present when sending PUZZLE_M and answer
>    should be constructed accordingly. If needed padding added to  
> the end
>    of opaque number. Opaque number + padding modulus 32 should result
>    into zero.
>
I agree that the two parameters could be condensed to just one  
parameter. However, the reason why I chose that thwo parameters would  
be beneficial is that I suspect that the puzzle will only be needed  
rarely (i.e under attack conditions). Using the puzzle even for  
normal operation requires transmit 9 additional bytes for the puzzle  
and 17 additional bytes for the solution.  With regard to the  
restricted space in the HIP packets and the possibility of having  
cascaded middleboxes, I thought separating the puzzle form the  
echo_request to save space would be a good idea.

> 5) As an suggestion or an answer to the following
>
>    "- Andrew McGregor raised concern about having responders solve
>    puzzles, but otherwise voiced support for developing this further"
>
>   I suggest two possible ways to delegate the Responders middlebox
>   puzzle to the Initiator to be solved.
>
>   Original:
>   Figure 1: Middlebox authentication of a HIP base exchange.
>
>   Main path:
>
>   Initiator                Middlebox                         Responder
>                        .-----------------.
>    I1                  |                 |  I1
>   -------------------> |                 |  
> ---------------------------->
>                        |                 |
>    R1, + EQ1, [PM1]    | Add EQ1, PM1    |  R1
>   <------------------- |                 |  
> <----------------------------
>                        |                 |
>    I2, {ER1, SM1}      | Verify SM1, EQ1 |  I2, {ER1, SM1} + EQ2,  
> [PM2]
>   -------------------> | Add EQ2, PM2    |  
> --------------------------->
>                        |                 |
>                        |                 |
>    R2, {ER2, SM2}      | Verify SM2, ER2 |  R2, {ER2, SM2}
>   -------------------> |                 |  
> ---------------------------->
>                        '-----------------'
>
>   EQ: Middlebox Echo reQuest
>   ER: Middlebox Echo Response
>   PM: Puzzle of the Middlebox
>   SM: Solution of Middlebox puzzle
>
>   How Responder could move the puzzle to the Initiator.
>   In the extended version 1, I show how you could utilize the fact  
> that
>   the Initiator will process second R1 received in I2-SENT state and
>   send a second I2. This second R1 is used to carry the puzzle  
> given by
>   the middlebox to the Initiator of the BEX.
>
>   Copy-paste from base-10
>   ...
>    System behaviour in state I2-SENT, Table 4.
>
>    +--------------------- 
> +---------------------------------------------+
>    | Trigger             |  
> Action                                      |
>    +--------------------- 
> +---------------------------------------------+
>    | Receive I1          | Send R1 and stay at I2- 
> SENT                 |
>    |                      
> |                                             |
>    | Receive R1, process | If successful, send I2 and cycle at I2- 
> SENT |
>   ...
>
>   Extended 1:
>   Figure 1: Middlebox authentication of a HIP base exchange.
>
>   Main path:
>
>   Initiator                Middlebox                         Responder
>                        .-----------------.
>    I1                  |                 |  I1
>   -------------------> |                 |  
> ---------------------------->
>                        |                 |
>    R1, + EQ1, PM1      | Add EQ1, PM1    |  R1
>   <------------------- |                 |  
> <----------------------------
>                        |                 |
>    I2, {ER1, SM1}      | Verify SM1, EQ1 |  I2, {ER1, SM1} + EQ2, PM2
>   -------------------> | Add EQ2, PM2    |  
> --------------------------->
>                        |                 |
>    R1, {EQ2, PM2}      | Verify EQ2, PM2 |  R1, {EQ2, PM2}
>   <------------------- |                 |  
> <----------------------------
>                        |                 |
>    I2, {ER2, SM2}      | Verify SM2, PM2 |  I2, {ER2, SM2}
>   -------------------> |                 |  
> ---------------------------->
>                        |                 |
>    R2                  |                 |  R2
>   <------------------- |                 |  
> <----------------------------
>                        '-----------------'
>
>   EQ: Middlebox Echo reQuest
>   ER: Middlebox Echo Response
>   PM: Puzzle of the Middlebox
>   SM: Solution of Middlebox puzzle
>
>   On the other hand Initiator, Responder and the Middlebox could  
> use the
>   registration extension (draft-ietf-hip-registration-02), for service
>   ESP on the middlebox. But this needs firewall on middlebox to set  
> the
>   ESP ports open for the HIT pair.
>
>   Extended 2:
>   Figure 1: Middlebox authentication of a HIP base exchange.
>
>   Main path:
>
>   Initiator                Middlebox                         Responder
>                        .-----------------.
>    I1                  |                 |  I1
>   -------------------> |                 |  
> ---------------------------->
>                        |                 |
>    R1, RN(ESP)         | Add EQ1, PM1    |  R1, RN(ESP)
>   <------------------- |                 |  
> <----------------------------
>                        |                 |
>    I2, RR(ESP) +       |                 |  I2, RR(ESP) + {ER1, SM1} +
>        {ER1, SM1}      | Verify SM1, EQ1 |      EQ2, PM2
>   -------------------> | Add EQ2, PM2    |  
> --------------------------->
>                        |                 |
>    R2, RF({EQ2, PM2})  | Verify PM2, EQ2 |  R2, RF({EQ2, PM22})
>   <------------------- |                 |  
> <----------------------------
>                        |                 |
>    UPDATE, RR(ESP) +   |                 |  UPDATE, RR(ESP) +
>            {ER2, SM2}  | Verify ER2, SM2 |          {ER2, SM2}
>   -------------------> |                 |  
> --------------------------->
>                        |                 |
>    UPDATE, RQ(OK)      | Open ports for  |  UPDATE, RQ(OK)
>   <------------------- | ESP traffic     |  
> <----------------------------
>                        '-----------------'
>
>   EQ: Middlebox Echo reQuest
>   ER: Middlebox Echo Response
>   PM: Puzzle of the Middlebox
>   SM: Solution of Middlebox puzzle
>   RN: Registry iNfo
>   RQ: Registry reQuest
>   RR: Registry Responde
>   RF: Registry Failed
>
>   In my opinion the Extended 2 is a cleaner way to do the  
> delegation of
>   Responders middlebox puzzle to the Initiator. Its not a novel idea,
>   but it should work. In both of these ways the Responder at least has
>   to sign the puzzle so verifying that it owns the secret key to this
>   identity.
>

I believe that pushing the puzzle to the initiator is a good  
workaround for the problem. I'm just not sure if it wouldn't be  
easier to let the middlebox hand over two puzzles to the initiator of  
which the initiators solves both and sends one solution to the  
responder. Having all these additional HIP messages during the  
handshake seems to be overkill.

BR,

Tobias

> BR,
> Samu Varjonen
> samu.varjonen at hiit.fi

--  
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
http://ds.cs.rwth-aachen.de/members/heer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20080123/e77690c4/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2448 bytes
Desc: not available
Url : https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20080123/e77690c4/attachment-0001.bin 

From: heer at cs.rwth-aachen.de (Tobias Heer)
Date: Wed, 23 Jan 2008 13:08:52 +0100
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Miika, Philip, and Tom.
Am 22.01.2008 um 17:15 schrieb Miika Komu:

> On Mon, 21 Jan 2008, Henderson, Thomas R wrote:
>
> Hi,
>
>> Questions or comments raised during the RG presentation:
>> - Philip Matthews raised some questions about the relevance of the  
>> use
>> case described (access point sharing, and the assumptions on the
>> location of the attackers) and whether HIP was the right solution for
>> this (versus, for example, WPA).  He also suggested to look at other
>> work in IETF on how to talk to middleboxes
>
In the draft, we are not trying to invent a new way to talk to  
middleboxes. We are targeting a specific weakness in the HIP protocol  
and we try to fix it in a simple and HIP-like (HIP compatible) way. I  
agree that the weakness is quite specific and I also agree that the  
weakness only shows if HIP is used to authenticate towards third  
parties during the BEX but I think we should address this issue and  
provide a solution.

> WPA is used wireless networks and it does not solve the problem for  
> wired
> networks. I am not an wireless expert, but I believe you need  
> something
> like RADIUS to create individual WPA keys for each host, right?  
> Otherwise
> hosts can snoop each others traffic and do the attack described in the
> draft.
Yes, WPA and a RADIUS server with TTLS EAP authentication can solve  
the problem of eavesdropping in wireless networks. However, this  
requires to deploy a RADIUS server, to separately manage user  
identities, and to perform different authentication. When using the  
combination WPA + RADIUS + HIP there are many things done twice.
Coming back to the issue of eavesdropping and Wi-Fi sharing.  
Eavesdropping on the wireless link is not the only threat here. A  
malicious access point can also eavesdrop on a user's traffic. WPA  
won't help here. The same is true for every other malicious device on  
the Access point's uplink.

Regarding the draft:
It is written to be quite general and the proposed mechanism can be  
used for other scenarios than for Wi-Fi sharing. Wi-Fi sharing was  
only the initial driver and motivation for beginning this work. The  
aim of the draft is to prevent replay attacks on authenticating  
middleboxes. I believe that other scenarios (e.g. HIP firewalls)  
require for such protection as well. I believe that HIP was designed  
to enable authentication by middleboxes (e.g. the RSA and DSA  
signatures in the UPDATE messages are not needed if third-party  
authentication is not a goal). It would be nice if HIP would actually  
enable to use this feature in a secure way.

> Also, WPA is usually used at the edge and it does not
> solve the problem when the multiple middleboxes on the path.
>
This is right. As mentioned above, the eavesdropping is not  
necessarily done on the wireless link. It can be done at any location  
on the path between the Initiator and the Responder.

> I don't think that we should force dependencies to some other
> protocols in a *HIP* middlebox... does not make much sense to me.
>
I agree. IMO, if people want to support authentication and access  
control based on HIs, there should be a secure HIP mechanism to aid  
this. Otherwise, the concept of the new cryptographic namespace seems  
incomplete to me.

Thanks for your comments so far, I'm looking forward to more discussion.

> As a conclusion, I think the middlebox draft from Tobias makes a  
> lot of
> sense for replay protection for middleboxes.
>
> -- 
> Miika Komu                                       http://www.iki.fi/ 
> miika/
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg at listserv.cybertrust.com
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg

-- Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
http://ds.cs.rwth-aachen.de/members/heer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2448 bytes
Desc: not available
Url : https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20080123/337e85ff/attachment-0001.bin 

From: julien.IETF at laposte.net (Julien Laganier)
Date: Wed, 23 Jan 2008 11:43:11 +0100
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello Miika,

On Tuesday 22 January 2008, Miika Komu wrote:
> On Mon, 21 Jan 2008, Henderson, Thomas R wrote:
> > Questions or comments raised during the RG presentation:
> > - Philip Matthews raised some questions about the relevance of the
> > use case described (access point sharing, and the assumptions on
> > the location of the attackers) and whether HIP was the right
> > solution for this (versus, for example, WPA).  He also suggested to
> > look at other work in IETF on how to talk to middleboxes
>
> WPA is used wireless networks and it does not solve the problem for
> wired networks. 

WPA is a specification of the Wi-Fi Alliance that implements (most) IEEE 
802.11i specification. 

IEEE 802.11i specifies security for 802.11 wireless media, and relies on 
IEEE 802.1x which is a network access control/authentication mechanisms 
for 802 style media. 

Thus, IEEE 802.1x is not limited to wireless or wired, and can perfectly 
be used with IEEE 802.3 media, a.k.a. Ethernet.

> I am not an wireless expert, but I believe you need 
> something like RADIUS to create individual WPA keys for each host,
> right? Otherwise hosts can snoop each others traffic and do the
> attack described in the draft. 

IEEE 802.1x does not require a AAA infrastructure per se, it is an 
underlying layer for EAP. However, for scalability reasons you might 
want to centralize credentials in a AAA server so that credentials need 
not be distributed to all access points.

> Also, WPA is usually used at the edge and it does not solve the
> problem when the multiple middleboxes on the path.

W.r.t. edge vs. multiple midboxes on-path, if network access 
control/authentication is the goal, it is sufficient to perform it 
once, at the edge.

I think the draft should more accurately state what is the goal, 
security-wise. E.g. authentication alone is vague and prone to 
ambiguous interpretation. Once that is done, relevance of the solution 
can be assessed.

> I don't think that we should force dependencies to some other
> protocols in a *HIP* middlebox... does not make much sense to me.
>
> As a conclusion, I think the middlebox draft from Tobias makes a lot
> of sense for replay protection for middleboxes.

I think we should first determine what's the goal pursued. Then we can 
decide if the specific solution makes sense.

My 2 cents.

--julien

From: samu.varjonen at helsinki.fi (Samu Varjonen)
Date: Wed, 23 Jan 2008 11:26:51 +0200
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

Miika Komu wrote:

> As a conclusion, I think the middlebox draft from Tobias makes a lot of 
> sense for replay protection for middleboxes.
> 

I agree with Miika that replay protection makes sense but I have few 
comments about the draft.

Here is some comments on the draft-heer-hip-middle-auth-00
==========================================================
First some small nitpicks. Then something more interesting.

1) Fig.1 says that R2 is sent from Initator to Responder. (arrows
    point to wrong direction)

2) Section 1.1. where it discusses about X and Y. It could be clearer
    in form
    "Middlebox has no way to distinguish legimate users X and Y from
    attackers A and B..."
    or
    "Middlebox has no way to distinguish X and Y from A and B"

3) Section 2.1.1. discusses about the maximum size of total length
    of the packets (R1, I2, R2 and UPDATE affected). should not exceed
    ove 1280 bytes, because of IPv6 fragmentation. This statement uses
    capitalized SHOULD and I think that in practise this contradicts
    with base-10, which says the following:

    "the maximum length of the HIP Parameters field is (255*8)-32 = 2008
    bytes"

    And added to this the HIP header its about twice the size suggested
    in middle-auth-00. If "SHOULD" is changed to "should", then it would
    just say it would be preferred that the size would not exceed 1280.
    This is a valid concern, but i think "should" was meant and not
    carefully weighted maybe i'll do otherwise. And continuing with this
    thought I think the fragmentation and packet size limits should be
    handled in base-10.

4) One request-response parameter pair can do the same job as two pairs.
    PUZZLE_M and SOLUTION_M already have the opaque value in them. If
    longer opaque is needed then something similar to the following would
    suffice.

    PUZZLE_M:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Type              |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | K, 1 byte     |    Reserved   |        Opaque length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Opaque (variable len)                     | Padding (var.len.)|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Random # I, 8 bytes                                           |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    SOLUTION_M:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Type              |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | K, 1 byte     |    Reserved   |        Opaque length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Opaque (variable len)                     | Padding (var.len.)|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Random # I, 8 bytes                                           |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Puzzle solution #J, 8 bytes                                   |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Now if K is zero then there is no puzzle in the parameter. Similarly
    if opaque length is zero there is no opaque number in the parameter.
    Either or both should be present when sending PUZZLE_M and answer
    should be constructed accordingly. If needed padding added to the end
    of opaque number. Opaque number + padding modulus 32 should result
    into zero.

5) As an suggestion or an answer to the following

    "- Andrew McGregor raised concern about having responders solve
    puzzles, but otherwise voiced support for developing this further"

   I suggest two possible ways to delegate the Responders middlebox
   puzzle to the Initiator to be solved.

   Original:
   Figure 1: Middlebox authentication of a HIP base exchange.

   Main path:

   Initiator                Middlebox                         Responder
                        .-----------------.
    I1                  |                 |  I1
   -------------------> |                 | ---------------------------->
                        |                 |
    R1, + EQ1, [PM1]    | Add EQ1, PM1    |  R1
   <------------------- |                 | <----------------------------
                        |                 |
    I2, {ER1, SM1}      | Verify SM1, EQ1 |  I2, {ER1, SM1} + EQ2, [PM2]
   -------------------> | Add EQ2, PM2    | --------------------------->
                        |                 |
                        |                 |
    R2, {ER2, SM2}      | Verify SM2, ER2 |  R2, {ER2, SM2}
   -------------------> |                 | ---------------------------->
                        '-----------------'

   EQ: Middlebox Echo reQuest
   ER: Middlebox Echo Response
   PM: Puzzle of the Middlebox
   SM: Solution of Middlebox puzzle

   How Responder could move the puzzle to the Initiator.
   In the extended version 1, I show how you could utilize the fact that
   the Initiator will process second R1 received in I2-SENT state and
   send a second I2. This second R1 is used to carry the puzzle given by
   the middlebox to the Initiator of the BEX.

   Copy-paste from base-10
   ...
    System behaviour in state I2-SENT, Table 4.

    +---------------------+---------------------------------------------+
    | Trigger             | Action                                      |
    +---------------------+---------------------------------------------+
    | Receive I1          | Send R1 and stay at I2-SENT                 |
    |                     |                                             |
    | Receive R1, process | If successful, send I2 and cycle at I2-SENT |
   ...

   Extended 1:
   Figure 1: Middlebox authentication of a HIP base exchange.

   Main path:

   Initiator                Middlebox                         Responder
                        .-----------------.
    I1                  |                 |  I1
   -------------------> |                 | ---------------------------->
                        |                 |
    R1, + EQ1, PM1      | Add EQ1, PM1    |  R1
   <------------------- |                 | <----------------------------
                        |                 |
    I2, {ER1, SM1}      | Verify SM1, EQ1 |  I2, {ER1, SM1} + EQ2, PM2
   -------------------> | Add EQ2, PM2    | --------------------------->
                        |                 |
    R1, {EQ2, PM2}      | Verify EQ2, PM2 |  R1, {EQ2, PM2}
   <------------------- |                 | <----------------------------
                        |                 |
    I2, {ER2, SM2}      | Verify SM2, PM2 |  I2, {ER2, SM2}
   -------------------> |                 | ---------------------------->
                        |                 |
    R2                  |                 |  R2
   <------------------- |                 | <----------------------------
                        '-----------------'

   EQ: Middlebox Echo reQuest
   ER: Middlebox Echo Response
   PM: Puzzle of the Middlebox
   SM: Solution of Middlebox puzzle

   On the other hand Initiator, Responder and the Middlebox could use the
   registration extension (draft-ietf-hip-registration-02), for service
   ESP on the middlebox. But this needs firewall on middlebox to set the
   ESP ports open for the HIT pair.

   Extended 2:
   Figure 1: Middlebox authentication of a HIP base exchange.

   Main path:

   Initiator                Middlebox                         Responder
                        .-----------------.
    I1                  |                 |  I1
   -------------------> |                 | ---------------------------->
                        |                 |
    R1, RN(ESP)         | Add EQ1, PM1    |  R1, RN(ESP)
   <------------------- |                 | <----------------------------
                        |                 |
    I2, RR(ESP) +       |                 |  I2, RR(ESP) + {ER1, SM1} +
        {ER1, SM1}      | Verify SM1, EQ1 |      EQ2, PM2
   -------------------> | Add EQ2, PM2    | --------------------------->
                        |                 |
    R2, RF({EQ2, PM2})  | Verify PM2, EQ2 |  R2, RF({EQ2, PM22})
   <------------------- |                 | <----------------------------
                        |                 |
    UPDATE, RR(ESP) +   |                 |  UPDATE, RR(ESP) +
            {ER2, SM2}  | Verify ER2, SM2 |          {ER2, SM2}
   -------------------> |                 | --------------------------->
                        |                 |
    UPDATE, RQ(OK)      | Open ports for  |  UPDATE, RQ(OK)
   <------------------- | ESP traffic     | <----------------------------
                        '-----------------'

   EQ: Middlebox Echo reQuest
   ER: Middlebox Echo Response
   PM: Puzzle of the Middlebox
   SM: Solution of Middlebox puzzle
   RN: Registry iNfo
   RQ: Registry reQuest
   RR: Registry Responde
   RF: Registry Failed

   In my opinion the Extended 2 is a cleaner way to do the delegation of
   Responders middlebox puzzle to the Initiator. Its not a novel idea,
   but it should work. In both of these ways the Responder at least has
   to sign the puzzle so verifying that it owns the secret key to this
   identity.

BR,
Samu Varjonen
samu.varjonen at hiit.fi

From: jeffrey.m.ahrenholz at boeing.com (Ahrenholz, Jeffrey M)
Date: Tue, 22 Jan 2008 13:07:39 -0800
Subject: [Hipsec-rg] Issues in draft-ahrenholz-hiprg-dht-02.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Stephane,
Thanks for your comments. Responses inline below...

> -----Original Message-----
> From: Stephane Bortzmeyer [mailto:bortzmeyer at nic.fr] 
> Sent: Monday, January 21, 2008 6:41 AM
> To: Ahrenholz, Jeffrey M
> Cc: opendht-users at opendht.org; hipsec-rg at listserv.cybertrust.com
> Subject: Issues in draft-ahrenholz-hiprg-dht-02.txt
> 
> [There is no address in the Internet-Draft for the
> discussion. Therefore, I copy the HIP research group - but I'm not a
> member - and the OpenDHT mailing list, where I am subscribed.]

Yes, discussion for this draft usually occurs on the hipsec-rg list.

> 
> The "HIP DHT Interface" Internet-Draft
> (http://tools.ietf.org/html/draft-ahrenholz-hiprg-dht, I checked with
> version 02) raises two issues for me.
> 
> One is the TTL. The Internet-Draft says things like "The ttl_sec field
> used with address publish includes the time-to- live, the number of
> seconds for which the entry will be stored by the DHT" or "The
> name-to-HIT binding needs to be refreshed periodically before the TTL
> expires" which seem to assume that OpenDHT will keep the value for the
> duration of the TTL. Although it does not seem documented, I fear that
> OpenDHT is free to remove the data *before* the TTL expires, if it
> runs out of resources and that the TTL field in a put() is more an
> indication than a firm request. May be the draft should warn
> implementors that refreshing may have to be done more frequently?

This is a good point, I will update the draft to mention that the TTL is
only a hint, and a host may want to update its published values
periodically, per policy, more frequently than the stated TTL.

> 
> Another issue is the risk of collisions between keys. Two HITs can be
> identical (the RFCs on HIP probably cover the case) but, more
> important, you may have a collision between a HIT and another,
> unrelated key, in OpenDHT. This does not seem clearly documented but
> experience indicates that OpenDHT keys are global, not
> per-application, so if an unrelated application chooses a key which
> collides with a HIT, the advice "when performing an address lookup,
> the *last* HDRR in the DHT response list should be used and considered
> to contain the current preferred address" is probably
> dangerous. (There is apparently no way in OpenDHT to filter results
> based on the application string.)

I didn't know that the application string provides no separation. The
signature and Host Identity in the HDRR will need to be verified by the
client before using it, so that is one protection. Maybe each HDRR
should contain a monotonically increasing counter (like the SEQ
UPDATE_ID in the HIP UPDATE packet) and the client should use the HDRR
that has the greatest counter value. This would also help against an
attack using replayed PUT packets.

-Jeff

From: miika at iki.fi (Miika Komu)
Date: Tue, 22 Jan 2008 18:15:56 +0200 (EET)
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 21 Jan 2008, Henderson, Thomas R wrote:

Hi,

> Questions or comments raised during the RG presentation:
> - Philip Matthews raised some questions about the relevance of the use
> case described (access point sharing, and the assumptions on the
> location of the attackers) and whether HIP was the right solution for
> this (versus, for example, WPA).  He also suggested to look at other
> work in IETF on how to talk to middleboxes

WPA is used wireless networks and it does not solve the problem for wired 
networks. I am not an wireless expert, but I believe you need something 
like RADIUS to create individual WPA keys for each host, right? Otherwise 
hosts can snoop each others traffic and do the attack described in the 
draft. Also, WPA is usually used at the edge and it does not 
solve the problem when the multiple middleboxes on the path.

I don't think that we should force dependencies to some other 
protocols in a *HIP* middlebox... does not make much sense to me.

As a conclusion, I think the middlebox draft from Tobias makes a lot of 
sense for replay protection for middleboxes.

-- 
Miika Komu                                       http://www.iki.fi/miika/

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Mon, 21 Jan 2008 15:38:17 -0800
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
Message-ID: <[email-masked]>

Hi all,

Those of you who attended the Vancouver meeting will recall the
presentation by Tobias Heer regarding PISA and authentication extensions
for HIP exchanges:

http://tools.ietf.org/id/draft-heer-hip-middle-auth-00.txt
http://www3.ietf.org/proceedings/07dec/slides/HIPRG-4.pdf

We agreed at the meeting to discuss on the list any further questions
about this draft and whether the RG would commit to making the
extensions described (support for middleboxes adding nonces to HIP
messages) a RG work item.

Questions or comments raised during the RG presentation:
- Philip Matthews raised some questions about the relevance of the use
case described (access point sharing, and the assumptions on the
location of the attackers) and whether HIP was the right solution for
this (versus, for example, WPA).  He also suggested to look at other
work in IETF on how to talk to middleboxes
- Miika Komu supported further work on this topic
- Andrew McGregor raised concern about having responders solve puzzles,
but otherwise voiced support for developing this further
- Martin Stiemerling suggested to clarify the preconditions/assumptions
about this work; namely, that we are talking about HIP-aware middleboxes

I would like to encourage some more discussion and questions about this
draft, and some comment on whether this is a work item that some subset
of the RG would be willing to spend cycles to develop further.  If
sufficient interest is expressed, it could be a candidate for an
IRTF-track document:
http://tools.ietf.org/id/draft-irtf-rfcs-01.txt
such as what we previously did with the NAT traversal problem statement.

Please speak up if you would like to participate in developing the above
work as a RG item, or if you have further questions.

Thanks,
Tom

From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Mon, 21 Jan 2008 15:41:29 +0100
Subject: [Hipsec-rg] Issues in draft-ahrenholz-hiprg-dht-02.txt
Message-ID: <[email-masked]>

[There is no address in the Internet-Draft for the
discussion. Therefore, I copy the HIP research group - but I'm not a
member - and the OpenDHT mailing list, where I am subscribed.]

The "HIP DHT Interface" Internet-Draft
(http://tools.ietf.org/html/draft-ahrenholz-hiprg-dht, I checked with
version 02) raises two issues for me.

One is the TTL. The Internet-Draft says things like "The ttl_sec field
used with address publish includes the time-to- live, the number of
seconds for which the entry will be stored by the DHT" or "The
name-to-HIT binding needs to be refreshed periodically before the TTL
expires" which seem to assume that OpenDHT will keep the value for the
duration of the TTL. Although it does not seem documented, I fear that
OpenDHT is free to remove the data *before* the TTL expires, if it
runs out of resources and that the TTL field in a put() is more an
indication than a firm request. May be the draft should warn
implementors that refreshing may have to be done more frequently?

Another issue is the risk of collisions between keys. Two HITs can be
identical (the RFCs on HIP probably cover the case) but, more
important, you may have a collision between a HIT and another,
unrelated key, in OpenDHT. This does not seem clearly documented but
experience indicates that OpenDHT keys are global, not
per-application, so if an unrelated application chooses a key which
collides with a HIT, the advice "when performing an address lookup,
the *last* HDRR in the DHT response list should be used and considered
to contain the current preferred address" is probably
dangerous. (There is apparently no way in OpenDHT to filter results
based on the application string.)

From: miika at iki.fi (Miika Komu)
Date: Sat, 19 Jan 2008 01:24:54 +0200 (EET)
Subject: [Hipsec-rg] hipl release 1.0.3
Message-ID: <[email-masked]>

Hi,

hipl release 1.0.3 is out! It includes binaries for Ubuntu, Fedora and 
Nokia tablets. The release is located here:

http://hipl.hiit.fi/hipl/release/1.0.3/

-- 
Miika Komu                                       http://www.iki.fi/miika/

From: gurtov at cs.helsinki.fi (Andrei Gurtov)
Date: Thu, 17 Jan 2008 11:50:41 +0200
Subject: [Hipsec-rg] minutes and slides from the previous HIPRG meeting
Message-ID: <[email-masked]>

Minutes and slides from the previous HIPRG meeting (IETF 70)
are available in IETF proceedings:

http://www3.ietf.org/proceedings/07dec/index.html

Andrei

From: gurtov at cs.helsinki.fi (Andrei Gurtov)
Date: Wed, 16 Jan 2008 17:53:39 +0200
Subject: [Hipsec-rg] meeting at IETF 71st
Message-ID: <[email-masked]>

We have tentatively requested a 2-hour meeting slot for HIP RG meeting
in IETF 71st in Philadelphia. Our preference is Friday morning, although
we don't know of the actual slot yet.

If you're interested in presenting your HIP-related research work at the
meeting, please let me and Tom know.

Andrei

From: jeffrey.m.ahrenholz at boeing.com (Ahrenholz, Jeffrey M)
Date: Mon, 14 Jan 2008 11:34:44 -0800
Subject: [Hipsec-rg] FW: I-D ACTION:draft-ahrenholz-hiprg-dht-02.txt
Message-ID: <[email-masked]>

Here is an update to the DHT draft containing some changes discussed on
this list.
This uses Samu's proposed resolver packet as a "HIP DHT Resource
Record". 
Here is the changelog:

A.1.  Changes from Version 01 to 02

   sockaddr address format changed to use HIP DHT Resource Record
   containing the HIP LOCATOR format.  The HIT prefix is dropped before
   using it as a key.  Separate "secure" service was dropped, and
   signatures made mandatory.  Legacy versus hip-aware DHT servers are
   distinguished.  Text packet examples added.

-Jeff

-----Original Message-----
From: Internet-Drafts at ietf.org [mailto:Internet-Drafts at ietf.org] 
Sent: Monday, January 14, 2008 11:15 AM
To: i-d-announce at ietf.org
Subject: I-D ACTION:draft-ahrenholz-hiprg-dht-02.txt 

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: HIP DHT Interface
	Author(s)	: J. Ahrenholz
	Filename	: draft-ahrenholz-hiprg-dht-02.txt
	Pages		: 24
	Date		: 2008-1-14
	
This document specifies a common interface for using HIP with a
   Distributed Hash Table service to provide a HIT-to-address lookup
   service and an unmanaged name-to-HIT lookup service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ahrenholz-hiprg-dht-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ahrenholz-hiprg-dht-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv at ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ahrenholz-hiprg-dht-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

From: shep at alum.mit.edu (Tim Shepard)
Date: Tue, 08 Jan 2008 18:50:15 -0500
Subject: [Hipsec-rg] Garbage-collecting LSIs?
In-Reply-To: Your message of Thu, 20 Dec 2007 08:39:32 -0500. <[email-masked]> 
Message-ID: <[email-masked]>

> Right now, I understand that the 1/8 space is being used in all three  
> implementations, which is currently marked as "reserved" by IANA.  
> While this is sufficient for research purposes, I think this is not  
> sufficient for production use.

I'm still fond of using part of 127.0.0.0/8 for LSI's, something like
127.128.0.0/9 with 23 bits to play with, and I believe that was tried
but some problem was found in linux where linux's knowledge of
127.0.0.0/8 was a little bit too hardwired into the kernel and caused
problems for one of the HIP implementations which was entirely in
userspace.

Can we try using LSIs in 127.0.0.0/8 again and see if there are any
real issues with that?  If there are any issues, might they be fixable?

			-Tim Shepard
			 shep at alum.mit.edu

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Tue, 08 Jan 2008 14:39:07 -0600
Subject: [Hipsec-rg] Garbage-collecting LSIs?
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi, Julien,

I may not have been clear enough here. I was suggesting PART OF 240/4 for 
LSIs. Since other people already have their eyes on this prefix, I don't 
think asking for a /4 is the fast path to success :-)

Thanks,

Spencer

> On Wednesday 26 December 2007, Spencer Dawkins wrote:
>> > Maybe the right answer is to progress a short document through the
>> > HIP RG or HIP WG trying to allocate 1/8 for this purpose and see
>> > what happens?
>>
>> IAB and IESG are trying to figure out what to do with 240/4 - the
>> problem is (1) this address range has lots of IPv4 addresses, but (2)
>> probably isn't routable on the global Internet because it's been
>> reserved since, like, forever.
>>
>> If you're going to go there (requesting a large IPv4 allocation for
>> LSIs, but the allocation doesn't have to be routable), you might
>> start with a request to allocate part of 240/4.
>>
>> One proposal is at
>> http://www.ietf.org/internet-drafts/draft-fuller-240space-00.txt, so
>> this is a good time to talk about possible uses.
>
> Looks like a good idea.
>
> I however have a feeling that success will be tough to reach following
> that path.
>
> Given the difficulty we encoutered to allocate a temporary /28 chunk out
> of the full /128 IPv6 address space for, amongst other purposes, HIP
> (see RFC4843), probably it's going to be a lot harder to get a /4 chunk
> out of a /32  -- not taking into account the fact that v4 allocations
> are, unlike v6 ones, a scarce resource ;-)
>
> Anyway, wish you all the best!
>
> --julien
> 

From: julien.IETF at laposte.net (Julien Laganier)
Date: Tue, 8 Jan 2008 18:43:30 +0100
Subject: [Hipsec-rg] Garbage-collecting LSIs?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday 26 December 2007, Spencer Dawkins wrote:
> > Maybe the right answer is to progress a short document through the
> > HIP RG or HIP WG trying to allocate 1/8 for this purpose and see
> > what happens?
>
> IAB and IESG are trying to figure out what to do with 240/4 - the
> problem is (1) this address range has lots of IPv4 addresses, but (2)
> probably isn't routable on the global Internet because it's been
> reserved since, like, forever.
>
> If you're going to go there (requesting a large IPv4 allocation for
> LSIs, but the allocation doesn't have to be routable), you might
> start with a request to allocate part of 240/4.
>
> One proposal is at
> http://www.ietf.org/internet-drafts/draft-fuller-240space-00.txt, so
> this is a good time to talk about possible uses.

Looks like a good idea. 

I however have a feeling that success will be tough to reach following 
that path.

Given the difficulty we encoutered to allocate a temporary /28 chunk out 
of the full /128 IPv6 address space for, amongst other purposes, HIP 
(see RFC4843), probably it's going to be a lot harder to get a /4 chunk 
out of a /32  -- not taking into account the fact that v4 allocations 
are, unlike v6 ones, a scarce resource ;-)

Anyway, wish you all the best!

--julien

From: lars.eggert at nokia.com (Lars Eggert)
Date: Tue, 8 Jan 2008 17:27:57 +0100
Subject: [Hipsec-rg] Garbage-collecting LSIs?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 2007-12-26, at 18:28, ext Spencer Dawkins wrote:
> IAB and IESG are trying to figure out what to do with 240/4 - the
> problem is (1) this address range has lots of IPv4 addresses, but (2)
> probably isn't routable on the global Internet because it's been  
> reserved
> since, like, forever.
>
> If you're going to go there (requesting a large IPv4 allocation for  
> LSIs,
> but the allocation doesn't have to be routable), you might start  
> with a
> request to allocate part of 240/4.
>
> One proposal is at
> http://www.ietf.org/internet-drafts/draft-fuller-240space-00.txt, so  
> this is
> a good time to talk about possible uses.
>
> (Unless one or more ADs quickly explains why this is a dumb idea)...

Actually, I was going to suggest the same thing :-)

Given all the potential issues with using 240/4 as routable address  
space, arguments that that space be used for something else have  
already be made (e.g., to add it to the RFC1918 "private use" list).  
Using it for HIP seems like a valid suggestion.

Lars