headers
Joseph Salowey (jsalowey | 5 Mar 2007 17:59
Picon
Favicon

Agenda for EMU at IETF 68

Please let me know if you have any additions or corrections:

PRELIMINARIES (10 minutes)

Blue sheets
Minute takers
Agenda bash
Document Status

ITEMS IN EMU WG LAST CALL (40 minutes)

Topic: RFC2716bis - EAP-TLS
Presenter: TBD (Bernard Aboba)
Time: 20 minutes
URL:
http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-08.txt

Topic: EAP-GPSK
Presenter: TBD (Hannes Tschofenig, Charles Clancy)
Time: 20 minutes
URL: http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-03.txt

PASSWORD BASED METHOD (50 min)

Topic: Password Based Method Requirements
Presenter: TBD (password based design team)
Time: 20 minutes
URL: TBD(Summary mail to be sent to list)

Topic: Password based method approach discussion
(Continue reading)

Permalink | Reply | 0 comments |
headers
Narayanan, Vidya | 6 Mar 2007 03:03

WGLC: Review of draft-ietf-emu-eap-gpsk-03

All,
I reviewed the document and unfortunately, don't feel it is ready for
publication yet. I will only get into the meta issues here - nits can be
addressed later. 

Major Comments: 
---------------
1. Overall, I'm looking for a compelling reason to have another EAP
method and I found none in the document. For instance, all the design
goals listed seem to be satisfied by EAP-TLS-PSK (inclusion of protected
payloads can be done as an extension to TLS as well). And, given that
EAP-TLS-PSK is an incremental change to EAP-TLS, it would be much more
compelling to use EAP-TLS-PSK than EAP-GPSK. So, is there at least one
design goal of GPSK that cannot be met by other methods? 

2. Are the EAP and GPSK headers integrity protected? The SEC_SK
construction in various places does not seem to imply so - I don't think
that is the intention, as those headers must be integrity protected. 

3. The message, GPSK-4, seems to be there since an EAP Response is
needed after an EAP Request. However, this seems to lead to a couple of
things - a) a potentially empty message sent with a MAC (what is the MAC
calculated on?), b) having the client to reflect back a failure message
in the event of a failure. I think if the EAP and GPSK headers are
protected with a MAC, we should be okay with this. 

4. Is there a reference to GKDF? I'm wondering why we are advocating the
use of hash functions as KDFs instead of HMACs. I have more questions on
the derivation of MK and other keys, but, I'll wait for the
clarification on GKDF before I ask those.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Lakshminath Dondeti | 6 Mar 2007 03:15

Re: WG Last Call: draft-ietf-emu-eap-gpsk-03.txt

Review summary:  Thanks to Charles and Hannes for their hard work on 
this draft, but I think it needs another revision before going to AD 
Review and IETF LC.

I have been part of the design team, and so I am responsible for some of 
the following issues being still pending at this stage.  I may have also 
brought up some of these issues in the past and the consensus determined 
the current contents; if so, please refresh my memory :).  Thanks.

1. The definition of KS is inconsistent.  Figure 3 shows that SHA-1 is 
the hash function and the key size is 16.  The definition in Section 2 
says that KS is the key size of the selected cipher suite.  Well that is 
not precise enough as it turns with the 128-bit key cipher and 160-bit 
key hash function being used.

2.  Nit: There may be 1 or more occurrences of the word 
PD_Payload_Blocks; my understanding is that there is only one block and 
there could be 1 or more PD_Payloads.

3. Nits: The relative order of definitions of PK, SK and MK might be 
changed so there is no forward referencing.  I recall complaining that 
the names PK and SK are not intuitive.  Same goes for SEC_X(Y) by the 
way.  I also realized I don't quite like us renaming the EAP peer as the 
"client."

4. Borderline Nit: The description of the messages at the beginning of 
Page 9 can be tighter.  Some examples:

* The MAC computation needs to be more clearly specified.  The current 
text says the MAC is over all "these" parameters and "session
(Continue reading)

Permalink | Reply | 2 comments |
headers
Narayanan, Vidya | 6 Mar 2007 04:58

RFC4279 support in draft-simon-emu-rfc2716bis?

All,
I have a question on support for the TLS PSK ciphersuites in EAP-TLS.
Looking at the message flow in section 2.1.1, I don't see any reason why
the TLS PSK ciphersuites, as specified in RFC4279, cannot be used with
it, but, the optional TLS elements are not immediately clear from it and
hence, the question. 

Thanks,
Vidya
Permalink | Reply | 10 comments |
headers
Bernard Aboba | 6 Mar 2007 08:28
Picon
Favicon

RE: RFC4279 support in draft-simon-emu-rfc2716bis?

According to RFC 2716, a compliant EAP-TLS implementation must support 
certificates.  Since the resources required to support certificates is much 
larger than the resources required for TLS-PSK, a combined method would not 
be optimal for use within an embedded environment.  There would also be 
substantial costs to adding support for additional authentication methods to 
EAP-TLS.  For example, EAP-TLS certification and testing programs have been 
developed which focus solely on certificate ciphersuites; rewriting those 
test suites would be costly.

By developing EAP-TLS-PSK as a separate EAP method an implementation can 
solely implement TLS-PSK while remaining compliant.  This permits EAP 
TLS-PSK implementations to be optimized for embedded environments.  As a 
side benefit, this approach also eliminates multiple levels of negotiation, 
which had been raised as a potential problem.
Permalink | Reply | 4 comments |
headers
Narayanan, Vidya | 6 Mar 2007 20:51

