Subject: [Hipsec-rg] moving draft-tschofenig-hiprg-hip-natfw-traversal-03.txt to RG status
From: [email-masked] (Pekka Nikander)
Date: Thu Nov 24 09:35:01 2005

> http://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-hip- 
> natfw-tra
> versal-03.txt
>
> I would like to ask for comments on advancing this draft to RG status.

In general, I am supportive to adopting the draft.  However, I would  
suggest that the authors spend a considerable amount of time  
clarifying their meaning and making the language more exact.  I have  
indicated a number of mostly editorial problems below; however, I  
didn't have the energy to go through all of the text at the same  
detail level, generating similar comments.  However, IMHO the  
language as it stands now is somewhat sloppy; ok for conveying the  
rough message, but not something that I would like to see in an RFC.

My biggest concern is that the draft seems to be take an implicit  
stance w.r.t. asymmetric routing.  The draft proposes that for the  
case of asymmetric routing and distributed firewalls, the firewalls  
should be actively involved in the HIP base exchange.  Personally, I  
don't find the idea very appealing.  I would prefer the consider the  
distributed firewall or other middle box as a single logical unit,  
and leave the problem of distributing information between separate  
parts of a distributed middle box for the middle box.  That is,  
rather than modifying the HIP protocol, I would provide a protocol  
that allows the middle box components to deliver the necessary  
information about flow identifiers to each other.  So, rather than  
having the approach depicted in Figure 3 of the draft, I would prefer  
one which could be drawn as follows:

                    I1         +----------+         I1
        +--------------------> | Firewall | -----------------------+
        |           I2         |  Part 1  |         I2             |
        |  +-----------------> |          | ------------------+    |
        |  |                   |----------|                   v    v
    +---------+                     ^                      +---------+
    |Initiator|                |    |     |                |Responder|
    +---------+                     v                      +---------+
        ^  ^        R1         |----------|         R1        |    |
        |  +------------------ | Firewall | <-----------------+    |
        |           R2         | Part 2   |         R2             |
        +--------------------- |          | <----------------------+
                               +----------+

To put my argument differently, I don't understand how the situation  
of Figure 3 (in the draft) could be created in real life.  In any  
sensible setting, any set of firewalls protecting a part of a network  
will be under a single administration.  That is, in essence, captured  
in the modified picture above.

But this is certainly something that we need to discuss.  I may well  
be wrong and just not understand the draft.

Substantial comments:
=====================

> HIP is liable to all known incompatibilities of IPsec with  
> middleboxes such as NATs [RFC3022]    and firewalls.

This is not true.  In principle, if a NAT passes ESP traffic by just  
modifying the IP addresses, this is NOT a problem for HIP, as the  
transport checksums will still verify correctly.

Stylistic and language comments to Abstract and Introduction
============================================================
(Note that there are also similar problems later in the text, but I  
didn'

Semi substantial:

>    and Firewalls) to participate in the base exchange messages in  
> order

I don't understand what "participate in the ... messages" means.   
Either participate in the exchange, or inspect messages.   
Editorially, I think it is better say "allows participating" or  
"allows inspecting" than "allows to participate" or "allows to  
inspect".  But YMMV.

>    to learn the flow identifier and thereby, relying the data traffic.

What is "the flow identifier"?  I find the expression ill-defined in  
this context.  I know, you define it in Section 2, but Abstract  
should stand alone, without the rest of the text.

Secondly, (and more editorially) I don't understand the structure of  
the last part of the sentence, "and thereby, relying the data  
traffic".  If it is meant to be "it allows the middleboxes ...  
relying the data traffic", make sure that the verb form matches the  
one before.

>    An IP address serves the dual role of a locator and an  
> identifier for
>    every host on the Internet.  Since, the transport layer connections
>    are bound to the IP address, end systems that use IP addresses as
>    identifiers cannot support dynamic changes in the mapping  
> between the
>    identifier and the locator in case of multi-homing and mobility.

I think that the message of this paragraph is imprecise.  Mobile IP  
does exactly what this paragraph says is impossible, and so will  
SHIM6.  Please rephrase.

Editorial:

