Multicast Security WG Chairs: Ran Canetti and Lakshminath Dondeti Monday: 3:20 - 5:20 @ IETF-67 November 6, 2006 Note Takers: Sheela Rowles and Steffen Fries ____________________________________________ Agenda: * Key management protocols > "GDOI Extensions" draft-liu-gdoi-extensions-00.txt. Liu Ya > "GDOI Key Management Exchanges for the SRTP Data Security Protocol". draft-baugher-msec-gdoi-srtp-00 Mark Baugher > "Updates to GDOI" draft-ietf-msec-gdoi-update-01 Brian Weis > "GKDP" Lakshminath Dondeti > "MIKEY-ECC" TBD * Multicast IPsec > "IPsec extensions" draft-ietf-msec-ipsec-extensions-04 Brian Weis > "IPsec TESLA" draft-dondeti-msec-ipsec-tesla-01 Lakshminath Dondeti > "Using Counter Modes for ESP and AH to Protect Group Traffic" draft-weis-esp-group-counter-cipher-00 Brian Weis _________________________________________________________ "GDOI Extensions" draft-liu-gdoi-extensions-00.txt. Liu Ya liuya@huawei.com Sharing key messages amongst group members Goal: to make one GCKS serve more group members Steps: - building group neighborship - sharing key messages between neighboring members 2 ways to establish group neighborship: It can be manually configured on GM side It can be centrally managed on GCKS 2 new exchanges: NEIGHBORSHIP-ESABLISH-NOTIFY NEIGHBORSHIP-DESTROY-NOTIFY Defined for GCKS Sharing keying messages GroupKEY-SHARE - a new exchange in the draft, is used for this purpose It can only be executed between neighboring members of the same sub-group. Only Keying messages rather then keys are shared. Recent keying messages must be cached. For security consideration, authentication is necessary for GROUPKEY-SHARE Currently, digital signature method is used. * Discussion o Mark: have members act as group controllers and key server as basic idea? ' some kind of distributed GCKS. * Why key massages and not keys? Key messages are protected and may even be published through a website. Mark will post his ideas/comments to the msec list. o Lakshminath: What is the use case? Requirements document for the draft? The current requirements are not fully understood, why it is necessary. Brian: We lose being able to do authorization between group members. We still have authentication. Hard to determine if other group member is authorized to get the key. With GDOI, can use KS to build an LKH tree which keeps track of group membership, and can remove authorization of a bad member quickly. This is hard to do in this case. o Lakshminath: OSPFv3 working group for this? Something has to happen elsewhere before we can discuss it here further. Liu: let's discuss on mailing list. Brian: subgroup restriction? May need to set up router to be between subgroups. Liu: subgroup formed automatically. How to build subgroup is a group policy and determined by network manager. Brian: why only 1 subgroup? Liu: purpose of subgroup is to share group messages. Subgroup A cannot share messages with subgroup B. Brian: we need a reqts doc since there are ideas we don't understand here. Lakshminath: why not let transport layer take care of it? Let's do a reqts analysis of what it is we're trying to achieve. i.e. I want to use ipsec for ospf message protection - this is already a contentious topic. So, what is key mgmt reqts? Then decide if GDOI fits this model chicken & egg problem: OSPF first? GDOI first? Lakshminath: reqts driven by ospv3. we may not have expertise here. Need to figure out requirements. Not in charter. If it is found useful for routing, needs to be determined elsewhere. _______________________________________________________________ Mark Baugher: "GDOI Key Management Exchanges for the SRTP Data Security Protocol". draft-baugher-msec-gdoi-srtp-00 Mark Baugher Enable GDOI to establish keys for SRTP. What is SRTP: Useful for multicast SRTP sessions. SRTP: RTP rfc3550/rfc3551. RTP typically runs over UDP. Add information to payload: seq, timestamp, payload type with media, etc. RTP session is a bidirectional flow. SRTP adds confidentiality of the payload & integrity. Default is AES Counter mode. SRTP works off a single master key - input to SRTP KDF, output is authentication key & encryption key. There are 2 ways to hand off keys. Crypto context in GDOI is a traffic encryption key. What is GDOI: (3547) Protocol for requesting group keying material from a GCKS, an independent 3rd party. GDOI is a framework based on IKEv1. one system that manages all your keys was a great idea. * GDOI signaling of EKT o IV and ROC are used for providing more randomness, needs to be passed to the receiver o EKT may distribute the SRTP master key, GDOI will distribute the EKT key 2 new payloads defined: SRTP Encrypted Key Payload (EKP) Proposal: Complete GDOI-SRTP spec Add to Brian's GDOI ref code Add to Mcgrew's libSRTP? Lakshminath: why not use MIKEY? Mark: don't think so. Has MIKEY been doing group revocation? For groups that have capability to do revocation. Never thought of MIKEY as well suited for group keying in general. o Lakshminath: Interest?, Reviewer (Lakshminath, Russ) o Brian: applications seen, where this is seen as useful o More discussion on the list ______________________________ "Updates to GDOI" draft-ietf-msec-gdoi-update-01 Brian Weis This memo describes updates to the Group Domain of Interpretation (GDOI) [RFC3547]. It provides clarification where the original text is unclear. It also includes a discussion of algorithm agility within GDOI, and proposes several new algorithm attribute values. * Small change to address the mitigation attack from Meadows&Pavlovic if GCKS performs authentication based on IKEv1 * Attack mitigation * POP change: planned to include SKEYID_A as suggested by Meadows, but not clear if access is always possible, thus IKE-INIT-PH1-ID and IKE-RESP-PH1-ID is used ______________________________________________ Brian Minard: ECC algorithms for MIKEY Update to ECC algorithms to MIKEY 1. introduced DHSIGN with RSA 2. MIKEY-ECIES; tied use of symmetric ciphers to key sizes 3. editorial changes. *Discussion o Russ: ECDSA with SHA-1, there will be a future draft version addressing the SHA-1 usage o Steffen: ECDSA will be included in next version o Next version will be done till end of this year _________________________________________________ XTR Algorithm for MIKEY Draft-liang-msec-mikey-xtr-00.txt Jing Liang Hui Problem: RFC3830 use DH to establish the secure channel to xfer group secure key. Draft-ietf-msec-mikey-ecc-01 employs ECC for MIKEY Advantages of XTR: Efficient parameter & key selection Small key size with the same security level of RSA Speed better due to the computation quality of algorithm Without the need to share ..? XTR overview: XTR makes use of traces to represent and calculate powers of elements of a subgroup of a finite field. Trace(h) = h + h**p**2 + h**p**4 Performance: operation speed is faster & key selection is faster than ECC XTR-DH message Exchange: Initiator exchange with responder. By first compute trace of power a, and responder computes power of b. Both parties compute power to the g**(a*b) Mark: need 2 documents: one to define the algorithm. 2nd to define the algorithm inside of MIKEY or some other protocol. CFRG to bring new algorithms to IETF. Russ: if new algorithm, bring in Informational draft first. Is there a paper that will tell us more about XTR? Jing: will send the paper. Richard: security is not the problem here. Also there is a US patent on this - also an IETF issue. Security & efficient not the issue but patent & unfamiliarity are the issues. Gregory: is this the first time you've shown XTR? If this is new crypto, does this have applicability to other protocols: IKE, SSL, etc.? Richard: anywhere you see Elliptic curve, you can say XTR and don't have to generate a curve. ________________________________________________ Brian: "IPsec extensions" draft-ietf-msec-ipsec-extensions-04 Brian Weis mature draft - only editorial changes. 1.Not clear whether IPsec SAs for mcast are unidirectional. 2. Why in PAD section adding reqt that group policy could say to drop packets. 3. Apppendix a.2 seems to suggest that GKM can also setup unicast IPsec SAs? Tero comment: ikev2 NAT wasn't interpreted correctly.. This is in the middle of a large section that says NAT is a bad way Greg: will you specify one way for IKE and another IKEv2? Brian: not declaring how to do it - up to group management protocol. Greg: pick a flavor you like and specify that? Brian: no, this is in the middle of the security considerations. was meant to be an example. Gregory: sounds like it's suggested but not instructive. Waiting for more comments. Lakshminath: waiting for more comments Brian: wait a couple of weeks then we're ready for last call. _________________________________________________ "IPsec TESLA" draft-dondeti-msec-ipsec-tesla-01 Lakshminath Dondeti TESLA authentication fields * ID_i of K_i optional in contrast to SRTP TESLA, where it is mandatory Tesla-srtp? Makes it mandatory Cleanup & editorial work. Have notes on multisender & CTR mode: o Some nodes on CTR and multisender ' can go to MSEC IPSec extension draft? o Brian: doesn't know what to include ' combined mode? o Lakshminath will talk to Mark regarding ID_i * After that ready for WGLC ____________________________________________________ Using Counter Modes for ESP and AH to Protect Group Traffic" draft-weis-esp-group-counter-cipher-00 Brian Weis Recent class of algorithms. Defining class of algorithms with group traffic. There is a wrong way to do it; Current 4 RFC RFC 3686 RFC 4106 RFC 4309 RFC 4543 Counter mode - needs unique IV per packet. There are good uses to use counter mode Applying counter mode to group SAs: Currently unique IV restricts us to single sender. But many applications (like OSPF) use many to many and could benefit from counter mode. Proposed method: very simple Partition the IV field into 2 sub-fields. Sender identifier (SID). This value is unique.. SID Allocation: Who is allocating? GCKS of the group. For simplicity - the SID should be a sender attribute used with all group SAs. The GCKS can re-allocate a SID Effect of a shorter SSIV GM obligated to stop sending after its SSIV space is exhausted. A GM should not be left without a replacement key. Simple method: set SA lifetime Explicit GKM actions for avoiding an overused key: GM SHOULD notify the GCK in advance of its IV space being exhausted and require a new SA be distributed. Gregory: how big is the space? The question will be 5 years from now, will the sending rate be such that it will still work? Brian: .. Lakshminath: 32 bit key? Should this be a WG draft? Lakshminath: limited the charter for 1 to many. Brian: originally true but we opened it up. Lakshminath: there are probably many multiple sender issues we haven't thought about. Brian: personally don't think there are any issues. 1 to many was just the starting point. Lakshminath: will look at the charter & talk to Russ. Don't need to the CFRG route. o Re-chartering necessary to do this work o Acceptance necessary in the WG to do this work here o Vote in favor: 6 hands, nobody against ' some interest