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


            multiple of 8, then the pepper value SHALL be padded to the
            left, with '0' bits to the nearest multiple of 8 before
            being used in the PBKDF2 calculation.  This is to ensure the
            input to the calculation consists only of whole octets.  As
            an example, if the chosen pepper length is 4, the pepper
            value will be padded to the left, with 4 '0' bits to form an
            octet before being used in the PBKDF2 calculation.

            When pepper is used, it is RECOMMENDED that the length of
            the pepper and the iteration count are chosen in such a way
            that it is computationally infeasible/unattractive for an
            attacker to brute-force search for the given OTP within the
            lifetime of that OTP.

            As mentioned previously, a peer MUST NOT include a newly
            generated pepper value in the PBKDF2 computation if the
            server did not indicate its support for pepper searching in
            this session.  If the server did not indicate support for
            pepper searching, then the PBKDF2 computation MUST be
            carried out with a sufficiently higher number of iterations
            so as to compensate for the lack of pepper (see further
            Appendix D).

            A server may, in an earlier session, have transferred a
            pepper value to the peer in a Confirm TLV (see below).  When
            this is the case, and the peer still has that pepper value
            stored for this server, the peer MUST NOT generate a new
            pepper but MUST, instead, use this transferred pepper value
            in the PBKDF2 calculations.  The only exception to this is
            when a local policy (e.g., timer) dictates that the peer
            must switch to a new pepper (and the server indicated
            support for pepper searching).

            The following applies to the auth_id component:

            -  For dial-up, "auth_id" SHALL be either the empty string
               or the phone number called by the peer.  The phone number
               SHALL be specified in the form of a URL conformant with
               RFC 3966 [8], e.g., "tel:+16175550101".  Processing of
               received phone numbers SHALL be conformant with RFC 3966
               (this assumes that "tel" URIs will be shorter than 256
               octets, which would normally be the case).

            -  For use with IEEE 802.1X, "auth_id" SHALL be either the
               empty string or the MAC address of the authenticator in
               canonical binary format (6 octets).





Nystroem                     Informational                     [Page 30]