MSEC WG minutes, IETF79
Chairs: Brian Weis & Vincent Roca
Scribe: Frederic Detienne

Audio: http://www.ietf.org/audio/ietf79/ietf79-ch4-mon-noon2.mp3
       Begins 16:03 from the beginning of the recording.

** 3:20 PM -- actual start of session & Document status
Slides: http://www.ietf.org/proceedings/79/slides/msec-0.pdf

Brian reads out
  - agenda (slide 2)
 - active drafts (slide 3)
 - related RFC's and drafts (slide 4)

** 3:23 PM -- draft-ietf-msec-gdoi-update-07
Draft: http://tools.ietf.org/html/draft-ietf-msec-gdoi-update-07
Slides: http://www.ietf.org/proceedings/79/slides/msec-1.pdf

(please refer to slides)

slide readout.

Slide 6:
  LKH is a mechanism by which a key can be distributed to a very large group and a member of the group can be de-authorized efficiently.

  Brian does not feel we need to put on a tutorial on LKH inside GDOI -- please read the reference material provided in the draft.


Slide 7:
  For every protection algorithm, it is important to related to the RFC for how to implement it (example was given with counter mode).

Slide 9/10:
  Security considerations. Will be discussed and addressed in the document.

Brian clarifies Backward and Forward access control.
 - Forward access control: a revoked GM can't have access to the TEK and KEK (and protected traffic) anymore.
 - Backward access control: a newly joining GM can't have access to previously encrypted traffic, previous KEK's and TEK's

slide 15: SENDER_ID value distribution
Having multiple SENDER_ID seems only realistic if the protocol is overhauled. Would require significant changes -- bumping protocol version number :-) (hmms/laughters in the room).

** 3:35 PM: Sam Hartman presents Multicast Routing Key Management Protocol
Draft: http://tools.ietf.org/html/draft-hartman-karp-mrkmp-00
Slides: http://www.ietf.org/proceedings/79/slides/msec-2.pdf

(please refer to slides -- there were no slide number)

Described as hop by hop integrity assurance of routing protocols -- includes all routing protocols.

Routing protocol is not to be changed -- TLS or DTSL may not be a good fit as require "in protocol changes" (no elaboration on details).

Threat model:
 - every member can become GCKS
 - LKH not needed (small groups, rare eviction)

Credentials: very abstract -- must be a black box. Anything does.

Starting from known technologies:
 - interested in IKEv2 and GDOI
 - not interested specifically in IPsec
 - can use most of the payloads nonetheless
 - IKEv1 spec too fragmented (DOI, ISAKMP, IKE,…) so v2 is preferred (single document)

Election process: tie breaking done via a priority system

Election constraints:
 - election can not be blocked
 - election is insecure but validated by authentication after the fact

Comments
Brian Weis:
 - happy to see state machine -- was missing from initial draft - Sam admits new state variable will be introduced
 - Believes that complexity will increase; can likely not be kept this simple (experience call). Sam agrees
 - tying the protocols (IKEv2 and KMP ?)  together will be "interesting" (sic.)

Brian & Sam discuss that an attacker may force A instead of B to be elected but "this is it" and is not perceived as a major problem (if at all).

Brian:
 - commenting again on re-using gIKEv2 and piggy backing KMP on top be challenging though interesting. 

** 3:50 PM end of session