[Emu] Minutes from IETF-69

Below are minutes to the EMU session at IETF-69.  I will also upload
them to the proceedings page.  Let me know if you have any corrections.

Thanks to Mauricio and Nancy for taking good notes.

Joe

Notes from EMU meeting at IETF 69
Tuesday, July 24, 2007
Chicago

Agenda
-----------------------
+ Administrivia (5 min)

Note takers, blue sheets, agenda bashing

+ Document Status (20 min)

EAP-TLS (5 min)
EAP-GPSK (15 min)

+ IEEE Liaison Request (20 min)

+ Password based method (75 min)

Requirements (10 min)
PP-EAP - draft-zhou-emu-pp-eap-01.txt (20 min)
EAP-TTLS - draft-funk-eap-ttls-v0-01.txt (20 min)
Discussion    (25 min)

Document Status
---------------------
+ EAP-TLS 

Ready to go to the IESG

+ EAP-GPSK

Some open comments still need to be addressed that will be addressed in
security considerations.

+ IEEE Liaison Request

Matthew Gast presented overview of work in 802.11u related to
requirements for an EAP method for emergency services.

Joe Salowey: surprised by request.  There is already a WG in IETF
working on emergency related technology. thought that group would be
tapped instead of EMU.

Matthew Gast: Highlighted the EMU was tapped instead of ECRIT because
they deal with high-order call handling.  EMU seen as better WG to
answer question at hand.  

- Matthew Gast Presents

Bernard Aboba: asserted that EAP methods have poorer DoS resistance than
PSK.
Joe: agrees
Matthew: admits he was loose with usage of DoS

Presentation Continues

Paul Hoffman: in what way EAP is used by 802.11
Matthew: it's for link-layer operations

Presentation continues: 

- Basic requirements for emergency services: 
1) No pre-existing trust relationships
- anonymous cryptography is acceptable to them
- Is it secure?
2) Small number of round-trips 
- concern that TLS messages are too long, they'd like to reduce latency
- want fast speed of access since they realize the call will be of short
duration

Hannes Tschofenig: suggests that a new EAP type be allocated that then
leverages a watered-down version of EAP-TLS that satisfies the reduced
security requirements for 802.11u.  

Bernard: questions the requirement for regulatory requirements driving
need for link encryption.   Points out that the encryption without
authentication is not satisfying any useful security requirements.   
Matthew: responds that operators/carriers sometimes reject having an
open SSID.  
Bernard: most will have at least one open SSID.
Matthew: in 11u, an SSID is set up that is dedicated only to emergency
services. Objections in 802.11 to design a network only for emergency
services....there is some fear that they conversation will have to be
protected somehow, at least from hijacking, spoofing or splicing.  From
a network implementation view, the username in the public credential can
be defined as being part of the emergencies architecture to know to
treat it in a special way without having to reconstruct the
infrastructure.
Bernard: questions who the regulatory compliance requirements apply to:
Is it enterprise or carrier.

Joe: points out that there are still questions about requirements, but
doesn't feel that EMU WG is not the right forum to discuss or change the
initial requirements.  there may still be some requirements based on the
presentation.  It's not clear that requirements are valid or that EMU
can address this.  Most of the work items and the way EAP works is
focused on authenticating the peer.  There may be possible solutions, as
Hannes brought up a special method for it.
Steve Hana: EAP-TTLS supports server-side auth only if needed.
Joe: take discussion to list to see if there is anyone on list that has
additional insight on what could solve 802.11u requirement

Hao Zhou: asks about timelines
Matthew: says this exercise is not critical path for their work.  They
ultimately just want to point to the IETF recommendation at the end. 
Dorothy: it would be extremely desirable to have a final recommendation
by July '08.
Hao: feels that there is no need for a new EAP method. Existing EAP
protocols can be leveraged as long as a pre-defined policy is adhered to
that satisfies 802.11u requirements.

