Subject: [FW: Re: [eap] Please review -- IETF Last Call ondraft-barany-eap-gee-04.txt]

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 26 Dec 2006 13:57:50 -0500

----- Forwarded message from Yoshihiro Ohba <[email-masked]> -----

From: Yoshihiro Ohba <[email-masked]>
Subject: Re: [eap] Please review -- IETF Last Call ondraft-barany-eap-gee-04.txt
To: Bernard Aboba <[email-masked]>
Cc: [email-masked], [email-masked]
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 <[email-masked]>
> >To: Jari Arkko <[email-masked]>
> >CC: AC Mahendran <[email-masked]>, [email-masked]
> >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
> >> > [email-masked] mailing lists by 2007-01-19. Exceptionally,
> >> > comments may be sent to [email-masked] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Jari Arkko <[email-masked]>
Date: Wed, 27 Dec 2006 15:37:03 +0200

Yoshihiro,
> utilizing this EAP WG review as peer review as we have done for IEEE
I fully agree with Bernard that the work needs to be tied
to the specific lower layer and specific use of EAP in that.
If this was a general mechanism for all EAP uses, it
would require a different IETF process, consideration
of a broad set of requirements from different
usage scenarios, etc. As Bernard points out, merely
turning this on in other link layers would break them.
(We need to work on what the details are for
the sufficient tie-in to the link layer is, however.
The current document is already tied to 3GPP2 link
layer, though based on Bernard's review, in an
inadequate manner.)

However, I believe that submitting specifications
developed outside the IETF as non-standard RFCs
is sometimes useful, as long as the situation
and status is clearly indicated. Typical cases where
such publication can be useful are "Using IETF
technology <X> in environment <Y>" documents
where it is felt that significant IETF review is
warranted (such as in this case), and where
the community might benefit from availability
of an RFC.

Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 29 Dec 2006 10:49:14 -0500

Hi Jari,

I do think that general security analysis on running multiple EAP
conversations between peer and authenticator is quite beneficial for
designers of EAP lower layers.

I agree that it makes sense for IETF to have an RFC on usage of IETF
technology <X> in environment <Y> as long as environment <Y> is
defined by other SDO.  However, the draft is also defining part of
environment <Y> where Y=3GPP2 and GEE is part of 3GPP2.  Even if this
"experiment" succeeds, I don't think IETF can recommend this specific
GEE format to other lower layers, because there are multiple different
ways of transporting EAP messages, depending on the characteristics of
each lower layer.  How to support multiple EAP conversations between
peer and authenticator, including encoding format, is just part of EAP
transport design (except general security analysis as I mentioned
above).

Having said that, I still think that ideally 3GPP2 should take the
ownership of the GEE format and its processing rule within their
specification unless there is a particular situation that prevents
3GPP2 from doing that.

Regards,
Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 29 Dec 2006 13:12:03 -0800

I guess we went back and forth on this topic a few times already.  I 
will state my opinion one more time and let the IESG decide.  Please 
see inline:

At 07:49 AM 12/29/2006, Yoshihiro Ohba wrote:
>each lower layer.

All I am saying is we document how multiple authentications can be 
done in the 3GPP2 context using GEE and go from there.  Like Jari 
said, we have done that before.  One example that I can put forth 
here is the 3GPP EAP-AKA design (RFC 4187).  Turns out, 3GPP2 also 
uses AKA now.

Now, I don't want to get into speculation on what other standards 
organizations may use GEE.  The point is they can if they want to.

>How to support multiple EAP conversations between

3GPP2 wrote an LS to the IETF expressing their interest in this work 
being done in the IETF.  Next, I don't see the downside of the work 
being done at the IETF.  As a result of the IETF process, the work 
got good reviews from a number of people.  There are some technical 
gaps that I already agreed to filling.  I think that is the best path 
forward instead of endless discussion on 'do it here vs. do it there.'

thanks,
Lakshminath