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

[Albert Chu]

> 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

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

----- 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>
>