Protocol Action: 'The Simple and Protected GSS-API Negotiation Mechanism' to Proposed Standard

The IESG has approved the following document:

- 'The Simple and Protected GSS-API Negotiation Mechanism '
   <draft-ietf-kitten-2478bis-05.txt> as a Proposed Standard

This document is the product of the Kitten (GSS-API Next Generation) Working 
Group. 

The IESG contact persons are Sam Hartman and Russ Housley.

Technical Summary
This document specifies a negotiation mechanism for the Generic
Security Service Application Program Interface (GSS-API) which is
described in RFC 2743.

GSS-API peers can use this negotiation mechanism to choose from a
common set of security mechanisms.

If per-message integrity services are available on the established
mechanism context, then the negotiation is protected against an
attacker forcing the selection of a mechanism not desired by the
peers.

Working Group Summary

At IETF 61, a team of implementors, the WG Chair, and the AD met
to validate the approach to providing security and backward
compatibility.  WGLC in December produced several issues which were
subsequently addressed on the mailing list with clear consensus.
It is the opinion of the chair that a second WGLC was not required.

Re: enctype negotiation and GSS naming extensions

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams <at> sun.com> writes:

    Nicolas> At MN I said I did not oppose Larry's Kerberos enctype
    Nicolas> negotiation proposal.

    Nicolas> I'm less sure now.

    Nicolas> You may recall that at the interim meeting at Boulder we
    Nicolas> decided that extensions would add a typed hole, distinct
    Nicolas> from authorization-data, to the authenticator and AP-REP.
    Nicolas> We'd argued over whether it was proper to overload
    Nicolas> authorization-data and decided that it was not.

    Nicolas> Larry's proposal overloads authorization-data by using it
    Nicolas> to transport a client's enctype proposal to the server.

    Nicolas> I am still inclined to agree that enctype negotiation is
    Nicolas> an allowable overloading of authorization-data, but the
    Nicolas> GSS-API naming extensions we're discussing at the KITTEN
    Nicolas> WG give me pause.

I've thought about this for a while and I also think it is reasonable
overloading if only because we don't want to tell Larry to wait for
extensions.

--Sam

Re: enctype negotiation and GSS naming extensions

On Tue, Apr 05, 2005 at 09:13:33AM -0400, Sam Hartman wrote:
>     Nicolas> I am still inclined to agree that enctype negotiation is
>     Nicolas> an allowable overloading of authorization-data, but the
>     Nicolas> GSS-API naming extensions we're discussing at the KITTEN
>     Nicolas> WG give me pause.
> 
> I've thought about this for a while and I also think it is reasonable
> overloading if only because we don't want to tell Larry to wait for
> extensions.

Ok, and as a one-time thing a mechanism implementation could filter
enctype negotiation AD out in the GSS naming interfaces.

I have no remaining objections to Larry's proposal.

Nico
--

-- 

Re: enctype negotiation and GSS naming extensions

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams <at> sun.com> writes:

    Nicolas> On Tue, Apr 05, 2005 at 09:13:33AM -0400, Sam Hartman
    Nicolas> wrote: I am still inclined to agree that enctype
    Nicolas> negotiation is an allowable overloading of
    Nicolas> authorization-data, but the GSS-API naming extensions
    Nicolas> we're discussing at the KITTEN WG give me pause.
    >>  I've thought about this for a while and I also think it is
    >> reasonable overloading if only because we don't want to tell
    >> Larry to wait for extensions.

    Nicolas> Ok, and as a one-time thing a mechanism implementation
    Nicolas> could filter enctype negotiation AD out in the GSS naming
    Nicolas> interfaces.

Could but should not.

Proposed Minutes of IETF62 - Please review

Thanks to Jeff, Nico, and Love for taking notes and scribing.
These minutes are really rough but then again the open discussion
went so fast that with recordings it was impossible to keep up.

Jeffrey Altman

IETF62 Minutes for Kitten Working Group
=======================================
Wednesday, March 9 2005 1:00-3:00 Central Standard Time.
Chairperson:  Jeffrey Altman

Thanks to Jeffrey Hutzelman and Nico Williams for Jabber Scribing
Thanks to Love Hörnquist Åstrand for taking notes.

agenda bashing:
        no comments

Larry Zhu updates on SPNEGO:
 - sent to IESG, Last Call ends March 22.

 - implementations include Longhorn beta 1, Heimdal, and a 
   future update to solaris 10

 - there is no open issues; please read draft

 - no questions

 - first document from kitten, beats the milestone.

Bill told us so: stackable mechs, SPNEGO and substitutions

