Hank,

I wasn't working on IPMI 5 years ago when this was all settled so I'm having
to piece it together from bug reports on code someone else wrote and an
industry standard specification.    I'm just trying to help out the best I can.

-- Jim Mankovich | jm...@hp.com --


On 5/1/2012 5:42 AM, Hank Bruning wrote:
Duncan,
maybe you should use a different model in programming. Object Oriented vs 
Procedural.
Make a class with a public API as below,  It handles 16 and 20 bytes passwords 
with all the underling IPMI 2.0 cipher suits.

http://www.jblade.com:8080/products/retuli/ipmiCx/doc/javadoc/com/jblade/lib/retuli/ipmi/std/session/JbIpmiRmcpSessionAccountPassword.html
http://www.jblade.com/products/retuli/ipmiCx/RetuliIpmiCxOverview.jsf

Gentleman, the discussion on passwords lengths is getting silly and stupid. 
This was settled 5 years ago independent of C++ vs Java by Intel.
Hank Bruning
JBlade


On Tue, May 1, 2012 at 7:12 AM, Duncan Idaho <dune.id...@gmail.com 
<mailto:dune.id...@gmail.com>> wrote:

    Jim,

    it is all right. Attached is v2 which covers user name longer than 16
    bytes. I've also checked the code, again, and password length restrain
    will work for all three methods - cli, ask-pass, file. Let me know if
    we're done with this one, and I'll attach patch to SF.net ticket.
    Funny enough, I've found a bug by testing this. Reading password from
    file is limited only to 16byte passwords. I've logged SF.net ticket.

    As for 'user set password', don't think about it now. I think limiting
    password length is sufficient for now. I've logged feature request
    already, so it is noted and won't be forgotten. I don't think this is
    feature that has to make it into 1.8.12.
    I will eventually look at it, however I have nothing to test against
    nor I'm optimistic about many, if any, BMCs actually supporting 20
    byte passwords.

    --Duncan

    On Mon, Apr 30, 2012 at 9:41 PM, Jim Mankovich <jm...@hp.com 
<mailto:jm...@hp.com>> wrote:
    > Duncan,
    >
    > Your validation is reasonable for password "input" verification since the
    > input password is only
    > applicable to lan/lanplus.
    >
    > You were correct when you said that I was talking about the code which 
sets
    > the password.  For that
    > case, we simply permit folks to specify up to 20 characters independent of
    > the interface or IPMI
    > version.
    >
    > When I looked at your changes I was thinking about password "set"
    > verification which is why I
    > my comments didn't make sense with regard to your changes.
    >
    > Sorry for the all the confusion.
    >
    >
    > -- Jim Mankovich | jm...@hp.com <mailto:jm...@hp.com> --
    >
    >
    > On 4/30/2012 2:39 PM, Duncan Idaho wrote:
    >>
    >> I'm probably have a very thick skull. Have any of you looked at the
    >> patch? Because I still feel like it handles what's described in the
    >> ticket.
    >> Anyway, I obviously fail to understand and thus I'm not correct person
    >> to fix it. Anyone else give it a go, please ;)
    >>
    >> --Duncan
    >>
    >> On Mon, Apr 30, 2012 at 8:33 PM, Andy Cress<andy.cr...@us.kontron.com 
<mailto:andy.cr...@us.kontron.com>>
    >>  wrote:
    >>>
    >>> Duncan,
    >>>
    >>>  From the remote client (before it connects), you would verify that the
    >>> -P input is<= 20 characters.
    >>> Then after initiating the connection (GetChanAuthCap), you could detect
    >>> if it is IPMI 2.0 or not, and then be able to find out if it supports
    >>> 20-byte passwords.
    >>>
    >>> IPMI 1.5 and prior = only 16-byte passwords can be used
    >>> IPMI 2.0 = many vendors implement 20-byte passwords, but not all.
    >>>
    >>> To make it (much) simpler, just validate the input once at 20
    >>> characters, and let it go through after that.  The user has to know the
    >>> correct password anyway.
    >>>
    >>> Andy
    >>>
    >>> -----Original Message-----
    >>> From: Duncan Idaho [mailto:dune.id...@gmail.com 
<mailto:dune.id...@gmail.com>]
    >>> Sent: Monday, April 30, 2012 4:10 PM
    >>> To: Jim Mankovich
    >>> Cc: ipmitool-devel@lists.sourceforge.net 
