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 phase 1, via something like a client cert.
>
>   That flow does look a little odd to me:

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.

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?

On a related note, the document does litter with ('Result-TLV') and without the 
hyphen ('Result TLV') all over the place for this and other attributes.

Makes Ctrl-F a bit of a pain...do we think we should fix this up; personally 
prefer *with* the hyphen so I can steer results towards statements about TLVs 
rather than stand alone words?

>   I think it would just need Identity-Hint?
>
> Identity-Hint "bob" --> 
>
>                 <-- Basic-Password-Auth-Req
>
> Basic-Password-Auth-Resp  "bob" password "hello" -->
>

Eugh, all this time I have been reading 'Identity-Hint' as 'Identity-Type'.

>> To trim a round trip, you could add language on for servers supporting this 
>> MAY wish to treat this as a username if the server would only send a 
>> Basic-Password-Auth-Req asking for the same information anyway...to trim a 
>> round trip.
>> 
>> I'm unable to think of a time why you would respond to a username request 
>> differently for an inner method, so it should be safe...mostly.
>
>   Different authentication types required for user / machine auth?  
> Password for users, and EAP-TLS for machines?

I was thinking more:

Identity-Hint = "bob" -->

                      <-- EAP-Identity Request

EAP-Identity Response = "not bob" -->

                      <-- huh? wat?!

>   For me it's also partly about not forbidding certain work flows.  
> Right now, "select auth based on identity" is either impossible, or 
> requires extra "oopsie" packet exchanges.  That doesn't seem right.

Reducing RTT's smells like something to resolve for TEAPv2?

Maybe we can use it as a carrot to persuade other vendors to move it it...one 
day.

Cheers

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Reply via email to