>    SAs to protect subsequent data traffic.  HIP is designed to be a
>    middlebox friendly protocol, it allows the middleboxes (such as  
> NATs

Either add an "As" before "HIP" or, preferably, replace the comma  
with a semicolon.

>    Adding authentication and authorization mechanisms can help the

Adding to what?  Adding to the current Internet architecture?  Please  
be more specific.

>    An IP address serves the dual role of a locator and an  
> identifier for

Add to the beginning:  In the current Internet architecture,

>    every host on the Internet.  Since, the transport layer connections

Remove the comma, replace "Since" with "As" following RFC Editor's  
guidelines,
and remove the definitive article as you are introducing connections  
and not
referring to some connections that you have mentioned earlier.

                 ....  Internet.  As transport layer connections

>    The Host Identity Protocol (HIP) [I-D.ietf-hip-base] proposes to
>    separate the identifier from the locator by adding an additional

Please add the word "role" to appropriate places to be more precise.

From: [email-masked] (Andrei Gurtov)
Date: Mon Nov 21 06:46:00 2005
Subject: [Hipsec-rg] Two Master's theses ready
Message-ID: <[email-masked]>

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_courier-14077-1132573515-0001-2
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Two HIP-related Master's theses have been recently completed in InfraHIP 
project:
http://infrahip.hiit.fi/publications.html

E. Vehmersalo, Host Identity Protocol Enabled Firewall: A Prototype 
Implementation and Analysis 
<http://infrahip.hiit.fi/papers/essi_dippa.pdf>, Master's thesis, TKK, 
September 2005.

N. Karlsson, Enabling Multiple Host Identities on Linux 
<http://infrahip.hiit.fi/papers/niklas_dippa.pdf>, Master's thesis, TKK, 
September 2005.

Corresponding implementations available below
http://hipl.hiit.fi/cgi-bin/archzoom.cgi/[email-masked]?expand

A new Master's thesis on HIP Privacy Support has been started at TKK by 
Laura Takkinen, [email-masked]

Andrei

--=_courier-14077-1132573515-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_courier-14077-1132573515-0001-2--

From: [email-masked] (Yogesh Prem Swami)
Date: Fri Nov 18 18:58:01 2005
Subject: [Hipsec-rg] identity-based cryptography
In-Reply-To: <[email-masked]>
References: <[email-masked]>	 <[email-masked]>  <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7B09662B81D37CCDFF58A82C
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

> In my opinion the PKG must be even more trustworthy than a CA. A CA just
> ensures that a 'name - key' mapping is correct. A PKG uses a master key
> to create private keys for its clients. Therefore, the PKG is able to
> decrypt all messages which were sent to its clients.

Yes, this is an issue. Jon Callas (PGP corp.) has some slides on the 
issues with IBE. Here's the link to his slides:
 
http://middleware.internet2.edu/pki05/proceedings/callas-conventional_ibe-presentation.pdf

> One can argue that a CA can also fool people into a man-in-the-middle-
> attack but that requres active measures during the establishment of the
> connection. If a PKG is used it is sufficient to get hold on the master
> key at a later time to decrypt recorded messages. If the PKG master key
> is compromised all messages addressed to its clients can be decrypted.
> For me this is a significant difference. Please correct me if I am
> wrong.
> 

The point about MITM I was making was somewhat different. In IBE, there 
are PKG parameters that are derived from the master secret (M). These 
parameters are often called ``well known parameters," and sometimes 
claimed to be similar to the Diffie-Hellman group parameters <g,p>. 
However, in IBE the ``well-known parameters" are specific to M (so it's 
not possible to write something like RFC3526 which once published cannot 
to be easily forged/changed). The problem with this is that if someone 
can replace the legitimate ``well-known parameters" for doamin x.y.z 
with their own PKG parameters (derived from their own master key M'), 
then they can decrypt all messages. This is a far more serious threat 
and requires some form certification (in a broad sense) that <M, x.y.z> 
is the correct binding. This brings us back to the TTP problem.

 From my perspective, DNSsec is a good design choice for HIP (why DNSsec 
is not being deployed is a different issue).

Thanks
Best Regards
Yogesh

--------------enig7B09662B81D37CCDFF58A82C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig7B09662B81D37CCDFF58A82C--

From: [email-masked] (Tobias Heer)
Date: Fri Nov 18 12:51:01 2005
Subject: [Hipsec-rg] identity-based cryptography
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>  <[email-masked]>
Message-ID: <[email-masked]>

On Thu, 2005-11-17 at 17:53 -0600, Yogesh Prem Swami wrote:
> Julien Laganier wrote:
> > On Wednesday 16 November 2005 23:29, Henderson, Thomas R wrote:
> > 
> >>What James was pointing out is that there may be a way to bind
> >>these non-cryptographic identities to the keys used by the
> >>protocol, using identity-based cryptography.  A practical benefit
> >>may be the avoidance of deploying a PKI to validate the binding
> >>between non-key-based name and the key.
> > 
> > 
> > I am not sure of the actual benefit. 

Isn't it the case that HIP requires a lookup to map a HI to an IP. Why
not just return a 'HI/HIT - DNS' mapping signed by a well known CA plus
the IP(s) in that step. That would eliminate the need to contakt the CA
to verify the 'HI - DNS' mapping at the cost of a little more bandwidth
to transfer the data. 
> 
> 
> Totally agree. Actually it might make the problem worse because the node 
> that uses ``any name" to derive the public-key must have access to the 
> right PKG parameters. If a rogue node can convince a message sender that 
> for ``for ID with ietf.org, use these PKG parameters a,b,c" then, that 
> rogue node can decrypt all messages that use "any name" as their 
> public-key. (I'm assuming that people are not proposing one giant PKG 
> run by IANA of something similar, because that won't scale.)
> 
> The problem of PKI is really a problem of having a Trusted Third Party 
> in a system as diverse as the Internet. There is no mathematical scheme 
> that can act as a third-party--there has to be a physical entity that 
> verifies end users and acts as a third party.
> > 
> > In effect, IB cryptography requires a Private Key Generator which, 
> > albeit being different from a CA, has to be common to nodes verifying 
> > each others signatures. So yes, you don't need to deploy CAs, but you 
> 
> I guess you mean each party must trust that the PKG parameters came from 
> the domain that it claims to represent. It's possible to have different 
> PKGs  at the two sides (just as having different CAs for each end-point).
> 

In my opinion the PKG must be even more trustworthy than a CA. A CA just
ensures that a 'name - key' mapping is correct. A PKG uses a master key
to create private keys for its clients. Therefore, the PKG is able to
decrypt all messages which were sent to its clients.
One can argue that a CA can also fool people into a man-in-the-middle-
attack but that requres active measures during the establishment of the
connection. If a PKG is used it is sufficient to get hold on the master
key at a later time to decrypt recorded messages. If the PKG master key
is compromised all messages addressed to its clients can be decrypted.
For me this is a significant difference. Please correct me if I am
wrong.

> It seems a lot of people have got the notion that using IBE can get rid 
> of all the PKI problems, which is not true. IBE can help with deployment 
> issues, but the real problem is of cross-domain trust. IBE cannot help 
> with that.
> 
> Thanks
> Yogesh

Tobi

-- 
Tobias Heer <[email-masked]>
HIIT - Helsinki Institute for Information Technology

From: [email-masked] (Tobias Heer)
Date: Fri Nov 18 05:18:01 2005
Subject: [Hipsec-rg] identity-based cryptography
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 2005-11-18 at 10:14 +0100, Zoltán Turányi (IJ/ETH) wrote:
> Hi,
> 
> Could please someone send me some background material on the ID based crypto (papers, links) this discussion is about? Thanks in advance,
> 
> Zoltan

I found a references list on the internet. You can find many references
to identity based PK crypotography there. 
http://ntrg.cs.tcd.ie/~argp/ibe.html

The paper about using Weil Pairing for identity based identifiers can be
found here: 
http://crypto.stanford.edu/~dabo/papers/ibe.pdf

An interesting aproach which uses hierarchical identity-based encryption
can be found here:
http://math.scu.edu/~jhorwitz/pubs/hibe.pdf
(The PKG is split up in multiple PKGs which are responsible for some
domain... this could milden the scalability problem).

Tobi

> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] 
> > Sent: Friday, November 18, 2005 9:52 AM
> > To: Henderson, Thomas R
> > Cc: Lloyd Wood; Tschofenig, Hannes; [email-masked]
> > Subject: Re: [Hipsec-rg] identity-based cryptography
> > 
> > > One of the questions at the HIP workshop that I heard 
> > consistently was 
> > > "why do you insist that your host identities are public keys?  Can 
> > > your architecture support more generality?"  The suggested 
> > framework 
> > > might be applicable to the scenario we were discussing 
> > (operator that 
> > > would like to associate host identities with something else like an 
> > > IMEI, and that would like to avoid deploying PKI to secure the 
> > > binding).
> > 
> > I think that in the longer run it is _very_ important to 
> > study alternatives to public key based host identities.  We 
> > have the danger that all PK crypto may collapse at some point 
> > in the future.  Hence, host identities that are based on some 
> > completely other form of crypto, such as renewable hash 
> > chains, symmetric crypto, or even something completely new, 
> > would be very good.
> > 
> > While the current completely decentralised nature of HIP has 
> > lots of appeal, i.e., it is nice that anyone can generate 
> > host identities, it is also important, in the longer run, to 
> > study alternatives where host identity generation is more 
> > limited but still preferably distributed.  Consider, for 
> > example, a scheme where host identities are related to some 
> > community and require co-operation by several community 
> > members in establishing a new one.
> > 
> > --Pekka
> > 
> > _______________________________________________
> > Hipsec-rg mailing list
> > [email-masked]
> > http://honor.trusecure.com/mailman/listinfo/hipsec-rg
> > 
> _______________________________________________
> Hipsec-rg mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec-rg
-- 
Tobias Heer <[email-masked]>
HIIT - Helsinki Institute for Information Technology

From: [email-masked] (=?iso-8859-1?Q?Zolt=E1n_Tur=E1nyi_=28IJ/ETH=29?=)
Date: Fri Nov 18 04:17:01 2005
Subject: [Hipsec-rg] identity-based cryptography
Message-ID: <[email-masked]>

Hi,

Could please someone send me some background material on the ID based =
crypto (papers, links) this discussion is about? Thanks in advance,

Zoltan

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]]=20
> Sent: Friday, November 18, 2005 9:52 AM
> To: Henderson, Thomas R
> Cc: Lloyd Wood; Tschofenig, Hannes; [email-masked]
> Subject: Re: [Hipsec-rg] identity-based cryptography
>=20
> > One of the questions at the HIP workshop that I heard=20
> consistently was=20
> > "why do you insist that your host identities are public keys?  Can=20
> > your architecture support more generality?"  The suggested=20
> framework=20
> > might be applicable to the scenario we were discussing=20
> (operator that=20
> > would like to associate host identities with something else like an=20
> > IMEI, and that would like to avoid deploying PKI to secure the=20
> > binding).
>=20
> I think that in the longer run it is _very_ important to=20
> study alternatives to public key based host identities.  We=20
> have the danger that all PK crypto may collapse at some point=20
> in the future.  Hence, host identities that are based on some=20
> completely other form of crypto, such as renewable hash=20
> chains, symmetric crypto, or even something completely new,=20
> would be very good.
>=20
> While the current completely decentralised nature of HIP has=20
> lots of appeal, i.e., it is nice that anyone can generate=20
> host identities, it is also important, in the longer run, to=20
> study alternatives where host identity generation is more=20
> limited but still preferably distributed.  Consider, for=20
> example, a scheme where host identities are related to some=20
> community and require co-operation by several community=20
> members in establishing a new one.
>=20
> --Pekka
>=20
> _______________________________________________
> Hipsec-rg mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec-rg
>=20

From: [email-masked] (Pekka Nikander)
Date: Fri Nov 18 03:52:01 2005
Subject: [Hipsec-rg] identity-based cryptography
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> One of the questions at the HIP workshop that I heard consistently was
> "why do you insist that your host identities are public keys?  Can  
> your
> architecture support more generality?"  The suggested framework  
> might be
> applicable to the scenario we were discussing (operator that would  
> like
> to associate host identities with something else like an IMEI, and  
> that
> would like to avoid deploying PKI to secure the binding).

I think that in the longer run it is _very_ important to study  
alternatives to public key based host identities.  We have the danger  
that all PK crypto may collapse at some point in the future.  Hence,  
host identities that are based on some completely other form of  
crypto, such as renewable hash chains, symmetric crypto, or even  
something completely new, would be very good.

