[Emu] Draft Meeting Minutes from IETF-68
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Emu] Draft Meeting Minutes from IETF-68
Below are draft meeting minutes from IETF-68. Please let me know if you
have any additions or corrections.
------------------------------------------------------------------------
----------------------
EAP Method Update (EMU) Minutes
IETF-68
Prague, Czech Republic
March 19, 2007
--------------------------------
Chair: Joseph Salowey
Note Taker: Nancy Cam-Winget
--------------------------------
--------------------------------
Agenda
--------------------------------
1. rfc2716-bis
2. EAP-GPSK
3. Password-based method
4. Additional Item - EAP extensions
--------------------------------
RFC 2716bis - Bernard Aboba
--------------------------------
- Discussion of changes in version 08
- Open Issues mostly around certificate usage
+ Discussion on multiple names in certificate
Joe Salowey: what if there is more than one subjectAltName?
Tim Polk: states that we need to define the same context and rules.
Stefan Santesson: having more names in a cert is not a problem so long
as matching the name requirement is okay in general.
Tim: retorts that it can get tricky as it depends on where the name
"sought" is in the appropriate place.
Sam Hartman: trying to authorize access; all names provided in a cert
should be valid, so if any of those names match an authorizable name,
then access should be granted.
Tim: questions whether there would be an issue if there's a
distinguished name versus an RFC2716 name...
Sam and Tim: agree that as long as there is a searchable name, it should
be "good enough".
Bernard Aboba: comments AAA server should try to see for the name to
match in any and all the fields.
Hannes Tschofenig: comments it may just be an implementation issue by
the EAP server. Doesn't believe the checks need to be constrained and
precise as it would require full description of what is to be matched;
in this case it shouldn't matter.
+ Discussion on where to put MAC address in certificate raised by Ryan
Hurst on list
Bernard: comments that it arose from cert applicability of whether the
MAC address is in the subjectAltName and whether they should be colon
delimited or not.
Stefan: comments on 3 alternatives: (1) distinguished name; (2)
permanent serial number and (3) creating a new "other" field. Concern
of use of (2) and (3); suggests the use of an OID as part of the TLS
exchange.
+ Some consensus that the previous comment should not be part of this
spec.
Tim: agrees its out of scope for this group. All names should be
equally valid for the subject; they are for specific contexts.
+ back to multiple names in certificate
Joe: comments that subjectName may have multiple components.
Sam: mentions that all parts in the subjectName needs to be valid.
Tim: notes that especially for distinguished name, one should not
extract a portion it should be used as a whole.
Sam: mentions RFC 2818 describes exactly what Tim said not to do.
Bernard: summarizes it may not take long to resolve.
Paul Hoffman: comments on how prior descriptions still may not give us
interoperability. Servers tend to be lazy as they will scan for first
match and then fail (too easily).
Bernard: concurs and notes that we'd need to add more text.
Gregory Liebowitz: mentions that there should be a clear indication of
what name should be sought.
Hannes: mentions that IPSec has experience on this, 802.16 also has this
application. We should find out where the MAC address validation
occurs, if it is terminated by the EAP server, AAA server or otherwise.
Vidya Narayanan: comments TLS cipher suites not supported by the draft,
questions which ones are.
Several respond that there are quite a few that are documented as SHOULD
and SHALLs to enumerate the supported ones.
Bernard: mentions behavior of 2716 requires that request for cert is
still be made.
Sam: mentions that this is last call issues and to be cognizant of this
state so that we do not open up more new issues.
Bernard: states that we should look at text and see if there's anything
wrong. If there's nothing broken, then we can open it to a wider group
to get more eyes that have deeper certificate expertise to help review.
--------------------------------
EAP-GPSK - Hannes Tschofenig
--------------------------------
Current status and mention of reviewers.
- discussion of cipher suites and KDFs
- 2 current cipher suites: AES-CBC-128, NULL
- suggested change #1 CBC to CTR in ciphersuite #1
- suggested change #2 KDF use MAC-based vs. hash based KDF. The
commenter mentions that the change is not aligned with
http://tools.ietf.org/html/draft-dang-nistkdf-01
+ KDF discussion
Tim (with NIST "hat"): tries to clarify without having looked at this
document. NIST has a standard for keys derived from key establishment
(DH, MQV)...they way NIST works, it looks at a standard to use one of
the approved methods. There's nothing against using MAC's in KDFs by
NIST, previous guidance may have been misled on the belief that key
establishment was based on DH.
Charles Clancy: comments there were other suggestions but HASH vs. MAC
requires a new cryptographic function in the draft. Sam: argues that
there's no theoretical basis for why hashes are good for KDFs.
Tim: apologizes that NIST's SP856 can be confusing, he hopes to do a
presentation in Chicago to help clarify. Suspects the suggested
reordering may be warranted but change from MAC to HASH is not a
requirement.
Lakshminath Dondeti: comments that he'd like to see the draft before
commenting.
Sam: mentions that if a MAC constructions meets the desired properties,
that should be fine...unless you want to do something different and its
aptly justified it could also be accepted.
Lakshminath: comments to the contradicting opinions on hash vs. mac
constructions. From the current feedback, perception is that hash may
be stronger.
Hannes: comments that the draft will revert back to the MAC
construction.
Tim: mentions there is sensitivity to ordering and unambiguous ordering.
But this group is not in the space of SP856 so that document should not
have an impact on this body of work.
+ CTR vs. CBC
+ Hannes: brings back suggestion to change CBC to CTR mode.
Lakshminath: as one who suggested change, notes that it is not such a
big deal; but mentions that CBC mode requires implementation of both
encrypt and decrypt.
Hannes and Joe: mention that performance is not an issue.
Hannes: also mentions that code size is also not an issue as the code
bloat is not that large. Document explicitly notes that other
ciphersuites may be used.
Joe: notes there's no strong compelling reason to change
Sam: notes the group has to have consensus to change which is not
apparent
--------------------------------
Password based method
design team update
Madjid Nakhjiri
--------------------------------
+ Discussion of requirements
+ Open issues on requirements to discuss:
- Should we require password/pin change
- Other password based protocols (CHAP, MSCHAP, etc)
- Cryptographic binding of password exchange keys to keys of the
protection layer
- extension mechanism (data exchanges inside tunnel)
- transport of channel binding data
- protected result indication
- OCSP for cert-based "server authentication"
+ Leaning direction: towards Use of TLS
- presentation of how TLS is used
- data format alternatives discussed: XDR (RFC1832), AVP,
ASN.1....leaning towards AVPs
+ Discussion of Remaining Open issues:
+ new EAP method type: do we use one method type for passwords only?
Sam: cautions multi-layer negotiation as being a potential issue
+ Do we need messaging framework or just TLVs?
Sam: comments on crypto binding as being a requirement that
authentication at one layer be tied to authentication at another layer.
Like using the TLS finished message. This is as an alternative to
mixing key derivation but notes that crypto binding is a requirement.
Hao Zhou: mentions that using the TLS finished message signing may
require extensions to this.
Sam: mentions that we could sign the TLS finished message
Hao: mentions that we may not get a key from the password method
Sam: agrees that if we use the key from TLS that is another way to get
the crypto binding.
Hannes: mentions the crypto binding discussion came from the tunneling;
the best work showed that crypto binding is a requirement. If a
password is done on top of the EAP exchange, it wasn't clear that we
needed the crypto binding....still not sure on how to handle that case.
Hao: responds to Sam that the TLS tunnel is used to generate the EMSK
and MSK since its not guaranteed that a key is generated from the
password exchange.
Joe: mentions other issues with other password based protocols, where
some methods require the passing of username and passwords during the
exchange.
Hao: mentions to adopt a consistent crypto binding as there are
different password exchanges
+ Joe: asks whether we want to adopt other schemes than just plaintext
password, asks the general group if there is use to adopt something
other than plaintext password.
Hao: mentions that some client implementations only obtain the hash of
the password.
Bernard: you can always ask the user
Joe: Hao are you referring to the case where single sign on or some
other mechanism restricts access to password
Hao: yes
Joe: mentions there's not much excitement in adopting more than
plaintext but discussion to be continued on the thread.
Lakshminath: asks how this work would be different than PAP?
Joe: mentions it will not be any more different than TTLS, PEAP or
EAP-FAST but wants to make sure we do not support everything under the
sun. Keep the model simple.
Lakshminath: asks on EAP-TLS and discussions on how to use EAP with TLS.
Hannes: mentions that it is not new, it is new in the sense that one
author dropped from the original draft.
Sam: mentions that EAP has limited applicability.
Hannes: comments EAP applicability in TLS has also been rationale in
IKEv2
Sam: mentions there are different mechanisms for doing authentication;
doesn't want groups adopting frameworks based on methods supported.
Unless all frameworks are made to work together, he will make strict
ruling on applicability. But it is outside of scope to this group.
Bernard: comments that customers are tired of this and wants to
standardize on a single one and not to create more tunneled EAP
methods.
- Joe: returns to open issues and discussion of password/pin change:
Sam: believes it is very hard to achieve
Paul: email did this (POP) and no-one used it
Hao: believes we need to address it, if we don't, a new method will be
created to address it
Paul: iterates that we need it though is not convinced that we need to
spend a lot of time to get it "right"
Jeff Hutzelman: mentions a requirement for extension as a pro and
suggest that at a minimum, defer the password change mechanism until we
get to the extensibility. As the extensibility should allow us to do
password change in the future.
Hao: speaks as an implementer to getting many customer requirements to
support OTP and password change.
Hannes: asks if there is such a mechanism documented.
Sam: mentions there isn't one and this environment may be different than
an email environment. Today, with EAP, it may not be feasible to get
anywhere until the password is changed.
Paul: agree
Joe: closes that there is agreement that we need to support password
change...we may need to go further
Paul: mentions that this (password change) may be a good test of
extensibility
Joe summarizes:
+ crypto binding may be taken care of thru the use of the EAP TLS tunnel
for key generation. More discussion to continue on the email thread.
+ extension mechanism is a requirement as it will be used as a means to
address other requirements such as password change.
+ transport of channel binding data: may be another use for an extension
+ requiring protection of the result indication
Sam: You need to explain how you are going to meet draft housley AAA
requirements
- Discussion of the results being reliable
Jefferey: asks if the EAP fails, how do we authenticate the result
indication? Joe agrees it is a hard problem, but could authenticate
the other failures like bad password or other conditions within the
tunnel. More people think its good and no one was against implementing
this.
Sam: asks to look at the Housley requirement if we choose not to do
this.
- OCSP for cert-based "server authentication"
Sam: comments that this may be not enough as it doesn't give you status
of intermediate, nor anything else that could be done to remedy this
without touching TLS.
Charlie: mentions that SCVP could help.
Sam: doesn't quite agree as TLS would have to be modified to do SCVP
within TLS....though it could be done within the tunnel (as a blob).
But the catch is that SCVP may not be widely implemented to force this
be implemented by this group.
Joe: asks whether OCSP should be mandatory?
Jeff: comments that question is not well formed.
Joe: clarifies that this would require OCSP extensions to be mandatory
to implement.
Jeff: mentions that requirement imposes a deployment requirement on the
protocol
Joe's: concern is more on implementation that if its not supported, then
there is no means to enable vs. disable this feature.
Stefan: notes that it is different to say support (enforce) OCSP versus
require to implement
Joe: means require to implement OCSP
Tim and Sam: agree that there has to be a strategy for certificate
checking including revocation; given the proposals there must be one
mandatory to implement
Joe: wants to continue discussion
Yoshihiro Obha: mentions that his presentation discusses channel binding
Joe: mentions target is to have draft out by next meeting
(this concludes working group Discussion of Working group items)
Sam: asks if there are any Hokey chairs and caucus with them to
determine that Yoshi's presentation is out of scope for this group.
Yoshiro: retorts that his presentation is on an EAP method
Glen Zorn (HOKEY Co-Chair): Does not have an objection to the
presentation
--------------------------------
EAP-EXT - Yoshihiro Obha
--------------------------------
* Proposal to use EMSK usage
* Channel binding issues: two approaches and lack of support
* EAP notes: no version, lack of backward compatibility
* Design discussion on how to extend EAP to allow for:
- sequencing in a single EAP conversation
- sequencing multiple EAP conversations
- allow for channel binding
* Proposes EAP-EXT: a tunneled method with protected capabilities
exchange to enable sequencing inside the tunnel and allow for backwards
compatibility.
- proposal includes TLV for accomplishing Key (EMSK) derivation,
channel binding and crypto binding but using its own construction.
- proposal was also presented in HOKEY meeting
Hao: questions how this is different than TTLS, PEAPv2, EAP-FAST
Yoshi: mentions capability negotiation and being able to do "other"
things.
Glen: likes the capability negotiation and would like to see it
expanded, though there's not much applicability in HOKEY it is work
looking at other uses
Alan: going on capability discussion there's a lot of discussion in
RADEXT
Joe: mentions there's no space to take this up as a work item.
Jeff: What do you recommend the author?
Sam: clarifies that this working group has a fixed charter and this is
not one of them; revising core EAP is not in this group's charter.
Jeff: concludes that there's no current home
Sam: suggests a BOF
Joe: says need to articulate the problem we're trying to solve in the
BOF
Sam: mentions it could be an individual submission but is leery of this
given that it is more intrusive to the EAP protocol
_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
