IETF 76 - Hiroshima - Monday, November 9th - MSEC minutes
https://datatracker.ietf.org/meeting/76/materials.html
=========================================================

(Audio for the session is available here.)

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: (Rolf): In that case an entity that didn't answer the call would be able to
  generate the session key.
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)
(Also in 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.