1 / 7

MIKEY discussion

The status of the MIKEY work was discussed during IETF-64 in Vancouver on November 8, 2005. Key topics included the introduction of additional modes such as DH-HMAC, RSA-R, and ECC, alongside proposed variants within the DH mode. The meeting addressed usability, operational efficiency, and the complexities arising from multiple modes and interop issues. A roadmap document for integrating these new features and addressing the outlined problems was suggested. There's an emphasis on updating RFC 3830 to streamline MIKEY usage while balancing backward compatibility with innovative enhancements ahead of IESG submission in June 2006.

arav
Download Presentation

MIKEY discussion

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MIKEY discussion Lakshminath Dondeti, ldondeti@qualcomm.com MSEC meeting IETF-64, Vancover, Nov 8, 2005

  2. Status of MIKEY work • 3830 • Addl modes: • DH-HMAC in RFC Ed queue • RSA-R • ECC • Others proposed at the meeting today • Variant of DH mode • Additional capabilities • General extension work describing “rekeying” the group key • Delivery of multiple keys via a single run of MIKEY • What’s the motivation for all this work? • Usability/operational issues, efficiency issues

  3. How do we deal with this? • So, what are we talking about • Multiple modes • Multiple documents describing these modes • New features and more in the pipeline • And we talked about this problem • Possible solutions include • Writing a roadmap document • The IETF is discussing this issue as well; so follow whatever they come up with • Do nothing: this contributes to job security for all of us

  4. Let’s look at the problem in detail RFC 3830 MUST MIKEY-RSA MAY GenExt MIKEY-DH MUST MIKEY-PSK Multiple Key download DHHMAC RSA-R MQV ECC Another DH mode

  5. So what? • The multiple modes will result in interop issues • How do end points negotiate what mode to use? • The various extensions are disjoint and make MIKEY look like a patchwork

  6. What might we do? • Perhaps it is time to revise 3830 to clear up some of this • Make as few changes as possible to the base protocol, but we are talking about some retrofitting of new concepts and topics. Specifically, • Normative • RSA-R related extensions • Sending multiple TGKs • GenExt-newtype-keyid stuff • Informational text on mode usage

  7. Questions on impact on implementations • We realize that there are implementations of MIKEY out there • Questions • How disruptive vs. useful is this type of exercise? • This is still early in the lifetime of MIKEY as opposed to doing this much later • The plan is to send the revised version to the IESG in Jun 2006.

More Related