Subject: [eap] draft-arkko-eap-service-identity-auth-04

From: badra <[email-masked]>
Date: Sun, 11 Dec 2005 15:36:00 +0100

Dear Jari & Pasi,

Section 5.1 of draft-arkko-eap-service-identity-auth-04 said:

   "This works the same way when resuming session.  Note that the
   parameters can change from the initial authentication."

And section 2.3 of RFC 3546 said:

   "If the resumption request is denied, then a new set of extensions
   will be negotiated as normal.  If, on the other hand, the older
   session is resumed, then the server MUST ignore extensions appearing
   in the client hello, and send a server hello containing no
   extensions; in this case the extension functionality negotiated
   during the original session initiation is applied to the resumed
   session."

Extensions introduced in 3546 will not be able to convey different 
parameter objects, unless a full TLS session takes place. Or the 
extension introduced in the draft allows that, in which more 
clarifications may be added to its definition.

BTW, why we don't use AVPs or TLVs to carry parameter objects instead of 
using a new TLS extension.

Best regards,
Badra

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 13 Dec 2005 14:34:50 +0200

badra wrote:

> BTW, why we don't use AVPs or TLVs to carry parameter objects instead 
> of using a new TLS extension.

Good questions. In general, the TLS support in the draft is somewhat
suspect in any case, because getting it done would indeed require
an extension in the standards track, if I recall the TLS IANA rules
correctly.

What AVPs or TLVs were you thinking of? I was not aware that there
was any other place in TLS than the extensions to put additional
new information, but is there? And EAP-TLS format is already fixed
to be TLS record protocol messages, nothing else.

--Jari

---

From: Mohamad Badra <[email-masked]>
Date: Tue, 13 Dec 2005 14:02:10 +0100

> to be TLS record protocol messages, nothing else. 

I was thinking of Tunneled methods. Since we are going to have a new 
version of EAP-TLS, I think it could be possible to define a framwork 
allowing, among others, parameter object exchange; between TLS Finished 
and EAP-Success.

Best regards,
Badra

---

From: Jari Arkko <[email-masked]>
Date: Tue, 13 Dec 2005 15:34:10 +0200

> allowing, among others, parameter object exchange; between TLS 
> Finished and EAP-Success.
>
Sure. We already had (and may still have - I don't remember) an
extension for PEAP that did this. But for pure EAP-TLS its harder.
Note that EMU BoF/WG has proposed work item that deals with
EAP-TLS extensions to support all RFC 4017 features, including
channel bindings. So it could be handled there. But it won't necessarily
be EAP-TLS as we know it, likely a new type code is needed.

--Jari