The EAP Protected One-Time Password Protocol (EAP-POTP)

Voir toute la rfc dans une seule page

Télécharger le PDF

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]