> -----Original Message----- > From: Yoshihiro Ohba [mailto:[email protected]] > Sent: Monday, January 21, 2013 4:20 PM > To: Jim Schaad > Cc: [email protected] > Subject: Re: [abfab] Eap Applicability: Re-authentication > > Just to clarify that my comment was about "Retransmission Text for EAP > applicability" that is discussed in another thread. > > Please see my comment below. > > (2013/01/22 5:08), Jim Schaad wrote: > > 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. > > This simply means that application is part of EAP lower-layer, as oppose to > your previous statement you made in Nov 19, 2012: "However this does not > change my opinion that application protocol that is using GSS-API is not part > of the EAP lower-level."
No - I think the EAP lower-level is part of the application. Jim > > We need to first mention in EAP applicability is that a GSS-EAP application is > part of EAP lower-layer and needs to follow the EAP lower-layer > requirements. > > Then, we can further have detailed text on retransmission and message > discarding behavior as suggested by Sam, but I still suggest replacing > "application" with "lower-layer" in there, because technically there is nothing > specific to applications. > > Regards, > Yoshihiro Ohba > > > 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
