[FW: Re: [eap] Please review -- IETF Last Call ondraft-barany-eap-gee-04.txt]
2006-12-26 12:02:39
----- Forwarded message from Yoshihiro Ohba
<yohba(_at_)tari(_dot_)toshiba(_dot_)com> -----
From: Yoshihiro Ohba <yohba(_at_)tari(_dot_)toshiba(_dot_)com>
Subject: Re: [eap] Please review -- IETF Last Call ondraft-barany-eap-gee-04.txt
To: Bernard Aboba <bernard_aboba(_at_)hotmail(_dot_)com>
Cc: yohba(_at_)tari(_dot_)toshiba(_dot_)com, eap(_at_)frascone(_dot_)com
User-Agent: Mutt/1.5.13 (2006-08-11)
X-UIDL: 1)f!!M]4!!1ci"!DF&!!
If we agree that EAP GEE is part of a 3GPP2 EAP lower layer, wouldn't
it be more appropriate to standarize EAP GEE within 3GPP2, with
utilizing this EAP WG review as peer review as we have done for IEEE
802.16e and 802.1aa?
Also, according to the IANA considerations section, IETF Review will
be needed for allocating new values for Version, TID and RFL fields.
If this is standardized within 3GPP2, there will be no need to come to
IETF to ask new values for these fields.
Yoshihiro Ohba
On Sat, Dec 23, 2006 at 05:37:35PM -0800, Bernard Aboba wrote:
I agree with Yoshi that EAP GEE is really part of a 3GPP2 EAP lower layer.
The problem with a generic GEE shim is that it requires modification to
existing EAP lower layers. No existing EAP lower layer has been defined to
handle the GEE header, and if it were to be inserted, it will be
interpreted as the EAP code field by existing EAP peers, authenticators and
servers:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Version|TID|RFL|
+-+-+-+-+-+-+-+-+
The version field = 0, and the TID field = 00/01. The RFL bits are = 10
or 00.
Given this, the GEE header would be interpreted as one of the following
code values:
0 (TID = 0, RFL = 00) (Reserved in RFC 3748)
2 (TID = 0, RFL = 10) (Response, in RFC 3748)
4 (TID=01, RFL = 00) (Failure, defined in RFC 3748).
6 (TID=01, RFL=10) Not defined in RFC 3748.
While the document states that a conforming EAP peer or authenticator is to
strip off the GEE header, it is not made clear how use of EAP GEE is
negotiated within EAP so that an EAP peer or authenticator can tell if GEE
is being used or not. Presumably this negotiation is to occur in the link
layer, but since no existing EAP link layers support such a negotiation,
EAP GEE appears incompatible with existing EAP lower layers other than
perhaps 3GPP2.
A generic shim that only works with a single link layer is somewhat of a
contradiction in terms.
The document makes much more sense if EAP GEE s viewed as part of a
definition of a 3GPP2 lower layer for EAP. Presumably 3GPP2 has defined a
mechanism by which the use of GEE can be negotiated, and once this is done,
3GPP2 peers and authenticators can encapsulate and decapsulate EAP packets
within a 3GPP2 lower layer including the GEE header.
However, if the document is seen as defining an EAP lower layer then there
are some missing peices, such as a demonstration that the lower layer meets
the requirement for transport of EAP packets, described in RFC 3748,
Section 3.1.
From: Yoshihiro Ohba <yohba(_at_)tari(_dot_)toshiba(_dot_)com>
To: Jari Arkko <jari(_dot_)arkko(_at_)piuha(_dot_)net>
CC: AC Mahendran <mahendra(_at_)qualcomm(_dot_)com>,
eap(_at_)frascone(_dot_)com
Subject: Re: [eap] Please review -- IETF Last Call
ondraft-barany-eap-gee-04.txt
Date: Fri, 22 Dec 2006 21:49:40 -0500
Here is my review:
In Section 3, strictly speaking, "Lower Layer" in Figures 2 and 3 is
not the lower layer as defined in Section 2.2 of RFC 3748, because
this "Lower Layer" carries GEE frames, not directly carry EAP frames.
Instead, either "GEE layer" or the combination of "GEE layer" and
"Lower Layer" should be the lower layer in terms of RFC 3748. This
should be clarified in the document to avoid any confusion.
In Section 5.3, I don't understand what exact problem the
non-cryptographic identifier binding is trying to solve. In fact,
this would require static dependency between the two identities used
for different authentication types, which is useless if service
provider and access provider are totally independent of each other.
Isn't it better not to talk about non-cryptographic identifier binding
at all?
Best Regards and Happy Holidays!
Yoshihiro Ohba
On Fri, Dec 22, 2006 at 02:33:43PM +0200, Jari Arkko wrote:
Hi,
I have received a request from the authors of this draft
to publish it as an experimental RFC. The document
specifies a method by which the 3GPP2 networks
can run two EAP conversations between a peer and
an authenticator.
It is being taken for IETF review in order to get feedback
from the IETF EAP experts on applying EAP in this
particular environment and in this way. It is not being
taken on as a generic solution to multiple authentication
in other environments than 3GPP2 networks.
I have reviewed this specification, but additional review
would be very welcome. In particular, please look into
possible security issues, impacts to EAP state machine,
EAP backend processing, etc.
The IESG has received a request from an individual submitter to
consider
the following document:
- '3GPP2 Generic EAP Encapsulation (GEE) Protocol '
<draft-barany-eap-gee-04.txt> as an Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to
the
ietf(_at_)ietf(_dot_)org mailing lists by 2007-01-19. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org instead. In either
case, please
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-barany-eap-gee-04.txt
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.frascone.com/pipermail/eap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.frascone.com/pipermail/eap
----- End forwarded message -----
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [FW: Re: [eap] Please review -- IETF Last Call ondraft-barany-eap-gee-04.txt],
Yoshihiro Ohba <=
|
|
|