Sam, Here are some initial inline comments
Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Sam Hartman > Sent: Friday, January 18, 2013 11:45 AM > To: [email protected] > Subject: [abfab] Eap Applicability: Re-authentication > > > > 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 [JLS] I have problems with talking about the re-authentication happening within an existing session. EAP does not have sessions so you don't re-authenticate inside of an EAP session. You need to clarify what session you are talking about. You should also potentially talk about what a session means, are we talking about cryptographic sessions, application sessions, infrastructure session? s/fro/for/ > 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 s/establishing/re-establishing/ > 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 s/one side of a connection/one party in the protocol/ > connection. If another party in the protocol MAY need the security [JLS] Suggest killing the MAY. There is not real protocol requirement on this statement - it could never be testable. s/ in the protocol MAY need the/in the protocol needs the/ > 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. The EAP applicability statement document should make some type of definition for what a lower layer is. Copying the definition from section 2.2 in 3748 is fine with me. [JLS] The lower lay needs to 1) identify which party(s) can initiate the re-authentication and 2) how to send an appropriate protocol message to that party(s) to request that it initiate re-authentication. > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
