[SECMECH] Minutes from the EMU BOF

"Salowey, Joe" <jsalowey@cisco.com> Tue, 06 December 2005 22:36 UTC

Received: from localhost.cnri.reston.va.us ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjlQ8-0001mu-5t; Tue, 06 Dec 2005 17:36:24 -0500
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjlQ6-0001m9-Nu for secmech@megatron.ietf.org; Tue, 06 Dec 2005 17:36:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01247 for <secmech@ietf.org>; Tue, 6 Dec 2005 17:35:32 -0500 (EST)
Received: from sj-iport-4.cisco.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejllf-0004Et-P7 for secmech@ietf.org; Tue, 06 Dec 2005 17:58:40 -0500
Received: from sj-core-2.cisco.com ([]) by sj-iport-4.cisco.com with ESMTP; 06 Dec 2005 14:36:13 -0800
Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com []) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB6Ma6BH014397 for <secmech@ietf.org>; Tue, 6 Dec 2005 14:36:07 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 6 Dec 2005 14:42:02 -0800
Message-ID: <7210B31550AC934A8637D6619739CE69065487A0@e2k-sea-xch2.sea-alpha.cisco.com>
Thread-Topic: Minutes from the EMU BOF
Thread-Index: AcX6tXBPW+KXAIGjSRigaYWwt4Lluw==
From: "Salowey, Joe" <jsalowey@cisco.com>
To: <secmech@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 539f8b288ab42db633e5c7cf1c34fca1
Content-Transfer-Encoding: quoted-printable
Subject: [SECMECH] Minutes from the EMU BOF
X-BeenThere: secmech@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <secmech.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/secmech>
List-Post: <mailto:secmech@lists.ietf.org>
List-Help: <mailto:secmech-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=subscribe>
Sender: secmech-bounces@lists.ietf.org
Errors-To: secmech-bounces@lists.ietf.org

Minutes from the EMU BOF, let me know if there are any correction:

Thursday, November 10, 2005, 9:00-11:30
Vancouver, Canada

Based on Notes taken by Nancy Cam-Winget Notes Edited By Joe Salowey

Chairs: Jari Arkko, Joe Salowey


Background Discussion and relation to Secmech - Sam Hartman

+ Conclusion of previous BoF at IETF 63:
  - unify authentication mechanisms currently existing in IETF would be
nice, needs more people
  - EAP mechanisms meeting requirements of others standards organization
is important

+ today's meeting looks at the second conclusion
  - charter working group to meet EAP method requirements of other SDO's
so it's not a free for-all, it's a small number of mechanism to meet
external requirements
  - for now "grand unifying framework" is out of scope for the working
group.  But those working on the specific EAP methods would work with
those interested in unifying the different framework to ease the path
further down the road for when it may become the scope of the working
group charter.

Rohan Mahy: will the 7 presentations address the requirements imposed by
the SDOs?
Sam Hartman?: I don't think so
Jari: It will be discussed later.


BOF Goals - Joe Salowey 

Presentation -

