Re: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length

[Heikki Vatiainen <[e-mail]>]

On Fri, 27 Jan 2023 at 13:30, Eliot Lear <[e-mail]> 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
[e-mail]