Joe: don't know of any standard track methods that could address this.
If there is work to be done, we'll need a liaison to keep the work
going.
Hao: based on some current methods, it doesn't seem like a new protocol
is needed but rather a policy to help validate the server cert or client
credential.  If we can make the current EAP method that can be
configured in such a way, no new method is needed.
Joe: to do something expedient, there may be more work that is required
since the current methods do not meet all of the requirements presented
by TGu.

+ Password Based Method

Joe: excused himself that he was not able to dedicate as much time as
desired into this work item.  Other high-priorities (EAP-TLS and
EAP-GPSK) took his time.

Joe goes through password based requirements

Paul: Question whether password need to be truly randomized or can it be
human "memorizable".   Joe: says that password can be anything perceived
as a "password".
Gareth: asks whether OTP have been considered, asks if this would
preclude POTP
Chair: this mechanism is looking at supporting a password, could be but
not limited to OTP
Gareth: only mentioned other password

- Hao Zhou presents PP-EAP

Kaushik Narayan: asks how this work is different from EAP-PEAPv2 or
EAP-TTLS?  Is this a new method?  
Hao:  says that they leveraged common design details from existing EAP
methods and that a new EAP type will be likely allocated.  This work may
conceptually boil down to just extensions of existing methods, but
because versioning brings its own set of disadvantages the cleaner
approach is to treat it as a separate EAP method.  
Kaushik: responds that he felt the desire of IETF was to reduce the
number of EAP methods, not increase them.  
Hao: a lot of these constructs were taken from other methods.  But
because other constructs are added and to solve interoperability issues,
a new EAP method type is to be assigned.
Kaushik: this is potentially a new version of an existing method.
Joe: a concern of the extensibility, is that the WG charter item is to
do a password based method. With the extensibility, will get us well
beyond the WG item and make it more complex than it needs to be and
cause interoperability issues.  Make sure that the decisions we make do
not confine us or cause more confusion.
Kaushik: thought we need less not more methods
Hao: but we need one that will be adopted by all and interoperate

Glen Zorn: Asks where key material only comes from TLS exchange.  
Hao: yes.  
Glen: asks how crypto binding can be done if there is only a password.
Glens asks whether the method has an inner method defined.  
Hao: no.  Crypto binding left in method to allow future extensions that
may require crypto binding.   Today it's not required. If group feels
that there should be no crypto binding, then it can be removed.
Charles Clancy: the reason for the attack in MSCHAPv2 is because it
could be done outside.  Here there is no inner method, so it can not be
run outside the tunnel.  So, there's no need to bind the exchange to the
keys derived.  For this specific step....the binding is done for future.
Doesn't believe we should support tunneled method inside this (like
EAP-MSCHAPv2) the
Glen: not really true.  PEAP was that it could be used the same form of
the password for other methods, this is true for stuff like VPN.  We can
not outlaw them for multi-use password
Sam: needs to be documented in the security considerations
David Nelson: points out that we should be careful on number of bells
and whistles added.  Points out that current proposal is a mega-method
with ability to define any number of smaller sub-methods. 
Hannes: counters that there may be usefulness for allowing for future
extensibility, in particular in light of desire to reduce number of
future EAP methods. 
Dave: but then that should be another method.
Dan Harkins: sarcastically points out that no one ever uses self-signed
certificates on their authentication serves.  Usage of  self-signed
certificates essentially nullifies any value of TLS. Passwords would be
effectively transferred in the clear.
Hao: but there are some backend databases where clear text password is
not accessible.
Hannes: EMU has already adopted methods like EAP-GPSK that could be used
for such a purpose. 
Bernard: comments that the PEAP MiTM attack had nothing to do with the
method.

Hannes: so this should force us to put a requirement to guard against
such an attack?
Charles: http authentication over TLS.  We're not worried about binding
the password into the TLS key.
Sam: but we should be
Joe: seems like crypto-binding should not be required if we're trying to
"keep it simple"".

