Re: [Emu] RFC7170bis and lack of identities

[Alan DeKok <[e-mail]>]

On Feb 2, 2023, at 1:52 PM, Alexander Clouter <[e-mail]> 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://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:

EAP-Response/
  EAP-Type=TEAP, V=1
  [TLS certificate,]
   TLS client_key_exchange,
  [TLS certificate_verify,]
   TLS change_cipher_spec,
   TLS finished ->
                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TLS change_cipher_spec,
                           TLS finished,
                           Crypto-Binding TLV (Request),
                            Result TLV (Success))


  So... the first set of data in the tunnel is Crypto-Binding?  Hmm..

  I'll have to test that to see if it works.

> Using the Identity-Hint TLV to steer the server so at least it knows if it is machine or a user authentication coming its way is useful. Some if not most sites should find this good enough for them.
> 
> Though if you are proposing this to be optional, why not define another new TLV the client MAY send with Identity-Hint TLV that takes the place of the EAP-Identity response for only when it wants to go and do Basic-Password-Auth.

  I think it would just need Identity-Hint?

Identity-Hint "bob" --> 

                <-- Basic-Password-Auth-Req

Basic-Password-Auth-Resp  "bob" password "hello" -->

> 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?

  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.

  Alan DeKok.