Skip to main content

The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism
RFC 4178

Revision differences

Document history

Date Rev. By Action
2018-12-20
05 (System)
Received changes through RFC Editor sync (changed abstract to 'This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API), which …
Received changes through RFC Editor sync (changed abstract to '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 that forces the selection of a mechanism not desired by the peers.

This mechanism replaces RFC 2478 in order to fix defects in that specification and to describe how to inter-operate with implementations of that specification that are commonly deployed on the Internet. [STANDARDS-TRACK]')
2015-10-14
05 (System) Notify list changed from jaltman@columbia.edu, lzhu@microsoft.com to jaltman@columbia.edu
2005-10-05
05 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2005-10-05
05 Amy Vezza [Note]: 'RFC 4178' added by Amy Vezza
2005-10-04
05 (System) RFC published
2005-04-05
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-04-04
05 Amy Vezza IESG state changed to Approved-announcement sent
2005-04-04
05 Amy Vezza IESG has approved the document
2005-04-04
05 Amy Vezza Closed "Approve" ballot
2005-04-01
05 (System) Removed from agenda for telechat - 2005-03-31
2005-03-31
05 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza
2005-03-31
05 Allison Mankin
[Ballot comment]
IESG has asked for a ban on protocols calling themselves "Simple"  - this is no doubt as
simple as it can be, but …
[Ballot comment]
IESG has asked for a ban on protocols calling themselves "Simple"  - this is no doubt as
simple as it can be, but it's not simple.  So I know that this can't be renamed - it is
recycling, but I'm just registering that it would have been nice to be able to change
the S to Straightforward instead of Simple :)
2005-03-31
05 Sam Hartman Add reference to rfc 2743 in section 1 per genart review.
2005-03-31
05 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2005-03-31
05 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Discuss by Allison Mankin
2005-03-31
05 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2005-03-31
05 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to Discuss from No Objection by Allison Mankin
2005-03-31
05 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen
2005-03-31
05 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Undefined by Allison Mankin
2005-03-31
05 Allison Mankin
[Ballot comment]
IESG has asked for a ban on protocols calling themselves "Simple"  - this is no doubt as
simple as it can be, but …
[Ballot comment]
IESG has asked for a ban on protocols calling themselves "Simple"  - this is no doubt as
simple as it can be, but it's not simple.  I think it could be called the "Straightforward and
Protected Negotiation..."
2005-03-31
05 Allison Mankin [Ballot Position Update] New position, Undefined, has been recorded for Allison Mankin by Allison Mankin
2005-03-31
05 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2005-03-31
05 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2005-03-30
05 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-03-30
05 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2005-03-28
05 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2005-03-28
05 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-03-28
05 Brian Carpenter
[Ballot comment]
(from Spencer Dawkins, Gen-Art reviewer)

This document is basically ready for publication. It's also OK for me to say that it's a well-written …
[Ballot comment]
(from Spencer Dawkins, Gen-Art reviewer)

This document is basically ready for publication. It's also OK for me to say that it's a well-written document that makes sense to first-time readers.

I do have one comment.

There's a lot of text around "per-message integrity services" in this document - it's important enough to mention in the abstract - but this term wasn't precisely defined and I didn't see an obvious reference that it pointed to. It wasn't clear to me what the connection between "per-message integrity services" and MICs was - and I didn't see a reference for MICs, either. It may be that all of this is perfectly clear to security types, but I didn't "get it". A quick look at ftp://ftp.rfc-editor.org/in-notes/rfc2743.txt made me wonder if this should be the reference, but I'm not smart enough to know what the reference should be.
2005-03-28
05 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2005-03-25
05 Sam Hartman [Ballot Position Update] New position, Yes, has been recorded for Sam Hartman
2005-03-25
05 Sam Hartman Ballot has been issued by Sam Hartman
2005-03-25
05 Sam Hartman Created "Approve" ballot
2005-03-25
05 Sam Hartman
Tom Yu comments:

2478bis>        ContextFlags ::= BIT STRING {
2478bis>            delegFlag      (0),
2478bis>      …
Tom Yu comments:

2478bis>        ContextFlags ::= BIT STRING {
2478bis>            delegFlag      (0),
2478bis>            mutualFlag      (1),
2478bis>            replayFlag      (2),
2478bis>            sequenceFlag    (3),
2478bis>            anonFlag        (4),
2478bis>            confFlag        (5),
2478bis>            integFlag      (6)
2478bis>        } (SIZE (32))

There should be additional text explaining that the size constraint
does not affect the DER requirement for the encoder to strip trailing
zero bits from the bit string, and that implementations should not
depend on receiving exactly 32 bits in an encoding.

Suggested text:

"The size constraint on the ContextFlags ASN.1 type only applies to
the abstract type.  The ASN.1 DER require that all trailing zero bits
be truncated from the encoding of a bit string type whose abstract
definition includes named bits.  Implementations should not expect to
receive exactly 32 bits in an encoding of ContextFlags."
2005-03-25
05 Sam Hartman State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Sam Hartman
2005-03-22
05 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2005-03-22
05 Sam Hartman Placed on agenda for telechat - 2005-03-31 by Sam Hartman
2005-03-22
05 Sam Hartman [Note]: 'proto shepherd: jaltman@columbia.edu' added by Sam Hartman
2005-03-08
05 Amy Vezza Last call sent
2005-03-08
05 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2005-03-08
05 Sam Hartman Last Call was requested by Sam Hartman
2005-03-08
05 Sam Hartman State Changes to Last Call Requested from Publication Requested by Sam Hartman
2005-03-08
05 (System) Ballot writeup text was added
2005-03-08
05 (System) Last call text was added
2005-03-08
05 (System) Ballot approval text was added
2005-03-08
05 Sam Hartman

1.a) Have the chairs personally reviewed this version of the
Internet
      Draft (ID), and in particular, do they believe this ID is …

1.a) Have the chairs personally reviewed this version of the
Internet
      Draft (ID), and in particular, do they believe this ID is
