Please review -- IETF Last Call on draft-barany-eap-gee-04.txt

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
> ietfietf.org mailing lists by 2007-01-19. Exceptionally,
> comments may be sent to iesgietf.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

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
> > ietfietf.org mailing lists by 2007-01-19.
Exceptionally,
> > comments may be sent to iesgietf.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

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 <yohbatari.toshiba.com>
>To: Jari Arkko <jari.arkkopiuha.net>
>CC: AC Mahendran <mahendraqualcomm.com>, eapfrascone.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
> > > ietfietf.org mailing lists by 2007-01-19.
Exceptionally,
> > > comments may be sent to iesgietf.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


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

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

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 <yohbatari.toshiba.com>
> >To: Jari Arkko <jari.arkkopiuha.net>
> >CC: AC Mahendran <mahendraqualcomm.com>, eapfrascone.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
> >> > ietfietf.org mailing lists by 2007-01-19.
Exceptionally,
> >> > comments may be sent to iesgietf.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
> 
> 
> 
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

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

>From what I understand, the 3GPP2 lower layer definition
is still in 
progress, but there has been no liaison request from 3GPP2
to IETF to review 
it.  From the document, I wasn't clear to me if GEE is
included in the 3GPP2 
lower layer definition.  Presumably it would have to be in
order to work 
with 3GPP2.

It also seems a bit awkward for me for IANA to administer
parameters within 
the 3GPP2 lower layer.  This would be like IETF maintaining
a registry for 
IEEE 802.1X,  IEEE 802.11i or IEEE 802.16e.  What happens if
3GPP2 decides 
to allocate a parameter but there is an issue which holds
this up?

I would agree that the best process would probably be for
3GPP2 to make the 
lower layer specification available and request IETF review.
Portions could 
be published as an Informational RFC for the benefit of the 
community, but 
it would be clear that ownership resided in 3GPP2.

Yoshi Obha said:

>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


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

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