[Emu] Draft meeting minutes for IETF 71

Draft meeting minutes for IETF-71 are available below and at
http://www.ietf.org/proceedings/08mar/minutes/emu.txt.  Thanks to
Dorothy and Charles who took excellent notes.  Let me know if there are
any additions or corrections. 

Thanks,

Joe

EMU
IETF-71 - Philadelphia
Thursday, March 13, 2008 0900-1130
----------------------------
Chair: Joe Salowey
Note Takers: Charles Clancy, Dorothy Stanley
----------------------------

Document Status (Joe Salowey)
-----------------------------

+ RFC2716bis (EAP-TLS) is in Auth 48
+ EAP-GPSK is in AD-review, new revision is needed 

Charter Update
-----------------------------

+ General Text 

Joe: Text Should be updated to reflect current status of method
publication. Propose to accept and revise. When the original charter was
written, there weren't many published EAP methods. Now there are. Need
to update the text. 

Joe: does anyone object to modifying the text to reflect current status?

Group: No objection

+ Tunnel Method

Joe: became a potential work item due to desire to support legacy
databases. Needs to work when clear text password or a derivation
thereof is not available on the server side. Could look at other
password methods separately. 

Sam Hartman: if had a proof of concept, could do legacy methods without
a password. Design team method used a TLS handshake, didn't support
tunneling an arbitrary method. If going to use "tunneled" in that
manner, need to clarify this in the charter. Need terminology that means
"tunnel other EAP methods" so that we are clear. 

Joe: Bernard had raised question on the list regarding need to avoid
fruitless arguments. Acceptable outcome to update one or more existing
methods if they meet the requirements.
Bernard Aboba: Don't have to pick just one. If group can't come to
consensus to one method, what do you do? Work on none? On more than one?
Seems more reasonable to work on more than one, where there is interest.
Steve Hanna: Better to agree on one than on "n". Reluctant to have
charter assume we can't agree on one. Have charter be silent on the
number. Having 2 or 3 is not a desirable outcome.
Joe: First thing to do is to come up with requirements on the tunnel
method to support passwords, channel bindings and multiple EAP method.
After we have the requirements, then move forward to look at number of
methods to meet. Concern, have not had a lot of volunteers to contribute
text for requirements.
Steve Hanna: volunteers to contribute text for requirements. 
Joe: Thank you. For charter revision for a tunnel method, proposal is to
not state the number of methods. Work through requirements, and then
work on meeting those requirements. Legacy password, legacy EAP methods
and channel bindings.
Steve: Don't object, discuss the question - what happens if two methods
come forward?
Bernard: Merger is the worst possible option. Likely to be a garbage
outcome, worst of both. 
Tim Polk - As an AD - don't like to see groups provide multiple
competing protocols. Hope that "n" is a really small number. Don't have
the charter bind you in a corner. But multiple solutions not viable
either. See what the candidates are, and their strengths.
Sam: Agree, words of wisdom.
Joe: Take this to the list, good direction

Hao Zhou: Can you show the current proposed charter revision?  See
current text?
Dan Harkins: Obliquely talking about N methods, really only 2.  Prefer a
cage match.  Merger would be bad.
Glen: Tend to agree with Dan. This would take care of the editor and
contributors needed. 
Pasi Eronen (as AD): Share Glen's concern.  If you're willing to work on
this, say so.
Dan: massive deployed base for each method. We won't be changing the
methods. Vendors won't want to change deployed base.
Steve: We have identified requirements that neither of the current
methods meet. There will be some minor changes or revisions to the
current method. Steve Hanna again volunteers to work on requirements.
Hao: Crypto agility, channel binding, internationalization all
necessary, so we need a requirements document.  Willing to contribute.
Joe: Requirements document is a good thing to do.
Pasi: Have requirements that alternatives don't meet.  Supports
documenting requirements.  Don't spend too much time on it. Short and
done quickly.
Glen: Not sure a full requirements document is not a waste of time.  Put
as a section of the protocol document itself. We've already identified
the requirements.
Pasi: Don't need to publish document as an RFC as long as it completes a
WGLC.
Tim: In PKIX set back 1-2 years by developing a requirements document.
What is important is to document the requirements - need agreement, when
there are multiple candidates, or won't move forward.
Hao: Agrees.
Glen: This changes the tunnel method item on the power-point. Don't need
editors and contributor. Joe can send a list of requirements to the
list. Get comments reviewers on the list. Finish in 2-3 weeks. Then
those in un-named companies can busily work on modifying their
proposals. The have knife fight to determine solution.
Hao: Do we really want a knife fight? Have a deployed base, some don't
want to upgrade.
Tim: Initial goal is to make a decision and pick one, but that doesn't
always happen.
Gene Chang: Interested in consensus and requirements document.
Joe: Light-weight requirements, sent to list for review, goal is to
select a single protocol.

+ Secure Password Only Method

Joe: Secure password only method. Access to clear-text or some
consistent form of password available. No other credentials necessary.
Ask for presentation from Dan Harkins on motivation for the method. This
is another set of requirements.

