Re: [Freeipmi-devel] adding md2/md5 support

[Anand Babu]

Hi Al,
Creating another template for session header perfectly aligns with our
design framework. But more work than using a free auth_code field for
now.

I can see your point, how OEMs will not work out for us. You have
already experienced with super-micro boards. 

Definitely "tmpl_hdr_session_authbuf" is the best of all the ones you
have proposed.

Happy Hacking
-ab

,----[ Albert Chu <address@hidden> ]
| > I will do the (2)nd way. It keeps the APIs clean, uniform and
| > simple.
| 
| I know see why #2 didn't sit well with me.  #2 assumes the authcode is
| a function of the password. Some vendors (*cough* trust me, i know of
| one *cough*) may implement an OEM authentication scheme that is not
| based on passwords.
| 
| After thinking about it, I think adding one more session header
| template would work out best:
| 
| fiid_template_t tmpl_hdr_session_authbuf = { {8, "auth_type"}, {32,
|   "session_seq_num"}, {32, "session_id"}, {8, "ipmi_msg_len"}, {128,
|   "authbuf"}, <-- could increase size {0, ""} };
| 
| And the API works as follows:
| 
| When the user uses tmpl_hdr_session_auth, fill_hdr_session() fills in
| the auth_code field by copying from the auth_code parameter.
| assemble_lan_packet() will simply copy the auth_code when buffer when
| assembling the packet.
| 
| When the user uses tmpl_hdr_session_authbuf, fill_hdr_session() fills
| in the authbuf field copying from the auth_code parameter.
| assemble_lan_packet() will calculate the auth_code based on the data
| passed in from the authbuf field.
| 
| When we need to implement OEM specific authentication schemes, we can
| document what the user needs to pass into fill_hdr_session(), may it
| be password, challenge string, whatever.  But we still give the option
| to users to calculate the authcode outside of the function.
| 
| This keeps the APIs clean, API doesn't change, and authentication is
| hidden from the user if they want it hidden.  I think this approach
| accomplishes everything we want.
| 
| Let me know what you think.
| 
| Al
`----

----- Original Message -----
From: Anand Babu <address@hidden>
Date: Thursday, February 12, 2004 8:47 pm
Subject: Re: [Freeipmi-devel] adding md2/md5 support

> Hi Al,
> ,----[ Albert Chu <address@hidden> ]
> | Hey everyone,
> | 
> | The current API is not perfect for md2/md5 checksum support.  The
> | reason is that in order to calculate md2/md5 checksums, we need the
> | lan_msg_hdr, command, and packet checksums to be filled in *first*.
> | Then, the md2/md5 authcode is calculated *last*.  This won't work in
> | the current API b/c we call fill_hdr_session() before calling
> | assemble_lan_packet().
> | 
> | I see several ways to add md2/md5 support:
> | 
> | 1) Pass authtype and password to assemble_lan_packet instead of
> |    fill_hdr_session(): Pro: Easiest Con: Messes up nice API
> | 
> | 2) fill_hdr_session() copies "password" into the authcode buffer.
> |    Within assemble_lan_packet(), recalculate the authentication code
> |    if the authtype is md2 or md5.  You can think of this as a 
> "hidden"|    way to pass the password from fill_hdr_session to
> |    assemble_lan_packet.  Pro: Keeps API nice Con: A "work around"
> |    solution.  Doesn't sit well with me.  But in some respects it is
> |    still "clean".  I might feel better if someone else feels this is
> |    ok.
> | 
> | 3) Add a "lan_msg_hdr" and "obj_cmd" parameters to 
> fill_hdr_session().|    Pro: Easy and keeps API relatively clean 
> Con: Requires user to call
> |    fill_lan_msg_hdr and fill_X_cmd before fill_hdr_session.
> | 
> | Al
> `----
> I will do the (2)nd way. It keeps the APIs clean, uniform and
> simple.
> 
> ,----[ Albert Chu <address@hidden> ]
> | P.S. There are a number of subtle authtype checks that need to be 
> put| into fill_hdr_sessino() and assemble_lan_packet() to handle 
> this and
> | pre-msg-authentication.  I will add that whenever i do this ... 
> Also I
> | think assemble_lan_packet() should return the length of the buffer
> | written into the packet buffer.  The length will vary depending 
> on the
> | authentication type.
> `----
> Go ahead and try different auth types and make necessary changes.
> Returning buffer-len in assemble_XXXX_pkt() makes sense too. Right now
> its done using MACROs.
> 
> -- 
> _.|_ 
> (_||_)
> Free as in Freedom <www.gnu.org>
> 



-- 
 _.|_ 
(_||_)
Free as in Freedom <www.gnu.org>