Name
Access-Challenge
Synopsis
|
Packet Type |
Response |
|
Code |
11 |
|
Identifier |
Identical to Access-Request |
|
Length |
Header length plus all additional attribute data |
|
Authenticator |
Response |
|
Attribute Data |
0 or more |
If a server receives conflicting
information
from a user, requires more information,
or simply wishes to decrease the risk of a fraudulent authentication,
it can issue an Access-Challenge packet to the
client. The client, upon receipt of the
Access-Challenge packet, must then issue a new
Access-Request with the appropriate information
included.
It should be noted that some clients don’t support
the
challenge/response process like this; in that case, the client treats
the Access-Challenge packet as an
Access-Reject packet. Some clients, however, do
support challenging, and at that point a message can be given to the
user at the client requesting the additional authentication
information—it’s not necessary in that
situation to set off another round of request/response packets.
Much like the Access-Reject packet, there are only
two standard attributes that can be included in an
Access-Challenge packet: the
State and Reply-Message
attributes. Any necessary vendor-specific attributes can be included
as well. The Reply-Message attribute can be
included in the packet multiple times, but the
State attribute is limited to a single instance.
The State attribute is copied unchanged into the
Access-Request that is returned to the challenging
server.
The Access-Challenge ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access