(Dan Harkins Presents on draft-harkins-emu-eap-pwd-01.txt.)

Sam: Does not work with legacy password databases, and is therefore out
of scope for the charter.  Everyone is probably interested in it if it's
IPR-free.
Bernard: IPR concerns are about to expire in the next few years.
Dan: 2010 is the EKE patent, but doesn't think it applies. SPEKE and
Certicom patents are of concern.  Belief is that if you use ECC with
prime field you can avoid IPR.  Minefield but *possibly* navigable.
Pasi: Believe not in current charter, can be added in the charter
revision, subject to usual conditions - volunteers to contribute, edit,
review. 
Dan: WRT charter - current charter doesn't mention tunneled method. 
Pasi: Legacy password methods don't work with this method.
Dan: This consensus was confirmed on the list in the fall. Not something
that is new. 
Glen: The thing about the fall - that was the previous charter. 
Joe: Work on password method for legacy data bases, agreed on modifying
the charter to add a tunneled method. Look at adding a new separate item
to the charter.
Dan: This method is useful and not yet another password based method. It
doesn't require use of certificates.
Pasi:  Show of hands?
Tim: (Jumps the queue) This is the IPR space that killed other working
groups. Worried that this is a heavily encumbered space. Other groups
have failed at this point. If mentioned in the SPEKE patent, nervous.
Happy to see work continue on the draft. Prefer not to add to the
charter at this point. But I'm not your AD. Mines are close together
here.
David McGrew: "Authentication with short authentication strings" are
similar class of protocols, but avoid IPR claims.
Steve: metaphor of a minefield is a good one. There may be submarine
patents here too. Just looking at published claims not enough. Support
moving forward, will fully support if not encumbered. 
Sam: If not standards track, shouldn't be in the charter. If
informational, then don't need to spend our time on. Two issues need
more info on - security analysis, is this method secure. Second - IPR.
Talk to Phoenix, will they say this is not covered? Implementers to look
at this, and they don't believe that patent licenses - commercial
implementers, rather than open source. If either of these happened, then
would feel comfortable with.
Dan: On the security front - sent to some reviewers, "looks good", need
a formal proof. Will still work on this.
Charles: Prof Katz's work from UMD.
Sam: If EKE patent is expiring, we should start looking at an EAP method
that does EKE now. This might be a good approach.
Glen: Since EKE is ready to expire, why bother with this? 
Sam: Because this approach is better, if it is secure.
Bernard: Suggest taking this to the SAAG, since it doesn't affect just
us.
Dan: Deterministic process would be good.  Could be submarine patent,
security proof difficult.  Wants an outline of steps to reach goal.
Joe: IPR steps are fairly well laid out.  Security review needs a broad
set of eyes.
Pasi (as AD): This is a new topic -- tackle other work items first
before taking on new work.
Tim: This is a standards process, not a deterministic one. If WG is
evolving, there is no reason to not revise the charter as long as
progress in being made in the group. There is a lot of interest in this
type of method, need to build consensus that IPR space is sufficiently
unencumbered. Or maybe WG will decide that even if it is IPR encumbered,
that it is so compelling that it should go forward. 
Dan: Doing charter revision now, so add it now.
Yaron Sheffer - Believe there is significant value in this work. Do an
IPR analysis on paper rather than relying on open source developers to
prove that it is unencumbered.
Pasi: Individuals may have opinions on IPR, but not working groups.
Dan: Will initiate a process on IPR; lawyers get involved because people
disagree.
Yoshihiro Obha: Start from experimental, and then consider standards
track.
Pasi: Wouldn't expect IESG to actively block it as long as there is a
reasonable security evaluation.

+ Channel Bindings

(Presentation by Katrin Hoeper)

Clint Chaplin (Clint): Thanks for working on this, and encourage this
work to continue. No good definition to date.
Sam(individual): Have a reference to 5056, that uses the "channel
binding" term in a different way. Bind different layers of a session;
prevent a man-in-the-middle attack. Include this in the document that
you are writing.
Bernard: Echo Clint's comments. Note that in an implementation, there
are impacts to the drivers to pass up specific data - from driver to the
method. 
Joe: What are the important parameters - need to define.
Dan: Agree that this work should go forward. Concern with viral nature
of EAP, and EAP being used to solve every problem. Authentication
requires identifying the entity that is being authenticated.
Pasi(AD): draft aarko-eap-service-identity-auth defines "channel
binding" but with a different name. 
Katrin: First need to agree that this is a working group item.
Joe: Is there interest in working on a channel binding draft? Then,
provide specific recommendations. May be one or 2 drafts. 

Joe: Should the group take on this work (raise hands?) 
Hands raised - yes. 
Joe: Asked for text contributors - 3-4 people. (Charles, Katrin,
Bernard)
Joe: Asked for reviewers - many hands. 

Tunnel Method Requirements
-----------------------------

