On Fri, 27 Jan 2023 at 13:30, Eliot Lear <l...@lear.ch> wrote: >> On 27.01.23 12:17, Heikki Vatiainen wrote: >> >> For example, an OTP system could do this: >> - Start authentication with username + static password; if ok then >> - Server prompts for the next method: Choose 1 for push to mobile app, >> 2 for telephone callback, 3 for emergency use pre-printed code. Leave >> password empty for the default method (not mandatory: can always >> choose one of 1-3). >> - The next server response then depends on what was chosen by the user >> >> The above may need to run as one exchange without any >> Intermediate-Result TLV between static password and OTP dialogue >> because it gets proxied as Radius PAP to "Inner Method server" as >> described in section 2.1 of the draft
> Hold the phone on this. That's not how Jouni's code works, and that's not > what we just agreed to on the calls. Jouni's code has something of a filler > intermediate-result and CB, and we just agreed that everything should have > that. Now, I am still not a fan of that decision, but it's what we decided. > Do we need to revisit? Revisit was not intended, my intention was to give some examples of why various uses of Basic-Password-Auth-Resp TLV and how it sometimes carries information other than password. I may have gotten the sequencing incorrectly with my example above. My understanding is that the "housekeeping" functionality, or any other variation of multi-round inner password authentication, means that Basic-Password-Auth-Req <--> Basic-Password-Auth-Resp exchange is done multiple times before a single inner password authentication method is considered completed and an Intermediate-Result TLV and Crypto-Binding TLV are needed. I'll need to check the previous discussion about filler Intermediate-Result and CB. When strictly reading the RFC and draft, it doesn't talk about multi-round inner password authentication, but I guess this is supported? -- Heikki Vatiainen h...@radiatorsoftware.com _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
