Subject: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt

From: Marcus Wong <[email-masked]>
Date: Fri, 11 Sep 2009 11:46:51 -0400

Hi Everyone,

I'm new to the working group.  I've uploaded a draft on the use of notify
payload for integrity data exchanges in IKEv2 for your comments and review.
All comments are highly appreciated.  Thanks everyone.

A new version of I-D, draft-wong-ipsecme-ikev2-integrity-data-00.txt has
been successfuly submitted by Marcus Wong and posted to the IETF repository.

Filename:	 draft-wong-ipsecme-ikev2-integrity-data
Revision:	 00
Title:		 Integrity Data Exchanges in IKEv2
Creation_date:	 2009-09-11
WG ID:		 Independent Submission
Number_of_pages: 9

Abstract:
IKEv2 supports mutual authentication of the peers but does not support
platform integrity validation of the peers nor does it support the exchange
of data related to the platform integrity validation.  This extension allows
platform integrity validation data to be exchanged from one peer (initiator)
to another (respondent), allowing the other peer to either use the data for
statistical analysis, pass it along to a validation entity for validation or
pass it along to a Fraud Information Gathering System for fraud detection or
analysis.

A URL for this Internet-Draft is:
http://www.ietf.org/id/draft-wong-ipsecme-ikev2-integrity-data-00.txt

Regards,

Marcus Wong
Huawei Technologies Co.,Ltd.
400 Somerset Corp Blvd., Suite 602
Bridgewater, NJ 08812
(908)541-3505

---

From: Stephen Kent <[email-masked]>
Date: Fri, 11 Sep 2009 15:22:49 -0400

>pass it along to a Fraud Information Gathering System for fraud detection or

I have mot read you I-D, but this sounds like a NEA issue being 
pushed into an IPsec protocol. Am I wrong?

Steve

---

From: Marcus Wong <[email-masked]>
Date: Fri, 11 Sep 2009 16:06:24 -0400

Steve, you are mostly right, but this I-D only deals with the integrity data
exchange using the notify payload.  Thanks. 

Marcus

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Friday, September 11, 2009 3:23 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt

Steve

---

From: Stephen Kent <[email-masked]>
Date: Sat, 12 Sep 2009 03:47:35 -0400

>exchange using the notify payload.  Thanks.

Thanks for the clarification. That still raises the question of why 
we ought to duplicate this NEA functionality in IKE. Does the I-D 
provide suitable motivation for that, and has the idea been passed by 
the NEA WG folks?

Steve

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 12 Sep 2009 15:29:19 +0300

I completely agree that we shouldn't be duplicating the NEA protocols. OTOH, I'm willing to consider transport of NEA information within IKE/IPsec if people are interested. Note that NEA has just only started to look at their own mainstream transport protocol (NEA-PT). This is very likely to end up being EAP.

Thanks,
        Yaron

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stephen Kent
> Sent: Saturday, September 12, 2009 10:48
> To: [email-masked]
> Cc: [email-masked]
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.

---

From: Marcus Wong <[email-masked]>
Date: Wed, 16 Sep 2009 15:27:40 -0400

Thanks for the initial feedback.  I certainly agree with the view that we
shouldn't duplicate the NEA protocols and I couldn't emphasize enough that
the intent of the ID is purely from transport's perspective.  I am grateful
that you can view the ID with an open mind.  

Perhaps a little background could stir up people's interest.  I have drafted
this ID with initial 3GPP femto application in mind.  In 3GPP femto case,
there are some very specific security requirements that the device
authentication and device integrity validation be bound together due to the
fact that the femto AP will be deployed in environments that is not very
well controlled by the network operators (e.g. semi-hostile environment)
Part of the device integrity validation necessitates transporting NEA
information to the network for validation.  3GPP working group SA3 has
chosen IKEv2 as the authentication protocol with certificate-based
credentials for the femto devices.  The working group has also agreed in
principle that the Notify payload within IKEv2 can be used for transporting
the integrity information.  Please see the latest draft of the 3GPP
standards for additional information.  The latest draft is here:
ftp://ftp.3gpp.org/TSG_SA/WG3_Security/TSGS3_56_Seattle/Docs/S3-091491.zip ,
which is also one of the references in the ID. Please note that I'm also the
editor of this 3GPP document.  We have looked at what other groups have done
and it looks like that with minimal extension to IKEv2 we could piggyback
the NEA transport part using the Notify payload with relative simplicity and
least amount of interoperability issues, especially since IKEv2 is widely
used as the de facto standard protocol for authentication and key exchange.

Thanks,

Marcus

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yaron Sheffer
Sent: Saturday, September 12, 2009 8:29 AM
To: Stephen Kent; [email-masked]
Cc: [email-masked]
Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt

I completely agree that we shouldn't be duplicating the NEA protocols. OTOH,
I'm willing to consider transport of NEA information within IKE/IPsec if
people are interested. Note that NEA has just only started to look at their
own mainstream transport protocol (NEA-PT). This is very likely to end up
being EAP.

Thanks,
        Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 16 Sep 2009 23:29:58 +0300

Hi Marcus,
reading your 3GPP document, I think you have something else in mind, not exactly what NEA is planning on doing. NEA posture information may be very large, containing data about many components of the OS and applications. I believe what you are looking for is a much more limited set of hash values, similar to what you'd measure as part of TPM validation of a system. This is a very unique reqiurement right now, probably a few years ahead of NEA (their origins are with TCPA, but they're far from the Trusted Computing paradigm now). So I am not sure there is value today in integrating your requirements (and the related IKE-based solution) with NEA or even in standardizing this solution within ipsecme.

You are still free to request a notification type, so there's nothing blocking your 3GPP work from moving forward. And I am open to be convinced otherwise. Also, I suggest that you talk to the NEA chairs.

And a related technical issue: IKE is not good as a transport for large pieces of information, because everything needs to fit into a UDP packet. Your lightweight notification will not be a problem. But large NEA posture blobs will be.

Thanks,
    Yaron

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Marcus Wong [[email-masked]]
Sent: Wednesday, September 16, 2009 10:27 PM
To: [email-masked]
Subject: Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt

Thanks,

Marcus

-----Original Message-----

Thanks,
        Yaron

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Sep 2009 17:24:01 -0400

Marcus,

Thanks for the additional background. I am not an expert on 3GPP. Do 
you know if there an IETF liaison to the 3GPP? If so, the right 
approach is to have that individual coordinate an action like this 
between the SDOs, i.e., when SDO-A wants SDO-B to modify/extend a 
protocol to accommodate a function that SDO-A wants to implement 
using SDO-B's protocol.

Steve