Minutes of MSEC WG Meeting, 56th IETF, 17 March 2003
---------------------------------------------------

1. Recharter, Thomas:  A new charter was posted to the msec list for discussion.  
Thomas showed the current MSEC I-Ds list.  GDOI & MIKEY are in Last Call.  
Recharter to extend msec life to 2004 to finish work and develop new focus on 
distributed architectures and many:many multicast.  Mar 03 Last Call on GKMARCH 
with several more following.  New focus areas are not on the list or Proposed I-
Ds, but Ran thinks that these problems should be issues for each of the present 
drafts rather than separate drafts.

2. TESLA Update, Adrian: Brief description of TESLA stream, outline of current 
drafts, and future works on broadcast authentication.  Problem is to prevent 
receiver from impersonating sender in a secure group.  Sender precomputes N+1 
keys, 0..N, where Kn = HMAC(Kn-1, 1), K0 = K.  K is installed securely prior to 
the session start.  The sender creats a chain from the installed key(0) to 
key(N-1) where key(N-1) is the first key to be revealed in a TESLA packet during 
the session.  The receiver can always verify that a key(n-k) is part of the 
chain by computing key(n-j), j=k..n, and compute key(N-1) or some intermediate 
key that the receiver has received and cached.  The TESLA I-Ds is draft-ietf-
msec-tesla-intro-01 that adds immediate authentication and concurrent TESLA 
instances (to handle receivers over networks with a wide range of packet delays. 
draft-ietf-msec-tesla-spec-00 is current technical draft that gives a 
bootstrapping procedures (e.g. time synchronization), format, operation with 
ESP, etc.  B.Whillock has done a reference implementation that is available on 
the web.  Looking for a second implementation.  Also need to integrate with 
ESP/MESP.  

3. IPSEC Multicast Issues, Brian: Ran, Mark, Thomas and Brian wrote an I-D to 
document the multicast issues in AH/ESP while they are being revised by S.Kent.  
The issues are (1) SPI allocation and SA lookup using 3-tuple without using 
source address, (2) Anti-replay protection for multi-sender SAs (part of new 
charter of msec), and (3) ICV name.  Overall, this was a productive exchange 
IPSEC and MSEC with good collaboration with S.Kent.  

4. MESP, Mark:  Made MESP into a transform framework for ESP rather than a 
separate protocol.  The framework is based on group secrecy, internal 
authentication and external authentication where external authentication 
protects internal.  Need to resolve making ENC, INT, EXT processing order to be 
mandatory.

5. Feedback messages, Lakshminath: Feedback is needed for GSA synchronization, 
NAKs, and de-registration. Most GKM systems keep a unique key per member; 
suggest we use that unique key for feedback from each group member.  SA lookup 
could probably use the SPI. Proposed feedback message resembles the groupkey 
push message in GDOI.  Hugh pointed out that the unique key is usually a KEK and 
said that the use of a KEK for a TEK could be problematic.  Replay protection 
may use the SEQ# and this may work for NAKs and de-registration but not for out 
of sync feedback messages.  Question:  is this something the group should do?  
The answer is yes.

6. Group key management, Lakshminath:  Do one RFC for LKH, OFT, and OFC as well 
as treating key tree management.  The latter uses binary or natural number 
encoding, the goal is to manage the splitting and shrinking in an efficient 
manner.  Zhang et. al. scheme keeps rekey messages small and limits number of 
messages for maintaining tree.  Two Options.  First, standardize key tree 
encoding and try to get a key tree encoding for all interesting trees.  Second, 
GCKS may advertise a standardized scheme and use it - tradeoffs footprint, 
communication cost, etc.

7. GSAKMP, Hugh: GSAKMP Light done in Sep 2001 that was shorter and simpler.  
Since GSAKMP Light is favored, we decided to focus just on GSAKMP Light and make 
it GSAKMP.  Old GSAKMP considered for Informational RFCs; Russ favors 
Experimental over Informational; if it catches on, then an Experimental track 
protocol can go standards track, Informational cannot.

8. Policy Token, Hugh: New spec has GSAKMP Roles and Policy token.  GSAKMP 
creates set of roles (GO, GCKS, Sub GCKS,and GM).  Policy token wraps policy and 
sent from GO to GCKS who then distributes it to subordinates of group members 
(GM).  GSAKMP protocol incorporates policy-token dissemination.  Policy uses 
Identification, Authorizations, Access Control, Mechanisms, and Signature.  Each 
was explained.

9. DHHMAC for Mikey, Martin:  intended for proposed standard, identity 
protection clarified, aligned with MIKEY v6, and editorial improvements.  
Document is ready for WG last call?  But a -02 version will be submitted prior 
to last call. Ran said that this probably should not go ahead of MIKEY.  Thomas 
will submit in two weeks.  Also, there may be some need for EC for MIKEY.

10. SDP Security Descriptions, Mark: After a brief overview of SDP, Mark 
described two configurations for which SDP Security Descriptions apply; one is 
an end-to-end RTSP running in TLS; the other is a hop-by-hop SIP running over 
some collection of TLS connections.  He briefly described the SDP status, 
syntax, parameters and next steps.  In the discussion, Russ went thumbs down on 
the hop-by-hop SIP security descriptions as offering no security.  Mark and Dan 
Wing wrote the draft-ietf-mmusic-sdescriptions-00.txt and will be updating it to 
draft-ietf-mmusic-sdescriptions-01.txt in the Spring. 
-----------------------------------------------------------------------------------