`  ::::: Ok, that's 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 aren't 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 8.2.1:     When CHAP is performed over a non-encrypted channel, it is vulnerable    to an off-line dictionary attack.  Implementations MUST support use    of up to 128 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 3720, page 101).  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 doesn't cover``.  :::::  `