While the current completely decentralised nature of HIP has lots of  
appeal, i.e., it is nice that anyone can generate host identities, it  
is also important, in the longer run, to study alternatives where  
host identity generation is more limited but still preferably  
distributed.  Consider, for example, a scheme where host identities  
are related to some community and require co-operation by several  
community members in establishing a new one.

--Pekka

From: [email-masked] (Miika Komu)
Date: Fri Nov 18 02:16:01 2005
Subject: [Hipsec-rg] moving draft-tschofenig-hiprg-hip-natfw-traversal-03.txt to RG status
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 16 Nov 2005, Henderson, Thomas R wrote:

> At the RG meeting last Friday, we discussed the future status of the
> following draft (problem statement) on HIP-aware middleboxes:
>
> http://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-hip-natfw-tra
> versal-03.txt
>
> This document has existed for some time now with little feedback, and
> Hannes has consequently requested that this become a RG document.  There
> were some comments at the meeting suggesting alignment of this draft
> with other IETF/IAB documents on NATs, but aside from that, the meeting
> did not object to adopting this draft as a RG item.
>
> I would like to ask for comments on advancing this draft to RG status.
> If you have read the draft and support such an action, please let me
> know, or raise any comments on the list.  Even if you have read the
> draft and simply support it with no comments, please respond so that it
> can be noted.

Seems like a good idea to adopt it as a RG item, IMHO.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

From: [email-masked] (Yogesh Prem Swami)
Date: Thu Nov 17 18:54:01 2005
Subject: [Hipsec-rg] identity-based cryptography
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6D67D4C4BF9DA92048127695
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Julien Laganier wrote:
> On Wednesday 16 November 2005 23:29, Henderson, Thomas R wrote:
> 
>>What James was pointing out is that there may be a way to bind
>>these non-cryptographic identities to the keys used by the
>>protocol, using identity-based cryptography.  A practical benefit
>>may be the avoidance of deploying a PKI to validate the binding
>>between non-key-based name and the key.
> 
> 
> I am not sure of the actual benefit. 

Totally agree. Actually it might make the problem worse because the node 
that uses ``any name" to derive the public-key must have access to the 
right PKG parameters. If a rogue node can convince a message sender that 
for ``for ID with ietf.org, use these PKG parameters a,b,c" then, that 
rogue node can decrypt all messages that use "any name" as their 
public-key. (I'm assuming that people are not proposing one giant PKG 
run by IANA of something similar, because that won't scale.)

The problem of PKI is really a problem of having a Trusted Third Party 
in a system as diverse as the Internet. There is no mathematical scheme 
that can act as a third-party--there has to be a physical entity that 
verifies end users and acts as a third party.

> 
> In effect, IB cryptography requires a Private Key Generator which, 
> albeit being different from a CA, has to be common to nodes verifying 
> each others signatures. So yes, you don't need to deploy CAs, but you 

I guess you mean each party must trust that the PKG parameters came from 
the domain that it claims to represent. It's possible to have different 
PKGs  at the two sides (just as having different CAs for each end-point).

It seems a lot of people have got the notion that using IBE can get rid 
of all the PKI problems, which is not true. IBE can help with deployment 
issues, but the real problem is of cross-domain trust. IBE cannot help 
with that.

Thanks
Yogesh

--------------enig6D67D4C4BF9DA92048127695
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig6D67D4C4BF9DA92048127695--

From: [email-masked] (Julien Laganier)
Date: Thu Nov 17 11:31:01 2005
Subject: [Hipsec-rg] identity-based cryptography
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday 16 November 2005 23:29, Henderson, Thomas R wrote:
>
> What James was pointing out is that there may be a way to bind
> these non-cryptographic identities to the keys used by the
> protocol, using identity-based cryptography.  A practical benefit
> may be the avoidance of deploying a PKI to validate the binding
> between non-key-based name and the key.

I am not sure of the actual benefit. 

In effect, IB cryptography requires a Private Key Generator which, 
albeit being different from a CA, has to be common to nodes verifying 
each others signatures. So yes, you don't need to deploy CAs, but you 
need to deploy IB-PKG. 

IMHO the burden is roughly equivalent, you just trade one box against 
another. 
 
--julien

From: [email-masked] (Henderson, Thomas R)
Date: Thu Nov 17 11:06:02 2005
Subject: [Hipsec-rg] identity-based cryptography
Message-ID: <[email-masked]>

=20

> -----Original Message-----
> From: Lloyd Wood [mailto:[email-masked]]=20
> Sent: Thursday, November 17, 2005 2:46 AM
> To: Henderson, Thomas R
> Cc: Tschofenig, Hannes;=20
> Subject: RE: [Hipsec-rg] identity-based cryptography
>=20
> On Wed, 16 Nov 2005, Henderson, Thomas R wrote:
>=20
> > > hi tom,
> > >
> > > why does the host identity need to be overloaded with=20
> functionality=20
> > > (except from using it as a host identifier).
> >
> > From architectural perspective, it doesn't need to be=20
> overloaded, but=20
> > from a practical perspective, there may be some benefit.
>=20
> this is where we came in, with IP addresses being overloaded=20
> to give identity, and HIP coming along to try and fix that.
>=20
> I'm reasonably sure that any overloading will later be seen=20
> as an error of commission.
>=20

Maybe overloading is not quite right word for this.  In the suggested
framework, the identity is still being used as a host identity in the
protocols (not functionally overloaded), it is just that it is not
generated from random input but instead bound to another name.  However,
there is no requirement to generate host identities in that fashion.

One of the questions at the HIP workshop that I heard consistently was
"why do you insist that your host identities are public keys?  Can your
architecture support more generality?"  The suggested framework might be
applicable to the scenario we were discussing (operator that would like
to associate host identities with something else like an IMEI, and that
would like to avoid deploying PKI to secure the binding).=20

Tom =20

From: [email-masked] (Henderson, Thomas R)
Date: Wed Nov 16 17:31:00 2005
Subject: [Hipsec-rg] identity-based cryptography
Message-ID: <[email-masked]>

=20

> -----Original Message-----
> From: Tschofenig, Hannes [mailto:[email-masked]]=20
> Sent: Wednesday, November 16, 2005 1:56 PM
> To: Henderson, Thomas R; [email-masked]
> Subject: AW: [Hipsec-rg] identity-based cryptography
>=20
> hi tom,=20
>=20
> why does the host identity need to be overloaded with=20
> functionality (except from using it as a host identifier).

>From architectural perspective, it doesn't need to be overloaded, but
from a practical perspective, there may be some benefit.  What if you
want to assign a human-readable (or more generally, non-key-based) name
to the device (such as a FQDN, or in the context we were discussing at
the meeting, the IMEI) and users/operators want to refer to the host by
this name, but the protocols want to refer to the host by the host
identity (key)?  What then is the binding between the name and key, and
how is it secured? =20

What James was pointing out is that there may be a way to bind these
non-cryptographic identities to the keys used by the protocol, using
identity-based cryptography.  A practical benefit may be the avoidance
of deploying a PKI to validate the binding between non-key-based name
and the key.
=20
>=20
> maybe we can find out what the benefit of associating the=20
> host identity with the network interface, person/user,=20
> session, sim card, etc. are.
>=20

I agree with Pekka's comment that the right level of granularity for HIP
seems to be "host" (not network interface, user, person), where host is
intentionally vague to allow for multiple logical hosts (some anonymous,
some published) to coexist on a device.  However, I have heard of
several proposals concerning the binding a host identity to other
things, such as a person.  While this may be possible from an IPsec
channel binding perspective, I don't know whether anyone has fully
sketched out how that architecture would work.

Tom =20

From: [email-masked] (Tschofenig, Hannes)
Date: Wed Nov 16 16:57:00 2005
Subject: AW: [Hipsec-rg] identity-based cryptography
Message-ID: <[email-masked]>

hi tom,=20

why does the host identity need to be overloaded with functionality =
(except from using it as a host identifier).=20

maybe we can find out what the benefit of associating the host identity =
with the network interface, person/user, session, sim card, etc. are.

ciao
hannes

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]] Im Auftrag von=20
> Henderson, Thomas R
> Gesendet: Mittwoch, 16. November 2005 17:27
> An: [email-masked]
> Betreff: [Hipsec-rg] identity-based cryptography
>=20
> At the RG meeting last Friday, during the discussion of identities to
> use for SIP-related sessions, James Kempf noted that they had explored
> the option of using Boneh-Franklin identity-based cryptography to
> generate the keys based on non-cryptographic identifiers such=20
> as NAI and
> URI.  He presented a brief paper on this concept at last year's HIP
> workshop:
> http://hiprg.piuha.net/workshop/kempf_deeper_issues.pdf
> _______________________________________________
> Hipsec-rg mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec-rg
>=20

