draft-ietf-kitten-2478bis-00.txt   draft-ietf-kitten-2478bis-01.txt 
NETWORK WORKING GROUP L. Zhu NETWORK WORKING GROUP L. Zhu
Internet-Draft P. Leach Internet-Draft P. Leach
Obsoletes: 2478 (if approved) K. Jaganathan Obsoletes: 2478 (if approved) K. Jaganathan
Expires: May 23, 2005 Microsoft Corporation Expires: May 26, 2005 Microsoft Corporation
W. Ingersoll W. Ingersoll
Sun Microsystems Sun Microsystems
November 22, 2004 November 25, 2004
The Simple and Protected GSS-API Negotiation Mechanism The Simple and Protected GSS-API Negotiation Mechanism
draft-ietf-kitten-2478bis-00 draft-ietf-kitten-2478bis-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 23, 2005. This Internet-Draft will expire on May 26, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
Abstract Abstract
This document specifies a negotiation mechanism for the Generic This document specifies a negotiation mechanism for the Generic
Security Service Application Program Interface (GSS-API) which is Security Service Application Program Interface (GSS-API) which is
described in RFC 2743. described in RFC 2743.
skipping to change at page 2, line 21 skipping to change at page 2, line 21
2. Conventions Used in This Document . . . . . . . . . . . . . . 5 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Negotiation Protocol . . . . . . . . . . . . . . . . . . . . . 6 3. Negotiation Protocol . . . . . . . . . . . . . . . . . . . . . 6
3.1 Negotiation Description . . . . . . . . . . . . . . . . . 6 3.1 Negotiation Description . . . . . . . . . . . . . . . . . 6
3.2 Negotiation Procedure . . . . . . . . . . . . . . . . . . 7 3.2 Negotiation Procedure . . . . . . . . . . . . . . . . . . 7
4. Token Definitions . . . . . . . . . . . . . . . . . . . . . . 9 4. Token Definitions . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Mechanism Types . . . . . . . . . . . . . . . . . . . . . 9 4.1 Mechanism Types . . . . . . . . . . . . . . . . . . . . . 9
4.2 Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 9 4.2 Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 9
4.2.1 negTokenInit . . . . . . . . . . . . . . . . . . . . . 10 4.2.1 negTokenInit . . . . . . . . . . . . . . . . . . . . . 10
4.2.2 negTokenResp . . . . . . . . . . . . . . . . . . . . . 11 4.2.2 negTokenResp . . . . . . . . . . . . . . . . . . . . . 11
5. Processing of mechListMIC . . . . . . . . . . . . . . . . . . 13 5. Processing of mechListMIC . . . . . . . . . . . . . . . . . . 13
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. Normative References . . . . . . . . . . . . . . . . . . . . 18 10. Normative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
A. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 20 A. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 21
A.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 20 A.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 21
A.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 20 A.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 21
B. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 22 B. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . 24
1. Introduction 1. Introduction
The GSS-API [RFC2743] provides a generic interface which can be The GSS-API [RFC2743] provides a generic interface which can be
layered atop different security mechanisms such that if communicating layered atop different security mechanisms such that if communicating
peers acquire GSS-API credentials for the same security mechanism, peers acquire GSS-API credentials for the same security mechanism,
then a security context may be established between them (subject to then a security context may be established between them (subject to
policy). However, GSS-API doesn't prescribe the method by which policy). However, GSS-API doesn't prescribe the method by which
GSS-API peers can establish whether they have a common security GSS-API peers can establish whether they have a common security
mechanism. mechanism.
skipping to change at page 9, line 28 skipping to change at page 9, line 28
This specifies that the tagging context for the module will be This specifies that the tagging context for the module will be
explicit and non-automatic. explicit and non-automatic.
The encoding of SPNEGO protocol messages shall obey the Distinguished The encoding of SPNEGO protocol messages shall obey the Distinguished
Encoding Rules (DER) of ASN.1 as described in [X690]. Encoding Rules (DER) of ASN.1 as described in [X690].
4.1 Mechanism Types 4.1 Mechanism Types
In this negotiation model, each OID represents one GSS-API mechanism In this negotiation model, each OID represents one GSS-API mechanism
or one variant of it according to [RFC2743]. or one variant (see Section 6) of it according to [RFC2743].
MechType ::= OBJECT IDENTIFIER MechType ::= OBJECT IDENTIFIER
-- OID represents each security mechanism as suggested by -- OID represents each security mechanism as suggested by
-- [RFC2743] -- [RFC2743]
MechTypeList ::= SEQUENCE OF MechType MechTypeList ::= SEQUENCE OF MechType
4.2 Negotiation Tokens 4.2 Negotiation Tokens
The syntax of the initial negotiation tokens follows the The syntax of the initial negotiation tokens follows the
skipping to change at page 11, line 19 skipping to change at page 11, line 19
negotiation message. negotiation message.
4.2.2 negTokenResp 4.2.2 negTokenResp
NegTokenResp ::= SEQUENCE { NegTokenResp ::= SEQUENCE {
negResult [0] ENUMERATED { negResult [0] ENUMERATED {
accept_completed (0), accept_completed (0),
accept_incomplete (1), accept_incomplete (1),
reject (2), reject (2),
request_mic (3) request_mic (3)
}, } OPTIONAL,
-- REQUIRED in the first reply from the target
supportedMech [1] MechType OPTIONAL, supportedMech [1] MechType OPTIONAL,
-- present only in the first reply from the target
responseToken [2] OCTET STRING OPTIONAL, responseToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL, mechListMIC [3] OCTET STRING OPTIONAL,
... ...
} }
This is the syntax for all subsequent negotiation messages. This is the syntax for all subsequent negotiation messages.
negResult negResult
This field contains the state of the negotiation. This can be: This field, if present, contains the state of the negotiation.
This can be:
accept_completed accept_completed
No further negotiation message from the peer is expected, No further negotiation message from the peer is expected,
and the security context is established for the sender. and the security context is established for the sender.
accept_incomplete accept_incomplete
At least one more negotiation message from the peer is At least one more negotiation message from the peer is
needed to establish the security context. needed to establish the security context.
reject reject
The sender terminates the negotiation. The sender terminates the negotiation.
request_mic request_mic
The sender indicates that the exchange of MIC tokens, as The sender indicates that the exchange of MIC tokens, as
described in Section 5, will be REQUIRED if per-message described in Section 5, will be REQUIRED if per-message
integrity services are available on the mechanism context to integrity services are available on the mechanism context to
be established. This value SHALL only be present in the be established. This value SHALL only be present in the
first reply from the target. first reply from the target.
This field is REQUIRED in the first reply from the target, and
it is OPTIONAL thereafter.
supportedMech supportedMech
This field SHALL only be present in the first reply from the This field SHALL only be present in the first reply from the
target. It is a choice from the mechanism(s) offered by the target. It is a choice from the mechanism(s) offered by the
initiator. initiator.
ResponseToken ResponseToken
The field, if present, contains tokens specific to the The field, if present, contains tokens specific to the
mechanism selected. mechanism selected.
skipping to change at page 13, line 25 skipping to change at page 13, line 25
context is fully established. context is fully established.
It is assumed that per-message integrity services are available on It is assumed that per-message integrity services are available on
the established mechanism context in the following procedure for the established mechanism context in the following procedure for
processing MIC tokens of the initiator's mechanism list. processing MIC tokens of the initiator's mechanism list.
a) The mechlistMIC token (or simply the MIC token) is computed a) The mechlistMIC token (or simply the MIC token) is computed
through invoking GSS_GetMIC(): the input context_handle is the through invoking GSS_GetMIC(): the input context_handle is the
established mechanism context, the input qop_req is 0, and the established mechanism context, the input qop_req is 0, and the
input message is the mechTypes field in the initial negotiation input message is the mechTypes field in the initial negotiation
message (only the "value" portion, omitting the tag and length, of message (only the DER encoding of type MechTypeList is included).
the ASN.1 encoding for that field is included).
b) If the selected mechanism uses an even number of mechanism tokens b) If the selected mechanism uses an even number of mechanism tokens
(namely the acceptor sends the last mechanism token), the acceptor (namely the acceptor sends the last mechanism token), the acceptor
does the following when emitting the negotiation message does the following when emitting the negotiation message
containing the last mechanism token: if the MIC token exchange is containing the last mechanism token: if the MIC token exchange is
not required, GSS_Accept_sec_context() either indicates not required, GSS_Accept_sec_context() either indicates
GSS_S_COMPLETE and does not include a mechlistMIC token, or GSS_S_COMPLETE and does not include a mechlistMIC token, or
indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token
and an accept_incomplete state; if the MIC token exchange is and an accept_incomplete state; if the MIC token exchange is
required, GSS_Accept_sec_context() indicates required, GSS_Accept_sec_context() indicates
skipping to change at page 14, line 23 skipping to change at page 14, line 19
(IV) If no mechlistMIC token was included, but the MIC token (IV) If no mechlistMIC token was included, but the MIC token
exchange is required, the negotiation SHALL be terminated. exchange is required, the negotiation SHALL be terminated.
GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
c) In the case that the chosen mechanism uses an odd number of c) In the case that the chosen mechanism uses an odd number of
mechanism tokens (namely the initiator sends the last mechanism mechanism tokens (namely the initiator sends the last mechanism
token), the initiator does the following when emitting the token), the initiator does the following when emitting the
negotiation message containing the last mechanism token: if the negotiation message containing the last mechanism token: if the
negResult state was request_mic in the first reply from the negResult state was request_mic in the first reply from the
target, a mechlistMIC token MUST be included, otherwise the target, a mechlistMIC token MUST be included, otherwise the
mechlistMIC token is OPTIONAL. GSS_Init_sec_context() indicates mechlistMIC token is OPTIONAL. In the case that the optimistic
GSS_S_CONTINUE_NEEDED. Initiators who wish to be compatible with mechanism token is the only mechanism token for the initiator's
legacy Windows SPNEGO implementations as described in Appendix B preferred mechanism, the mechlistMIC token is OPTIONAL.
shall not generate a mechlistMIC token when the MIC token exchange GSS_Init_sec_context() indicates GSS_S_CONTINUE_NEEDED.
is not required. The acceptor then processes the last mechanism Initiators who wish to be compatible with legacy Windows SPNEGO
token, and does one of the following: implementations as described in Appendix B shall not generate a
mechlistMIC token when the MIC token exchange is not required.
The acceptor then processes the last mechanism token, and does one
of the following:
(I) If a mechlistMIC token was included, and is correctly (I) If a mechlistMIC token was included, and is correctly
verified, GSS_Accept_sec_context() indicates GSS_S_COMPLETE. verified, GSS_Accept_sec_context() indicates GSS_S_COMPLETE.
The output negotiation message contains a mechlistMIC token, The output negotiation message contains a mechlistMIC token,
and an accept_complete state. The initiator MUST then verify and an accept_complete state. The initiator MUST then verify
this mechlistMIC token. this mechlistMIC token.
(II) If a mechlistMIC token was included but is incorrect, the (II) If a mechlistMIC token was included but is incorrect, the
negotiation SHALL be terminated. GSS_Accept_sec_context() negotiation SHALL be terminated. GSS_Accept_sec_context()
indicates GSS_S_DEFECTIVE_TOKEN. indicates GSS_S_DEFECTIVE_TOKEN.
(III) If no mechlistMIC token was included and the mechlistMIC (III) If no mechlistMIC token was included and the mechlistMIC
token exchange is not required, GSS_Accept_sec_context() token exchange is not required, GSS_Accept_sec_context()
indicates GSS_S_COMPLETE. The output negotiation message indicates GSS_S_COMPLETE. The output negotiation message
contains an accept_complete state. contains an accept_complete state.
(IV) If no mechlistMIC token was included and the acceptor sent a (IV) In the case that the optimistic mechanism token is also the
last mechanism token (when the initiator's preferred mechanism
is accepted by the target), and the target sends a request_mic
state, but the initiator did not send a mechlistMIC token, the
target then MUST include a mechlistMIC token in that first
reply. GSS_Accept_sec_context() indicates
GSS_S_CONTINUE_NEEDED. The initiator MUST verify the received
mechlistMIC token, and generate a mechlistMIC token to send
back to the target, who SHALL in turn verify the returned
mechlistMIC token and complete the negotiation.
(V) If no mechlistMIC token was included and the acceptor sent a
request_mic state in the first reply message (the exchange of request_mic state in the first reply message (the exchange of
MIC tokens is required), the negotiation SHALL be terminated. MIC tokens is required), the negotiation SHALL be terminated.
GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN. GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
6. Extensibility 6. Extensibility
Two mechanisms are provided by extensibility. First, the ASN.1 Two mechanisms are provided by extensibility. First, the ASN.1
structures in this specification MAY be expanded by IETF standards structures in this specification MAY be expanded by IETF standards
action. Implementations receiving unknown fields MUST ignore these action. Implementations receiving unknown fields MUST ignore these
fields. fields.
skipping to change at page 18, line 8 skipping to change at page 19, line 8
In all cases, the communicating peers are exposed to the denial of In all cases, the communicating peers are exposed to the denial of
service threat. service threat.
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. Acknowledgments 9. Acknowledgments
The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn, The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn,
Jeff Altman, Cristian Ilac and Martin Rex for their comments and Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments
suggestions on earlier versions of this document. and suggestions on earlier versions of this document.
Luke Howard provided a prototype of this protocol in Heimdal, and
resolved several issues in the initial draft.
Eric Baize and Denis Pinkas wrote the original SPNEGO specification Eric Baize and Denis Pinkas wrote the original SPNEGO specification
[RFC2478], of which some of the text has been retained in this [RFC2478], of which some of the text has been retained in this
document. document.
10 Normative References 10 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 22, line 23 skipping to change at page 23, line 23
identify the GSS-API Kerberos Version 5 mechanism. identify the GSS-API Kerberos Version 5 mechanism.
The following changes have been made to be compatible with these The following changes have been made to be compatible with these
legacy implementations. legacy implementations.
* NegTokenTarg is changed to negTokenResp and it is the message * NegTokenTarg is changed to negTokenResp and it is the message
format for all subsequent negotiation tokens. format for all subsequent negotiation tokens.
* NegTokenInit is the message for the initial token and that * NegTokenInit is the message for the initial token and that
token only. token only.
* mechTypes in negTokenInit is not optional. * mechTypes in negTokenInit is not optional.
* negResult is not optional in the negTokenResp token.
* Two MIC tokens are exchanged, one in each direction. * Two MIC tokens are exchanged, one in each direction.
* If the selected mechanism is also the most preferred mechanism * If the selected mechanism is also the most preferred mechanism
for both peers, it is safe to omit the MIC tokens. for both peers, it is safe to omit the MIC tokens.
If at least one of the two peers implements the pseudo mechanism If at least one of the two peers implements the pseudo mechanism
in this document, the negotiation is protected. in this document, the negotiation is protected.
The following changes are to address the problems in RFC 2478. The following changes are to address the problems in RFC 2478.
* reqFlags is not protected therefore it should not impact the * reqFlags is not protected therefore it should not impact the
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/