SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Use of SRP (draft -04)



    
    
    Steve,
    
    What I meant was that one "AuthMethod" will be negotiated instead of
    "InitAuth" and "TargetAuth", so mixed methods are not possible. The
    one-way / mutual will be decided in the text messages that carry the
    process of the selected method, in a manner specific to that method.
    
    SRP is mutual when using the last server's message by which it proves
    the knowledge of the password verifier (assuming the verifiers are kept
    confidentially by the server). From RFC2945:
    "To finish authentication, they must prove to each other that their keys
    are identical...
    If the server receives a correct response, it issues its own proof to
    the client.  The client will compute the expected response using its
    own K to verify the authenticity of the server."
    
    We can have the initiator specifies in the first SRP message (with
    the U) "TargetAuth=yes" or "TargetAuth=no" which determines whether
    the last server message should be sent, and this will be the manner
    specific to SRP (while in KERB5 the initiator set the krb_ap_req mutual
    flag).
    
       Regards,
         Ofer
    
    
    
    Ofer Biran
    Systems and Software
    IBM Research Lab in Haifa
    biran@il.ibm.com  972-4-8296253
    
    
    Steve Senum <ssenum@cisco.com> on 01/03/2001 01:14:31
    
    Please respond to Steve Senum <ssenum@cisco.com>
    
    To:   Ofer Biran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
    cc:
    Subject:  Re: iSCSI: Use of SRP (draft -04)
    
    
    
    
    Ofer:
    
    If SRP is mutual, then I think the draft should state that with
    text similiar to the Kerberos method, and also state how
    to handle mixed SRB and Kerberos authentication (or disallow it).
    
    Also, I am not sure I agree that SRP is entirely mutual.
    See draft-ietf-pppext-eap-srp-00.txt for a proposal
    for using SRP with PPP.
    
    Regards,
    Steve Senum
    
    biran@il.ibm.com wrote:
    >
    > Steve,
    >
    > You are correct, we'll change the SRP message sequence similar to telnet
    (U
    > --- N,g,s -- A -- B...).
    >
    > For simultaneous authentication processes (InitAuth, TargetAuth) it seems
    a
    > problem of over flexibility. The simpler
    > and reasonable way would be to negotiate one authentication method
    > AuthMethod and leave the one way / mutual
    > authentication decision to the specific method selected. In KERB5 the
    > client decides it by setting the krb_ap_req mutual
    > flag, in SRP it's actually mutual.
    >
    >   Regards,
    >       Ofer
    >
    > Ofer Biran
    > Systems and Software
    > IBM Research Lab in Haifa
    > biran@il.ibm.com  972-4-8296253
    >
    > Steve Senum <ssenum@cisco.com> on 02/28/2001 01:41:01 AM
    >
    > Please respond to Steve Senum <ssenum@cisco.com>
    >
    > To:   ietf-ips <ips@ece.cmu.edu>
    > cc:
    > Subject:  iSCSI: Use of SRP (draft -04)
    >
    > Julian:
    >
    > With respect to use of the SRP protocol for authentication,
    > I think the current draft is incomplete.  The SRP spec
    > requires that values for the Prime Modulus value 'N' and the
    > Generator value 'g' be sent by the authenticating entity
    > as well as 's' and 'B' (or known through some other method).
    > Look at RFC 2944 to see how telnet handles this.
    >
    > Also, if both Initiator and Target choose to authenticate with
    > SRP, or if InitAuth=KERB5 and TargetAuth=srp, the same key names
    > will be needed by both sides at the same time, resulting in the
    > same key name appearing twice in the same text message.  This
    > will make it difficult for the receiver to know which key names
    > goes with which authentication process, since there can be two
    > going on at one time.
    >
    > Regards,
    > Steve Senum
    
    
    
    


Home

Last updated: Tue Sep 04 01:05:28 2001
6315 messages in chronological order