From: [email-masked] (Henderson, Thomas R)
Date: Wed Nov 16 16:24:00 2005
Subject: [Hipsec-rg] moving draft-tschofenig-hiprg-hip-natfw-traversal-03.txt to RG status
Message-ID: <[email-masked]>

At the RG meeting last Friday, we discussed the future status of the
following draft (problem statement) on HIP-aware middleboxes:

http://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-hip-natfw-tra
versal-03.txt

This document has existed for some time now with little feedback, and
Hannes has consequently requested that this become a RG document.  There
were some comments at the meeting suggesting alignment of this draft
with other IETF/IAB documents on NATs, but aside from that, the meeting
did not object to adopting this draft as a RG item.

I would like to ask for comments on advancing this draft to RG status.
If you have read the draft and support such an action, please let me
know, or raise any comments on the list.  Even if you have read the
draft and simply support it with no comments, please respond so that it
can be noted.

Thanks,
Tom

p.s. Presently, having a draft reach RG status is a little bit less
meaningful than having an IETF draft reach WG status.  In the IETF, such
an action advances the draft forward (i.e., skips some steps) in the RFC
process.  Since there is not yet an IRTF review process that is
equivalent, any IRTF draft still must be processed as an individual
submission to the RFC editor.  Therefore, all that advancing a draft to
RG status means is that there is some consensus in the RG that the
material in the draft has been reviewed by the RG.  In the future, there
may be some kind of IRTF track for documents (the issue remains under
discussion).

From: [email-masked] (Henderson, Thomas R)
Date: Wed Nov 16 11:28:01 2005
Subject: [Hipsec-rg] identity-based cryptography
Message-ID: <[email-masked]>

At the RG meeting last Friday, during the discussion of identities to
use for SIP-related sessions, James Kempf noted that they had explored
the option of using Boneh-Franklin identity-based cryptography to
generate the keys based on non-cryptographic identifiers such as NAI and
URI.  He presented a brief paper on this concept at last year's HIP
workshop:
http://hiprg.piuha.net/workshop/kempf_deeper_issues.pdf

From: [email-masked] (Pekka Nikander)
Date: Wed Nov 16 03:44:00 2005
Subject: [Hipsec-rg] minutes of HIPRG meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Please let me know if you believe that there are any inaccuracies.

Good minutes!

A few corrections:

> Pekka:  There was a call-home BOF this meeting where the author  
> described

s/author/Jonathan Rosenberg/

> four mechanisms to talk through a NAT (connection, registration, keep

s/mechanisms/mechanisms necessary/

> alive, and message formats).  This document should try to  
> coordinate with
> him and with the IAB draft on NATs-- provide diffs against the more
> general cases of those drafts.

> Pekka:  current suggested name for these types of boxes-- TANNS
> (translating addresses not NATs).

Pekka: Realised that need to make difference between current type of  
NATs that change addresses without the peer hosts' explicit consent,  
and new types of architected NATs that change addresses under  
explicit control or co-operation with end hosts.  Looking for new  
name for the latter boxes, perhaps TANN (Translating Addresses not  
NAT), but discussion still going on.

> Pekka:  I potentially like this type of optimization-- would like to
> encourage implementation ane experiments

s/ane/and/

> Pekka:  IETF tools server via HIP

Pekka: Work going to make IETF tools server available via HIP

--Pekka

From: [email-masked] (Henderson, Thomas R)
Date: Tue Nov 15 15:07:01 2005
Subject: [Hipsec-rg] minutes of HIPRG meeting
Message-ID: <[email-masked]>

Draft meeting minutes of the HIPRG meeting are available at:
http://www3.ietf.org/proceedings/05nov/minutes/HIPRG.txt

Please let me know if you believe that there are any inaccuracies.

Tom

From: [email-masked] (Henderson, Thomas R)
Date: Thu Nov 10 19:33:00 2005
Subject: [Hipsec-rg] agenda for RG meeting tomorrow
Message-ID: <[email-masked]>

Below is the revised HIPRG agenda for tomorrow.  Please send me slides
this evening if you plan to present.  Please plan on roughly 20 minutes
to introduce new drafts, or 5-10 minutes for revised drafts, or let me
know if you need more time for some reason. =20

Please also bring your ideas for discussion on how we can move forward
towards more experimentation with HIP.  At the end of the meeting, we
will show some of the development in HIP software that may make such
experiments easier now.

Tom

Friday, Nov. 11, 12:30-15:00 hiprg meeting (Salon 1)
----------------------------------------------------

Administrative and agenda discussion

Experiment report status
- draft-irtf-hip-experiment-01.txt

Legacy NAT/middlebox traversal  (update)
- draft-irtf-hiprg-nat-00.txt

Advanced NAT/middlebox traversal  (update)
- draft-tschofenig-hiprg-hip-natfw-traversal-03.txt

SIP and HIP
- draft-papadoglou-hiprg-hit-presence-00.txt  (new draft)
- draft-tschofenig-hiprg-hip-srtp-01.txt (update)

Issues of HIP in an Operator's Network
- draft-dietz-hip-operator-issues-00  (new draft)

Opportunistic HIP (Miika Komu)
- draft-lindqvist-hip-opportunistic-00.txt (new draft)

HIP software review, demos, and discussion

Open discussion

From: [email-masked] (Miika Komu)
Date: Tue Nov  8 20:20:01 2005
Subject: [Hipsec-rg] Establishing Host Identity Protocol Opportunistic Mode with TCP Option
Message-ID: <[email-masked]>

I'll introduce this draft on the Friday RG session on the behalf of Janne
(sorry for the late submission). Comments are welcome.

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

        Title           : Establishing Host Identity Protocol
                          Opportunistic Mode with TCP Option
        Author(s)       : J. Lindqvist
        Filename        : draft-lindqvist-hip-opportunistic-00.txt
        Pages           : 14
        Date            : 2005-11-8

   This document specifies an alternative opportunistic mode for the
   Host Identity Protocol (HIP).  The opportunistic mode is initialized
   by adding a 128 bit Host Identity Tag (HIT) as a TCP option to a TCP
   SYN packet.  The mode introduces a performance improvement by
   allowing piggybacking of the TCP handshake to the HIP base exchange.
Also, the mode allows a TCP connection to be established directly
   without a timeout delay in the case the peer does not support HIP.
 A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lindqvist-hip-opportunistic-00.txt

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

From: [email-masked] (Thomas Dietz)
Date: Tue Nov  8 19:45:01 2005
Subject: [Hipsec-rg] RE: Comments on draft-dietz-hip-operator-issues-00.txt
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C5E49E.A9964350
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Pekka,

Find my comments inline

--=20
Thomas Dietz
Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany
=20
> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]=20
> Sent: Monday, November 07, 2005 11:58 PM
> To: Thomas Dietz; VF-Group Papadoglou Nick
> Cc: [email-masked]
> Subject: Comments on draft-dietz-hip-operator-issues-00.txt
>=20
> Thomas, Nick, and others,
>=20
> Some comments on draft-dietz-hip-operator-issues-00.txt.  Firstly, =20
> while I think it is very good to have this kind of drafts that =20
> addresses some operational concerns, I'm a little bit worried about =20
> some parts of the draft not being firmly enough rooted in the=20
> current =20
> reality and existing work.  Alternatively, some of the=20
> comments below =20
> may be a result just from my confusion.  On the other hand, they can =20
> also be understood as attempting to start the discussion that the =20
> draft is trying to start.
>=20
> More specifically, in Section 2 on page 4, the draft discusses the =20
> inability of classifying encrypted traffic for charging purposes.  =20
> The tone of the draft makes the impression that this is something =20
> new, something that HIP introduces.  However, people already=20
> now have =20
> the ability to encrypt their IP traffic, for example, by using IKE =20
> and IPsec.
>=20

