IETF 76 - Hiroshima - Monday, November 9th - MSEC minutes https://datatracker.ietf.org/meeting/76/materials.html ========================================================= Introduction (Brian) ==================== Active Drafts: –  draft-ietf-msec-tesla-for-alc-norm-07      Status: Approved for publication –  draft-ietf-msec-ipsec-group-counter-modes-02      Status: Completed WG Last Call, Ready for Next Step              (Need a document shepherd) –  draft-ietf-msec-gdoi-update-04    Status: Work in Progress             (Document re-structuring might be necessary) Related Drafts: –  draft-seokung-msec-mikey-seed    Status: IESG Review, one outstanding DISCUSS Milestones: Dec 2009  IETF Last Call on Using Counter Modes with ESP and AH Feb 2010  WG Last Call on Updates to the Group Domain of  Interpretation (GDOI) Mar 2010  WG re-charter for other work items or disband 1/ MIKEY-TICKET (draft-mattsson-mikey-ticket-00) - Rolf Blum http://www.ietf.org/proceedings/09nov/slides/msec-1.pdf ============================================================ This draft originates in the IMS media plane security (3GPP) for users requiring high security, who need for instance a central policy control, a GKM, secure forking, pre-distribution of keys, deferred delivery, etc. The solution is a ticket based key management that makes the key unique to each Responder (R) who presents the ticket he received from the Initiator (I). This proposal extends MIKEY with a set of new modes that use a trusted KMS and a ticket concept. Three modes of operation are considered: - full 3 roundtrips (basic mode), - kerberos like (not considered in this I-D), - Otway-Rees like (simplified mode where I generates the ticket). Key features: - trust is anchored in the KMS, which is potentially independent of the   operator, - policy enforcement by the KMS, - possibility of groups of recipients which makes group key management   simple, - secure forking, - possibility of pre-distributed tickets. The specs are currently being finalized in the context of 3GPP TS 33.328. The idea is to have MIKEY-Ticket based key management used for high security applications, while SDES based key management is used for other applications. Many comments... Q: The ticket must include the session key. How could it possibly be   pre-distributed? R: The initiator can request a lot of tickets for future use. It stores   them and uses them later. Q: What about PKI? Do all the participants have PubK/PrivK? R: The key requirement is to have a policy control at KMS. Q (Simon M.): With any of the schemes, if the responder and initiators   are located in different networks, what about possible timeouts? How   can it be responsive? R: The KMS should be always available, like many authentication systems.   Otherwise it won't work. In any case, it's not specific to this solution. Brian: Can the responder and initiator be located in different networks? R: When two users belong to diff KMS, the two KMS must have a trusted   relationship. Comment: The KMS must dialog in real-time, which is challenging. Comment: The KMS does not necessarily belong to the operator, it can   be independent. Comment: The KMS knows the keys for all the sessions. Q: Why does the responder need to go to KMS after receiving a ticket? R: It's common in IMS.   You don't want all devices to have the keys. The key is per-device. Q: What's the difference between this and Kerberos? R: Each call has to end up in a set of devices. It's like the secretary of   a boss. The secretary is not supposed to give the answer. Q: Can an interceptor use a ticket? R: No, the key(s) that a ticket carries are confidentiality protected and available only to a legitimate user of a ticket. 2/ MIKEY-IBAKE (Violeta Cakulev) http://www.ietf.org/proceedings/09nov/slides/msec-4.pdf ======================================================= MIKEY has already been updated by RFC 4650 (HMAC authenticated Diffie-Hellmann) and RFC 4738 (another mode for key distribution). However a mode is still missing that would: - enable a mutual authentication of parties, - make all parties contribute to session key generation, - provide forward and backward secrecy,... all of this being based on asynchronous cryptography without the need of a PKI. The proposed solution is MIKEY-IBAKE, an Identity Based Authentication Key Agreement. Identity based systems are a new step in public key cryptography (see in particular RFC 5091, "Identity-Based Cryptography Standard #1"). The proposed framework is the following: each entity has a PubK/PrivK, where the public key is identity based, and the private key is issued by a trusted KMS. Participants obtain their private key from the KMS offline, e.g. periodically. We also assume that the SA between the KMS and participant is pre-provisioned. The encryption/decryption of messages during key exchanges are then based on Identity Based Encryption (IBE). This framework enables both the Initiator and Responder to generate the same session key (the goal). This scheme supports: - forking: delivery of a request to multiple endpoints - retargeting: request sent to one endpoint but delivered to a   different endpoint - deferred delivery: if the session content cannot be delivered to   the destination at the time that it is being sent, it can be   stored encrypted, and only the intended Responder will be able   to decrypt it. MIKEY-IBAKE enables group communication extensions: - define a group key that is not known to the conference server; - issue a new group key whenever a new participant arrives; - issue a new group key whenever a participant exits; Q (Rolf): you have to share your private key to all the devices you   may want to communicate with? R: Not in the forking scenario. Q: XXXX R: An entity can have different PrivK/PubK corresponding to different   identities. MIKEY Future Directions discussion (Brian Weis) http://www.ietf.org/proceedings/09nov/slides/msec-2.pdf ======================================================= Brian summarizes the situation WRT MIKEY (see the slides), in particular the fact MIKEY isn't the key management protocol of choice for the IETF, the fact there's a significant number of modes without clear guidance on which one to use, which compromises interoperability. Hence the question... Q (Brian): Does it make sens for MSEC to continue to publish MIKEY I-D? Tim P.: This group decides what it thinks is appropriate to MIKEY in   the future. There are several options open. You need to vote. I   don't want to be a gatekeeper who decides whether or not a document   should be considered. Brian: Who wants to review MIKEY documents? (no answer). Okay, this   answers the question. Tim P.: Clearly there's no consensus to continue work on MIKEY in the   room. It needs to be confirmed on the list, but it seems rather clear. Tim offered to take the sponsor the two presented MIKEY drafts as individual submissions to the RFC Editor so that they can be allocated space in the MIKEY assigned number spaces. Overview of IEEE 802.1X-REV Dynamic Session Key Agreement & its Applicability to Link-Local Routing Protocols (Brian) http://www.ietf.org/proceedings/09nov/slides/msec-5.pdf =========================================================== Brian introduces "MACSec Key Agreement" (MKA), where MACSec refers to "IEEE 802.1AE-2006", a specification that provides encryption and packet authentication to IEEE 802.1 frames. MKA enables a subset of the stations connected to the same 802.1 link to define a Connectivity Association (CA) between themselves, and all the security mechanisms associated. More precisely, MKA: - Allows a group of link-local peers to establish that they form a group; - Provides replay protection between peers in the group; - "Elects" a key server, which distributes common keying material between  the link-local peers; - Key server role is not fixed, which provides for redundancy and  reliability; (See the slides for details.) Application of MKA concepts to link local routing protocols (Russ White) http://www.ietf.org/proceedings/09nov/slides/msec-5.pdf ======================================================================== This presentation is a follow-up of the previous one... The security of link local routing protocols (e.g. OSPF) could largely be improved by adding dynamic, automatic re-keying as well as replay protection. It turns out that the key agreement requirements for link-local MACsec are similar to the key agreement requirements of link-local routing protocols. So it's perhaps possible to take advantage of the concepts in MKA ... The routing protocols considered here are primarily OSPF, RIP, PIM, and to a certain level IS-IS (only for Hello). There are of course two implementation choices if we want to apply MKA: integrated into the routing protocol, or protocol independent. Russ: - does it make sense from a group security perspective? - is this something MSEC want to formalize? (No answer) => Go to the list.