On 16 Jan 2012, at 16:39 , Alan DeKok wrote: > Alejandro Perez Mendez wrote: >> We also thought that a new flag "T" could indicate the attribute is >> truncated across several packets. > > That sounds good.
Apart that I think it would make the mechanisms simpler to deal with, I must say I like Dave's symmetry argument for the "T" flag. > - the first Access-Accept must contain Service-Type = Authorize-Only > *or* a new Servicer-Type = Additional-Authorization > > This means that the user is not given network access when the > implementation does not support the new method. In the same spirit of keeping clarity, I'd say that Additional-Authorization would be more correct choice, unless adding a new Service-Type would somehow complicate adoption... > - the first Access-Accept must contain a State attribute > for is already required for use of Authorize-Only > > - additional authorization attributes are received via a series > of Access-Request / Access-Challenge > > - each Access-Request MUST contain Service-Type = Authorize-Only > and a State Or, respectively, Additional-Authorization, isn't it? > - the State MUST change for each Access-Challenge response > I can get into that later I can imagine this is with the intention of guaranteeing order and avoiding (or alleviating) MITM attacks, right? Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D e-mail: [email protected] Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
