The EAP Protected One-Time Password Protocol (EAP-POTP)
Voir toute la rfc dans une seule page
Page : 33 / 82
Télécharger le PDF
Auteur(s) : M. Nystroem
Classé sous : Otp
, Extensible authentication protocol
RFC 4793 EAP-POTP February 2007
at a given time, e.g., due to clock drift in the token. If
the given pepper length is not a multiple of 8, each tested
pepper value will be padded to the left to the nearest
multiple of 8, in the same manner as was done by the peer.
If the server already shares a secret pepper value with this
peer, then obviously there will only be one possible pepper
value, and the server will find it based on the
pepper_identifier provided by the peer. The server SHALL
send a new EAP-Request of type POTP-X with an OTP TLV with
the E bit set if the peer provided a pepper identifier
unknown to the server.
For each K_MAC', the EAP server computes
mac' = MAC(K_MAC', msg_hash(msg_1', msg_2', ..., msg_n'))
where MAC is the negotiated MAC algorithm, msg_hash is the
message hash algorithm defined in Section 4.9, and msg_1',
msg_2', ... msg_n' are the same messages on which the peer
calculated its message hash, but this time, as sent and
received by the EAP server. If the first 16 octets of mac'
matches the first 16 octets in the Authentication Data field
of the EAP-Response in question, and the provided
authenticator identity is acceptable (e.g., matches the EAP
server's view of the authenticator's identity), then the
peer is authenticated.
If the authentication is successful, the authentication
server then attempts to authenticate itself to the peer by
use of the Confirm TLV (see below). If the authentication
fails, the EAP server MAY send another EAP-Request of type
POTP-X containing an OTP TLV to the peer, or it MAY send an
EAP-Failure message (in both cases, possibly preceded by an
EAP-Request of type Notification).
4.11.4. NAK TLV
Presence of this TLV indicates that the peer did not support a
received TLV with the M bit set. This TLV may occur 0, 1, or more
times in an EAP-Response of type POTP-X. Each occurrence flags the
non-support of a particular received TLV.
The NAK TLV MUST be supported by all peers and all EAP servers
conforming to this specification and MUST NOT be responded to with a
NAK TLV. Receipt of a NAK TLV by an EAP server MAY cause an
authentication to fail, and the EAP server to send an EAP-Failure
message to the peer.
Nystroem Informational [Page 33]