Subject: [Hipsec-rg] Fwd: New Version Notification for draft-heer-hip-service-00
From: heer at cs.rwth-aachen.de (Tobias Heer)
Date: Sat, 28 Feb 2009 20:10:49 +0100

>
Hi folks,

There is a new Internet draft concerning services offered by HIP end- 
hosts and HIP middleboxes. It allows to specify services in a flexible  
and fine-grained manner.

Feedback is very appreciated. We are especially interested in service  
classifications that are of interest to you.

Best regards,

Tobias

>
> A new version of I-D, draft-heer-hip-service-00.txt has been  
> successfuly submitted by Samu Varjonen and posted to the IETF  
> repository.
>
> Filename:	 draft-heer-hip-service
> Revision:	 00
> Title:		 Service Identifiers for HIP
> Creation_date:	 2009-02-27
> WG ID:		 Independent Submission
> Number_of_pages: 10
>
> Abstract:
> The Host Identity Protocol [RFC5201] is a signaling protocol for
> secure communication, mobility, and multihoming that introduces a
> cryptographic namespace.  This document specifies an extension for
> HIP that enables HIP end-hosts and HIP-aware middleboxes to announce
> services to HIP hosts during a HIP Base EXchange (BEX) or HIP update.
> Service providers are able to specify the type and requirements of a
> service; clients can then decide to agree on the terms of service.
> This allows the service provider to verify the accordance of the
> client with the service conditions while the client is able to verify
> the authenticity of the used service.
>
>
>
> The IETF Secretariat.
>
>
>
>

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer

From: samu.varjonen at helsinki.fi (Varjonen Samu)
Date: Sat, 28 Feb 2009 11:48:43 +0200
Subject: [Hipsec-rg] draft-varjonen-hip-srp-00.txt
Message-ID: <[email-masked]>

Hi,

Just submitted a new draft on HIP and user authentication.

Title           : HIP and Strong Password Authentication of Users
Author(s)       : S. Varjonen
Filename        : draft-varjonen-hip-srp-00.txt
Pages           : 17
Date            : 2009-02-28

This document specifies how to use Secure Remote Password (SRP)
protocol in conjunction with Host Identity Protocol (HIP).  In order
to conceive this conjunction this document specifies three new
parameters to be used with HIP control packets.  These parameters are
used to transport values related to the SRP protocol.  This document
also specifies how peers should act when these SRP parameters are
found from HIP control packets and how this affects middleboxes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-varjonen-hip-srp-00.txt

Comments are appreciated.

BR,
Samu Varjonen

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Fri, 27 Feb 2009 09:27:01 -0800
Subject: [Hipsec-rg] HIP research group meeting:  call for agenda items
Message-ID: <[email-masked]>

Hi,
We applied for and received a meeting slot at the next IETF meeting:
Thursday March 26, 0900-1130, Breakout 2 room

We are starting to get private requests for the agenda and to be added
to the agenda, so please, if you would like to present or discuss
anything at the RG, feel free to reply to one of the chairs or to this
list.  

Thanks,
Tom

From: heer at cs.rwth-aachen.de (Tobias Heer)
Date: Fri, 27 Feb 2009 17:35:06 +0100
Subject: [Hipsec-rg] Fwd: New Version Notification for draft-heer-hip-middle-auth-02
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi folks,

There is a new version of the middle auth draft. For details see the  
change log below:

Changes since version 01:

* Most important: Condensed puzzle and nonce into one parameter. This  
simplifies handling at the middleboxes since these don't need to  
reorder parameters any more. It also makes the draft less complicated.

* Updated references to match last standardization progress of HIP  
drafts

* Removed ambiguity in Protocol Overview (Section 2.1)

* Removed 32-byte guideline and added more general text in Section 2.1.1

* Added reference to RFC2460 for IPv6 1280 byte packet limit in  
Section 2.1.1

* Fixed wrong figure numbers.

* Fixed some amiguities in section 2.2

* Removed redundant text - The document is much leaner now.

Changes since version 00:

* New section about security and bindings between HIP and ESP traffic