If we talk about the Internet you are certenly right, but if I am not =
mistaken you are currently not able to set up an IPSEC connection =
through a GSM Operator connection because their firewall will not allow =
it. So you have only standard TCP/UDP/IP connections and those can be =
classified.

> A difference between HIP and IKE is that IKE (both v1 and v2) focus =20
> on providing strong end-to-end security, and due to that requirement =20
> encrypt also the SPIs.  HIP, on the other hand, has been designed to =20
> be more friendly towards middle boxes, and among things sends both =20
> SPIs and signatures in clear text so that middle boxes can=20
> learn SPIs =20
> and verify signatures.  Consequently, HIP can be potentially=20
> extended =20
> to better support charging facilities by including new options into =20
> HIP control messages, if so desired.

This would be certainly another possibility to do charging and would be =
even easier than classifying the traffic by a middlebox. But you the =
charging information included in HIP must be reliable, though.

>=20
> It is important to note here that independent of what controls an =20
> operator applies to enforce traffic classification, it is *always* =20
> possible for a user to circumvent them.  In the extreme case of an =20
> operator doing strict content analysis (which would be very=20
> costly) a =20
> user could still use steganography, for example, to include a voice =20
> channel in pure video channel.  With strong enough steganographic =20
> cipher, the embedded voice channel would appear as if the video =20
> stream had slightly more noise than otherwise, being impossible for =20
> anyone to tell whether that is real noise or embedded steganographic =20
> data.
>=20
> It is especially important to note that the above applies to plain =20
> text data.  Hence, requiring that the operator has access to the end-=20
> to-end encryption key does not really help but against the=20
> most naive =20
> users.  Consequently, the operator can't avoid trusting the user('s =20
> equipment) to honestly tell what kind of traffic it wants to =20
> transmit.

Hiding information as text or voice in e.g. a video stream may not be a =
problem because the user probably pays more for the video than he does =
for voice or text transmission. But if the user wants to transmit =
(secure) voice traffice he certainly does not want to pay for video.

> Whether the data stream is encrypted or not does not =20
> really matter as long as it can be correctly classified, and such =20
> classification can be based on other available information but the =20
> upper layer headers.  For example, in IPv6 one can use the flow =20
> label, and both in IPv6 and IPv4 the SPIs are available for =20
> classification, if so desired.
>=20

As you said above the operator has then to trust the user. Nick, how =
about this? Do operators trust users :-;

> Hence, I strongly disagree with the Section 2.  What comes to=20
> Section =20
> 3 (LI), my only remark is that it is an issue that cannot be =20
> addressed without having access to the end devices, i.e., without =20
> designing it to be an integral part of an end device implementation, =20
> and therefore I don't any reason to address it as a part of IETF =20
> specifications.  Requiring anything else would be silly, as per the =20
> steganography argument above, a user that has full control over her =20
> device can always send encrypted traffic.

True, but nevertheless the operators have to deal with LI, and thus it's =
at least worth mentioning it even if the IETF has not really to deal =
with it. =20

>=20
> A remark w.r.t. Section 4, the first intended paragraph on=20
> page 6: It =20
> is technically not really possible to use DNS to resolve HIs or HITs =20
> to IP addresses, or to associate any data with a HI or HIT.  =20
> Furthermore, if it was possible, that would not require two DNS =20
> servers but merely two DNS lookups.  Also section 8 gets this wrong; =20
> you can't use DNS for HI->IP address mapping.  As a small detail =20
> (w.r.t 3rd para on page 11), it is unclear whether DHT update delay =20
> is short enough for most dynamic updates.

I thought, I maybe mistaken her, that what the DNS extension draft deals =
with. Resolve a name to a HIT or the public key of a HI and then get the =
IP for the HIT. Yes it's true that you don't need two DNS servers for =
this but two lookups.

Regarding the DHT, we also read about those doubts, but it's the only =
alternative that is currently discussed in more detail.

>=20
> A little bit further, I don't understand the comment of IPsec being =20
> open to MitM attacks.  The statement seems to lack context.
>=20
> What comes to mobility support in SIP, I have to admit that I don't =20
> really understand whether SIP mobility is designed to support =20
> mobility or mere some kind of nomadicity.  In any case, it sounds to =20
> me that a mobility solution based on session level signalling =20
> (especially through proxies) is likely to cause fairly long handover =20
> times.  Furthermore, I don't understand the remark of SIP protecting =20
> mobility with "authentication or public key cryptography."  I=20
> have no =20
> idea what it means,
>=20
> A small comment to Sections 6 and 7, and parts of Section 10: Host =20
> Identities have never been intended to identify network interfaces.  =20
> IP addresses are good enough for that.  HIs have been intended to =20
> identify hosts.  Period.  If one wants to use structurally similar =20
> identifiers to identify other entities, such as users or services, =20
> one should name those identifiers differently.  In other words, I =20
> think it is a fine idea to use public keys to identify=20
> interfaces (as =20
> people are trying to do at IEEE 802), users, or services, but such =20
> identifiers should not be called HIs.  Consequently, I think=20
> both the =20
> end of Section 6 and all of Section 7 are misleading and should be =20
> reworded.  [Note that I do not say _anything_ else about=20
> Section 7 or =20
> 10 here -- their intended messages may be just fine; I need to think =20
> more about it once it has been correctly framed.]
>=20

I know that the HI was inteded to be the identity for a Node/Host =
however you call it. But nevertheless I heard many discussions on this =
topic and the people discussing it are all not sure where this HI is =
associated to. So I think it's worth discussing the possiblities and =
concluding why the Node/Host was chosen.

> W.r.t Section 9, I'd like to mention three papers that partially =20
> address some of the privacy concerns, from different points of view:
>=20

Thanks for the links, I will have a look at them.

> Jari Arkko, Pekka Nikander, and Mats N=E4slund, "Enhancing=20
> Privacy with =20
> Shared Pseudo Random Sequences (preliminary version)," to appear in =20
> Security Protocols, 13rd International Workshop, Cambridge, 20-22 =20
> April, 2005.
>=20
> Jukka Ylitalo and Pekka Nikander, "BLIND: A Complete Identity =20
> Protection Framework for End-points", to appear in Security =20
> Protocols, Twelfth International Workshop, Cambridge, 24-28=20
> April, 2004.
>=20
> The problem identified in Section 10 is well known and I don't know =20
> if needs to be repeated.

Well, I think it is still an unsolved problem and has to do with the =
user trusting its provider. If the problem is solved then the section =
can vanish provided the solution is suitable for operators.

Best Regards,

Thomas

>=20
> --Pekka Nikander
>=20

------=_NextPart_000_000E_01C5E49E.A9964350
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_000E_01C5E49E.A9964350--

From: [email-masked] (Papadoglou, Nick, VF-Group)
Date: Tue Nov  8 14:33:01 2005
Subject: [Hipsec-rg] RE: Comments on draft-dietz-hip-operator-issues-00.txt
Message-ID: <[email-masked]>

=20
>>=20
>> More specifically, in Section 2 on page 4, the draft discusses the =20
>> inability of classifying encrypted traffic for charging purposes.  =20
>> The tone of the draft makes the impression that this is=20
>something new,=20
>> something that HIP introduces.  However, people already now have the=20
>> ability to encrypt their IP traffic, for example, by using IKE and=20
>> IPsec.
>>=20
>
>If we talk about the Internet you are certenly right, but if I=20
>am not mistaken you are currently not able to set up an IPSEC=20
>connection through a GSM Operator connection because their=20
>firewall will not allow it. So you have only standard=20
>TCP/UDP/IP connections and those can be classified.

Well, not absolutely true. You are able to send encrypted traffic e2e
via a GPRS/UMTS network, like Skype traffic.=20

>
>> A difference between HIP and IKE is that IKE (both v1 and=20
>v2) focus on=20
>> providing strong end-to-end security, and due to that requirement=20
>> encrypt also the SPIs.  HIP, on the other hand, has been designed to=20
>> be more friendly towards middle boxes, and among things sends both=20
>> SPIs and signatures in clear text so that middle boxes can=20
>learn SPIs=20
>> and verify signatures.  Consequently, HIP can be potentially=20
>extended=20
>> to better support charging facilities by including new options into=20
>> HIP control messages, if so desired.
>
>This would be certainly another possibility to do charging and=20
>would be even easier than classifying the traffic by a=20
>middlebox. But you the charging information included in HIP=20
>must be reliable, though.
>
>>=20

