IETF 77 - Anaheim - Tuesday March 23rd 2010 - MSEC minutes
==================================================
Meeting material:
https://datatracker.ietf.org/meeting/77/materials.html
http://www.ietf.org/proceedings/10mar/agenda/msec.html
Meeting audio track:
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf77/ietf77-ch6-tue-afnoon2.mp3.1
Introduction - Chairs
================
(Audio track offset: 14'30)
Active Drafts:
- draft-ietf-msec-tesla-for-alc-norm-10
Status: Nearly published (in auth48)!
- draft-ietf-msec-ipsec-group-counter-modes-05
Status: Completed WG Last Call
- draft-ietf-msec-gdoi-update-05
Status: Work in Progress
Related Drafts:
- draft-seokung-msec-mikey-seed-05
Status: In Auth48
- draft-mattsson-mikey-ticket-02
Status: In IETF Last Call
- draft-ietf-rmt-simple-auth-for-alc-norm-02
Status: Authors request MSEC review
Milestones:
- Apr 2010 IETF Last Call on Using Counter Modes with ESP and AH
- Jun 2010 WG Last Call on update to Group Domain of Interpretation (GDOI)
- Nov 2010 WG re-charter for other work items or disband
We will revise the MSEC milestones (can be done at any time).
Using Counter Modes with ESP and AH to Protect Group Traffic - David McGrew
==============================================================
- draft-ietf-msec-ipsec-group-counter-modes-05
- Slides
(Audio track offset: 20'00)
David introduces the motivations for this I-D, namely being able, in a multi-sender context, to manage the IV space in such a way to prevent IV collision between the various senders. This is made possible by portioning the IV field into a Sender-IDentifier (SIV) subfield, and a Sender-Specific IV subfield. The Group Controller Key Server (GCKS) is responsible for managing the SID values, and each sender manages its SSIV space. One constraint is the need for senders to notify the GCKS before exhaustion of its SSIV space.
The I-D has been revised to take into account the WGLC comments (one year ago), and the authors feel the document is ready for IESG review.
Q: what about situations having more than 256 senders?
A: several SID sizes are possible, under the control of the GCKS that chooses the most appropriate one. Some sizes are MUST implements.
Decision is to go to the list and if there is no objection, then ask Tim Polk to proceed with the IETF Last Call.
The Group Domain of Interpretation - Sheela Rowles
=========================================
- draft-ietf-msec-gdoi-update-05
- Slides
(Audio track offset: 27'00)
This I-D revisits the initial GDOI specifications (RFC 3547, July 2003).
Several changes have been made (since 2006, this is an "old" I-D), for instance for algorithm agility purposes, in order to support AH, clarifications have been made taking into account the experience gained, cryptographic algorithms recommendations updated, and finally this document has been aligned with the new IP security extensions for multicast (RFC 5374) and IPsec group counter mode I-D. Because of these changes, the whole document has been revamped.
Sheela first introduces the basics of GDOI, and then goes through the main differences with GDOI v1. Of interest are the modifications made in order to comply with rfc 5374 and the creation of a new payload (Group Associated Policy), that also carries the SID (Sender ID) value assigned to each particular sender (see draft-ietf-msec-ipsec-group-counter-modes). Finally, three new IANA registries are introduced.
Q (Tim): Is this document meant to obsolete GDOIv1 (RFC 3547)?
A: Yes and it is also in line with the new RFC 5374 that specifies how the IPsec security services are applied to IP multicast packets.
Q (BW): Does anybody volunteer to review this I-D during WGLC?
A: One volunteer.
Management Information Base for the Group Domain of Interpretation - Kavitha Kamarthy
=====================================================================================
- Slides
(Audio track offset: 37'00)
This I-D proposes a MIB for GDOI v1.
Q (BW): How many people read?
A: None.
Q (BW): How many people are interested?
A: 3 people are interested.
Q (Bill Atwood): How does it take into account the revised GDOI?
A: There is no need to make any changes to this.
Group Key Management using IKEv2 - Aldous Yeung
=========================================
- Slides
(Audio track offset: 44'50)
G-IKEv2 is an alternative to GDOI (NB: only GDOIv1 is considered in this presentation, not draft-ietf-msec-gdoi-update). Since IKEv2 is now deployed, it makes sense to leverage on it and to build a group key management system on top of this key exchange/transport protocol. After a quick survey of the G-IKEv2 versus GDOI differences, a focus is made on the registration and rekey exchanges. Then Aldous introduces the KEK, TEK and SIG payload changes W.R.T. GDOI.
Q (?): In IKEv2 both ends don't have to agree on the lifetime. Why does the lifetime need to be pushed to the GM with a GSA lifetime attribute?
A: If the key is lost during a rekey for a certain GM, this latter must have a way to determine that something went wrong. By knowing the TEK lifetime, this GM can identify that something went wrong and ask the GCKS to re-issue this key. How this is done is implementation detail.
Q: Why don't you use already existing SA and traffic selector payload?
A: It is the same thing named differently. We named it source and destination for clarity purposes.
Q: Why do you define a new payload called TEK instead of already existing payload available in IKEv2?
A: We don't want to make it so different from GDOI.
Q: (non audible)
A: I'll take a look at IKEv2 AUTH and see if anything can be reused instead of inserting a new one.
Should this be a WG Item?
Comment (Tim): We need time, we need people to read it (nobody did) and post to the list so that we can make a decision.
Symmetric Key Transport and Group Key Management - David McGrew
===============================================================
- Slides
(Audio track offset: 1:05'00)
David discussed how a Group Key Management (GKM) system distributes secret keys as part of an authenticated & encrypted exchange. He then introduced the concept of a key wrap service, using the AES Key Wrap as an example. Three options to integrating a key wrap service such as AES Key Wrap into a group key management exchange such has GDOI were presented, along some questions regarding the appropriateness of each option.
Q (Dan Harkins): Can a key wrap service use RFC 5297 (SIV-AES)? It could wrap any amount of data, and has many proofs. It's current status with NIST is that it is waiting on NIST review.
A (Tim Polk): NIST gets many suggested modes to analyze. But vendors then only want to use standards based modes.
Q (Tim Polk): What is involved to move to AES Key Wrap in these GKM protocols?
A: NIST currently gives the impression that key wrapping is a MUST.
Tim: That might be too strong a statement. There will be a new 800-38 series document that should be put out for review soon, and it clarifies requirements around key wrapping.
David: MSEC could benefit from a discussion with NIST.
Tim: The key wrapping original use case did not have higher cost. MSEC was not the application/use case intended by NIST.
Brian; Weill the new 800-38 series document clarify use-cases for key wrapping?
Tim: Not sure, but will check.
Allen Roginsky: The AES Key Wrap has been around sine 2007, but NIST did not publish it. NIST published implementation guidelines, which allow AES Key Wrap until year 2010. NIST is currently in a transition period, including key wrap. NIST 800-131 is the transition document , and though the comment period recently closed the authors are still open to comments. Please read the section on key wrap as it affects GDOI. GDOI is not included in the transition document. GDOI was submitted to NIST 2-3 years ago, and NIST accepted it through 2010 but not in the transition due to an inability to measure its security strength. The new transition policy states that keys need to be 2048 bits after 2010 for government use.
Tim agreed to send a URL to the transition document to the list.
MSEC Future Directions discussion - Chairs
==================================
- Slides
(Audio track offset: 1:33'38)
Future directions: we can't answer this today, but the two proposed items will need to taken to the list, and depending on what direction KARP takes in terms of automated multicast key management.