Re: [Emu] RFC7170bis and lack of identities

[Joseph Salowey <[e-mail]>]

On Thu, Feb 2, 2023 at 11:17 AM Alan DeKok <[e-mail]>
wrote:

> 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.
>
>
[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 executed so it uses the request action frame to start
up a new exchange.   Example C4 shows TLS client authentication with
renegotiation, but it seems a bit weird to me in that it is client
initiated in response to a server EAP-IDentity Request.

Did you find out if any of this is supported?

> 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.
>
>
[Joe] Although this seems OK, I'd rather be removing things than adding
things. I think we should make sure that the working group wants this.


>   Alan DeKok.
>
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu
>