>
>> Whether the data stream is encrypted or not does not really=20
>matter as=20
>> long as it can be correctly classified, and such=20
>classification can be=20
>> based on other available information but the upper layer=20
>headers.  For=20
>> example, in IPv6 one can use the flow label, and both in=20
>IPv6 and IPv4=20
>> the SPIs are available for classification, if so desired.
>>=20
>
>As you said above the operator has then to trust the user.=20
>Nick, how about this? Do operators trust users :-;
>
Not always. I believe that there are ways that thismay work even if it
is marked by the terminal and policed by the network.=20

From: [email-masked] (Papadoglou, Nick, VF-Group)
Date: Tue Nov  8 14:14:00 2005
Subject: [Hipsec-rg] RE: Comments on draft-dietz-hip-operator-issues-00.txt
Message-ID: <[email-masked]>

Hi Pekka,=20

Thanks for your comments, response inline=20

>-----Original Message-----
>From: Pekka Nikander [mailto:[email-masked]]=20
>Sent: 07 November 2005 22:58
>To: Thomas Dietz; Papadoglou, Nick, VF-Group
>Cc: [email-masked]
>Subject: Comments on draft-dietz-hip-operator-issues-00.txt
>
>Thomas, Nick, and others,
>
>Some comments on draft-dietz-hip-operator-issues-00.txt. =20
>Firstly, while I think it is very good to have this kind of=20
>drafts that addresses some operational concerns, I'm a little=20
>bit worried about some parts of the draft not being firmly=20
>enough rooted in the current reality and existing work. =20
>Alternatively, some of the comments below may be a result just=20
>from my confusion.  On the other hand, they can also be=20
>understood as attempting to start the discussion that the=20
>draft is trying to start.
>
>More specifically, in Section 2 on page 4, the draft discusses the =20
>inability of classifying encrypted traffic for charging purposes.  =20
>The tone of the draft makes the impression that this is=20
>something new, something that HIP introduces.  However, people=20
>already now have the ability to encrypt their IP traffic, for=20
>example, by using IKE and IPsec.

Very true, and certainly not something new. This limitation exists even =
in today's networks in the case where a user wants to use his "own" e2e =
encryption. If so, then the NO can only apply a limited set of charging =
models thus it looses the flexibility of applying different policies for =
different media types. We assume that the user will benefit from such =
charging models (since there may be a special rate for a certainl type =
of media) and will not be willing to use his "own" e2e encryption model. =
There was no intention to give this impression hence, will address this =
(clarify) in the new version of the draft.=20
>
>A difference between HIP and IKE is that IKE (both v1 and v2)=20
>focus on providing strong end-to-end security, and due to that=20
>requirement encrypt also the SPIs.  HIP, on the other hand,=20
>has been designed to be more friendly towards middle boxes,=20
>and among things sends both SPIs and signatures in clear text=20
>so that middle boxes can learn SPIs and verify signatures. =20
>Consequently, HIP can be potentially extended to better=20
>support charging facilities by including new options into HIP=20
>control messages, if so desired.
>
Yes, and this maybe a good way forward if we wanted to deploy HIP in an =
operators network.=20

>It is important to note here that independent of what controls=20
>an operator applies to enforce traffic classification, it is=20
>*always* possible for a user to circumvent them. =20
Yes I fully agree, but we assume that this will not be the case for the =
majority of the users.=20
>In the=20
>extreme case of an operator doing strict content analysis=20
>(which would be very costly) a user could still use=20
>steganography, for example, to include a voice channel in pure=20
>video channel.  With strong enough steganographic cipher, the=20
>embedded voice channel would appear as if the video stream had=20
>slightly more noise than otherwise, being impossible for=20
>anyone to tell whether that is real noise or embedded=20
>steganographic data.
>

Again, fully agree and furthermore I doubt that the operator will do a =
"strict content analysis".=20

>It is especially important to note that the above applies to=20
>plain text data.  Hence, requiring that the operator has=20
>access to the end- to-end encryption key does not really help=20
>but against the most naive users.  Consequently, the operator=20
>can't avoid trusting the user('s
>equipment) to honestly tell what kind of traffic it wants to=20
>transmit. =20

That's the assumption.

>Whether the data stream is encrypted or not does=20
>not really matter as long as it can be correctly classified,=20
>and such classification can be based on other available=20
>information but the upper layer headers.  For example, in IPv6=20
>one can use the flow label, and both in IPv6 and IPv4 the SPIs=20
>are available for classification, if so desired.
>

>Hence, I strongly disagree with the Section 2. =20

As mentioned above, the idea was to highlight the fact that if HIP was =
to be deployed in an operators network, e2e encryption will introduce a =
number of constrains and thus will not be a preffered choice by an NO. =
Today, users can encrypt their traffic or use staganography but this is =
at one's "own weal" and is not something that the NO will support or =
even more promote. =20

>What comes to Section
>3 (LI), my only remark is that it is an issue that cannot be=20
>addressed without having access to the end devices, i.e.,=20
>without designing it to be an integral part of an end device=20
>implementation, and therefore I don't any reason to address it=20
>as a part of IETF specifications.  Requiring anything else=20
>would be silly, as per the steganography argument above, a=20
>user that has full control over her device can always send=20
>encrypted traffic.
>

True. I think that the section does not clearly convey our thoughts, =
hence we will adress this in the next version. In a few words, there is =
no problem of using HIP because the traffic is encrypted and hence you =
can not do LI, since again today this may be possible if the user uses =
its own keys to encrypt the traffic. Most regulatory bodies specify that =
if the NO offers e2e encyption he should be able to do LI at some point =
of the network without the terminal being aware of this. In the case =
where the NO is not offering any encryption mechanism then it is not =
required to offer LI for those terminals. Hence, if HIP was to be =
deployed by an NO, then the keys would probably be issued and =
distributed by him in order to able to perform LI, although this may be =
an open issue.=20

>A remark w.r.t. Section 4, the first intended paragraph on=20
>page 6: It is technically not really possible to use DNS to=20
>resolve HIs or HITs =20
>to IP addresses, or to associate any data with a HI or HIT.  =20
>Furthermore, if it was possible, that would not require two=20
>DNS servers but merely two DNS lookups.  Also section 8 gets=20
>this wrong; you can't use DNS for HI->IP address mapping.  As=20
>a small detail (w.r.t 3rd para on page 11), it is unclear=20
>whether DHT update delay is short enough for most dynamic updates.
>
>A little bit further, I don't understand the comment of IPsec=20
>being open to MitM attacks.  The statement seems to lack context.
>
>What comes to mobility support in SIP, I have to admit that I=20
>don't really understand whether SIP mobility is designed to=20
>support mobility or mere some kind of nomadicity.  In any=20
>case, it sounds to me that a mobility solution based on=20
>session level signalling (especially through proxies) is=20
>likely to cause fairly long handover times.  Furthermore, I=20
>don't understand the remark of SIP protecting mobility with=20
>"authentication or public key cryptography."  I have no idea=20
>what it means,
>
>A small comment to Sections 6 and 7, and parts of Section 10: Host =20
>Identities have never been intended to identify network interfaces.  =20
>IP addresses are good enough for that.  HIs have been intended=20
>to identify hosts.  Period.  If one wants to use structurally=20
>similar identifiers to identify other entities, such as users=20
>or services, one should name those identifiers differently. =20
>In other words, I think it is a fine idea to use public keys=20
>to identify interfaces (as people are trying to do at IEEE=20
>802), users, or services, but such identifiers should not be=20
>called HIs. =20

Fully agree here, we should have used a more generic term such as =
"identifier" when talking about things except devices without the need =
to say for example session identifier and so own. As we conclude in the =
section, and we always had in mind was that HI's and HIT's will be the =
device id and furthermore for an operator it would be benefitial to =
creat some mapping between this and a user id as well as with a SIP URI, =
FQDN etc. As you mention below, we will reword the sections (6 and 7) to =
address this issue.=20

>Consequently, I think both the end of Section 6=20
>and all of Section 7 are misleading and should be reworded. =20
>[Note that I do not say _anything_ else about Section 7 or 10=20
>here -- their intended messages may be just fine; I need to=20
>think more about it once it has been correctly framed.]
>

We'll do that.=20

