Yoshihiro,
> 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?
>   
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

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

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

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

On Wed, Dec 27, 2006 at 03:37:03PM +0200, Jari Arkko wrote:
> Yoshihiro,
> > 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?
> >   
> 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
> 
> 
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

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

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:
>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.

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
>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.

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


>Regards,
>Yoshihiro Ohba
>
>On Wed, Dec 27, 2006 at 03:37:03PM +0200, Jari Arkko
wrote:
> > Yoshihiro,
> > > 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?
> > >
> > 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
> >
> >
>________________________________________________________
_________
>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