During the security review of SPNEGO, Bill brought up a concern.  The
windows compatibility is only secure if you cannot mechanically
transform the mechanism token of one mechanism into the token of
another mechanism.

I'm concerned that for many stackable mechanisms it would be
relatively easy to push or pop something onto the stack and manipulate
the tokens without cryptographic knowledge.

Also, at least some of the mechanisms we have been discussing in the
EAP context would be mechanisms that do not provide integrity unless
properly stacked with a mechanism that spins integrity out of raw PRF.

In short, there are a lot of security concerns surrounding stacking
and negotiation.

Please consider forward motion on PRF and mechanism attributes

Hi.  I'd like to ask the working group to consider trying to move
forward the PRF drafts rapidly.  In addition, while I don't think we
are close to being in a position to know what mechanism attributes we
want, I'd love to have consensus on the APIs for accessing mechanism
attributes.

Having forward progress on these items may end up helping a proposal
Joe Salowey is working on.

Re: Bill told us so: stackable mechs, SPNEGO and substitutions

On Mon, Apr 11, 2005 at 06:16:58PM -0400, Sam Hartman wrote:
> During the security review of SPNEGO, Bill brought up a concern.  The
> windows compatibility is only secure if you cannot mechanically
> transform the mechanism token of one mechanism into the token of
> another mechanism.

Right.  IIRC Bill said this during lunch on Wednesday or Thursday.

Bill is correct.

As an aside, we first noted such a problem when designing the new
Kerberos V GSS mechanism (CFX).  We had to figure out how to deal with
extensibility.  In the end we punted on extensibility but provided the
mechanism by which it could be added: we defined a slot where extensions
could be requested by the initiator and declared that any such
extensions will have to have the acceptor produce a context token that
cannot be mechanically transformed into a non-extended context reply
token.

The issue there, and here, is quite similar: it's about protecting
negotiation of security parameters.

> I'm concerned that for many stackable mechanisms it would be
> relatively easy to push or pop something onto the stack and manipulate
> the tokens without cryptographic knowledge.

Note that this issue arises, so far, only from negotiation above the
GSS-API.  SPNEGO, in particular, because of its historic brokenness, is
what forces us to consider this.

Re: Please consider forward motion on PRF and mechanism attributes

On Mon, Apr 11, 2005 at 06:21:24PM -0400, Sam Hartman wrote:
> 
> 
> Hi.  I'd like to ask the working group to consider trying to move
> forward the PRF drafts rapidly.  In addition, while I don't think we
> are close to being in a position to know what mechanism attributes we
> want, I'd love to have consensus on the APIs for accessing mechanism
> attributes.
> 
> Having forward progress on these items may end up helping a proposal
> Joe Salowey is working on.

As far as I'm concerned the I-Ds are ready for WG LC.

That said, we may want to remove the restriction that the krb5 GSS_Prf()
cannot be ready prior to full context establishment.  Applications that
use GSS_Prf() can certainly ensure that they call it in synchronized
fashion before OR after full context establishment.  I mention this ONLY
as a result of your other post today about negotiation and composite
mechanisms -- having GSS_Prf() prior to full context establishment could
help construct stackable pseudo-mechanisms that protect against
manipulation of its context tokens into those of underlying mechanisms'.

Nico
--

-- 

Re: Please consider forward motion on PRF and mechanism attributes

On Mon, Apr 11, 2005 at 05:51:14PM -0500, Nicolas Williams wrote:
> On Mon, Apr 11, 2005 at 06:21:24PM -0400, Sam Hartman wrote:
> > 
> > 
> > Hi.  I'd like to ask the working group to consider trying to move
> > forward the PRF drafts rapidly.  In addition, while I don't think we
> > are close to being in a position to know what mechanism attributes we
> > want, I'd love to have consensus on the APIs for accessing mechanism
> > attributes.
> > 
> > Having forward progress on these items may end up helping a proposal
> > Joe Salowey is working on.
> 
> As far as I'm concerned the I-Ds are ready for WG LC.
> 
> That said, we may want to remove the restriction that the krb5 GSS_Prf()
> cannot be ready prior to full context establishment.  Applications that
> use GSS_Prf() can certainly ensure that they call it in synchronized
> fashion before OR after full context establishment.  I mention this ONLY
> as a result of your other post today about negotiation and composite
> mechanisms -- having GSS_Prf() prior to full context establishment could
> help construct stackable pseudo-mechanisms that protect against
> manipulation of its context tokens into those of underlying mechanisms'.

Er, disregard that suggestion -- there's never a partially established
security context for the Kerbers V GSS mechanism on the acceptor side...