ready
      to forward to the IESG for publication?

The draft has been reviewed by the chair and I believe it is ready
for publication by the IESG.

1.b) Has the document had adequate review from both key WG members
      and key non-WG members?  Do you have any concerns about the
      depth or breadth of the reviews that have been performed?

The document has been reviewed and implemented by engineers from
Microsoft (Larry Zhu), Sun Microsystems (Wyllys Ingersoll), and
Heimdal (Love Hörnquist Ã…strand and Luke Howard).  There has
also been significant review and comment by Tom Yu, Martin Rex, Ken
Raeburn, Simon Spero, and Bill Sommerfeld.

1.c) Do you have concerns that the document needs more review from a
      particular (broader) perspective (e.g., security, operational
      complexity, someone familiar with AAA, etc.)?

No.

1.d) Do you have any specific concerns/issues with this document
that
      you believe the ADs and/or IESG should be aware of?  For
      example, perhaps you are uncomfortable with certain parts of
the
      document, or have concerns whether there really is a need for
      it.  In any event, if your issues have been discussed in the
WG
      and the WG has indicated it that it still wishes to advance
the
      document, detail those concerns in the write-up.

This document updates a proposed standard which is known to have
been implemented by a number of organizations which do not
participate in the IETF process.  The document which is being
replaced is ambiguous in several crucial areas.  This has resulted
in a variety of interoperability and security problems in the known
deployed implementations.  The working group has tried very hard to
provide security in the updated version while maintaining as much
backward compatibility as possible.  My one concern is that the
working group suspects that there are one or more implementations of
the original specification for which we do not have the ability to
verify that the proposed changes will be acceptable.  The working
group has done as much as is possible.  The only other option would
be to scrap GSS SPNEGO entirely but that would require a flag day
which the current participants of the working group insist must be
avoided.  The solution provided in this document does provide a high
degree of interoperability among implementations from the current
IETF participants.


1.e) How solid is the WG consensus behind this document? Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

The WG consensus behind this document is strong and represents the
opinions of all participating implementors of the specification.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent?  If so, please summarise the areas of conflict in
      separate email to the Responsible Area Director.

No.

1.g) Have the chairs verified that the document adheres to all of
the
      ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes.

The ASN.1 provided in Appendix A parses successfully using 'asnpp'.

1.h) Is the document split into normative and informative
references?
      Are there normative references to IDs, where the IDs are not
      also ready for advancement or are otherwise in an unclear
state?
      (note here that the RFC editor will not publish an RFC with
      normative references to IDs, it will delay publication until
all
      such IDs are also ready for publication as RFCs.)

Yes.


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.

This mechanism replaces RFC 2478 in order to fix defects in that
specification and to describe how to inter-operate with
implementations of that specification commonly deployed on the
Internet.


Working Group Summary:

The Kitten working group participants can be partitioned into two
significant groups: those who worked on GSS API Version 2 Update 1
and the other products of the CAT WG; and those who did not.  The
viewpoints of these two groups differ because of their respective
experiences and the requirements they have for the resulting
protocols.  The greatest challenge in producing this document was
ensuring that each group talked with each other instead of at each
other.  Once this was accomplished, reaching consensus was time
consuming but it was not controvertial in any way.

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.
Consensus was declared on the document on 4 March 2005.


Protocol Quality:

There are three existing implementations of the specified protocol
produced by Microsoft, Sun Microsystems and Heimdal although they
are not currently available to the public.  Testing has been
performed for backward compatibility and interoperability.  Testing
identified implementation defects but not protocol design problems.

A review of the document was conducted at the request of the
Security ADs by Bill Sommerfeld.
2005-03-08
05 Sam Hartman State Changes to Publication Requested from AD is watching by Sam Hartman
2005-01-24
05 (System) New version available: draft-ietf-kitten-2478bis-05.txt
2004-12-17
04 (System) New version available: draft-ietf-kitten-2478bis-04.txt
2004-12-15
05 Sam Hartman Draft Added by Sam Hartman in state AD is watching
2004-12-15
03 (System) New version available: draft-ietf-kitten-2478bis-03.txt
2004-12-02
02 (System) New version available: draft-ietf-kitten-2478bis-02.txt
2004-11-30
01 (System) New version available: draft-ietf-kitten-2478bis-01.txt
2004-11-29
00 (System) New version available: draft-ietf-kitten-2478bis-00.txt