I won't be there either, so here are my comments on Sam's slides: Slide 5: Please elaborate the pros and cons of re-auth. There's a reference to some apps replacing session easily. It'd be good to have a example of that for a better understanding.
Slide 6: "Application authorization lifetime". We need to expand on the meaning of that, or use a more precise terminology. I If this is about "authorizing the application client to use the given application protocol", then that authorization's lifetime is dictated by the MSK lifetime. It's the use of MSK or its derivative protecting the application protocol that proves to the server that the client is authorized. I.e., no key => nothing to prove authorization with. If you are talking about the "state created by the use of application protocol" which can exceed the lifetime of the MSK, that's fine. That's more like "application is authorized to create state that can outlive the MSK lifetime". On Nov 5, 2012, at 3:45 PM, Stefan Winter wrote: > Hi, > > since I won't be at the meeting, here are a few thoughts about Sam's > slides regarding the EAP Applicability draft, particularly about > > Authorization Lifetime, Slide 6 > > The original Applicability statement IMHO makes quite clear that > determining the Authorization Lifetime is not a good use of EAP. It > first creates a very short white-list of good uses (Network > *Authentication*, and with the revision Application *authentication*) > and then has a blanket statement blacklist: > > "Use of EAP for other purposes, [...], is NOT RECOMMENDED." > > One example is given, bulk data transport, but the statement is just as > valid for other examples like ", such as determining authorization > lifetime, " > > That statement has served well over the years to repel other uses of EAP > (and in fact seems to be so threatening that abfab found that change of > text is needed to get something new onto the whitelist). > > So answering the question brought up by Sam: I do not believe this needs > to be documented. The generic NOT RECOMMENDED statement covers this > adequately. > > For the other issues in the slide deck things are less clear; I'll be > interested in the outcomes of the discussion. > > Greetings, > > Stefan Winter > > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et > de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > > Tel: +352 424409 1 > Fax: +352 422473 > > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