+ Charter group to focus on EAP methods.
+ Focus on standardization of 1 or 2 methods. Once completed charter may
expand to include other work. 
+ What methods?
  - what infrastructures are required most?  (PKI, shared secret,
  - which ones are likely to succeed in a short amount of time?
+ Process is in place to go through IANA for EAP assignment; that will
not be replaced, it will persist.  This group is more focused to enable
some of the drafts to become standards track and of better quality.  So
this group is not to replace the already existing process for EAP
assignment and individual submission.


EAP-Method Requirements - Bernard Aboba

Presentation -

+ Work in progress: peer to peer in 802.1af RFC 4017 lists method 
+ requirements
  - Different credential types mentioned
  - mandatory requirements for key strength, key derivation and key
distribution to name a few.
  - No Requirements for PSK

Don: Why is pre-share key different than password?
Nancy Cam-Winget: in 11i we differentiated based on ease of deployment
Bernard: differentiation was conscious

+ Some thoughts
  - some usage scenarios still unsolved
  - don't try to drain the swamp or boil the ocean

Derek Atkins: Lack of kerberos, does that fall under username/password?

Bernard: yes, it probably would.
Rohan Mahy: Unmet requirement of public/private key with no
certificates. This could that be met using certificates without a
trusted root.
Hannes Tschofenig: agrees with Rohan and stresses username/password can
be dealt with existing methods.  
Bernard: while they may exist, they are not widely deployed.  
Hannes: there's a difference between widely deployed vs. widely used.


802.11 and EAP methods - Jari Arkko on behalf of Dorothy Stanley


+ 802.11i requires one or more published EAP methods.
+ Bernard's presentation covered most of the contents of this in this


Overview of proposed EAP methods, credential types and uses - Pasi


+ Many methods using shared secrets.

+ Passwords (his definition):
  - distinction with shared secret methods is that username/password
requires access to a database
  - many widely used and deployed methods using password, most of them
using tunneled mechanisms (EAP-FAST, EAP-TTLS, EAP-PEAP)
  - tunneled methods also used for one-time passwords and tokens
  - No kerberos specific method (EAP-GSS expired)

Hannes asks: got impression that use of kerberos within EAP was really
bad idea, so that's why it might have been dropped.  
Pasi: not sure we want to discuss now. 
Bernard: says different environments, like Universities that are using
it today, doing it through PAP.  
Sam: Methods that cannot deal with kerberos pre auth, methods where one
peer has no Kerberos credentials at the end of the authentication and
methods that expose the long term shared secret should not be identified
as kerberos methods.  

Yoshihiro Obha: With regard to the differentiation between password and
shared secret being that password stored in a backend database, if there
is an API to get the password wouldn't they be the same?
Pasi: The API may not provide access to the password itself. 

+ Summary
  - PKI: some are using EAP-TLS.  If we were to adopt this, may be good
  - Shared secrets:  no methods.  Believes we should have a standardized
method.  Should have a good chance of succeeding on meeting this
requirement.  But will require a substantial amount of work, especially
in building consensus.
  - Passwords: many proprietary methods widely deployed and used.  It
would be nice to have a standardized means, but pessimistic on its
success.  Not sure how much the vendors would be interested in
standardizing.  May be very difficult to get consensus in the IETF.

  - Shared secret methods

Hao Zhou: Is the difficulty in getting vendors to change their interface
to the databases or the authentication methods with no data base change?

Pasi: difficulty is more in getting the clients to implement the
standard method.
Bernard: Definition of password different for 802.11. 802.11
distinguished between password+asymmetric auth from pure password.

  - Kerberos: no new methods, but not much demand.  

Bernard: the university community would have an interest in using it in
internet 2.  
Rohan: comments a better way to say it is that it is probably not the
first thing we would do as responding with SDOs would take precedence in

  - Other possible work is to address channel binding.  Not sure there
is strong demand and is unclear on its success.  

Sam:  methods that we standardize will have to satisfy the Housley

BOF Discussion and Questions

Presentation -

X.509 certs, shared secrets, passwords, one-time passwords, cellular
credentials, kerberos, channel bindings
+ Jari presents an overview for how to lead this discussion.

Yoshihiro: Channel Binding, does each method require channel binding? is
common functionality?
Jari: Common to all methods and things we can do for existing methods.  

Madjid: Fast reauthentication required for methods?
Jari:  Yes
Bernard: Cellar credentials are already covered.  OTP is not as high
priority, don't see the demand.  What looks important are shared secrets
and passwords (pure passwords not asymmetric).  
Sam: clarifies on shared secrets, shared good keys, shared low entropy
keys and then there's passwords where server recovers the plaintext.
Third category is only possible with a server cert.  In the 2nd case,
people should follow the work that's not been done in the scared working
group and be aware of why it has and hasn't progressed.  
Pasi: Password against existing database is most important. Such as
using a tunneled proprietary thing which will require a cert of
something to authenticate the server.  
Hannes: highlights that we might fail if we rely on a backend server.
Learned from sacred working group

Madjid: comments whether there's no work needed to EAP-SIM but queries
whether the group should standardize on this.  
Jari: IETF has approved the individual submissions of EAP-SIM and
Sam: approval status of informational RFC is not the seal of approval
from IETF, it should be a standardize by the group as it will require a
fuller review.  
Madjid: comments it would be better if it had a fuller review.  
Sam: asks whether the group would be allowed to make changes to EAP-SIM
or EAP-AKA before it gets standardized?  
Madjid: doesn't know, but would like to see a review as he believes it
will be widely deployed in WiMax.  Interested in seeing if EAP-SIM/AKA
could be used securely, so requests a secure review.  
Pasi: comments that they went through a very long process, they didn't
"just" get published, it was widely reviewed and became informational
since it was clear that there was no consensus to standardize it.  So we
have to live with the limitations it has and the resulting method may
not be as nice unless we impose that SIM cards be changed.  
Rohan:  if the group decides on what changes would be made, it would be
irrelevant since SIM cards can not be replaced as a result of IETF spec.

Hao Zhou:  different take on one-time password.  Agrees that we need to
get the vendors working together, but if we solve the standard password
methods, then we may be able to get the one-time password issues
addressed as well.  We being Cisco.  
Dave Mitton:  defends one-time password.  Though, Pasi hit a point that
there is an assumption that there's a method to protect the one-time
password and bottom line is that RSA is interested in putting their
protocol out to the IETF. 

Michaela Vanderveen: why is the channel binding important?  
Jari:  it could become a separate item and not a hard requirement for
every method.  
Michaela:  as this is an IEEE optional feature what should we treat it?

Jari:  consider both optional and mandatory requirements.   
Pasi: comment on channel binding is separate item, as it is a feature of
the method, it would be important to do it roughly the same way in all
methods so that the different layers do not need to know the specific
Joe Salowey:  we need to clarify what is meant by channel binding is.
3748 is not clear on a mechanism.
Pasi: there's 3 diff ways the term is used.   Same identity is used by
NAS in both with the AAA server and the peer.  

Rohan:  wants to talk about enrollment, should be a high priority item
on the list.  Higher than one-time password and cellular credentials.
We look at stuff as technologists and not ordinary people.  It's a
problem when different devices in factories, hospitals with no display,
so providing a way to enroll them is essential for their deployment.
Some vendors in consumer space are doing proprietary mechanisms for
their enrollment, so it's important for this group to address the
problem to come up with a  standard mechanism.  In terms of priority,
EAP-TLS is highest priority then either shared-secret/password is second
but after its enrollment.  
Jari: speaking as a vendor, don't think we should work on cellular
credentials.  Don't see how we can effectively address those vendors
without hardware intervention.  Small updates on EAP-TLS would be on top
of the list and then channel-bindings on the methods would be second.
Third would be shared-secrets.  In response to Rohan, believes
enrollment is a big problem and it would make sense to address but have
reservation of how likely we'd succeed in defining this.  
Hannes: comments on Rohan, agrees and advocates for this work.  But
there seems to be discussions and impressions that some vendors don't
really care. 

Madjid: is the issue that we want to inject channel binding in every
Jari: maybe but it is not germane to today's discussion.  The group is
chartered to address some of the keying framework but we're not directly
chartered to address the channel binding per se.  We are mute on how we
would address channel binding, e.g. as method independent or dependent.

Michaela: is it a requirement?  
Sam: believes it is because it is part of the Housley criteria. 

Jari: reason for this as a possibility that we could make an extension
to some (existing) methods to allow them to achieve channel binding.
Rohan: unclear on what channel binding is...seems like it's clear we
need to do it, but the questions is how?  all methods or independent?
Joe: we can look to see how to ensure that its done consistent for all
methods, or we can leave it to each method to achieve it on its own
which may be inconsistent. Consistency is probably better so we can
understand what it means when it is claimed.
Rohan: asking for a single document for how channel binding is to be
achieved?  Address it in terms of a work item.
Jari: Sam will require that all methods we standardize will address
channel binding.  Question is whether we do something more, where the
"more" is a general document that attempts to update already existing
David Mitton : some EAP authors have tried to do channel binding and run
into issues into RFC 3748. Needs clarification. Its an issue.
Jari: that's a discussion for the EAP group
Sam: recommends that we drop the channel binding question.


* Do you believe EAP methods for infrastructure of type X.509 are
   Yes: lots of hands   No: no one

* Do you believe the IETF should work on standards track EAP methods for
   Yes: lots of hands   No: no one

* Do you believe EAP methods for infrastructure of type strong shared
secrets are important?
   Yes: Many hands (less than X.509)  No: no one

* Do you believe the IETF should work on standards track EAP methods for
strong shared secrets?
   Yes: many hands   No: no one

* Do you believe EAP methods for infrastructure of type weak shared
secrets are important?
    Yes: 22   No: 2

* Do you believe the IETF should work on standards track EAP methods for
weak shared secrets?
    Yes: 13  No: 8 

* Do you believe EAP methods for infrastructure of type passwords are
    Yes: 25  No: 0

* Do you believe the IETF should work on standards track EAP methods for
    Yes: 13  No: 0

* Do you believe EAP methods for infrastructure of type OTP are
    Yes: 6  No: 4

* Do you believe the IETF should work on standards track EAP methods for
    Yes: 4  No: 6

* Cellular credentials important?
    Yes: 23   No: 1

* Cellular should IETF work?
   Yes: 0   No: lots of hands

* Kerberos important:
   Yes: 17 No: 0

* Kerberos IETF work?
   Yes: 17 No:  2

* Enrollment important:
   Yes: 18  No: 0

* Enrollment IETF work
    Yes: 5 hands  No: 0

* Many hands raised to willing to contribute to this group.

Joe: Same order of interest for X.509, strong/weak and password based
secrets.  Some support for Kerberos though not as much as the other
credential types.

*How many items?

Sam: had hoped for only 2.  Note some of these can be combined.  Let's
try to clarify some of the polls.

Sam: how many people believe the existing password databases are
sufficient to meet the strong secret passwords.
Hannes: comments that merging them would be difficult as the device
types would be different.
Sam:  talks about dropping some of them.
Hannes: do not understand the implications of dropping or merging them.
Perhaps we should ask whether we're willing to standardized on EKE, SRP,
Rohan: agrees as we didn't ask that in the poll explicitly
Sam: ok so 1st category is like TLS PSK and kerberos variant,  problem
is that it depends on strong key, no certs.  The 2nd category is like
SPEKE, EKE, DoCoMo proposal, SRP where it's not cert based but the issue
is the IPR (weak shared secret).  The 3rd category is actually sending
the password in a protected tunnel.  
Hannes: clarification helps, but there needs more investigation where
databases are not used but certificates from server and password from
the client are being used.
Jari: we can't do everything, especially if there is IPR.
Sam: keep in mind that this if for the first round.  We can come back
and do more.
Hannes: who knows by then, the IPR might have expired!
* Are you willing to work on strong shared secret?
   Yes: 4 1/2

* Are you willing to work on weak shared secret (EKE etc.)?
   Yes: 2 

* Are you willing to work on existing password database
   Yes:  4

Jari:  so it looks like strong shared and password are close.

* Seems like there's lack of critical mass.
   Sam: 4 means 4 document authors.  We need to ask for reviewers as
others would be willing to review.

* Who's willing to review generally (anything)?
   Significant number of reviewers.

Sam: not comfortable working on 3 methods out of this group.  Consider
trivial ways in which some of these can be combined.  So, if the working
group can remove one of the methods and still not violate requirements,
we should do this.

Sam: who is willing to start a working group to address X.509, strong
shared secret and username/password to meet the SOD requirements?
   Yes:many hands   No: no one

* Who's willing to work on X.509?   7 hands

EAP-TLS report - Bernard Aboba

Presentation -

+ RFC 2716
  - original goal is to support EAP over PPP, took 24 months from
beginning to end.
  - Made experimental: new at a time and few existing deployments
  - Security analysis provided by Arbaugh and Se, issues were addressed
in RFC 3478 and RFC 4017.
  - WFA using EAP-TLS as part of interoperability testing since 2003.
  - FIPS 140-2 has EAP-TLS as only FIPS certifiable method.  Restriction
on mechanisms.
Hannes: asks how many of the implementations EAP-TLS are deployed?  
Bernard: about 10%. Much higher among sites that deploy certs

+ Options:
  - Do nothing:  leaves some points unclear though no outstanding issues
blocking development of interoperable implementations.  Though some
issues per SOD requirements may be overlooked.
  - Standard approach: leverage wfa test program, remove features that
have not been shown to interoperate between the already existing
implementations.  Issue RFC2716 as a proposed standard.  Add features
that would be "nice to have"

Sam: Speaking as individual would like to see if we can merge for
instance the use of PSK in EAP-TLS for addressing the strong shared
secret authentication.
Bernard: it may depend on how we deal with this especially with already
deployed systems.
Sam: Can you abort and continue in EAP?
Bernard: No
Thomas Narten: Strongly encourage draft standard approach. Leverage
community knowledge now before it fades. 
Joe: we should consider that there's something to be gained in tracking
what happens in TLS as issues arise and are addressed within TLS and not
have a divergence.  
Bernard: responds that clarifications could be made and included.
Joe: Beyond clarifications things may need to be fixed, PRF is an
example.  best to avoid divergence. 

EAP-PSK , EAP-IKEv2 - Hannes Tschofening presentation

+ Contextual history: work stemmed from Jesse Walker/Russ Housley
EAP-Archie work.
+ Based on a strong pre-shared secret, relies on strong shared secret
and its simplicity allows it to not require fast reconnect,
fragmentation, is immune to DoS attacks.
+ Reviewed by Jesse Walker, answered comments waiting for response for a
number of months. 
+ Implementation is available

+ Reuses IKEv2 authentication, key establishment and protection 
+ mechanisms Flexibility in supporting pre-shared and certificate based 
+ authentication Reviewed by Pasi Eronen

EAP-PAX Charles Clancy

+ Pre-shared secret based authentication Provides ciphersuite 
+ extensibility, provisioning with a weak key or password, key
management, identity protection/user anonymity and authenticated data
+ Charles completed full proof of security, publication pending.
* Provable security is based on random oracle model [bellare 93],
provides the different bounds and limitations of the authentications and
shared secret strength.
+ Reviewed by Jari Arkko

Charles: claims that this proposal addresses all 3 shared secret types.
Hannes and Sam: challenge claim as this method doesn't address how it
handles the interface to password database Nico Williams: sees this as
an enrollment to a stronger shared secret.

EAP-POTP - David Mitton
Presentation -

+ Designed for one-time password tokens
+ Features offers strong user mutual authentication, fast reconnect, 
+ optional channel binding, key management (fresh keying), protected 
+ results

EAP-MAKE2 - Michaela Vanderveen
presentation -

+ Requests review
+ version 1 was defined in 2001.
+ Pre-shared key method: key derivation to satisfy 802.11i

Bernard: asks if its related to MAKEv1, different authors?  
Michaela: clarifies that it really doesn't have anything to do with
EAP-MAKE the original version

SECMECH mailing list