SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: 7.2.1 CHAP Considerations (12-98)




    Steve,

    Ofer already suggested 2 - I just forgot - so that is fine.

    As for the 96 bits - that is a semantic issue - if you know that the 96 bits you generate are not random (e.g., extend a weak password) then the length is not enough.
    It is not supposed to check randomness - that is an administration part that is specified earlier.

    Julo


    Steve Senum <ssenum@cisco.com>

    06/13/2002 06:12 PM
    Please respond to Steve Senum

           
            To:        Julian Satran/Haifa/IBM@IBMIL
            cc:        ietf-ips <ips@ece.cmu.edu>
            Subject:        Re: iSCSI: 7.2.1 CHAP Considerations (12-98)

           


    Julian,

    Better, but I would suggest:

    If an initiator or target generates or verifies a CHAP secret that has less
    than 96 random bits then IPsec encryption (according to the implementation
    requirements in Section 7.3.2 Confidentiality) MUST be used to protect the
    connection. Moreover, in this case IKE authentication with group pre-shared
    keys SHOULD NOT be used unless it is not essential to protect group members
    against off-line dictionary attacks by other members, and an implementation
    MUST NOT continue with the login unless it can verify that IPsec encryption
    is being used to protect the connection.

    I want to more strongly tie the last requirement to the initial condition.

    Further comments on this text:

    1. I would suggest changing "96 random bits" to "96 bits".
    I don't think it is practical to verify the number of random bits
    in a single secret.

    2. I would suggest changing the final "MUST NOT" to a "SHOULD NOT".
    As with IKE pre-shared keys, the need to protect against off-line
    dictionary attacks is ultimately a local deployment consideration.


    Regards,
    Steve Senum

    Julian Satran wrote:
    >
    > The text I would suggest in 7.2.1 is:
    >
    > If an initiator or target generates or verifies a CHAP secret that has less
    > than 96 random bits then IPsec encryption (according to the implementation
    > requirements in Section 7.3.2 Confidentiality) MUST be used to protect the
    > connection. Moreover, in this case IKE authenti-cation with group pre-shared
    > keys SHOULD NOT be used unless it is not essential to protect group members
    > against off-line dictionary attacks by other members. When CHAP is used with
    > secret shorter than 96 bits, a compliant implementation MUST NOT continue with
    > the login unless it can verify that IPsec encryption is being used to protect
    > the connection.
    >
    > Julo
    >




Home

Last updated: Sun Jun 30 02:19:01 2002
11024 messages in chronological order