On Feb 4, 2023, at 3:46 AM, Eliot Lear wrote:
> To me, the way to look at this is that when a Result TLV is transmitted by
> the server, it is a signal that the server has no more requirements of the
> peer, and if it is transmitted by the peer, then it is a signal that the peer
> has no more r
On Feb 7, 2023, at 1:04 AM, Joseph Salowey wrote:
> [Joe] The intent here was that the client authenticated using a certificate
> during the TLS handshake and that the server viewed this as sufficient to
> meet the authentication requirements, but the client requires another method
> to be exe
On Thu, Feb 2, 2023 at 11:17 AM Alan DeKok
wrote:
> On Feb 2, 2023, at 1:52 PM, Alexander Clouter
> wrote:
> >> I'm not clear how that would happen. Nothing in the doc discusses
> >> how a client may choose authentication methods.
> >
> > The documentation does not but I did see Appendix C.9 l
On 04.02.23 08:57, Alexander Clouter wrote:
I agree on both points, Result TLV should be final and is easy to explain to
others.
It may be easy, but I don't think it's quite right.
To me, the way to look at this is that when a Result TLV is transmitted
by the server, it is a signal that the
On Sat, 4 Feb 2023, at 01:40, Alan DeKok wrote:
>> Should we state somewhere that the client can "effectively rollback the
>> entire inner state machine" so Result TLV is not final for the whole session?
>>
>> Should the client be able to do this multiple times?
>
> I would say "no".
I really
On Feb 3, 2023, at 6:56 AM, Alexander Clouter wrote:
> Another chunk of greyness (at least to me) is the server has sent a Result
> TLV (not intermediate) and then later after another method or chain of
> methods it is expected to send it again.
I would argue that Result TLV is final. The In
On Thu, 2 Feb 2023, at 19:16, Alan DeKok wrote:
>> The documentation does not but I did see Appendix C.9 lets the client state
>> what it wants to do:
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-03#name-c9-peer-requests-inner-meth
>
> i.e. the client authenticates in p
On Feb 2, 2023, at 1:52 PM, Alexander Clouter wrote:
>> I'm not clear how that would happen. Nothing in the doc discusses
>> how a client may choose authentication methods.
>
> The documentation does not but I did see Appendix C.9 lets the client state
> what it wants to do:
>
> https://data
On Thu, 2 Feb 2023, at 18:31, Alan DeKok wrote:
> On Feb 2, 2023, at 2:22 AM, Eliot Lear wrote:
>> I am wondering if we should close this issue. At the end of the day, if the
>> client knows it's doing something like 2FA that requires an EAP method, it
>> can initiate.
>
> I'm not clear how t
On Feb 2, 2023, at 2:22 AM, Eliot Lear wrote:
> I am wondering if we should close this issue. At the end of the day, if the
> client knows it's doing something like 2FA that requires an EAP method, it
> can initiate.
I'm not clear how that would happen. Nothing in the doc discusses how a
c
I am wondering if we should close this issue. At the end of the day, if
the client knows it's doing something like 2FA that requires an EAP
method, *it* can initiate. If it doesn't and the server decides it
needs it based on the Basic-Password-Auth-Resp, then the server can
insist, using a Re
I've opened an issue: https://github.com/emu-wg/rfc7170bis/issues/14 ,
summarized as:
When using normal EAP, the server sees the EAP Identity before it selects which
EAP type is being used.
However, with TEAP, the inner tunnel method (EAP or basic password) has to be
chosen by the server bef
12 matches
Mail list logo
