Re: Why GSSAPI/SPKM? (Was: Re: SACRED Protocol (long!))

Magnus Nystrom <[email protected]> Mon, 10 Dec 2001 17:30:32 -0700 (Mountain Standard Time)
Newsgroups gmane.ietf.sacred
Message-ID <Pine.WNT.4.31.0112101730180.2060-100000@mnystrom-lap>
Hi Stephen,

Maybe it was not worded properly, the intent was to state that _if_ an
implementation supports Account creation, _then_ it MUST etc.

The reason is that SPKM-3 allows for the same functionality as the
current draft uses TLS for, namely authentication of the server and
establishment of a security context, without relying on TLS.

-- Magnus

On Fri, 7 Dec 2001, Stephen Farrell wrote:

> Magnus, Gareth,
>
> (Trying to split up the issues involved in your proposals...)
>
> Its not clear to me why there's any advantage in adding this, and
> it also seems to me to add quite a bit of complexity. So, my
> questions are:
>
> - What can I do with this that I couldn't do with just SASL as an
> extensibility mechanism?
> - Why would all this be MUST?
>
> Stephen.
>
> >   2.2.2 GSSAPI
> >
> >    An implementation MUST support the GSSAPI SASL mechanism which in
> >    turn must support the SPKM GSS-API mechanism.
> >
> >    The SPKM implentation MUST support:
> >
> >    - The NULL-MAC [LIPKEY] and sha1WithRSAEncryption algorithmgs as
> >      I-ALGs. (Targets MUST not use this algorithm.)
> >    - AES  as a C-ALG.
> >    - SHA-1 [FIPS] as an O-ALG.
> >
> >    << QOP bitmap needs to be defined.>>"