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