* Rewrite and extension of the discussion of the security properties.

* Minor fixes for alignment with the base documents (packet sizes)

Abstract:
The Host Identity Protocol [RFC2119]is a signaling protocol for
secure communication, mobility, and multihoming by introducing a
cryptographic namespace.  This document specifies an extension for
HIP that enables middleboxes to unambiguously verify the identities
of hosts that communicate across them.  This extension enables
middleboxes to verify the liveness and freshness of a HIP association
and, thus, enables reliable and secure access control in middleboxes.

Comments are very appreciated.

The draft can be found here:
http://www.ietf.org/internet-drafts/draft-heer-hip-middle-auth-02.txt

BR,

Tobias

Anfang der weitergeleiteten E-Mail:

> Von: IETF I-D Submission Tool <idsubmission at ietf.org>
> Datum: 27. Februar 2009 13:18:49 MEZ
> An: heer at cs.rwth-aachen.de
> Kopie: wehrle at cs.rwth-aachen.de, miika at iki.fi
> Betreff: New Version Notification for draft-heer-hip-middle-auth-02
>
>
> A new version of I-D, draft-heer-hip-middle-auth-02.txt has been  
> successfuly submitted by Tobias Heer and posted to the IETF  
> repository.
>
> Filename:	 draft-heer-hip-middle-auth
> Revision:	 02
> Title:		 End-Host Authentication for HIP Middleboxes
> Creation_date:	 2009-02-28
> WG ID:		 Independent Submission
> Number_of_pages: 20
>
> Abstract:
> The Host Identity Protocol [RFC5201] is a signaling protocol for
> secure communication, mobility, and multihoming that introduces a
> cryptographic namespace.  This document specifies an extension for
> HIP that enables middleboxes to unambiguously verify the identities
> of hosts that communicate across them.  This extension allows
> middleboxes to verify the liveness and freshness of a HIP association
> and, thus, to secure access control in middleboxes.
>
>
>
> The IETF Secretariat.
>
>

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer

From: zhangdacheng at huawei.com (Zhang Dacheng)
Date: Mon, 09 Feb 2009 12:12:57 +0800
Subject: [Hipsec-rg] Key Revocation Issue
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi, Tom:

Very happy to get your reply again. It is very nice to exchange ideas with
you. 

In a security system, a key revocation may occur not only when a key has
been found to be compromised but also when the possibility of key compromise
is over a threshold. For example, the operating system of our computer may
remind us to change our password every three months, which indicates the
strengths of our passwords are not secure enough as time passes rather than
our passwords have been stolen. 

I agree that in a distributed system, the identifiers of system components
are desired to be stable. Transient identifiers will make the system more
complex and error prone. However, in the HIP architecture, each HIT is
associated with a cryptographic key which needs to be updated periodically
to keep the security strength. Therefore, the key revocation issues cannot
be ignored unless we only expect a HIP system works securely for a
relatively short period (for example, one year). Do you agree with this
point?

In addition, I believe there are many things left in the area for us to
explore. For instance, in PKI, one can assess the validity of a public key
by checking its living-period in corresponding certificate. In HIP, no such
information is provided. In addition, PKI provides the Online Certificate
Status Protocol for users to query the validity of certificates while no
similar protocol is provided in HIP. 

Best Regards

Dacheng

> -----Original Message-----
> From: Henderson, Thomas R [mailto:thomas.r.henderson at boeing.com]
> Sent: Friday, February 06, 2009 11:58 PM
> To: Zhang Dacheng; hipsec-rg at listserv.cybertrust.com
> Subject: RE: [Hipsec-rg] Key Revocation Issue

> 
> Sorry for the delay in responding...
> 
> I agree that there will be a need to deal with HIT changes in any 
> practical deployment.  What I was observing is that, if the HIT is 
> transient, this is all the more reason not to base ACLs on them, but 
> to use rather the long-term stable name.
> 
I definitely agree with that. Additionally, in this case, additional
information needs to be provided to authenticate or verify the long -term
stable name. 

