From: heer at cs.rwth-aachen.de (Tobias Heer) Date: Sat, 28 Feb 2009 20:10:49 +0100 Subject: [Hipsec-rg] Fwd: New Version Notification for draft-heer-hip-service-00 References: <49A7D89F.8080204@hiit.fi> Message-ID: <4DF1C64C-44B9-4163-ACEA-F42227F39619@cs.rwth-aachen.de> > 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: <49A9087B.7080807@helsinki.fi> 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: <77F357662F8BFA4CA7074B0410171B6D07B0BE78@XCH-NW-5V1.nw.nos.boeing.com> 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: <20090227121849.D72313A6979@core3.amsl.com> Message-ID: <01EF6C3E-84AB-433A-83BF-9C801920D5B1@cs.rwth-aachen.de> 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 > 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: <77F357662F8BFA4CA7074B0410171B6D07B0BD96@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: <001401c98a6c$b0824c00$480c6f0a@china.huawei.com> 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: <003f01c98410$f93282b0$480c6f0a@china.huawei.com> References: <77F357662F8BFA4CA7074B0410171B6D07B0BD39@XCH-NW-5V1.nw.nos.boeing.com> <003f01c98410$f93282b0$480c6f0a@china.huawei.com> Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0BD96@XCH-NW-5V1.nw.nos.boeing.com> > -----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