Skip to main content

Definition of Master Key between PANA Client and Enforcement Point
draft-ohba-pana-pemk-04

Revision differences

Document history

Date Rev. By Action
2012-08-22
04 (System) post-migration administrative database adjustment to the No Objection position for Pasi Eronen
2010-01-12
04 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2010-01-11
04 (System) IANA Action state changed to No IC from In Progress
2010-01-11
04 (System) IANA Action state changed to In Progress
2010-01-11
04 Cindy Morgan IESG state changed to Approved-announcement sent
2010-01-11
04 Cindy Morgan IESG has approved the document
2010-01-11
04 Cindy Morgan Closed "Approve" ballot
2010-01-09
04 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Lt. Mundy.
2010-01-08
04 Jari Arkko State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Jari Arkko
2010-01-08
04 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen
2010-01-08
04 (System) Removed from agenda for telechat - 2010-01-07
2010-01-07
04 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-01-07
04 (System) New version available: draft-ohba-pana-pemk-04.txt
2010-01-07
04 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2010-01-07
04 Lisa Dusseault [Ballot Position Update] Position for Lisa Dusseault has been changed to Undefined from No Objection by Lisa Dusseault
2010-01-07
04 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2010-01-07
04 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2010-01-07
04 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2010-01-07
04 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2010-01-07
04 Dan Romascanu [Ballot comment]
I support the first part of Pasi's DISCUSS.
2010-01-07
04 Dan Romascanu [Ballot comment]
I support the fist part of Pasi's DISCUSS.
2010-01-07
04 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2010-01-07
04 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2010-01-07
04 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2010-01-06
04 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2010-01-05
04 Pasi Eronen
[Ballot discuss]
I have reviewed draft-ohba-pana-pemk-03, and have couple of
concerns/questions that I'd like to discuss before recommending
approval of the document:

- Using …
[Ballot discuss]
I have reviewed draft-ohba-pana-pemk-03, and have couple of
concerns/questions that I'd like to discuss before recommending
approval of the document:

- Using the address family numbers doesn't guarantee cryptographic
separation between different lower-layer protocols; for example,
802.11 and 802.16 use totally different security protocols, but share
the same address family number. And on top of the IPv4 address
family, you could run other things than IPsec.

However, an 802 address would still uniquely identify the EP, so I'm
not sure if this is a huge problem (and plain EAP without EAP channel
bindings doesn't provide even this much). But if the spec continues to use
address family numbers, at the very least the text about cryptographic
independence needs to be clarified.

- While the hash algorithm used for calculating PEMKname doesn't
really matter much security-wise, it's a bit strange to require MD5
here. Since RFC 5191 requires that all PANA implementations to
have the code for SHA-1, wouldn't that be a better choice?
(Either way, a normative reference for the algorithm is needed
here, too.)
2010-01-05
04 Pasi Eronen [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen
2010-01-05
04 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2010-01-04
04 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2010-01-03
04 Jari Arkko State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jari Arkko
2010-01-02
04 Ralph Droms
[Ballot comment]
Why is draft-ohba-pana-pemk an individual submission when it is a WG document according to the writeup:

Working Group Summary

  This is an …
[Ballot comment]
Why is draft-ohba-pana-pemk an individual submission when it is a WG document according to the writeup:

Working Group Summary

  This is an output of the PANA working group.
2010-01-02
04 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2010-01-02
04 Ralph Droms
[Ballot comment]
Why is draft-ohba-pana-pemk an individual submission when it is a WG document according to the writeup:

Working Group Summary

  This is an …
[Ballot comment]
Why is draft-ohba-pana-pemk an individual submission when it is a WG document according to the writeup:

Working Group Summary

  This is an output of the PANA working group.
2010-01-01
04 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2010-01-01
04 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-12-30
04 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov
2009-12-30
04 Alexey Melnikov
[Ballot comment]
2.1.  Key Name of PEMK

  The key name of the PEMK is defined as follows.

  PEMKname = MD5(EPID | SID | …
[Ballot comment]
2.1.  Key Name of PEMK

  The key name of the PEMK is defined as follows.

  PEMKname = MD5(EPID | SID | KID), where MD5 denotes Message-Digest
  algorithm 5 hash function.

This needs a Normative reference to RFC defining MD5.
2009-12-24
04 Amanda Baber IANA comments:

As described in the IANA Considerations section, we understand this
document to have NO IANA Actions.
2009-12-15
04 Jari Arkko Placed on agenda for telechat - 2010-01-07 by Jari Arkko
2009-12-09
04 Samuel Weiler Request for Last Call review by SECDIR is assigned to Lt. Mundy
2009-12-09
04 Samuel Weiler Request for Last Call review by SECDIR is assigned to Lt. Mundy
2009-12-04
04 Amy Vezza Last call sent
2009-12-04
04 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-12-04
04 Jari Arkko State Changes to Last Call Requested from AD Evaluation::External Party by Jari Arkko
2009-12-04
04 Jari Arkko Last Call was requested by Jari Arkko
2009-12-04
04 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2009-12-04
04 Jari Arkko Ballot has been issued by Jari Arkko
2009-12-04
04 Jari Arkko Created "Approve" ballot
2009-12-04
04 (System) Ballot writeup text was added
2009-12-04
04 (System) Last call text was added
2009-12-04
04 (System) Ballot approval text was added
2009-12-04
04 Jari Arkko Pasi says MSK usage is not the only approach, but is quite reasonable
2009-10-27
04 Jari Arkko State Changes to AD Evaluation::External Party from AD Evaluation by Jari Arkko
2009-10-27
04 Jari Arkko State Changes to AD Evaluation from Publication Requested by Jari Arkko
2009-10-27
04 Jari Arkko
AD review:

I have reviewed this document with the idea of taking this on as an AD sponsored submission for Proposed Standard. I only had …
AD review:

I have reviewed this document with the idea of taking this on as an AD sponsored submission for Proposed Standard. I only had one minor editorial issue with it:

>    o  EPID is the identifier of the EP.  The first two octets represents
>      the AddressType, which contains an Address Family defined in
>      [IANAADFAM].

Is there a better reference for this than the IANA web page? An RFC perhaps? If you find a better reference please issue a new draft version.

Also, there's a bigger potential issue around the EMSK vs. MSK usage that we have already discussed earlier this year. In my own analysis I think the draft is doing the right thing -- MSK is already delivered to the PANA agent and already derived in one way to secure PANA itself. I see no problem in using it for the second time to derive a related key. However, I have asked the security ADs for advice on this issue, and maybe I'll be surprised on what they say. Stay tuned.
2009-10-27
04 Jari Arkko Draft Added by Jari Arkko in state Publication Requested
2009-09-09
03 (System) New version available: draft-ohba-pana-pemk-03.txt
2009-04-27
04 (System) Document has expired
2008-10-24
02 (System) New version available: draft-ohba-pana-pemk-02.txt
2007-11-18
01 (System) New version available: draft-ohba-pana-pemk-01.txt
2007-11-12
00 (System) New version available: draft-ohba-pana-pemk-00.txt