>W.r.t Section 9, I'd like to mention three papers that=20
>partially address some of the privacy concerns, from different=20
>points of view:
>
>Jari Arkko, Pekka Nikander, and Mats N=E4slund, "Enhancing=20
>Privacy with Shared Pseudo Random Sequences (preliminary=20
>version)," to appear in Security Protocols, 13rd International=20
>Workshop, Cambridge, 20-22 April, 2005.
>
>Jukka Ylitalo and Pekka Nikander, "BLIND: A Complete Identity=20
>Protection Framework for End-points", to appear in Security=20
>Protocols, Twelfth International Workshop, Cambridge, 24-28=20
>April, 2004.
>
>The problem identified in Section 10 is well known and I don't=20
>know if needs to be repeated.
>
>--Pekka Nikander
>
>
>
>
>
>
>
>
>

From: [email-masked] (Papadoglou, Nick, VF-Group)
Date: Mon Nov  7 21:33:01 2005
Subject: [Hipsec-rg] RE: [Hipsec] I-D ACTION:draft-dietz-hip-operator-issues-00.txt
Message-ID: <[email-masked]>

Tom,

I have requested a 10 to 15 minute slot from Gonzalo to present the work
tomorrow in the WG session, although as you mention it might be more
relevant to the RG. Hence, I will take up your offer and present it on
Friday and maybe decide there if it should be part of the new HIP WG
after the re-chartering or remain under the RG.=20

Regards,

Nick

>-----Original Message-----
>From: Henderson, Thomas R [mailto:[email-masked]]=20
>Sent: 07 November 2005 21:33
>To: Papadoglou, Nick, VF-Group
>Cc: [email-masked]; HIP
>Subject: RE: [Hipsec] I-D ACTION:draft-dietz-hip-operator-issues-00.txt
>
>Nick,
>This topic (deployment issues of HIP) is within scope of the=20
>HIP RG, so I invite you to present it on Friday also if you=20
>are able to.  Please let me know.
>=20
>Thanks,
>Tom
>
>
>________________________________
>
>	From: Papadoglou, Nick, VF-Group
>[mailto:[email-masked]]=20
>	Sent: Monday, November 07, 2005 11:02 AM
>	To: HIP
>	Subject: [Hipsec] I-D
>ACTION:draft-dietz-hip-operator-issues-00.txt
>=09
>=09
>	Hi,
>	=20
>	We have submitted the following ID which we would like=20
>to present/discuss tomorrow at our slot if there is enough=20
>time. Comments are more than welcome.=20
>=09
>http://www.ietf.org/internet-drafts/draft-dietz-hip-operator-is
sues-00.t
>xt
>	=20
>	Many thanks,
>	=20
>	Nick
>	=20
>
>

From: [email-masked] (Pekka Nikander)
Date: Mon Nov  7 17:58:00 2005
Subject: [Hipsec-rg] Comments on draft-dietz-hip-operator-issues-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Thomas, Nick, and others,

Some comments on draft-dietz-hip-operator-issues-00.txt.  Firstly, =20
while I think it is very good to have this kind of drafts that =20
addresses some operational concerns, I'm a little bit worried about =20
some parts of the draft not being firmly enough rooted in the current =20=

reality and existing work.  Alternatively, some of the comments below =20=

may be a result just from my confusion.  On the other hand, they can =20
also be understood as attempting to start the discussion that the =20
draft is trying to start.

More specifically, in Section 2 on page 4, the draft discusses the =20
inability of classifying encrypted traffic for charging purposes.  =20
The tone of the draft makes the impression that this is something =20
new, something that HIP introduces.  However, people already now have =20=

the ability to encrypt their IP traffic, for example, by using IKE =20
and IPsec.

A difference between HIP and IKE is that IKE (both v1 and v2) focus =20
on providing strong end-to-end security, and due to that requirement =20
encrypt also the SPIs.  HIP, on the other hand, has been designed to =20
be more friendly towards middle boxes, and among things sends both =20
SPIs and signatures in clear text so that middle boxes can learn SPIs =20=

and verify signatures.  Consequently, HIP can be potentially extended =20=

to better support charging facilities by including new options into =20
HIP control messages, if so desired.

It is important to note here that independent of what controls an =20
operator applies to enforce traffic classification, it is *always* =20
possible for a user to circumvent them.  In the extreme case of an =20
operator doing strict content analysis (which would be very costly) a =20=

user could still use steganography, for example, to include a voice =20
channel in pure video channel.  With strong enough steganographic =20
cipher, the embedded voice channel would appear as if the video =20
stream had slightly more noise than otherwise, being impossible for =20
anyone to tell whether that is real noise or embedded steganographic =20
data.

It is especially important to note that the above applies to plain =20
text data.  Hence, requiring that the operator has access to the end-=20
to-end encryption key does not really help but against the most naive =20=

users.  Consequently, the operator can't avoid trusting the user('s =20
equipment) to honestly tell what kind of traffic it wants to =20
transmit.  Whether the data stream is encrypted or not does not =20
really matter as long as it can be correctly classified, and such =20
classification can be based on other available information but the =20
upper layer headers.  For example, in IPv6 one can use the flow =20
label, and both in IPv6 and IPv4 the SPIs are available for =20
classification, if so desired.

Hence, I strongly disagree with the Section 2.  What comes to Section =20=

3 (LI), my only remark is that it is an issue that cannot be =20
addressed without having access to the end devices, i.e., without =20
designing it to be an integral part of an end device implementation, =20
and therefore I don't any reason to address it as a part of IETF =20
specifications.  Requiring anything else would be silly, as per the =20
steganography argument above, a user that has full control over her =20
device can always send encrypted traffic.

A remark w.r.t. Section 4, the first intended paragraph on page 6: It =20=

is technically not really possible to use DNS to resolve HIs or HITs =20
to IP addresses, or to associate any data with a HI or HIT.  =20
Furthermore, if it was possible, that would not require two DNS =20
servers but merely two DNS lookups.  Also section 8 gets this wrong; =20
you can't use DNS for HI->IP address mapping.  As a small detail =20
(w.r.t 3rd para on page 11), it is unclear whether DHT update delay =20
is short enough for most dynamic updates.

A little bit further, I don't understand the comment of IPsec being =20
open to MitM attacks.  The statement seems to lack context.

What comes to mobility support in SIP, I have to admit that I don't =20
really understand whether SIP mobility is designed to support =20
mobility or mere some kind of nomadicity.  In any case, it sounds to =20
me that a mobility solution based on session level signalling =20
(especially through proxies) is likely to cause fairly long handover =20
times.  Furthermore, I don't understand the remark of SIP protecting =20
mobility with "authentication or public key cryptography."  I have no =20=

idea what it means,

A small comment to Sections 6 and 7, and parts of Section 10: Host =20
Identities have never been intended to identify network interfaces.  =20
IP addresses are good enough for that.  HIs have been intended to =20
identify hosts.  Period.  If one wants to use structurally similar =20
identifiers to identify other entities, such as users or services, =20
one should name those identifiers differently.  In other words, I =20
think it is a fine idea to use public keys to identify interfaces (as =20=

people are trying to do at IEEE 802), users, or services, but such =20
identifiers should not be called HIs.  Consequently, I think both the =20=

end of Section 6 and all of Section 7 are misleading and should be =20
reworded.  [Note that I do not say _anything_ else about Section 7 or =20=

10 here -- their intended messages may be just fine; I need to think =20
more about it once it has been correctly framed.]

W.r.t Section 9, I'd like to mention three papers that partially =20
address some of the privacy concerns, from different points of view:

Jari Arkko, Pekka Nikander, and Mats N=E4slund, "Enhancing Privacy with =20=

Shared Pseudo Random Sequences (preliminary version)," to appear in =20
Security Protocols, 13rd International Workshop, Cambridge, 20-22 =20
April, 2005.

Jukka Ylitalo and Pekka Nikander, "BLIND: A Complete Identity =20
Protection Framework for End-points", to appear in Security =20
Protocols, Twelfth International Workshop, Cambridge, 24-28 April, 2004.

The problem identified in Section 10 is well known and I don't know =20
if needs to be repeated.

--Pekka Nikander

From: [email-masked] (Henderson, Thomas R)
Date: Mon Nov  7 16:34:01 2005
Subject: [Hipsec-rg] RE: [Hipsec] I-D ACTION:draft-dietz-hip-operator-issues-00.txt
Message-ID: <[email-masked]>