> This may also mean that guidance similar to RFC 1958 section
> 4.1 may apply to HITs, in such use cases:
> 
>    4.1 Avoid any design that requires addresses to be hard coded or
>    stored on non-volatile storage (except of course where this is an
>    essential requirement as in a name server or configuration server).
>    In general, user applications should use names rather than 
> addresses.
> 
This is the way that I am thinking in. However, since HITs are used to
identify hosts in HIP, we seems to have no choice but to find some ways to
let the entities using an antique HIT know that the HIT has been updated. 

> Also, if HITs truly need to be revoked due to key compromise, it seems 
> problematic to try to define a framework where one HIT is linked 
> somehow to another so holders of the old HIT can securely find the new 
> HIT, based on HIP mechanisms alone.
> 
I agree with that. In many existing security systems, human involvement is
required when dealing with key compromising issues. However, this doesn't
mean we need to do nothing when we design HIP. Maybe we cannot  solve the
entire problem, but at least we can try to push a step forward. For example,
in PKI, when a certificate is found to be compromised, the CA are normally
informed in an out-of-band way. But this does not prevent the Certificate
revocation list protocol and the Online Certificate Status Protocol from
being adopted.

> Tom
> 
> Tom

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Fri, 6 Feb 2009 07:58:02 -0800
Subject: [Hipsec-rg] Key Revocation Issue
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Zhang Dacheng [mailto:zhangdacheng at huawei.com] 
> Sent: Saturday, January 31, 2009 6:01 PM
> To: Henderson, Thomas R; hipsec-rg at listserv.cybertrust.com
> Subject: ??: [Hipsec-rg] Key Revocation Issue
> 
> Hi,
> 
> Very happy to get your feedback. Actually, the requirements 
> of HIT mapping
> are not limited to ACLs. There are still some other scenarios 
> where HIT
> mapping is needed. For example, the components of a current business
> application can be developed independently, maintained by different
> organizations, combined at runtime, and communicate with asynchronous
> messages.  A typical collaboration between such two 
> components can last from
> days to months.  Therefore, in such a scenario, change of HITs can be
> common.(Please refer to the literature of SaaS (software as a 
> service) and
> SOA (service oriented architecture) for more details.) When a 
> host changes
> its HIT, there should be a way to inform other collaborating 
> asynchronous
> hosts of the change. DNS is a potential solution. But my 
> concern is whether
> every host in the HIP architecture should be associated with 
> a FQDN. In this
> point, I agree with Andrew.
> https://listserv.cybertrust.com/pipermail/hipsec-rg/2009-Janua
> ry/000616.html
> . If a host only consumes services provided by other hosts, it is not
> reasonable to force the host to apply and maintain an FQDN. 
> 
> > > Currently, I am thinking whether 
> > it is a good 
> > > way to achieve this objective by extending the functionality of 
> > > Rendezvous servers. DNS can also be a candidate.
> 
> As I mentioned previously, I am not trying to introduce a 
> "new" third party.
> It is fantastic if DNS service can be provided. But in the 
> cases there is no
> FQDN, we can try to solve the HIT mapping issue by extending the
> functionality of Rendezvous servers. In addition, a HIT can 
> only last for a
> very short period (maybe  minutes), while it may take time for DNS to
> refresh information. In this case, the idea of  extending of  
> Rendezvous
> servers seems to be more valuable. 
> 
> What do you think about it?

Sorry for the delay in responding...

I agree that there will be a need to deal with HIT changes in any
practical deployment.  What I was observing is that, if the HIT is
transient, this is all the more reason not to base ACLs on them, but to
use rather the long-term stable name.

This may also mean that guidance similar to RFC 1958 section 4.1 may
apply to HITs, in such use cases:

   4.1 Avoid any design that requires addresses to be hard coded or
   stored on non-volatile storage (except of course where this is an
   essential requirement as in a name server or configuration server).
   In general, user applications should use names rather than addresses.

Also, if HITs truly need to be revoked due to key compromise, it seems
problematic to try to define a framework where one HIT is linked somehow
to another so holders of the old HIT can securely find the new HIT,
based on HIP mechanisms alone.  

Tom

Tom