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.
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. Interoperability testing
has not been reported between implementations of the new specification
although participants report that new implementations have been
tested against existing SPNEGO implementations.
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. The working group was unable to maintain compatibility
with correct implementations of RFC 2478, maintain interoperability
with deployed implementations and make reasonable security
guarantees. The working group chose to sacrifice interoperability
with correct implementations of RFC 2478.
This specification was reviewed by Sam Hartman for the IESG.
RFC Editor Note
Add a reference to RFC 2743 in paragraph 5 of section 1 after the
firstmention of per-message integrity services.
At the bottom of page 11 insert a warning about ASN.1 encoders.
old:
This field, if present, contains the service options that are
requested to establish the context (the req_flags parameter of
GSS_Init_sec_context()). This field is inherited from RFC 2478
and it is not integrity protected. For implementations of this
specification the initiator SHOULD omit this reqFlags field,
and the acceptor MUST ignore this reqFlags field.
new:
This field, if present, contains the service options that are
requested to establish the context (the req_flags parameter of
GSS_Init_sec_context()). This field is inherited from RFC 2478
and it is not integrity protected. For implementations of this
specification the initiator SHOULD omit this reqFlags field,
and the acceptor MUST ignore this reqFlags field.
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.
_______________________________________________
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
