I don't think we have suggested that GSS-EAP is the "lower -layer", nor is
it the "application".    GSS-EAP states that the "application" is
responsible for doing in order delivery for during the initialization.

Let us consider the case of SSH using GSS-EAP for authentication.  One could
run SSH over UDP, TCP, DTLS/UDP, TLS/TCP.  In these cases SSH, the
"application", would need to have code to deal with in order delivery with
UDP, however TCP, DTLS/UDP and TLS/TCP themselves all satisfy the in order
requirements.  

Many of the things that we are talking about however are based on SSH, how
does it deal with re-authentication being one of those things.  One does not
expect TCP to know anything about the process of asking for and dealing with
re-authentication, but SSH is the proper layer to talk about this.  

In this working group we are focused on applications not lower-layers.  We
need to tell applications what they need to do (one of which is to figure
out how to get in order delivery somehow) and not confuse the issue between
what is an application as oppose to making them think about lower-layers
instead (which are maybe different).

Jim


> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Yoshihiro Ohba
> Sent: Sunday, January 20, 2013 4:54 PM
> To: [email protected]
> Subject: Re: [abfab] Eap Applicability: Re-authentication
> 
> Sam,
> 
> I suggested to replace "application" with "lower-layer" in your text and
Jim
> was against my suggestion.  To continue the discussion, I asked a question
> whether GSS EAP token carries a sequence number but it was not
> answered yet.   My point is that GSS-EAP solely cannot be considered as
> an EAP lower layer unless GSS-EAP itself provides in-order delivery of EAP
> message.  For the same reason, IEEE 802.1X can be considered as an EAP
> lower-layer only if 802.1X frame is carried over Ethernet or alike media
that
> provides in-order delivery of EAP message.
> 
> Yoshihiro Ohba
> 
> 
> (2013/01/19 4:45), Sam Hartman wrote:
> >
> > So, I was wondering what's up with the EAP applicability draft and why
> > we've not made more progress. I'm kind of glad I didn't ask the
> > question but instead went back to my notes, because I discovered that
> > I dropped the ball.
> > I already put forward some text on retransmission; Jim and Yoshi
> > provided edits and they were happy with that.
> > I don't think Alper was happy with the result; the chairs and editors
> > of EAP applicability will need to resolve who is in the rough there.
> >
> > However, I also promised text on re-authentication.
> >
> > Proposed text:
> >
> > EAP lower layers MAY provide a mechanism for re-authentication to
> > happen within an existing session [RFC 3748]. Diameter standardizes a
> > mechanism fro an AAA server to request re-authentication [RFC 4005].
> > Re-authentication permits security associations to be updated without
> > establishing a new session. For network access, this can be important
> > because interrupting network access can disrupt connections and media.
> >
> > Some applications might not need re-authentication support. For
> > example if sessions are relatively short-lived or if sessions can be
> > replaced without significant disruption, re-authentication might not
> > provide value. Protocols like HypertextTransport Protocol (HTTP) and
> > Simple Mail Transport Protocol (SMTP) are examples of protocols where
> > establishing a new connection to update security associations is
> > likely to be sufficient.
> >
> > Re-authentication is likely to be valuable if sessions or connections
> > are long-lived or if there is a significant cost to disrupting them.
> >
> > Another factor may make re-authentication important. Some protocols
> > only permit one side of a connection (for example the client) to
> > establish a new connection. If another party in the protocol MAY need
> > the security association refreshed then re-authentication can provide
> > a mechanism to do so.
> >
> > Lower layers SHOULD describe whether re-authentication is provided and
> > which parties can initiate it.
> > _______________________________________________
> > abfab mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/abfab
> >
> 
> 
> _______________________________________________
> abfab mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/abfab

_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab

Reply via email to