Ok thats fair  But since the RFC is the standard it would be a good idea to make it clear when something being discussed is an aspect of a nonconforming implementation rather than of the standard  That way conforming implementations arent as likely to be tarred with the tar brush   I have to disagree with you about reflection and dictionary attacks  Both are directly covered in section      When CHAP is performed over a nonencrypted channel it is vulnerable    to an offline dictionary attack  Implementations MUST support use    of up to  bit random CHAP secrets including the means to generate    such secrets and to accept them from an external generation source  and    Any CHAP secret used for initiator authentication MUST NOT be    configured for authentication of any target and any CHAP secret used    for target authentication MUST NOT be configured for authentication    of any initiator  If the CHAP response received by one end of an    iSCSI connection is the same as the CHAP response that the receiving    endpoint would have generated for the same CHAP challenge the    response MUST be treated as an authentication failure and cause the    connection to close this ensures that the same CHAP secret is not    used for authentication in both directions  Also if an iSCSI    implementation can function as both initiator and target different    CHAP secrets and identities MUST be configured for these two roles   both from RFC  page   The first quote talks about dictionary attacks the second one describes reflection attacks   Your last edit to the article seems fine to me  It does raise one question you wrote most attacks  which suggests the question please list the attacks that it doesnt cover