Subject: [MSEC] Draft minutes

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 09 Nov 2005 16:30:34 -0800

All,

Thanks to Steffen Fries we have the following draft minutes.  I 
edited them and so any mistakes are mine.  Please take the time to 
review them.  I would like to post these around noon tomorrow.  If 
you need more time, please let me know.  thanks.

http://www.securemulticast.org/IETF-64/minutes.txt

A couple (there are more; I will list them in the meeting summary) of 
action items from the meeting are as follows:

1. Start a discussion on the scope of the IPsec extensions work; once 
that is done, Brian and his co-editors will prepare -01- of that 
document and we will circulate to the IPSEC list.  (Brian to follow-up)

2. Start a discussion on the MIKEY modes.  (to follow-up)

regards,
Lakshminath

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: George Gross <[email-masked]>
Date: Thu, 10 Nov 2005 10:34:35 -0500 (EST)

Hi Lakshminath,

I have one correction, and a question....

The small correction regards a sentence describing Brian's update on the
IPsec extensions work in the last bullet item above Issue 1. The current
text says:

"for a small number of senders, it might be ok to just have
 as many GSAs as there are senders..."

I think that what you meant to say instead was:

"for a small number of senders, it might be ok to just have
 as many IPsec data SAs as there are senders..."

since in this context we are talking about having one GSA and an array of
IPsec data SA, each data SA having a distinct anti-replay state per sender
but all sharing the same group key. In other words, we do _not_ want to
imply that a Group Member must execute a join group registration exchange
for N groups, each with its own GSA, simply because the application has N
senders. This latter approach would not be transparent to the application.

As a separate question, could someone please clarify for my benefit more
about what was said in the context of the meeting minutes about Issue 1
where Russ is quoted as saying:

"Russ: 2401bis gets through the entire architecture without touching
IKE.  Why do you think you can't do the same thing."

Would it be accurate to say that if the MSEC IPsec extensions document
defined a conceptual interface between the GKMP and the IPsec subsystem
(as discussed in Issue 4) then the document would suffiently independent
from the GKMP, and therefore the document would be following in the spirit
of RFC2401-bis?

hth,
	George

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 10 Nov 2005 11:44:21 -0800

Hi George,

I replaced GSA with IPsec SA; that was my intent earlier and thanks 
for catching it.  On the clarification, we'll discuss it in detail very soon.

regards,
Lakshminath

---

From: Brian Weis <[email-masked]>
Date: Tue, 15 Nov 2005 09:16:17 -0800

Hi George,

[snip]

> from the GKMP, and therefore the document would be following in the spirit

There was some discussion (Issue 4 on the slides) on what a conceptual 
interface might be, but there was no consensus on the topic during the 
meeting. Someone did point out that one attempt has been made to define 
the interface between IKE and IPsec, which is PF_KEY. Note that this has 
never been standardized. Also, because it was designed with a particular 
architecture in mind it is not universally useful to all IKE/IPsec 
implementations.

I'm not sure a *conceptual interface* would be any more useful to 
IKE/IPsec than the PF_KEY. This indicates to me that such a conceptual 
GCKS/Ipsec interface wouldn't be any more useful to obtain interoperability.

On the other hand, an particular implementation IKE/IPsec interface 
could benefit from a singular interface from key management systems to 
IPsec. For example, I've found the Linux 2.6 IKE/IPsec interface (PF_KEY 
+ extensions) to be an adequate interface for my GDOI/IPsec 
implementation. Looking ahead, if the IPsec multicast extensions draft 
defines additional IPsec attributes, then the Linux 2.6 interface needs 
to be extended to pass those attributes. But however that particular 
interface gets extended should be sufficient for any GKMP running on 
that implementation.

Thanks,
Brian

-- 
Brian Weis
Advanced Security Development, Security Technology Group, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 15 Nov 2005 11:42:41 -0800

*****Speaking strictly as a WG member

At 09:16 AM 11/15/2005, Brian Weis wrote:
>There was some discussion (Issue 4 on the slides) on what a 
>conceptual interface might be, but there was no consensus on the 
>topic during the meeting. Someone did point out that one attempt has 
>been made to define the interface between IKE and IPsec, which is 
>PF_KEY. Note that this has never been standardized. Also, because it 
>was designed with a particular architecture in mind it is not 
>universally useful to all IKE/IPsec implementations.
>
>IKE/IPsec than the PF_KEY. This indicates to me that such a 
>conceptual GCKS/Ipsec interface wouldn't be any more useful to 
>obtain interoperability.

PF_KEY or any of its cousins are definitely out of scope for the MSEC 
IPsec extensions I think.  Russ's general guidance has been to take a 
look at what IPsecbis covers and address those areas.  If there is a 
case that group keying is different in this respect, I would like to see it.

