----------------------------------------------------
MSEC WG Minutes, IETF-58, Minneapolis (Nov 10, 2003)
----------------------------------------------------
Meeting at Monday 10 November, 9:00am-11:30am
Welcome - Thomas Hardjono
-------------------------
o No changes to agenda
o Review of WG status: I-D Milestones since last IETF foil
- www.securemulticast.org/msec-drafts.htm gives the draft status
- Ran: mesp features have been incorporated into IPsec ESPbis
- Thomas: Multicast issues draft could go to informational notably the "IPsec issues draft"
- Russ: If ESPbis has incorporated everything then should drop this; the consensus is to drop it
- No status on secure feedback draft.
- Ran: have nothing on how key management works with application layer data protection
- Mark: Hard to do this without having a particular application data security protocol in the pipeline but there is some work underway on multicast transport-layer security
- Ran: We should define this in anticipation of an application-security protocol
- Andrea: GSAKMP is supporting an app protocol that is not an IETF standard; Ran thought that the API and object definition would be of interest
- Brian: Is this specifically an API? Ran: Yes. Brian: not sure we need to do an API in the MSEC WG. The thing of interest is the objects and bindings in the protocol for doing this.
- Thomas: We need to discuss policy token; we'll do this after Andrea's presentation
MIKEY update - Elisabetta
-------------------------
o IESG evaluation reviewed (see foilset)
- Brian: Is a new PRF RFC required or is this is an extension?
Elisabetta said that this was an extension mechanism.
- Russ: some means are needed to signal the use of a new PRF
- General discussion on the need to decouple MIKEY from the mmusic key-mgt.
- Russ recommends to not reference the key-mgt document from MIKEY
o Status is that a revised I-D is needed for IESG last call
GKMARCH update - Ran (see foils)
--------------------
o There are two outstanding issues from WG Last Call, one being peer controllers
- George: From receiver, what's important is how the controller is authenticated. Will next draft allow re-key from peers?
- Brian: It seems important to allow for this.
o We will incorporate needed changes and resubmit to WG last call
GSAKMP update - Andrea (see foils)
----------------------
o Changes from last I-D and new additions presented
- Ran: are cookies still include in request to join?
- Andrea: yes
o Draft 04 is out is out and 05 will follow for possible last call
- Thomas: Policy token is now broken into two pieces with a generic piece. Would GDOI use them?
- Brian: Yes, GDOI could use the policy token
o Ran: We are going to be asked about having two separate group key management protocols when GSAKMP goes to the IESG last call in the future. Do we need two?
- Mark: historically the difference was between the ISAKMP header that GDOI used and GSAKMP did not. Now there are a lot of different functions in today's GSAKMP.
- Brian: GSAKMP also is closely tied to the policy token
- Thomas: There is an important application for GSAKMP that is distinct from GDOI just as there was a need for GDOI to leverage the IKE installed base. We need to move GSAKMP forward to WG Last Call a.s.a.p. given that MSEC Charter ends in July 2004.
- George: There is something to be said for parallel development of the two protocols; could focus on rekey message as a unifying message, e.g. GDOI uses a great variety of different authorization methods and these distinctions are a concern for the registration protocol and not the rekey protocol
- Thomas: When will GSAKMP be ready for last call? How about January or February.
- Andrea thought that was reasonable
DHHMAC update - Steffen Fries presenting on behalf of Martin (see foils)
-------------
o Changes from last I-D
o Version 05 will be done by xmas and this is recommended as a last call document
- Ran: is there a constituency for this?
- Mark: This aligns MIKEY with H.235? Steffen said 'yes'
- Betta: Is this needed for H.323? Steffen said 'yes'
- Thomas: Is there opposition to moving this forward?
(No one in audience opposses). Lets move it forward.
- Mark: The motivation would be to align this IETF protocol (MIKEY) with H.235 (would like to do the same with SRTP as well).
- Ran: Should take to WG last call?
- Thomas: We can do this with draft 05 is submitted.
MSEC & AAA - George (see foils)
----------
o Status given and motivation for including AAA/Diameter in MSEC focus.
o GDOI could leverage ISAKMP/IKE AAA work but GDOI does not separate KS from GC functions;
- Mark: What is the distinction?
- George: GC does registration but does not have the key for the group.
- Mark: This distinction is not generally well-defined in msec.
- George: This was discussed in the MSEC architecture.
- Brian: KS could be closest to member but the GC would do registration.
- Mark: In general, this problem is difficult and not yet solved in security systems, viz. X.509 PKI across domains.
- George: Large-scale multicast groups are likely to be multi-realm and we will need to solve this in MSEC.
- Andrea: It is unlikely to be able to separate these functions since there is always a potential collusion problem.
o GSAKMP uses the Diameter "push" model as opposed to the GDOI "pull" model.
o Have not yet decided how to introduce this to msec.
- Thomas: Can't this be in the generic policy token I-D?
- George: It will at least influence the design of the generic policy token and could be completely defined there
Wrap Up
-------
o Korea IETF in Mar 2004: Thomas took a show of hands and found ~9 persons were planning to attend.
o Ran might attend so there may be an msec meeting at IETF 59.
o Discuss again in mailing-list in early 2004.
------------------------------------------------------------------------------