------------------------------------------------
IETF 80 MSEC meeting - Tuesday, March 29th, 2011
------------------------------------------------

Yoav N.: jabber script

Agenda:
http://www.ietf.org/proceedings/80/agenda/msec.html  

Audio record (this is a partial record that covers GIKEv2-end, with a wrong name):
http://ietf80streaming.dnsalias.net/ietf80/ietf80-ch1-wed-am.mp3


Document Status (Chairs)
------------------------
http://www.ietf.org/proceedings/80/slides/msec-0.pdf

RFC6054 "Using Counter Modes with ESP and AH to Protect Group Traffic"
was published in Nov 2010.


MIKEY IANA Rules (Jari Arkko)
-----------------------------
draft-arkko-mikey-iana-00
http://www.ietf.org/proceedings/80/slides/msec-1.pdf

MIKEY (RFC 3830) defines several IANA namespaces. In practice, it turns out that
current rules to define MIKEY extensions are often too restrictive by requiring 
IETF Review.

The goal of this I-D is to change the way MIKEY related documents are standardized
within IETF. Certain namespaces could follow either "IETF Review or IESG Approval"
or "Specification required" rules.

Question: What is the feeling of the group? Should it be a WG document?

Brian: I'd like to know how the choice of "IETF Review or IESG Approval" has been made.
John Mattsson: By the authors who decided what rule should be for each field.

Tero: Most of registries are large enough to reduce the need for strict review.
Jari: Well, most fields are 8-bits long, so it's a bit strict.
Sean: Send to the WG list.

Vincent: Section 3 says that one need to take care about potential security
concerns with new values. But if there's no IETF review, who will check?
Jari: the IESG will check, as well as the authors.


The Group Domain of Interpretation (Brian Weis)
-----------------------------------------------
draft-ietf-msec-gdoi-update-08
http://www.ietf.org/proceedings/80/slides/msec-3.pdf

Significant changes have been made since 07 version. Some of them are editorial
(for clarity purposes) but others are more fundamental. There are:
- IANA changes:
- Counter mode changes: now the group member detects the use of a group counter
upon receiving an SA payload. The algorithm is detailed and guaranties there is
no duplicate use of SID.

No comment, no question.
Decision to WGLC the document ASAP, since the differences WRT version 07 are
significant.


Group Key Management using IKEv2 (Brian on behalf of the authors)
-----------------------------------------------------------------
draft-yeung-g-ikev2-02
http://www.ietf.org/proceedings/80/slides/msec-2.pdf

This document defines a group key distribution protocol that relies
on IKEv2 (RFC5996) while following the MSEC key management architecture.

Slide 5:
Tero: You have both IDr and IDg. Why? Is it really needed?
Brian: I'll ask the authors.

Slide6:
Tero: we have something special to do here. 
Brian: 
Tero: just using the header... is risky.
In IKEv2 if you see a message with same SSID you just drop it.
It's fine if there's just one entity sending it, but if there are multiple
entities it's risky.

Slide 12:
Tero: it would be better to have a notification and negotiation mechanism.
In IKEv2 we notify and negotiate several things.
Brian: OK.

About the relationships with MRKMP:

In previous meeting, there was a presentation from Sam on relationships with
KARP requirements on group key management (e.g. between several OSPF routers
that discuss on the same link).

There's a lot of common material with G-IKEv2 in fact. Therefore the G-IKEv2
team tried to explain how to use this protocol to address KARP requirements
through a dedicated profile.

What to do? Progress as individual I-D?
No question, no comment.