>could benefit from a singular interface from key management systems 
>to IPsec. For example, I've found the Linux 2.6 IKE/IPsec interface 
>(PF_KEY + extensions) to be an adequate interface for my GDOI/IPsec 
>implementation. Looking ahead, if the IPsec multicast extensions 
>draft defines additional IPsec attributes, then the Linux 2.6 
>interface needs to be extended to pass those attributes. But however 
>that particular interface gets extended should be sufficient for any 
>GKMP running on that implementation.

What might be in scope is a discussion or a mapping of the various 
parameters that a group keying system might provide and how they map 
into the various databases described in 2401bis.  An interface sounds 
somewhat rigid and it appears that is the problem with PF_KEY.  Many 
implementers found (reported in MOBIKE, IPSEC and other WG 
discussions) that they eventually drifted toward their own extensions 
to the interface and found that a standards based solution is either 
limiting or unnecessary.  I agree with that.

The IETF has no control really on how people map the parameters from 
the key management subsystem to the data encapsulation 
subsytem.  (Note that for instance, a number of implementations 
integrate the SPD into the firewall rules.)

Lakshminath

---

From: George Gross <[email-masked]>
Date: Tue, 15 Nov 2005 17:48:45 -0500 (EST)

Hi Lakshminath and Brian,

inline....

> >universally useful to all IKE/IPsec implementations.

I agree that PF_KEY is architecture specific. OTOH, the IETF has had a
long history of publishing informational RFC wrt/ how an implementation
could direct and manage a standards track RFC protocol. Examples that come
to mind are the various socket interfaces to IPv6, LDAP, and MIP CoA
management. So it is not unusual practice to complement the
bits-on-the-wire protocol spec with an API spec that helps implementations
make a common set of features and controls available to the programmer.

That said, I'm not advocating that the MSEC IPsec extensions doc add that
granularity of detail. What I do expect to identify in the document are
those attributes that are the MSEC IPsec superset of those SPD/SAD/PAD
attributes that one would exchange between a GKMP and an RFC2401-bis
capable IPsec subsystem.

see below for additional details...

> limiting or unnecessary.  I agree with that.

Yes, this aligns with what I had in mind. Unfortunately, everyone can take
the term "conceptual interface" and run with it in many directions,
including PF_KEY. The PF_KEY interface is not what I had in mind. I simply
want a line drawn in the architecture diagram, and a statement of what
MSEC IPsec and GKMP do that is special at that boundary.

Examples of the parameters that I'd like to see identified as being passed
from GKMP into the MSEC IPsec subsystem:

o SA sequence number for a Group Member joining a group data SA that is in
progress

o Signature public key of a Group Speaker used to validate source
authenticated ESP

o The ability to manage the timing of multiple concurrent data SA traffic
flows, with the goal of assuring application data flow continuity across
group rekey events (i.e. drain an old data SA's transmissions while the
group is installing a new data SA and then transitioning to that new data
SA).

o PAD group membership and GCKS authorization configuration data

o SA synchronization state for counter-oriented encryption algorithms.

o Ability to revise a SPD traffic selector's SSM source address to track a
change incurred by NAT.

o Allow Group Receivers to configure their SPD/SAD to permit unicast error
repair requests directed at the Group Speaker (i.e. when using NORM). In
other words, allow multicast in one direction, unicast in the other...

There may be other attributes needed in the so called "conceptual
interface" that will emerge as we go further into describing MSEC IPsec,
the above items are the ones that I thought of at this moment...

hth,
	George
> integrate the SPD into the firewall rules.)

agreed.

br,
	George

---

From: Brian Weis <[email-masked]>
Date: Thu, 17 Nov 2005 16:56:52 -0800

Hi George,

> attributes that one would exchange between a GKMP and an RFC2401-bis

I definitely agree that additional attributes (along the lines or your 
examples below) will need to be defined for IPsec group SAs. I don't 
think the MSEC IPsec extensions doc can do much more than identify the 
attributes though -- each GKMP & IPsec implementation will need to 
decide how to represent them in their own namespaces.

Thanks,
Brian

---

From: George Gross <[email-masked]>
Date: Thu, 17 Nov 2005 21:11:53 -0500 (EST)

Hi Brian,

okay, we seem to be on the same wavelength about this issue. I'd like to
suggest that we work out offlist (with Dragan too)  the details about how
to insert these additions to the MSEC IPsec extensions v01.

perhaps we should turn our attention to one of the other issues raised at
Vancouver? perhaps composite groups in support of crypto algorithm
migration? ;o)

br,
	George