-------------------
			 HOKEY Working Group
			   Meeting Minutes
			     29 July 2008
			       IETF 72
			 -------------------

Administrivia

 - No changes to agenda

 - Document status overview

Key management document (see presentation)

 - Peer consent issue (fraud possibility)

 - Yoshi vs Dekok on fraud issues

Key management discussion

 - Yoshi: question about proxy list

 - Tim: list is informal list for people who are interested in
        discussing issues surrounding security and proxies.  Informal
        and ad-hoc.  Specifically created so that other groups like
        hokey can make progress, and don't get rat-holed into side
        issues.  People shouldn't wait to solve those problems before
        making progress in other working groups

 - Glen: IRTF?

 - Tim: Document is planned.  If Katerin was in Dublin, she could have
        finished it.  It wasn't clear if it would be a formal effort.
        It's not clear where it should go or how quickly it should
        happen.  IRTF might be the right home.  Or, we may have a
        document by next spring.

 - Glen: fair number of people have been aware for years, but it seems
         to have snuck up on other people.

 - Tim: Document is envisioned to be ensure that this problem doesn't
        sneak up on other people.  Question is where would solution
        work happen.  State of the art needs to be documented so that
        people can read an RFC and see.  Solution space work in IRTF
        may be good.  Problem statement comes from where-ever...

 - Glen: mention of ERX bootstrap that would solve all of these
         problems.  Problem would not arise if we required a full EAP
         authentication if we moved between domains.  We had agreed to
         do that a while ago.

 - Charles: need authentication record to go with accounting record.
            List discussion is consistent with room discussion at last
            IETF.  Consensus is still valid.  Proposition to move
            forward with consensus as derived at last IETF meeting.

 - Yoshi: submitted paper related to this work.  Peer consent is
          important part of that paper.  Security considerations
          section of this document should be carefully written with
          warnings about lack of peer consent.

 - Tim: lot of blood spilled in coming to consensus so far.  Focus has
        been getting ERX and EMSK hierarchy through IESG process.
        Important thing is to implement consensus positions, and get
        document complete as representing WG positions so far.  Unless
        something has changed, we should move forward with document.

 - Charles: Encourage Yoshi && authors of
            draft-goankar-radext-erp-attrs to put together text that
            represents consensus.  Should be lot of WG list discussion
            on security consideration contents, security
            considerations for transport, impact on overall AAA

 - Tim: when do authors think that they could produce a draft to
        further discussion?

 - Yoshi: another document related to DIME to carry ERX keys that is a
          big document.  More discussion may be needed there.

 - Glen: why is it necessary to have two different documents for
         RADIUS and Diameter?

 - Vidya: Trying to re-use Diameter EAP attributes, and trying to
          specify small changes above that.  Approach for Diameter is
          slightly different than what's needed for RADIUS.  RADEXT is
          really slow... would rather see DIME document move forward
          so that interoperable implementations.  RADIUS VSA's are the
          only realistic solution in the next 3 years.

 - Glen: No... quickest way to get things done is to define standard
         RADIUS attributes, which can be carried in Diameter.  DIME
         isn't too much faster.  If we need to do it quickly, do it
         here, and request review by AAA-doctors.

 - ???: I agree... like anything RADEXT, it has to happen outside
        RADEXT, and then go into RADEXT for review

 - Bernard: So long as work in HOKEY is focussed in HOKEY, it's fine
            to do here.  You can do whatever you want.

 - Glen: No reason why we can't use stuff being developed in RADEXT
         without conflicting.

 - ???: Normative dependencies?  None..

 - Bernard: Any crypto-agility mechanisms defined to wrap anything.
   Can say it MUST be protected by something, and cite various ways.
   No normative dependencies.  Just reference other methods as MUST.

 - Charles: When can document be updated?

 - Yoshi: Not sure.

 - Tim: Please send rough time frame when authors have discussed.

 - Yoshi: September?

 - Lakshminath: changes easy, 30 minutes

 - Tim: Good to see 2 document cycles before next IETF.  Challenge to
        authors to do it quickly.