Kaushik: asks whether this new method could be run as a inner method to
another method.  
Hao: says no, but there isn't any way to disallow it.  
Joe: the idea is to avoid that situation.  Which is why we need to limit
what is inside this tunnel (method). 
Glen: Original question: since problem is reuse of credentials and we
can not force people to use the same password on different applications,
how are we going to address this?
Hao: we can not fix it because it is not on our scope.  We can put the
limits into the security considerations.

Glen: points out since the re-use of credentials is the base weakness at
root to many security vulnerabilities, is there anything this method
that will prevent credential re-use.  
Hao: says no.

Glen: isn't the layer EAP and PP-EAP mixed up?
Hao: this is looking at it from a packet encapsulation layer
Kaushik:  are these EAP TLVs?
Hao: these are just plain TLVs. Application layer TLS data.
Joe: packet format looks like EAP-TLS
Hao: yes.

Sam Hartman: : we haven't had enough fun yet.  Problem #1: what language
should the password be in?  Invite to side session on Thursday to talk
about internationalization.  The discussion will be on what lead to the
stringprep discussion.  Stringprep requires exact matching vs. fuzzy
matching; not clear that passwords in all environment meet that
requirement.  It may be reasonable to try different normalization of a
password.  We had an attempt in SASL (for internationalization); but
need to carefully consider when stringprep is used (profile and design
of profile needs to be strongly reviewed).
Hao: asks whether usage of just UTF-8 would suffice.  
Sam: Answer is an emphatic no from Sam.
Hannes: asks for suggestions on what to do.  
Sam: says attend the Thursday SAAG meeting and read the draft that deals
with issues on internationalization.
Glen: L2TP talks about internationalization so you may take a look at
that too.

Charles: Asks whether we need to wait until TLS exchange completes in
order to start exchanging challenges.  
Hao: says that it's possible to optimize and start exchanging
information beforehand.  

- Steve Hanna presents EAP-TTLS

Joe: asks why allow a DIAMETER AVP in EAP method?  
Steve: clarified that format is leveraged but not the code types.   
Bernard: this is not reusing Diameter, it is using the AVP format.
Joe: only format or type codes?
Steve: only the codes from RADIUS.
Joe: it is confusing to reuse the typespace from RADIUS
Allan: it is implicit, it seems like this is overly RADIUS.  One should
not put RADIUS stuff inside the authentication message originated by the
client.
Joe: agrees
Bernard: but could use it for channel binding
Sam: will need them for Housley key management

Steve: Base assertion is that EAP-TTLS can cover all requirements, so
why start over?
Hannes: Hannes asserts whether after all the changes being introduced
(channel binding and internationalization) can EAP-TTLS still be called
as EAP-TTLS.  
Steve: what you'd be doing is providing additional AVPs, the client can
send an AVP that it would prefer to use the new AVPs and the server
would have to ignore them if it doesn't know it.
Hannes: challenges whether EAP-TTLS can make the claim that it's free of
IPR restrictions. 

Steve: the extensions that we would define in TTLS vs. starting from a
new protocol.  But do we want to start with something that has been
widely implemented and extend AVPs or do we want to start from scratch
that can only be used for passwords.  Seems likely that the marketplace
has been enthusiastic about TTLS, but if we create a new way for
password; it seems unlikely to him that 'they' would abandon already
existing code .  Crypto binding are no longer considered a requirement.