Nick,
This topic (deployment issues of HIP) is within scope of the HIP RG, so
I invite you to present it on Friday also if you are able to.  Please
let me know.
=20
Thanks,
Tom

________________________________

	From: Papadoglou, Nick, VF-Group
[mailto:[email-masked]]=20
	Sent: Monday, November 07, 2005 11:02 AM
	To: HIP
	Subject: [Hipsec] I-D
ACTION:draft-dietz-hip-operator-issues-00.txt
=09
=09
	Hi,
	=20
	We have submitted the following ID which we would like to
present/discuss tomorrow at our slot if there is enough time. Comments
are more than welcome.=20
=09
http://www.ietf.org/internet-drafts/draft-dietz-hip-operator-issues-00.t
xt
	=20
	Many thanks,
	=20
	Nick
	=20

From: [email-masked] (Jari Arkko)
Date: Sat Nov  5 17:53:00 2005
Subject: [Hipsec-rg] Comment on draft-tschofenig-hiprg-host-identities-02.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hannes,

The discussion on draft-papadoglou-hiprg-hit-presence-00.txt
led me to go back to your draft and re-read it... and I have a
question.

Your note about this being related to the PBK idea led
me to think about the semantics of the transported HITs.
What specifically are the semantics? The security of
PBK approaches depend very much on to what the
keys are bound to, how, and for how long. Here's
some potential answers and related considerations:

1. Receiver binds sip-level identity to the HIT forever.

    This could lead to a vulnerability where, if I can
    once spoof a signalling message in some environment,
    I can take over someone's identity or at least render
    it unusable.

2. Receiver binds sip-level identity to the HIT after
    SSH style user confirmation (similar to what the base
    SIP spec already does for S/MIME).

    This is more workable. Not sure people in
    all environments are willing to do the
    confirmations in reliable manner.

3. HITs apply for a session; The HITs may be
    updated at any time through the SIP signalling
    messages.

    This seems more reasonable. But if hosts may
    talk directly SIP to each other (as they can in SIP)
    then one of your assumptions about a different path
    for the signaling traffic is violated. Of course, if
    there's security for the direct SIP connection then
    this won't be a problem - but such security essentially
    implies some cert-based solution, which could obviously
    be used for media protection too, without HIP.

4. The HITs may be updated at any time during a
    session, but we only support configuration through
    infrastructure.

    Based on item 3 above, this seems quite sensible.
    Incidentally, this is similar to what the presence
    approach was.

5. Session-based semantics where initial message has
    to contain all the identities.

    Identity hijack is not an issue beyond one session.
    Security of direct host-to-host SIP communications
    does not matter, because the initial messages are
    typically through the infrastructure anyway.

Approach 4 seems most reasonable, but I could
be missing something.

--Jari

From: [email-masked] (Henderson, Thomas R)
Date: Fri Nov  4 11:13:00 2005
Subject: [Hipsec-rg] draft HIP-RG agenda
Message-ID: <[email-masked]>

Please let me know if anyone would like a topic to be added, and we can
announce an update sometime next week.

(draft) HIP research group agenda

Friday Nov. 11, 12:30PM
-----------------------

- Administrative and agenda discussion

- Experiment report status
(draft-irtf-hip-experiment-01.txt)

- Legacy NAT/middlebox traversal
(draft-irtf-hiprg-nat-00.txt)

- Advanced NAT/middlebox traversal
(draft-tschofenig-hiprg-hip-natfw-traversal-03.txt)

- SIP and HIP
(draft-papadoglou-hiprg-hit-presence-00.txt)
(draft-tschofenig-hiprg-hip-srtp-01.txt)

- Opportunistic HIP (Miika Komu)

- HIP software review, demos, and discussion

- Open discussion

From: [email-masked] (Tschofenig, Hannes)
Date: Tue Nov  1 08:12:00 2005
Subject: AW: [Hipsec-rg] I-D ACTION:draft-papadoglou-hiprg-hit-presence-00.txt
Message-ID: <[email-masked]>

hi pekka,=20

interesting that you mention this.
we have an ietf draft about hip and sip interaction (see =
draft-tschofenig-hiprg-host-identities-02.txt) hanging around for some =
time. the approach outlined in =
draft-papadoglou-hiprg-hit-presence-00.txt illustrates the first item of =
our open issue list.=20

ciao
hannes=20

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] =
[mailto:[email-masked]] Im Auftrag von Pekka =
Nikander
Gesendet: Dienstag, 1. November 2005 11:49
An: Papadoglou, Nick, VF-Group
Cc: [email-masked]; [email-masked]
Betreff: Re: [Hipsec-rg] I-D =
ACTION:draft-papadoglou-hiprg-hit-presence-00.txt

This looks like an interesting approach to me; I'd encourage people =20
to read.

--Pekka

On Oct 30, 2005, at 19:09, Papadoglou, Nick, VF-Group wrote:

>  Dear all,
>
> Please find below a new ID that we submitted and we intent to
> present/discuss in the Vancouver meeting. Your comments/suggestions =20
> and
> constructive comments are more than welcome.
>
> Best regards,
>
> Nick
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 18, 2005 12:50 PM
> To: [email-masked]
> Subject: I-D ACTION:draft-papadoglou-hiprg-hit-presence-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>     Title        : Host Identity Tags (HIT) in Presence
> Information Data Format (PIDF)
>     Author(s)    : N. Papadoglou, H. Zisimopoulos
>     Filename    : draft-papadoglou-hiprg-hit-presence-00.txt
>     Pages        : 11
>     Date        : 2005-10-18
>
>    This document describes a new way of exchanging Host Identities (or
>    Host Identity Tags) by means of the Presence Information Data =20
> Format
>    [6]  using the Host Identity Protocol (HIP). A new presence
>    information element is proposed as an extension to the Presence
>    Information Data Format (PIDF), to include and convey the Host
>    Identity that corresponds to the different SIP URI's the node may
>    have registered. This automatically creates a list of associations
>    between the SIP URI and the Host identity for the different UA
>    instances on the same or different node.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-papadoglou-hiprg-hit-=20
> presence-
> 00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] 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-papadoglou-hiprg-hit-presence-00.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:
>     [email-masked].
> In the body type:
>     "FILE
> /internet-drafts/draft-papadoglou-hiprg-hit-presence-00.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.
>
> <draft-papadoglou-hiprg-hit-presence-00.URL>
>

_______________________________________________
Hipsec-rg mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec-rg

From: [email-masked] (Pekka Nikander)
Date: Tue Nov  1 05:50:01 2005
Subject: [Hipsec-rg] I-D ACTION:draft-papadoglou-hiprg-hit-presence-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

This looks like an interesting approach to me; I'd encourage people  
to read.

--Pekka

On Oct 30, 2005, at 19:09, Papadoglou, Nick, VF-Group wrote:

>  Dear all,
>
> Please find below a new ID that we submitted and we intent to
> present/discuss in the Vancouver meeting. Your comments/suggestions  
> and
> constructive comments are more than welcome.
>
> Best regards,
>
> Nick
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 18, 2005 12:50 PM
> To: [email-masked]
> Subject: I-D ACTION:draft-papadoglou-hiprg-hit-presence-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>     Title        : Host Identity Tags (HIT) in Presence
> Information Data Format (PIDF)
>     Author(s)    : N. Papadoglou, H. Zisimopoulos
>     Filename    : draft-papadoglou-hiprg-hit-presence-00.txt
>     Pages        : 11
>     Date        : 2005-10-18
>
>    This document describes a new way of exchanging Host Identities (or
>    Host Identity Tags) by means of the Presence Information Data  
> Format
>    [6]  using the Host Identity Protocol (HIP). A new presence
>    information element is proposed as an extension to the Presence
>    Information Data Format (PIDF), to include and convey the Host
>    Identity that corresponds to the different SIP URI's the node may
>    have registered. This automatically creates a list of associations
>    between the SIP URI and the Host identity for the different UA
>    instances on the same or different node.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-papadoglou-hiprg-hit- 
> presence-
> 00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] 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-papadoglou-hiprg-hit-presence-00.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:
>     [email-masked].
> In the body type:
>     "FILE
> /internet-drafts/draft-papadoglou-hiprg-hit-presence-00.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.
>
> <draft-papadoglou-hiprg-hit-presence-00.URL>
>