On Jan 27, 2023, at 7:56 AM, Heikki Vatiainen wrote:
> 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 si
On Jan 27, 2023, at 6:38 AM, Heikki Vatiainen wrote:
> Furthermore, let's consider multi-round inner password authentication,
> such as example flow C1 with "housekeeping":
> https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis#name-c1-successful-authenticatio
>
> Is there a reason why
On Fri, 27 Jan 2023 at 13:30, Eliot Lear 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 te
On Wed, 25 Jan 2023 at 03:14, Alan DeKok wrote:
>
> Section 4.2.14 (Basic-Password-Auth-Resp TLV) defines the length of the
> password "PassLen" as "Length of Password field in octets'. However, there
> is no requirement that the length be greater than zero.
>
> The same issue goes for the
Hiya,
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. Le
On Wed, 25 Jan 2023 at 10:21, John Mattsson
wrote:
>
> That sounds good. Would be good to have text stating that passwords of length
> 255 characters (the current max) shall be allowed. Requiring a minimum length
> of 8 or a least 6 characters would be good.
Basic-Password-Auth-Resp TLV is used
On Jan 25, 2023, at 9:49 AM, Eliot Lear wrote:
>
> In thinking about this flow, the real issue boils down to this:
>
> If the user is going to use 2FA, then the peer needs to know in advance. If
> the peer tries to use Basic Auth and server won't accept it, it should simply
> produce an error
In thinking about this flow, the real issue boils down to this:
If the user is going to use 2FA, then the peer needs to know in
advance. If the peer tries to use Basic Auth and server won't accept
it, it should simply produce an error. That's the simplifying flow.
If the peer doesn't know t
On Jan 25, 2023, at 9:06 AM, Eliot Lear wrote:
>
> First, I agree that this is a nit.
Except for the inability to get identities before choosing an authentication
method.
> On 25.01.23 14:54, Alan DeKok wrote:
> Sure, but 7170 doesn't say you can't have a null password. So it can finish
>
First, I agree that this is a nit.
On 25.01.23 14:54, Alan DeKok wrote:
On Jan 25, 2023, at 8:27 AM, Eliot Lear wrote:
No negotiation required. It gets the username as part of basic auth, sees the
name and then makes a decision to initiate a new inner method.
It has to finish the current
On Jan 25, 2023, at 8:27 AM, Eliot Lear wrote:
> No negotiation required. It gets the username as part of basic auth, sees
> the name and then makes a decision to initiate a new inner method.
It has to finish the current method first. i.e. the server only gets the
username after sending a B
On 25.01.23 14:22, Alan DeKok wrote:
What I'm not clear on is how they would negotiate a special username which
triggers a new auth, but without doing a password check. That seems odd to me.
No negotiation required. It gets the username as part of basic auth,
sees the name and then mak
On Jan 25, 2023, at 7:55 AM, Eliot Lear wrote:
> If you want to add some implementation guidance I think that's fine, but this
> isn't really a protocol consideration. I could envision the following
> circumstance, by the way: a username triggers the server to initiate a new
> inner method, an
On Jan 25, 2023, at 3:21 AM, John Mattsson wrote:
>
> That sounds good. Would be good to have text stating that passwords of length
> 255 characters (the current max) shall be allowed.
It can be stated in the text, but the 8-bit length field definitely limits
user names / passwords to 255 ch
On 25.01.23 09:21, John Mattsson wrote:
That sounds good. Would be good to have text stating that passwords of
length 255 characters (the current max) shall be allowed. Requiring a
minimum length of 8 or a least 6 characters would be good.
If you want to add some implementation guidance I t
: EMU WG
Subject: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length
Section 4.2.14 (Basic-Password-Auth-Resp TLV) defines the length of the
password "PassLen" as "Length of Password field in octets'. However, there is
no requirement that the length be greater th
Section 4.2.14 (Basic-Password-Auth-Resp TLV) defines the length of the
password "PassLen" as "Length of Password field in octets'. However, there is
no requirement that the length be greater than zero.
The same issue goes for the UserLen field.
TBH, any password less than 8 octets shou
17 matches
Mail list logo