RE: RFC4279 support in draft-simon-emu-rfc2716bis?

Hi Bernard,
Thanks much for the response. If we go down this path, are we then
saying that for every new ciphersuite that may be added to TLS, a
separate EAP method would need to be designed to support that in EAP?
Also, how is this different from TLS implementations having to support
the newer ciphersuites? 

I can understand the mandatory cert requirement in RFC2716, since at
that point of time, TLS did not have the PSK ciphersuites. But, now that
we are revising it, does it not make sense to support all the
ciphersuites supported in TLS? 

Also, could you please elaborate on the multiple negotiation problem?
Looking at the message flows in section 2.1 in
draft-otto-emu-eap-tls-psk-02 and section 2.1.1 in
draft-simon-emu-rfc2716bis-08, except for the certs portion, everything
else looks the same. 

Thanks,
Vidya

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba <at> hotmail.com] 
> Sent: Monday, March 05, 2007 11:29 PM
> To: Narayanan, Vidya; emu <at> ietf.org
> Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?
> 
> According to RFC 2716, a compliant EAP-TLS implementation 
> must support certificates.  Since the resources required to 
> support certificates is much larger than the resources
(Continue reading)

Permalink | Reply | 3 comments |
headers
Joseph Salowey (jsalowey | 6 Mar 2007 21:18
Picon
Favicon

RE: RFC4279 support in draft-simon-emu-rfc2716bis?


> -----Original Message-----
> From: Narayanan, Vidya [mailto:vidyan <at> qualcomm.com] 
> Sent: Tuesday, March 06, 2007 11:51 AM
> To: Bernard Aboba; emu <at> ietf.org
> Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?
> 
> Hi Bernard,
> Thanks much for the response. If we go down this path, are we 
> then saying that for every new ciphersuite that may be added 
> to TLS, a separate EAP method would need to be designed to 
> support that in EAP?
> Also, how is this different from TLS implementations having 
> to support the newer ciphersuites? 
> 

[Joe] We have a charter item for enhanced TLS which could support other
types of ciphersuites along with other features. 

> I can understand the mandatory cert requirement in RFC2716, 
> since at that point of time, TLS did not have the PSK 
> ciphersuites. But, now that we are revising it, does it not 
> make sense to support all the ciphersuites supported in TLS? 
> 
> Also, could you please elaborate on the multiple negotiation problem?
> Looking at the message flows in section 2.1 in
> draft-otto-emu-eap-tls-psk-02 and section 2.1.1 in 
> draft-simon-emu-rfc2716bis-08, except for the certs portion, 
> everything else looks the same. 
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Hannes Tschofenig | 7 Mar 2007 11:45
Picon

Re: RFC4279 support in draft-simon-emu-rfc2716bis?

We discussed this already several times and this lead me to work on a 
draft together with Thomas Otto:

http://tools.ietf.org/id/draft-otto-emu-eap-tls-psk-02.txt

Ciao
Hannes

Narayanan, Vidya wrote:
> All,
> I have a question on support for the TLS PSK ciphersuites in EAP-TLS.
> Looking at the message flow in section 2.1.1, I don't see any reason why
> the TLS PSK ciphersuites, as specified in RFC4279, cannot be used with
> it, but, the optional TLS elements are not immediately clear from it and
> hence, the question. 
>
> Thanks,
> Vidya
>
> _______________________________________________
> Emu mailing list
> Emu <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
>
Permalink | Reply | 4 comments |
headers
Hannes Tschofenig | 7 Mar 2007 11:56
Picon

Re: WGLC: Review of draft-ietf-emu-eap-gpsk-03

Hi Vidya,

just a quick comment.

Narayanan, Vidya wrote:
> All,
> I reviewed the document and unfortunately, don't feel it is ready for
> publication yet. I will only get into the meta issues here - nits can be
> addressed later. 
>
> Major Comments: 
> ---------------
> 1. Overall, I'm looking for a compelling reason to have another EAP
> method and I found none in the document. For instance, all the design
> goals listed seem to be satisfied by EAP-TLS-PSK (inclusion of protected
> payloads can be done as an extension to TLS as well). And, given that
> EAP-TLS-PSK is an incremental change to EAP-TLS, it would be much more
> compelling to use EAP-TLS-PSK than EAP-GPSK. So, is there at least one
> design goal of GPSK that cannot be met by other methods? 
>
>   

You must be kidding.

We worked on this several months within a design team. The design team 
concluded that a new EAP method is the right direction. Then, the result 
of the design team was confirmed by working group a long time ago.

Now, in WGLC you raise your voice although you and Lakshminath actively 
participate in the working group (with Lakshminath even being a design
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bernard Aboba | 7 Mar 2007 17:12
Picon
Favicon

Re: RFC4279 support in draft-simon-emu-rfc2716bis?

Hannes Tschofenig said:

>We discussed this already several times and this lead me to work on a draft 
>together with Thomas Otto:
>
>http://tools.ietf.org/id/draft-otto-emu-eap-tls-psk-02.txt

Which begs the question:  what is the WG doing with this draft?

>From where I sit, it seems quite likely that EAP-TLS-PSK, if completed, will 
be deployed.  When TLS 1.2 is done, this method could eventually benefit 
from KDF negotiation, and should meet the criteria for FIPS 140-2 
certification.  Given the TLS code base in embedded systems, it should not 
be hard to add support for EAP-TLS-PSK within embedded devices.

I my doubts about EAP-GPSK on several of these dimensions.
Permalink | Reply | 3 comments |

Gmane