Re: [cpp-netlib-devel] Security, Authentication and Encryption

[Dean M. B. <mik...@gm...>]

Hi Glyn!

On 5/24/07, Glyn Matthews <gly...@gm...> wrote:
> Boost Networkers,
>

I like the sound of that. ;-)

>
> A few times on this list we have mentioned security without ever yet going
> into any detail about it.  I believe this a rather fundamental aspect of
> network programming and it would be wrong to design a networking library
> without addressing this.  However, I do think that this is a whole other
> application area and probably beyond the scope of boost.network.  But what
> do other people on this list thing?
>

I agree that security is a very broad topic which should live better
in a different library. I however think that security is integral in
some protocols aside from HTTP and SMTP, and should be made a protocol
specific thing. We should strike a balance and be as complete as we
can as far as implementing the protocols are concerned -- without
being too ambitious as to implement all the possible variations of a
protocol (i.e. HTTP 1.0/1.1 would be enough, supporting only a few
security/authentication methodologies -- same goes for SMTP/ESMTP
implementing the most common security/authentication methodologies).

So I'm guessing, that an smtp::credentials<> type would be different
from an http::credentials<> type, and that an http::session<>'s
authentication implementation would be different from an
smtp::session<>'s authentication implementation as well.

> My thoughts:
> I am not aware of anything in boost, or that's been proposed, in the domain
> of security.  This is an area that moves rapidly and I can imagine its very
> difficult for a library designer to keep abreast of all the changes.  Also
> it can be quite tightly coupled to a particular protocol.  However, there
> are definitely algorithms and techniques which are used repeatedly by
> application developers and which definitely belong in a re-usable library or
> framework.
>

I personally do not intend to implement security routines -- i'd much
rather defer that to other libraries (libgcrypt, or GNU TLS, etc.). I
do however intend to support some of these to be usable in the
library, depending on the protocols using it.

> Does anyone think it is possible to develop security software for our own
> requirements and eventually fork should someone have the interest or will to
> take it on?  What do people normally do when they require authentication /
> encryption?  I often find it difficult to set out a clear policy of this,
> and the code I and my co-developers write is often rather disorganised.
> Therefore I think its a good candidate for considering developing a library
> or framework for addressing this, or at the very least determining a clear
> boost.network policy.
>

I think it should be possible to abstract the authentication and
security parts using the 'traits' idiom, where we can store certain
types in traits container classes which defer the implementation of
specific security implementations in more detail. I'd like to use an
example of what I mean just to be more precise:

namespace policies {
#ifdef __ENABLE_GNU_TLS__
  namespace gnu {
    struct tls {
      typedef gnu_tls_authentication_module auth;
      typedef gnu_tls_encryption_methodology encryption;
      typedef some_other_gnu_hashing hash;
    };
  } // namespace gnu
#endif
#ifdef __ENABLE_WIN_TLS___
  namespace win {
    struct tls {
      typedef win_tls_authentication_module auth;
      typedef win_tls_encryption_methodology encryption;
      typedef some_other_win_hashing hash;
  }
#endif
} // namespace policies

namespace http { // for example
  template <class AuthPolicy>
  struct session {
    // use the AuthPolicy contained types here
    // like 'typename AuthPolicy::auth' or 'typename AuthPolicy::encryption'
  };
}

We can even write simple wrappers to adapt the API of the different
implementations to fit in the model that we will use. This should
allow for easy extension as we go along.

> Any comments?
> G
>

Thanks for asking the very important question and providing insight. I
certainly hope we can figure something out this early, so that we can
explore them as soon as we can with code. :-)

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459