<mailto:ipmitool-devel@lists.sourceforge.net>; Albert Chu
    >>> Subject: Re: [Ipmitool-devel] Reg issue with password having 16 bytes
    >>> [ID:3184687]
    >>>
    >>> Jim,
    >>>
    >>> I'm sorry, but I don't follow. What? I feel like you're talking about
    >>> setting password now, eg. % ipmitool user set password UID PASSWORD;.
    >>> I thought the issue is % ipmitool -P veryLongPassword -H myhost some
    >>> commands here ; And that's what patch should address. I haven't tried
    >>> password from file and via ask-pass, come to think of it, but I have
    >>> tested -P parameter.
    >>>
    >>> Please, elaborate your e-mail a bit more. I'm, well, confused.
    >>>
    >>> Thanks,
    >>> --Duncan
    >>>
    >>> On Mon, Apr 30, 2012 at 8:01 PM, Jim Mankovich<jm...@hp.com 
<mailto:jm...@hp.com>>  wrote:
    >>>>
    >>>> Duncan,
    >>>>
    >>>> After I looked at this I came to the realization that I had over
    >>>
    >>> simplified
    >>>>
    >>>> the 16 vrs 20 byte
    >>>> password to lan vrs lanplus, when in fact it is really an IPMI 1.5 vrs
    >>>
    >>> IPMI
    >>>>
    >>>> 2.0 issue.
    >>>> It is also possible to set a password via the /dev/ipmi interface so
    >>>> qualification of
    >>>> password length using the interface is not sufficient to cover all the
    >>>> cases.
    >>>>
    >>>> I believe doing this correctly will require password length
    >>>
    >>> verification
    >>>>
    >>>> based on the current
    >>>> IPMI version.
    >>>>
    >>>> This patch will ca
    >>>>
    >>>> -- Jim Mankovich | jm...@hp.com <mailto:jm...@hp.com> --
    >>>>
    >>>>
    >>>>
    >>>> On 4/28/2012 5:41 AM, Duncan Idaho wrote:
    >>>>>
    >>>>> Jim,
    >>>>>
    >>>>> attached is proposed solution to constrain password length to 16,
    >>>>> resp. 20, bytes when LAN, resp. LAN+, interface is used.
    >>>>>
    >>>>> Comments are, of course, welcome from anybody.
    >>>>>
    >>>>> --Duncan
    >>>
    >>> ------------------------------------------------------------------------
    >>> ------
    >>> Live Security Virtual Conference
    >>> Exclusive live event will cover all the ways today's security and
    >>> threat landscape has changed and how IT managers can respond.
    >>> Discussions
    >>> will include endpoint security, mobile security and the latest in
    >>> malware
    >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
    >>> _______________________________________________
    >>> Ipmitool-devel mailing list
    >>> Ipmitool-devel@lists.sourceforge.net 
<mailto:Ipmitool-devel@lists.sourceforge.net>
    >>> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
    >>
    >>
    >

    
------------------------------------------------------------------------------
    Live Security Virtual Conference
    Exclusive live event will cover all the ways today's security and
    threat landscape has changed and how IT managers can respond. Discussions
    will include endpoint security, mobile security and the latest in malware
    threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
    _______________________________________________
    Ipmitool-devel mailing list
    Ipmitool-devel@lists.sourceforge.net 
<mailto:Ipmitool-devel@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/ipmitool-devel


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Reply via email to