Handover Keying (hokey) Working Group, March 25, 2009 10:30 AM-11:30 AM

Notes: Dorothy Stanley

 

 

Chair (Glen Zorn) called the meeting to order at 10:40am.

 

  1. Obtained volunteers for note takers and a jabber scribe.
  2. Review of agenda, no changes identified
    1. 10:40 - 10:50 AM Status of Key Management Draft, Katrin Hoeper (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-hokey-key-mgm-05.txt
    2. 10:50 - 11:15 AM Status of Draft Pre-auth Problem Statement, Qin Wu and Y. Ohba (25 minutes)
    3. 11:15 - 11:25 AM Future Hokey Protocol Application Scenarios, Behcet Sarikaya (10 minutes)
    4. Summary & Wrap-up (5 minutes)
  3. Presentation by Katrin Hoeper on Derivation, delivery and management of EAP keys
    1. Review of document status; has been around for a while, with dependencies on other documents.
    2. Review of main changes from -04 to -05

                                                               i.      Introduced new terminology, removed ambiguous “third party”. New terminology is Key Delivering Server, Key Requesting Server.

                                                              ii.      Removed peer from Key Distribution Exchange mechanism

                                                            iii.      Emphasized KDE usage in ERP

    1. Ask for folks to review the current draft; is the current title still reflective of the content of the draft? Chair: can change any content at any time.
    2. Comment: Believe document is ready for last call. Need to delete references to “USCRP”, title should be updated.
    3. Comment: Agree that the doc is ready for last call.
    4. Chair: not hearing objections to changing the title of the draft. Chair will then issue a last call next week.
  1. Presentation on the Draft Pre-Auth problem statement document, see http://www.ietf.org/internet-drafts/draft-ietf-hokey-preauth-ps-06.txt byYoshihiro Ohba.
    1. Review of high level changes made in the most recent version, includes editorial changes. Also reorganized the usage scenarios section 4 into the usage models section.

                                                               i.      Review of draft description of usage models for pre-authentication: Peer – SA- AAA- CA, and why the model is necessary.

                                                              ii.      Comment: The new model doesn’t fit model in RFC 5247. There are 3 SDOs that use the 5247 model. Intra vs. Inter domain issues.

                                                            iii.      Chair: Need to clarify that there are 3 standards organizations – following his interpretation of the RFC

                                                            iv.      Comment: Gave up following the discussion on the list after 60 e-mails. Need to decide if we really need a new model in this WG. If no existing relationship, then need a new entity. All models have their place, not sure they belong in the problem statement draft. Statement should cover many scenarios. Need to agree that they are necessary.

                                                             v.      Comment: Question on trust relationship between the entities. Talking about handover; implicit that there is some trust relationship between networks.

                                                            vi.      Response: Trust relationship is between two entities, not two networks.

                                                          vii.      Comment: Establishing trust relationship with the same AAA.

                                                         viii.      Response: AAA in home domain, other is visited network.

                                                            ix.      Chair: This model uses existing trust relationships. Originally, had direct trust relationship between the authenticators. Now considering indirect trust relationships.

                                                             x.      Comment: Use cases need the flexibility.

                                                            xi.      Comment: The problem statement vs. protocol development is to take a general look at requirements, and then identify the specific requirements needed. If have different approaches that follow the same signaling interface, need to refine.

    1. Chair: Would like to make progress

                                                               i.      Asked those who subscribe to the list to stand.

                                                              ii.      Asked those who will back their opinions on the list to remain standing.(8 people remain standing)

                                                            iii.      Have 3 choices: Are you interested in continuing the pre-authentication work? – strong hum.

                                                            iv.      Don’t continue working on this  - no hum

                                                             v.      If in favor of adding the new model as it is in the draft now – strong hum

                                                            vi.      Those against – weak hum.

                                                          vii.      Third choice would be to have separate documents, don’t get to this choice.

                                                         viii.      Have jabber input – 2 folks opposing.

                                                            ix.      Should the candidate scenario be supported at all? In one document or in a second document?

                                                             x.      Can rename the draft appropriately.

                                                            xi.      AD: Would folks support it if the scenario had a different name? Response in the room: yes. Can invent new words if we have to. Fix the terminology and move forward. Ask editors to fix the terminology. Jabber: calling it “early” authentication is confusing. Hum support for fixing the terminology.

                                                          xii.      Comment: Fixing the terminology may take four months.

                                                         xiii.      AD: At least have agreed that the functionality should remain – the scope issue, which is the important one. Task authors/editor to propose terminology solution. If no agreement, Chair to form a design team to select terms, and then ship it.

 

  1. Meeting adjourned at 11:30. Remaining presentation related to re-chartering will be addressed next time.