Below are the draft minutes for the IETF-70 EMU meeting. Thanks to
Nancy, Steve and Sue for taking notes. Please let me know if you have
any corrections.
------------------------------------------------------------------------
----------------
EMU Minutes
==========================
TUESDAY, December 4, 2007
0900-1130 Morning Session I
Cypress
==========================
Chair: Joe Salowey
Note Takers: Nancy Cam-Winget, Steve Hanna, Susan Thomson
===========================
+ Draft updates
- EAP-TLS (RFC2716bis) sent to the IESG
- EAP-GPSK editorial fixes and comment resolution for EAP-GSK based on
feedback from some researches ready for IESG
Sam Harman: mentioned that he will prioritize to forward the EAP-TLS
draft and when ready, the EAP-GSK drafts.
-----------------------------
+ Charter update
* Add a charter item for a standard tunnel method
* Modify the password-based item to use the tunnel method
* Modify the enhanced TLS item to focus on adding channel binding to a
TLS-based method (EAP-TLS or a tunnel method)
* Update the milestones to include requirements draft
+ method name
Joe Salowey: need to choose a consistent term: tunneled method,
tunneling method, tunnel method. Propose "tunnel method"
Steve Hanna: prefers "tunnel method".
+ RFC compliance requirements
Hao Zhou: do we have an exact definition of "enhanced TLS mechanism" and
what the enhancements are?
Joe: no, that is something we'll need to define and clarify.
Hao: when we say "additional authentication methods" are we talking
about channel binding, or other things?
Joe: channel binding is a requirement but the others, not sure that they
will need to be explicitly called out in the charter.
Bernard Aboba: clarifies that the bindings are optional based on RFC
3748.
Sam: speaking as an individual, I don't see how we would meet the
requirements of RFC 4962 without imposing channel bindings. It would be
useless if we adopted something that didn't meet those requirements.
Comment: RFC 4962 is currently not in the charter
Sam: is EAP keying listed in the charter?
Comment: given that it's still a draft, don't see how it could be
included. Also not referenced in the current charter (EAP keying)
Sam: if we're not bound by RFC 4962, then channel bindings are optional.
But then this can jeopardize the efforts of Hokey as there's no way to
ensure a method that can work with the work coming out of Hokey.
Joe: there no mention of these items in the emu-charter, not sure if
this was an oversight or intentional.
Steve: raised that the charter doesn't call out requirements such as the
keying framework....since other requirements list out the RFC's to
reference other documents to extract requirements should we do the same
for tunnels?
Steve: perhaps we can just clarify generally "all mechanisms defined by
EMU should meet the following requirements"....if there are other RFC's
then we can just add it to one list.
Update can read "All mechanisms standardized by this group must meet RFC
3748 and RFC 4017 requirements. This group is chartered to work on the
following types of mechanisms:"
Hao: are those the only 2 RFC's requirements? What about EAP-keying?
Why would we single other requirements to only one particular
Joe: does anyone else agree on this?
Sam: am more concerned on RFC 4962....would recommend not adopting
EAP-keying yet
Charles Clancy: how is RFC 4962 required for Hokey? The fact that its
bootstrapping its keying from RFC 4962
Sam: may put a requirement on an EAP method to get such keying material
Charles: RFC 4962 still has gaps in how keys are distributed.
Sam: there's an open issue with RFC 4962 and Hokey and how keys are
delivered
Charles: during authentication, the MSK needs to be delivered and its
not something that is currently RFC 4962 be compliant.
Sam: that was one of the intents of RFC 4962
Charles: if there's a proxy, then it will not help especially how all
those keys are being managed
Sam: yes, that is an issue that will be discussed tomorrow. There are
some problems with RFC 4962
Joe: RFC 4962 does not have EAP requirements.
Bernard: believe the issue is whether the method can determine that the
authenticator (or the port) gets the key as the intended party. The
channel binding can help as there is full agreement....there would
worthwhile to have a document that explains and clarify what the channel
binding architecture achieves since it has been hard to get the lower
layer guys push up required material. Making a case to go in this
direction is needed.
Sam: need to move on.
Joe: sounds like we need to require a statement that says methods must
also support for RFC 4962.
Hao: if we add this, then we'll have problems with EAP-PSK and
EAP-TLS....are we going to backtrack to fulfill these requirements?
Sam: sent question before regarding this. My recollection on mail sent,
Sam will ask to make it clear on how channel binding could be added to
these methods. Would be okay accepting this....did not recall getting
negative comments for this.
Hao: if we make the requirement to support channel binding, one of the
problems for TLS is we would have to grandfather it in since there are
implementations out there.
Sam: EAP-TLS has already move forward so lets leave it
Steve: lets remove it out of the list then.
Sam: remove completed items.
Paul Hoffman: that is weird. You're going to have a set of milestones
that will have a hole in the middle of them. Where there's normative
specs in the body but not in the ASN specs....while we're not meeting
RFC 4962, to take it out of the deliverables but then above to imply
that we've delivered it, is confusion. We need to be clear of where it
is required.
Joe: OK
Sam: doesn't like that but it's not worth fighting over.
Joe: includes RFC 4962 for some of the methods. There is a path to
support this in EAP-PSK so authors are okay with this addition.
Hao: suggests that we explicitly state channel binding versus calling
out RFC 4962.
Joe: believes it would be clearer though not sure it would be accurate
as there may be other requirements.
Sam: doesn't want to get into argument of what is and is not in RFC 4962
within the working group. So if 4962 is broken then we should fix it.
Steve: though we have an unspoken agreement, not clear that there is a
plan to address RFC 4962...don't think we should proceed "must meet
4962" when it may not be clear.
Hao: we should be clear on what it means to meet RFC 4962
Joe: so can change to "mechanisms must be capable of supporting channel
bindings."
Bernard: we really should defined what it means to "support channel
binding" should we add this as a work item? How do we ensure that it is
added to the group?
Joe: we will need to clearly define what this means....
Sam: agree with Bernard & must be written somewhere, though updates to
EAP are outside this group. We can change charter to this group, but it
will cause further review. This piece is missing and no one is fixing
it.
Joe: we need to fix this if we are to move forward.
Nancy Cam-Winget: if we can't define it in this group, then we should
remove it as a requirement on our charter revision.
Tim Polk: its up to the area directors to figure out where this work is
to be done. Perhaps we create an adhoc editing team to...may came back
to this group or another group. Regardless of where it happens, it
impacts many groups so leave it for now so it doesn't hinder our
progress.
Bernard: we will need to get consensus behind this. There will be
requirements on L2 that they are not doing, so the IETF will need to
motivate the lower layers to comply as well.
Tim: yes, it will have to be compelling enough to make everyone do it.
But we don't want to hold other work until this gets sorted out.
+ Enhanced TLS
Joe: we can move off this update to next item on the "enhanced TLS"
item.
Bernard: how is this different from the "tunnel method"?
Joe: feedback from Jari that definition may be slightly different even
though it's the same problem.
Hao: to clarify, it's not 2 different methods. As far as the channel
binding it's already covered in the top.
Joe: will modify it to explicitly state that it's not a new method.
Hao: we do need to ensure that "emergency call" scenarios are supported.
Joe: a response was made to TGu, that we "could" support them but until
we understand the security requirements of the emergency call and
operational requirements, it's not clear how we can tailor EAP-TLS to
meet their requirements.
Hao: am personally advocating that we should support such a scenario.
Joe: that is fine, but we will need to get clarifications on
requirements from them.
Glen Zorn: combing slides 6 and 7, there is probably a politically
morass given that these can constrain requirements to two methods that
have already been deployed.
Joe: while there is a desire to do that, it is not specifically
requiring it to be a particular method. This particular item is to
state that we don't want to create a new EAP TLS based method.
Steve: can clarify by stating "based on EAP-TLS or a TLS based tunnel
method in the preceding item".
+Password Method
Joe: Next item discussion are the updates on Slide 7: "A mechanism that
makes use of existing password databases such as AAA databases. The
implementation should strive to be usable in resource constrained
environments. This item will make use of the above tunnel method."
Dan Harkins: does the "constrain" mean no PKI?
Sam: if don't know what it means, then take it out.
Glen: don't want to take it out, but we should clarify. It's a good
thing to have as there are large customers do work in resource
constrained environments like 3GPP and 3GPP2. For this to be really
useful, we should be able to clarify such as "resource constrained
environments, such as mobile phones."
Bernard: we did have a discussion in GPSK. One of the conclusions was
that couldn't do a full TLS...but adding this to the work item may
Dan: a suggestion is to remove that sentence
Joe: group has already chosen this direction.
Pasi: note that current phone does support PKI
Sam: adding example will not help. To be useful as a constraint, we
need to be clear what the constraint is....must work in an environment
without PKI would be fine, but is one that we would disagree with. If
there's no volunteer to clarify, then drop it.
Glen Zorn: volunteers to help make this concrete.
+ Milestone update
- tunnel method items: add item for requirements draft
Glen: this (requirements) would be a good place to impose resource
constraints in here.
Joe: we can discuss them during requirements, not sure it makes sense to
impose in charter until we have clarity.
Hao: there should be 3 things in tunnel method, two of which are
mentioned but the inner method extensions are missing, not to mention
what the clarification of "inner methods". Discussed tunnel and
password method requirements but we need to define what the inner
authentication mechanisms. Need to see a definition of what "inner
authentication" (like method sequencing, data exchanges, vendor
extensions) means.
Joe: we should call that out in the charter though. At this point, need
to determine what the requirements are.
Hao: for the "extended tls method extension" deliverables, is that base
on the EAP-TLS method or the new method? (Joe agrees that it may apply
to both?)
Steve: agree that constraint environments should be included. Suggest
that "resource constraint" and level to which it is needed should be
part of the requirements definition and not necessarily part of the
charter.
Tim & Joe: agree....during requirements definition is when we as a group
can decide the constraints.
Glen accepts this...though milestones don't quite mesh yet as there are
no requirements for the password method in the deliverables. Point is
that we should be more explicit.
Joe: brought in by reference is that it would be included. But, we can
remove the "resource constraints" from the charter.
Joe: Take milestone discussion to the list.
(presentation modified during discussion is available with proceedings)
---------------------------------
Tunnel Method Presentations
---------------------------------
+ Steve Hanna Presents on EAP-TTLS
* New drafts for crypto agility and extensions for TTLS.
* Overview of TTLS protocol and supported features
* Extensions to TTLS: PRF negotiation through TLS version; crypto
binding through a key-confirmation AVP
- Hao: what keys are used to generate the crypto-binding? So, if the
inner method fails, TTLS can not do the key confirmation.
- Steve: correct.
Pat Calhoun: have addressed security issues with TTLS, that is good.
Should the standard address current security requirements and how would
the legacy be enabled and handled as it would have to be supported?
Steve: this depends on the group, whether we start from an existing
method and upgrade then to include the security extensions. TLS adds
support for transition through turning on M bit. Up to WG to decide on
whether new functionality falls under new EAP method or not. Not a
strong position either way.
+ Gene Chang presents on EAP-FAST
* description of deployed features inclusive of security considerations
* features include flexibility and scalability of credential types and
computational constraints
Sam: PAC What is it? How can you get one? referred as RFC 4507.
Joe: PAC is like a ticket as defined by the RFC
Sam: how do you get a ticket if you don't get it via a certificate.
Gene: can provision in-band through the protocol or manually
(out-of-band).
Hao: PAC is in RFC 4851 and used as defined in RFC 4507
--------------------------------
Requirements Discussion
--------------------------------
* Can start with password based methods since members were already
thinking of tunnel methods
Hao: we'll need to add crypto agility
Joe: hold that for now and add it during the brainstorm. Looking at
current requirements, we'll need to make sure that we can meet RFC 3748,
4017, eap keying, etc.
Hao: authentication of the EAP headers should be included and Identity
privacy.
Sam: if we are going to do anything with TLS, it needs to be reviewed by
the TLS group. Any mechanism like the PAC should be reviewed by the TLS
community.
Joe: so any novel uses of TLS should be approved by the TLS community.
Sam: how about requirement that the use of TLS and the tunnel method be
removed by the TLS community before completion of our work.
Consensus that suggestion is a good idea.
Steve: are these requirements for the tunnel method or the password
method?
Joe: we need to cover both, thus far these requirements are for both.
We could treat them as separate requirements.
Steve: requirements for the two are largely disjoint; no strong opinion
on whether its one or two documents. If it is one document, then they
should be described as two totally different things. For example:
password requirement may not need to include mutual authentication.
Joe: since group has decided to address password thru tunnel, the
combination must meet the requirement of mutual authentication. While
the requirements are disjoint, there may be some specific to tunnel or
to password, but there are interdependencies...so we need to make sure
that the combined meet full requirements. Agreement that we do need to
be clear.
Kaushik: are we creating a new set of requirements? Shouldn't the
requirements be to include existing password methods?
Joe: don't know that it is part of the charter....we are to support
existing databases not necessarily methods. If we're supporting EAP
authentication mechanisms within the tunnel, those will have their set
of requirements.
Hao: just as we mentioned internationalization, agree with Steve that we
need to list separate set of requirements.
Glen: ultimate goal is to get secure password based method; tunnel
method is to facilitate this.
Joe: yes, but there are those that want to support other features beyond
password authentication in the tunnel.
Glen: having designed a tunnel method before, would like to state that
it would be better to design these things together so that they work
appropriately. Generalization would be the enemy of this. If we're to
design a password based method, making the tunnel method support "the
kitchen sink" is not a good idea....focus should be on password first
and not make the goal to support other things.
Steve: disagrees. If we look at them together, that is good; but its
not desirable that we only focus on the password only. There was
consensus by the group to not specialize for password based method only;
not suggesting we expand the scope to include everything. But it would
be an error to only consider password.
Glen: intent was to ensure that the tunnel based and password based
method and how they work together are extremely well understood.
Generalizing makes it harder to do analysis.
Joe: agreement that we need to consider the password method within the
tunnel method. There is a constrained set, though not fully constrained
yet, of other conversations that may happen within the tunnel.
Glen: if tunnel method is well designed, then probability that its
confined to only work with the particular password method is low. Not
sure that password change really belongs here.
Joe: there was consensus that this was a desirable feature.
Steve: change of topic. Add requirement to include internationalization
of human readable strings.
Sam: should include "internationalization must be consistent with NAI,
human typed passwords, and prompts. Consider errors and other
indications." SASL RFC has good text on how to deal with
internationalization. If you use something like RFC 4013, we should be
on the right track.
Glen: not sure what the point of internationalizing password.
Sam: we need to ensure that it can work across different OS' which is
why we need to ensure it meets the internationalization criteria. If
the user has a password that contains an accented character, the
bytecodes generated for that password may differ depending on which
computer the user is typing on.
Joe: earlier we had a requirement for Constrained devices
Decide the charter updates through the working list
Need to get working on requirements draft together
Sam: RFC 4962 and channel bindings confusion. Could use some help here,
so contact Joe, Tim and Sam on how to resolve this as it is more
complicated than originally thought.
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