Hao: challenges statement that the other, PP-EAP, protocol is not widely
implemented.  Not true it is based on EAP-TLS which is widely deployed.
There are also other protocol 
Steve: it would interoperate, it just wouldn't take advantage of the new
features.  If you want to add crypto agility to TTLS
Hao: to meet this requirement, need to add crypto binding.  This will
need to be added.
Steve: if there is an AVP it doesn't know, you ignore it.  
Hao: there are a lot of options that the negotiation of what's required
versus not may be too confusing and complex.
Vidya Narayanan: Adding TLV to address Hao's point, if there's
extensions or changing the version number seems simple.  So, would be a
proponent to adopting something that is already deployed.  What is
missing from TTLS that we would have to add?
Joe: there were requirements that TTLS is not meeting which is why the
extensions to TTLS were proposed 
Kaushik: there are 2 options.  What is being proposed is an "uber"
method, but essentially do all the password based mechanism...that is
the key difference between TTLS and PP-EAP.  So, are we looking at an
"uber" method approach?  Because if we are doing that then we should
look at EAP-FAST or other tunneled methods.
Alan: TTLS uses the Diameter AVP, what are the IANA considerations for
the number space because it is reusing some of the name space?
Steve: Paul would be a better person to answer this.
Bernard: the scourge comes from vendor specific.  When talking to
customers: they do not say "we need more EAP methods".  If it possible
to start from something that is widely implemented, then it would cause
a lot less pail.  The nice thing about TTLS, it supports the notion of
non-mandatory AVPs so it makes it easy to add the channel and crypto
binding.  So there is a nice transition story since there is open source
code available.  For something like channel binding we will need code.
Charles: advantages of PP-EAP over TTLS.  The fact that PP-EAP cuts out
the unneeded things is the advantage; from an interoperability
standpoint.
Hannes: comment on what's new and what's not:  If you have a new
protocol and put stuff to it, like changing or adding AVP's, is that
new?  It is a philosophical issue.  To interoperability issue: it is a
tighter specification versus "flexibility" in negotiation.  There is
rarely a chance to change or "fix" some of the concepts like key
derivation, then it is not the same method.
Joe: a notice on both approaches.  We're looking for a password based
method, but then we get the kitchen sink which worries me.  There's a
significant amount of things just to meet the password based method,
like change of password, character sets that throwing other things is
expanding the charter and in general introduces a lot of complexity.
Gabriel Montenegro: seems painfully obvious that we need to start with
something that runs is known, has been known not to be extended and very
importantly has been adopted by different organizations.  These are
critical for actual deployment, TTLS is already being certified by WiFi
and soon Wimax, that should not be discounted to easily.
Alan and Steve: were going to say the same thing.

- Joe puts out question whether group has opinion whether we should
focus on just a simple password-based method or a more-complex, yet
extensible, method. 
David: : this sounds like re-do the charter.  Seems like the work that
was chartered was just a password method. Now it sounds like we are
trying to rescope the charter.
Joe: there are potential implications in adopting something broader,
like complexities and potentially more work.
Glen: depends if you're pragmatic or theologian.  TTLS is password based
but happens to be more...so it can be considered outside the charter
Sam: you can give me a TTLS and thou shall use it only for certain
things.
Glen: asserts that the editors of EAP-TTLS haven't been very active in
WG. Nervous about accepting work. 
Sam: says we can steal it, as long as they are fine with it.   
Steve: suggests that 
Glen: if we do what Sam suggests, since it is being considered by other
groups, they are not going to accept the idea of just plaintext
passwords.  So if our RFC says only plaintext then the other groups may
not adopt.
Steve:  if we take TTLS as the start, then the TTLSv0 could be
documented as the start.  That could be the stable point to start from.
Could also move forward in adding the AVPs to make sure that all
requirements are being met....and then there could be another document
to state how it is limited to address
Hao: concerned that if only a subset of TTLS functionality is carved out
whether it would introduce unacceptable interoperability problems. 
Alan: to a certain extent, EMU requirements could be to define a new
type to carry the restrictions of TTLS. 
Bernard: procedural complexity of informational, standards and working
drafts.  But from a purely technical point, it could be done without
having to bump a version number.

Joe asks the WG to hum on two questions:
-	Should we focus efforts on a password method, which could be
based on EAP-TTLS, EAP-PP, and can only be extended with channel
bindings but nothing else?
-	Should we focus efforts on a method that performs password
authentication and is extensible to do other forms of authentication?
-	Louder hum recorded to limit ourselves to just password method.

-	WG requests and Joe grants a hum on two  additional questions
	Second question
-	Who would like to base this on EAP-TTLS?
-	Who would like to base this on a new method?
	Consensus of hum is difficult to discern.

Joe: let's take it to the list. 

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu