SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: U=<user> in Authentication



    
    OK then Steve, and others  I would be interested in your answers to the
    following questions:
    
    If the UserID is exactly the same as the iSCSI Initiator Name, why would it
    be entered again?
    
    If the UserID is different, why was the iSCSI initiator Name required?  It
    is only used as:
    1. A unique string that can ensure that the full Session identification is
    unique, The UserID can do that.
    2. As an Authentication String.   The UserID can do that.
    
    If the same users wants access to different storage from different systems,
    that user can have a unique UserID for each system.
    
    If the User wants the same storage access from different systems, serially,
    then that user can use the same UserID on each system.
    
    So is the UserID a substitute for iSCSI Initiator Name?
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136
    Internet address: hufferd@us.ibm.com
    
    
    Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 09/19/2001 03:27:08 PM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ietf-ips <ips@ece.cmu.edu>
    cc:
    Subject:  Re: iSCSI: U=<user> in Authentication
    
    
    
    I don't think it should be possible to omit
    the usernames for AuthMethods SRP and CHAP.
    
    On the SRP and CHAP key names, I am mostly netural,
    though I would prefer ChapId instead of ChapID.
    Since they are AuthMethod specific though, I don't
    really see the need to change them.
    
    Steve Senum
    
    "CONGDON,PAUL (HP-Roseville,ex1)" wrote:
    >
    > I agree that more clarification regarding how to associate SCSI Names
    with
    > user identities should be provided.  I'm not sure if I agree that it
    should
    > be possible to omit the names entirely - however.  This would provide
    > another optional way to approach the exchange (may provide or may not)
    which
    > adds complexity to this portion of the code, more test cases, more
    > unnecessary options, etc..  As you've mentioned it may also be different
    > depending upon the authentication method in use. There is certainly room
    for
    > improvement here.
    >
    > I have a bit of a gripe about the key=value pairs during authentication
    > phase in general.  First of all, the key names are not very descriptive,
    > which defeats the purpose of using Text keys in the first place (in my
    > opinion).  Secondly and more importantly, there are key values that are
    not
    > unique and depend upon what authentication method is in progress in order
    to
    > decode/parse them.  For example, A=5 in CHAP for algorithm selection is
    > completely different that A=2345 in SRP.  Also N=initiatorName in CHAP is
    > totally different than N=5678 in SRP.   It would be much easier if the
    text
    > command parser didn't have to consider what authentication method was
    > running and that all key values were unique.  Thus I propose making the
    > following name changes to CHAP and SRP key values.  I'm not too concerned
    > about the exact key names used, just that they are somewhat descriptive
    and
    > unique.
    >
    > CHAP Key Values
    >
    > Old         New
    > ---         --------
    > A           ChapAlgorithm
    > I           ChapID
    > N           ChapUser
    > C           ChapChallenge
    > R           ChapResponse
    >
    > SRP Key Values
    >
    > Old             New
    > ---             ---
    > U               SrpUser
    > N               SrpSafePrime
    > g               SrpGenerator
    > s               SrpSalt
    > A               SrpPubKeyA
    > B               SrpPubKeyB
    > M               SrpSessionKey
    > HM              SrpKeyProof
    >
    > Paul
    >
    > +------------------------------------------+
    > Paul Congdon
    > HP ProCurve Networking
    > Hewlett Packard Company
    > 8000 Foothills Blvd - M/S 5662
    > Roseville, CA   95747
    > phone: 916-785-5753
    > email: paul_congdon@hp.com
    > +------------------------------------------+
    >
    > -----Original Message-----
    > From: John Hufferd [mailto:hufferd@us.ibm.com]
    > Sent: Tuesday, September 18, 2001 6:22 PM
    > To: Julian Satran; Ofer_Biran/Haifa/IBM%IBMUS; mbakke@cisco.com;
    > jtseng@NishanSystems.com
    > Cc: ips@ece.cmu.edu
    > Subject: iSCSI: U=<user> in Authentication
    >
    > Folks,
    > I think we should indicate in the Security section of the document how
    the
    > security Authentication process might validate that the iSCSI Initiator
    > Name sent in the Initial Login, has something approprate to do with the
    > "user" being authenticated.  (Otherwise, you could authenticate a user
    and
    > that user could claim/use any iSCSI Initiator Name in the InitiatorName
    > key=value pair.
    >
    > It is kind of obvious how to relate the U=<user> to the approprate iSCSI
    > Initiator Name (in the case of SRP), and little less obvious with Chap,
    > though I think it would be the N=<N> parameter.  However, it is really
    not
    > obvious when using Kerberos, and SPKM.
    >
    > It also should be possible for the initiator not to send another UserID,
    if
    > the Security Data Base the customer uses can support the iSCSI Initiator
    > Name as a UserID.  That is, it should be possible for the U=<user>
    > parameter not to be sent,and have that  imply  the value of <user> is the
    > iSCSI Initiator Node Name entered previously as a value in the
    InitiaorName
    > key=value pair. Same way with the N=<N> in Chap.
    >
    > However, it is not clear, how you do similar things with Kerberos, and
    > SPKM.
    >
    > What do you folks think about this, and how should we document it?
    >
    > .
    > .
    > .
    > John L. Hufferd
    > Senior Technical Staff Member (STSM)
    > IBM/SSG San Jose Ca
    > Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    > Home Office (408) 997-6136
    > Internet address: hufferd@us.ibm.com
    
    
    
    


Home

Last updated: Thu Sep 20 13:17:17 2001
6631 messages in chronological order