| draft-arkko-eap-service-identity-auth-04 | <– Date –> <– Thread –> |
|
From: badra (badra |
|
| Date: Sun, 11 Dec 2005 06:36:11 -0800 (PST) | |
Dear Jari & Pasi,
Section 5.1 of draft-arkko-eap-service-identity-auth-04 said:
And section 2.3 of RFC 3546 said:
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.
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
-
FW: I-D ACTION:draft-arkko-eap-service-identity-auth-02.txt Jari Arkko, May 4 2005
- draft-arkko-eap-service-identity-auth-04 badra, December 11 2005
-
Re: draft-arkko-eap-service-identity-auth-04 Jari Arkko, December 13 2005
- Re: draft-arkko-eap-service-identity-auth-04 Mohamad Badra, December 13 2005
- Re: draft-arkko-eap-service-identity-auth-04 Jari Arkko, December 13 2005
Results generated by Tiger Technologies using MHonArc.