Joe: Next discussion item, tunnel method requirements. Steve and Hao
have volunteered to be contributors. This is a little light. 
Joe: How many people are willing to review? About 5 hands are raised.  
Joe: How many people have reviewed a draft list of requirements? 3
people.
Hao: May be useful to separate the generic EAP requirements from the
tunnel method requirements. 
Steve: Good start on the list. Need to contribute a description of each
list item.
Joe: To move forward, get contributors together in the next week to
prepare a canonical list to publish to the list.
Joe: Any other comments on requirements? None

Channel Binding Drafts
---------------------------

(Charles Clancy presents)

Charles: See slides. Two phases, Information exchange and consistency
check.
Bernard: More than a consistency check. Peer has to verify correctness.
Glen:  What is the info that is being sent? 
Charles: Depends on the type of the network. 802.11 - SSID, contractual
billing information
Glen: What are the endpoints of the channel?
Charles: Trying to bind the info from the authenticator to the channel. 
Glen: In service provider network?
Charles: Related to the billing agreement.
Glen: Not related to the authenticator. 
CHarles: Home auth server can validate the rates from the roaming
partner.
Glen The data from the authenticator isn't being bound in this case.
Charles: Binding info from the network, not the authenticator.
Glen: Info about the network to which you are connecting. Previous
understanding was that what was bound was related to a single
authenticator.
Charles: Isn't relevant in this case. 
Joe: Look at this as authorization in addition to authentication.
Glen: The peer in a roaming situation is connected to a roaming partner.
What does this do for me in addition? If only one roaming partner - then
it's real or not, then get key from authenticator.
Charles: Roaming partner is advertising as a home network. You will be
charged roaming rates rather than home rates.
Glen: Sounds like something you fix with lawyers rather than a protocol.
Charles: Allows detection of these contract breaches. 
Glen: Send back - all ok
Charles: Happening in the connection to the home server, roaming network
can't spoof this.
Hao: Which EAP methods? How do you know what information to send?
Charles: Solution in document works for GPSK, PSK, PAX, TTLS, FAST
Charles: Client sends as much info as it has, server sorts out what it
needs.
Katrin: In response to Glen's comments - prove that it is important to
have a definition of channel bindings.
Glen: This redefines channel bindings as I understand it. This doesn't
solve the lying NAS problem. 
Charles: Solve lying NAS for enterprise, but not for service provider
roaming Trying to solve practical problems.
Commenter: Is useful to have definition of channel binding. What is
driving us to work on channel binding - are there requirements from the
real world other than our own comments on each others' documents.
Pasi: Have seen comments asking for binding to determine the type of
lower layer network being used by a network. 
Yoshi: If don't know the layer network, then can't solve the channel
binding problem.
Charles: There is a computational problem in the roaming environment,
can't know all the lower info at the authentication server. Send all
info we have. 
Commenter: That aspect is consistent with GPSK - include a container for
a set of information element.
Charles: Need to standardize to use with arbitrary peer and server.
Commenter: IKEv2 tried to talk to everyone. But in EAP, need to indicate
the required fields.
Joe: Want to reference fields that are understandable.
Commenter: Won't know all the MAC addresses.
Joe: Need an extensible framework.
Charles: We are defining an extensible framework that items can be added
to.
Commenter: Need to understand why the GPSK solution isn't sufficient.
Bernard: There is a threat model issue here. May have a lying service
provider. No way to detect that service provider and local one are both
lying.
Sam: Have more comments, get through rest of slides first.
Charles: Reviews design choices (see slide) Easy add-on to existing
methods.
Hao: Don't agree that no modification is needed, adding more messages.
Charles: Method itself is extensible.
Hao: Limiting applicable to only methods that are extensible.
Charles: Agree
Hao: Could also run in a tunnel.
Charles: Binding Information slide - exact parameters to bind are open
to discussion.
Charles: Trust model slide description.
Charles: EAP Method Requirements slide description.
Hao: Why do you need info1 and info2?
Charles: Took assumption that there are cases when the AS would provide
more info to the peer than the peer sent to it. If we find out that it
isn't needed, can be deleted.
Hao: Then not doing channel binding, it is a different problem. Need to
call it something else.
Charles: Future work slide description.
Glen: I think I understand now. Can you enumerate the EAP methods that
this works with?
Charles: EAP method must carry integrity protected blobs.
Glen: Not a tunneled method.
Charles: Correct. Can include in GPSK for example.
Dan: Trust model assumes that the peer is honest. All of info that is
bound is up to the peer. Make sure that identities are consistent. 
Charles: If every layer runs a method that supports bindings. Haven't
though about how you validate every level.
Sam: One part of the trust model, what are the implications of the peer
being untrustworthy. View most peers as untrustworthy. Make this
explicit in the document. What are the implications of a peer that
falsifies info to the server. 
Charles: Thinking of a DOS attack to shut down the NAS.
Katrin: That is not the EAP-FAST model -a ssume that the peer is
trustworthy. Channel binding solves only one problem, not the lying
peer.
Charles: Need to address this in security considerations section.
Sam: Assuming an honest peer isn't realistic. 
Charles: Summary - this is an -00 document, solicit input on the
direction to take. 

Joe: That is it for the agenda. Has everyone signed the blue sheets?
Joe: The session is adjourned (11:25am). 
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu