I don't think this is a substantive change, because what Heikki is
raising is entirely a matter of server-side policy. I also am not sure
it's the right change. For one thing, if a server is willing to issue a
new certificate, that's likely a policy statement that everything is
AOK. For another, this ISN'T a change of identity, and so there is
really no need to re-evaluate other policy aspects. Finally, in my
opinion, it makes sense that during onboarding a device might need to be
classified into a policy group, but if that is to change, then a COA
seems more appropriate at the radius level, rather than forcing a
re-connect.
Keep this in mind: end devices should be presumed to be pressed for
resources, and anything requiring additional unnecessary authentications
should be avoided in that case.
But again, this is all server side policy. The only aspect for the
client is that it should know when to re-authenticate if the server
requires it.
Eliot
On 02.08.23 02:59, Alan DeKok wrote:
On Aug 1, 2023, at 7:08 PM, Heikki Vatiainen wrote:
Using the above as an example case: When a client renews a certificate, should
the server mark the current TLS session as non-resumable? With EAP-TLS, the
server never knows immediately, because renewal is not in-band, when a
certificate is renewed, therefore this is not an issue for EAP-TLS. Here we
know that a renewal is in process and can take immediate action. While it's
possible that the certificate renewal is for non-TEAP use, it shouldn't harm if
the next authentication is full authentication.
These are all good points I wish I had thought of earlier.
i.e. any provisioning step should really be limited to provisioning. The user should
immediately drop the connection, and then reconnect using the provisioned credentials.
This means that any authorization phase always operates the same way, on full
credentials. And there is no mixing of provisioning + "real" authorization.
The simplest way to do this may be to require that any provisioning phase
result in EAP Failure. The inner tunnel can return the credentials,
crypto-binding TLV, and a Result TLV which indicates success. But the final
outer EAP packet should be EAP Failure.
I'm unsure if this is a substantive change to the document at this phase.
Given that no one has implemented PKCS provisioning yet, it may be acceptable
to make this change.
In general, here are some implementation related thoughts:
First, when housekeeping services are run in phase 2, should the current TLS
session be made non-resumable?
Yes. If Phase 2 is provisioning, OR if the users credentials are expired /
renewed in Phase 2, the current TLS session must be non-resumable.
The draft uses password and PIN change as examples of "housekeeping" and I'd say
certificate renewal and peer's use of Trusted-Server-Root TLV are also "housekeeping"
functions. Most, if not all, of these housekeeping services update or affect peer's credentials and
for this reason, it may be desired to force full authentication the next time the peer
authenticates again. More exactly: all currently cached TLS sessions with the peer may need to be
considered as non-acceptable for resumption.
Yes.
Second, in many cases there's some type of authorisation that follows
successful authentication. For example, VLAN assignment may be returned with
RADIUS Access-Accept that carries the EAP-Success. Maybe the draft should give
implementation guidance on being careful to ensure that authorisation happens
in controlled fashion?
I would say that authorization only follows full authentication. It cannot
follow a provisioning step.
To put this differently, EAP-Success doesn't happen in vacuum but grants access
to something. If housekeeping gets differently authorised access, then the
server must be careful to handle correctly those clients that try something
that a well-behaved client does not do.
For example, if peer authorisation happens differently when housekeeping is done, the
server should be careful to decline TLS resumption or otherwise the client may get a
shortcut to the housekeeping network. That is: resumption ok => Crypto-Binding TLS
+ Intermediate-Result TLV + Result TLV all saying success => access to
housekeeping network without housekeeping.
That's hard to manage. It may be easier to just mandate that servers reply
with EAP Failure after a provisioning step.
Another example: If the client does TLS resumption and then proceeds to
housekeeping, the server must be careful to ensure that authentication
information cached from the last full authentication is still fresh enough for
the housekeeping purposes.
Yes.
Third, EAP-FAST Dynamic Provisioning RFC 5422 suggests denying after
Server-Unauthenticated Provisioning Mode.
https://datatracker.ietf.org/doc/html/rfc5422#section-3.5
Would this type of functionality useful for some housekeeping cases? I've seen
