oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity

x

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@14624 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Love Hörnquist Åstrand
2005-03-07 17:25:58 +00:00
parent 842d538ec3
commit 3c06f39e98
6 changed files with 3756 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

784
doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-00.txt Normal file
View File

@@ -0,0 +1,784 @@
KITTEN WG N. Williams
Internet-Draft Sun
Expires: December 30, 2004 July 2004
Clarifications and Extensions to the GSS-API for the Use of Channel
Bindings
draft-ietf-kitten-gssapi-channel-bindings-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document clarifies and generalizes the GSS-API "channel
bindings" facility. This document also specifies the format of the
various types of channel bindings.
Williams Expires December 30, 2004 [Page 1]
Internet-Draft GSS-API Channel Bindings July 2004
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Generic Structure for GSS-API Channel Bindings . . . . . . . . 5
3.1 Proper Mechanism Use of Channel Bindings . . . . . . . . . 5
4. Channel Bindings for SSHv2 . . . . . . . . . . . . . . . . . . 6
4.1 GSS_Make_sshv2_channel_bindings() . . . . . . . . . . . . 6
4.1.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . 6
5. Channel Bindings for TLS . . . . . . . . . . . . . . . . . . . 7
5.1 GSS_Make_tls_channel_bindings() . . . . . . . . . . . . . 7
5.1.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . 7
6. Channel Bindings for IPsec . . . . . . . . . . . . . . . . . . 8
6.1 GSS_Make_ipsec_channel_bindings() . . . . . . . . . . . . 8
6.1.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 14
Williams Expires December 30, 2004 [Page 2]
Internet-Draft GSS-API Channel Bindings July 2004
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Williams Expires December 30, 2004 [Page 3]
Internet-Draft GSS-API Channel Bindings July 2004
2. Introduction
The concept of "channel bindings" and the abstract construction of
channel bindings for several types of channels are described in
[CHANNEL-BINDINGS]
To actually use channel bindings in GSS-API aplications additional
details are required that are given below.
First the structure given to channel bindings data in [RFC2744] is
generalized to all of the GSS-API, not just its C-Bindings.
Then the actual construction of channel bindings to SSHv2, TLS and
IPsec channels is given.
Williams Expires December 30, 2004 [Page 4]
Internet-Draft GSS-API Channel Bindings July 2004
3. Generic Structure for GSS-API Channel Bindings
The base GSS-API v2, update 1 specification [RFC2743]describes
channel bindings as an OCTET STRING and leaves it to the GSS-API v2,
update 1 C-Bindings specification to specify the structure of the
contents of the channel bindings OCTET STRINGs. The C-Bindings
specification [RFC2744]then defines, in terms of C, what should be
generic structure for channel bindings. The Kerberos V GSS mechanism
[RFC1964]then defines a method for encoding GSS channel bindings in a
way that is independent of the C-Bindings!
In other words, the structure of GSS channel bindings given in
[RFC2744] is actually generic, rather than specific to the C
programming language.
Here, then, is a generic re-statement of this structure, in
pseudo-ASN.1:
GSS-CHANNEL-BINDINGS := SEQUENCE {
initiator-address-type INTEGER,
initiator-address OCTET STRING,
acceptor-address-type INTEGER,
acceptor-address OCTET STRING,
application-data OCTET STRING,
}
The values for the address fields are described in [RFC2744].
Language-specific bindings of the GSS-API should specify a
language-specific formulation of this structure.
3.1 Proper Mechanism Use of Channel Bindings
As described in [CHANNEL-BINDINGS], GSS mechanisms should exchange
integrity protected proofs of channel bindings, where the proof is
obtained by running a strong hash of the channel bindings data
(encoded as per some mechanism-specific, such as in [RFC1964]) and a
binary value to represent the initiator->acceptor, and opposite,
direction.
The encoding of channel bindings used in [RFC1964], with the addition
of a binary value as described above, and the substitution of SHA-1
for MD5 is a reasonable, generic encoding of GSS-CHANNEL-BINDINGS
that any future GSS mechanisms can use.
Williams Expires December 30, 2004 [Page 5]
Internet-Draft GSS-API Channel Bindings July 2004
4. Channel Bindings for SSHv2
The SSHv2 channel bindings are constructed as an octet string for the
'application-data' field of the channel bindings by concatenating the
following values and in this order:
1. The ASCII string "GSS SSHv2 CB:"
2. The SSHv2 session ID
3. Any additional application-provided data, encoded as the DER
encoding of an ASN.1 OCTET STRING
4.1 GSS_Make_sshv2_channel_bindings()
Inputs:
o session_id OCTET STRING,
o additional_app_data OCTET STRING
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o channel_bindings_app_data OCTET STRING
Return major_status codes:
o GSS_S_COMPLETE indicates no error.
o GSS_S_FAILURE indicates failure to construct the channel bindings
as a result, perhaps, of a memory management, or similar failure.
This function constructs an OCTET STRING for use as the value of the
application-data field of the GSS-CHANNEL-BINDINGS structure
described above.
4.1.1 C-Bindings
OM_uint32 gss_make_sshv2_channel_bindings(
OM_uint32 *minor_status,
const gss_buffer_t session_id,
const gss_buffer_t additional_app_data,
gss_buffer_t channel_bindings_app_data
);
Williams Expires December 30, 2004 [Page 6]
Internet-Draft GSS-API Channel Bindings July 2004
5. Channel Bindings for TLS
The TLS channel bindings are constructed as an octet string for the
'application-data' field of the channel bindings by concatenating the
following values and in this order:
1. The ASCII string "GSS TLSv1.0 CB:"
2. The TLS finished message sent by the client
3. The TLS finished message sent by the server
4. Any additional application-provided data, encoded as the DER
encoding of an ASN.1 OCTET STRING
5.1 GSS_Make_tls_channel_bindings()
Inputs:
o client_finished_msg OCTET STRING,
o server_finished_msg OCTET STRING,
o additional_app_data OCTET STRING
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o channel_bindings_app_data OCTET STRING
Return major_status codes:
o GSS_S_COMPLETE indicates no error.
o GSS_S_FAILURE indicates failure to construct the channel bindings
as a result, perhaps, of a memory management, or similar failure.
This function constructs an OCTET STRING for use as the value of the
application-data field of the GSS-CHANNEL-BINDINGS structure
described above.
5.1.1 C-Bindings
OM_uint32 gss_make_tls_channel_bindings(
OM_uint32 *minor_status,
const gss_buffer_t client_finished_msg,
const gss_buffer_t server_finished_msg,
const gss_buffer_t additional_app_data,
gss_buffer_t channel_bindings_app_data
);
Williams Expires December 30, 2004 [Page 7]
Internet-Draft GSS-API Channel Bindings July 2004
6. Channel Bindings for IPsec
The IPsec channel bindings are constructed as an octet string for the
'application-data' field of the channel bindings by concatenating the
following values and in this order:
1. The ASCII string "GSS IPsec CB:"
2. The transform ID for encryption, as a 16-bit big-endian word
3. The transform ID for integrity protection, as 16-bit in
big-endian word
4. The initiator ID payload as used in the key exchange protocol
used for setting up the channel's SAs
5. The responder ID payload as used in the key exchange protocol
used for setting up the channel's SAs
6. Any additional application-provided data, encoded as the DER
encoding of an ASN.1 OCTET STRING
Note that traffic selectors are not included. Inclusion of
confidentiality/integrity algorithms protects against MITMs that can
compromise weaker algorithms that policy might permit, for the same
peers, for other traffic.
6.1 GSS_Make_ipsec_channel_bindings()
Inputs:
o encr_alg INTEGER,
o integ_alg INTEGER,
o initiator_id OCTET_STRING,
o acceptor_id OCTET_STRING,
o additional_app_data OCTET STRING
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o channel_bindings_app_data OCTET STRING
Return major_status codes:
o GSS_S_COMPLETE indicates no error.
o GSS_S_FAILURE indicates failure to construct the channel bindings
as a result, perhaps, of a memory management, or similar failure.
This function constructs an OCTET STRING for use as the value of the
application-data field of the GSS-CHANNEL-BINDINGS structure
described above.
Williams Expires December 30, 2004 [Page 8]
Internet-Draft GSS-API Channel Bindings July 2004
6.1.1 C-Bindings
OM_uint32 gss_make_ipsec_channel_bindings(
OM_uint32 *minor_status,
OM_uint32 encr_alg,
OM_uint32 integ_alg,
const gss_buffer_t initiator_id,
const gss_buffer_t acceptor_id,
const gss_buffer_t additional_app_data,
gss_buffer_t channel_bindings_app_data
);
Williams Expires December 30, 2004 [Page 9]
Internet-Draft GSS-API Channel Bindings July 2004
7. Security Considerations
For general security considerations relating to channel bindings see
[CHANNEL-BINDINGS]
Williams Expires December 30, 2004 [Page 10]
Internet-Draft GSS-API Channel Bindings July 2004
8. References
8.1 Normative
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
1964, June 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
8.2 Informative
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
(SPKM)", RFC 2025, October 1996.
[RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998.
[RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues
and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5",
RFC 2623, June 1999.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M. and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003.
Williams Expires December 30, 2004 [Page 11]
Internet-Draft GSS-API Channel Bindings July 2004
Author's Address
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
EMail: Nicolas.Williams@sun.com
Williams Expires December 30, 2004 [Page 12]
Internet-Draft GSS-API Channel Bindings July 2004
Appendix A. Acknowledgments
The author would like to thank Mike Eisler for his work on the
Channel Conjunction Mechanism I-D and for bringing the problem to a
head, Sam Hartman for pointing out that channel bindings provide a
general solution to the channel binding problem, Jeff Altman for his
suggestion of using the TLS finished messages as the TLS channel
bindings, Bill Sommerfeld, for his help in developing channel
bindings for IPsec, and Radia Perlman for her most helpful comments.
Williams Expires December 30, 2004 [Page 13]
Internet-Draft GSS-API Channel Bindings July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Williams Expires December 30, 2004 [Page 14]

393
doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-00.txt Normal file
View File

@@ -0,0 +1,393 @@
NETWORK WORKING GROUP N. Williams
Internet-Draft Sun
Expires: July 2, 2005 January 2005
Namespace Considerations and Registries for GSS-API Extensions
draft-ietf-kitten-gssapi-extensions-iana-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 2, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document describes the ways in which the GSS-API may be extended
and directs the creation of IANA registries for various GSS-API
namespaces.
Williams Expires July 2, 2005 [Page 1]
Internet-Draft GSS IANA Instructions January 2005
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extensions to the GSS-API . . . . . . . . . . . . . . . . . . 3
4. Generic GSS-API Namespaces . . . . . . . . . . . . . . . . . . 3
5. Language Binding-Specific GSS-API Namespaces . . . . . . . . . 4
6. Extension-Specific GSS-API Namespaces . . . . . . . . . . . . 4
7. Registration Form(s) . . . . . . . . . . . . . . . . . . . . . 4
8. Initial Namespace Registrations . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . 7
Williams Expires July 2, 2005 [Page 2]
Internet-Draft GSS IANA Instructions January 2005
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
There is a need for generic and mechanism-specific extensions to the
Generic Security Services Application Programming Interface
(GSS-API). As such extensions are designed and standardized, both at
the IETF and elsewhere, there is a non-trivial risk of namespace
pollution and conflicts. To avoid this we set out guidelines for
extending the GSS-API and create IANA registries of GSS-API
namespaces.
The registration of name prefixes and constant value ranges is
allowed so as to save the IANA the trouble of registering every
GSS-API name and constant, and to allow for reservation of portions
of some GSS namespaces for private extensions or extensions which
lack IETF Standards-Track extensions.
3. Extensions to the GSS-API
Extensions to the GSS-API can be categorized as follows:
o Generic
o Implementation-specific
o Mechanism-specific
o Language binding-specific
o Any combination of two or all three of the last three
Extensions to the GSS-API may be purely semantic, without effect on
the GSS-API's namespaces. Or they may introduce new functions,
constants, types, etc...; these clearly affect the GSS-API
namespaces.
Extensions that affect the GSS-API namespaces should be registered
with the IANA.
4. Generic GSS-API Namespaces
All the function, constant and type names, as well as all the
constant values specified in the base GSS-API specification for the
basic generic GSS-API namespace.
The generic GSS-API namespaces are:
o Type names
o Function names
Williams Expires July 2, 2005 [Page 3]
Internet-Draft GSS IANA Instructions January 2005
o Constant names for each type
o Constant values for each type
o Mechanism OIDs
o Name Type OIDs
o Mechanism Attribute OIDs (see [EXTENDED-INQUIRY])
5. Language Binding-Specific GSS-API Namespaces
<Add text; discuss header, module, library, class, method namespaces
and whatever else comes up that is language-specific and appropriate
for registration with the IANA.>
6. Extension-Specific GSS-API Namespaces
Extensions to the GSS-API may create additional namespaces.
Instructions to the IANA should included for the handling of such
namespaces.
7. Registration Form(s)
Registrations for GSS-API namespaces SHALL take the following form:
+----------------------+----------------------+---------------------+
| Registration Field | Possible Values | Description |
+----------------------+----------------------+---------------------+
| Registration type | 'Individual', | Indicates whether |
| | 'Prefix', 'Range' | this entry reserves |
| | | a given symbol name |
| | | or constant value |
| | | or whether it |
| | | reserves an entire |
| | | sub-namespace (the |
| | | name is a "prefix") |
| | | or constant value |
| | | range. |
| Bindings | 'Generic', | Indicates the |
| | 'C-bindings', | language bindings |
| | 'Java', 'C#', etc... | that this |
| | | registration is |
| | | for, or, if |
| | | 'Generic', that |
| | | this is an entry |
| | | for the generic |
| | | GSS-API, not |
| | | specific to any |
| | | programming |
| | | language. |
| Object Type | 'Symbol', | Indicates whether |
Williams Expires July 2, 2005 [Page 4]
Internet-Draft GSS IANA Instructions January 2005
| | 'Constant-Value' | this registration |
| | | is for a symbol |
| | | (e.g., function, |
| | | constant name(s)) |
| | | or constant value. |
| Object Programming | 'Data-Type', | Indicates the type |
| Type | 'Function', | of the object(s) |
| | 'Method', 'Integer', | whose symbolic name |
| | 'String', 'OID' | or constant value |
| | | is this entry |
| | | registers. |
| Object Name | <Symbol name or name | The name(s) of |
| | prefix> | symbols or values |
| | | being registered. |
| Object Value | <Constant value> or | [Only for |
| | <constant value | Constant-Value |
| | range> | registrations.] The |
| | | value(s) |
| | | registered. |
| Description | <Text> | Description of |
| | | object(s) being |
| | | registered. |
| Reference | <Reference> | Reference to |
| | | document that |
| | | describes the |
| | | object(s) being |
| | | registered. |
| Status | 'Standards-Track', | |
| | 'Informational', | |
| | 'Experimental', | |
| | 'Obsolete' | |
+----------------------+----------------------+---------------------+
The IANA should create a single GSS-API namespace registry, or
multiple registries, one for symbolic names and one for constant
values, or it may create a registry per-programming language, at its
convenience.
Entries in these registries should consist of all the fields from
their corresponding registration entries.
Entries SHOULD be sorted by object type, proggamming language, symbol
name.
<Add text on guidelines for IANA consideration of registration
applications, particularly with respect to entries lacking normative
references, "magic" entries (e.g., special values of 'time' types
which indicate something other than absolute or relative time, such
Williams Expires July 2, 2005 [Page 5]
Internet-Draft GSS IANA Instructions January 2005
as GSS_C_INDEFINITE), expert review requirements (if any) for
registrations lacking normative references, etc....>
8. Initial Namespace Registrations
<Add registration entries for namespaces (name prefixes) for RFC2743/
RFC2744/RFC2853.>
<Add registration entries for private namespaces (name prefixes) for
implementation- and/or platform-specific extensions.>
9. Security Considerations
This document has no security considerations.
10 Normative
[EXTENDED-INQUIRY]
Williams, N., "Extended Generic Security Service Mechanism
Inquiry APIs",
draft-ietf-kitten-extended-mech-inquiry-00.txt (work in
progress).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
Author's Address
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
EMail: Nicolas.Williams@sun.com
Williams Expires July 2, 2005 [Page 6]
Internet-Draft GSS IANA Instructions January 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Williams Expires July 2, 2005 [Page 7]

505
doc/standardisation/draft-ietf-kitten-gssapi-prf-02.txt Normal file
View File

@@ -0,0 +1,505 @@
NETWORK WORKING GROUP N. Williams
Internet-Draft Sun
Expires: December 30, 2004 July 2004
A PRF API extension for the GSS-API
draft-ietf-kitten-gssapi-prf-02.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines a Pseudo-Random Function (PRF) extension to the
Generic Security Service Applicatoin Programming Interface (GSS-API)
for keying application protocols given an established GSS-API
security context. The primary intended use of this function is to
key secure session layers that don't or cannot use GSS-API
per-message MIC (message integrity check) and wrap tokens for session
protection.
Williams Expires December 30, 2004 [Page 1]
Internet-Draft A PRF Extension for the GSS-API July 2004
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. GSS_Pseudo_random() . . . . . . . . . . . . . . . . . . . . . 5
3.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Normative References . . . . . . . . . . . . . . . . . . . . . 8
5.2 Informative References . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 9
Williams Expires December 30, 2004 [Page 2]
Internet-Draft A PRF Extension for the GSS-API July 2004
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Williams Expires December 30, 2004 [Page 3]
Internet-Draft A PRF Extension for the GSS-API July 2004
2. Introduction
A need has arisen for users of the GSS-API to key applications'
cryptographic protocols using established GSS-API security contexts.
Such applications can use the GSS-API for authentication, but not for
transport security (for whatever reasons), and since the GSS-API does
not provide a method for obtaining keying material from established
security contexts such applications cannot make effective use of the
GSS-API.
To address this need we define a pseudo-random function (PRF)
extension to the GSS-API.
Williams Expires December 30, 2004 [Page 4]
Internet-Draft A PRF Extension for the GSS-API July 2004
3. GSS_Pseudo_random()
Inputs:
o context CONTEXT handle,
o prf_in OCTET STRING,
o desired_output_len INTEGER
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o prf_out OCTET STRING
Return major_status codes:
o GSS_S_COMPLETE indicates no error.
o GSS_S_NO_CONTEXT indicates that a null context has been provided
as input.
o GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
provided as input.
o GSS_S_UNAVAILABLE indicates that the mechanism lacks support for
this function or, if the security context is not fully
established, that the context is not ready to compute the PRF.
o GSS_S_FAILURE indicates failure or lack of support; the minor
status code may provide additional information.
This function applies the established context's mechanism's keyed PRF
function to the input data (prf_in), keyed with key material
associated with the given security context and outputs the resulting
octet string (prf_out) of desired_output_len length.
The output string of this function MUST be a pseudo-random function
[GGM1][GGM2] of the input keyed with key material from the
established security context -- the chances of getting the same
output given different input parameters should be exponentially
small.
This function, applied to the same inputs by an initiator and
acceptor using the same established context, MUST produce the *same
results* for both, the initiator and acceptor, even if called
multiple times for the same context.
Mechanisms MAY limit the output of the PRF according, possibly in
ways related to the types of cryptographic keys available for the PRF
function, thus the prf_out output of GSS_Pseudo_random() MAY be
smaller than requested.
Mechanisms may be able to compute PRFs with security contexts that
Williams Expires December 30, 2004 [Page 5]
Internet-Draft A PRF Extension for the GSS-API July 2004
are not fully established, therefore applications MAY call
GSS_Pseudo_random() with such security contexts. Such mechanisms
MUST return GSS_S_UNAVAILABLE when called on to compute a PRF given a
security context that is not fully established and also not ready for
PRF computation. Mechanisms that allow for PRF computation prior to
full security context establishment MUST use the same PRF and key
material, for any given security context, both, before and after full
context establishment, and the PRF and key material negotiation MUT
be authenticated when the security context is fully established.
3.1 C-Bindings
OM_uint32 gss_pseudo_random(
OM_uint32 *minor_status,
gss_ctx_id_t context,
const gss_buffer_t prf_in,
ssize_t desired_output_len,
gss_buffer_t prf_out
);
Williams Expires December 30, 2004 [Page 6]
Internet-Draft A PRF Extension for the GSS-API July 2004
4. Security Considerations
Care should be taken in properly designing a mechanism's PRF
function.
GSS mechanisms' PRF functions should use a key derived from contexts'
session keys and should preserve the forward security properties of
the mechanisms' key exchanges.
Some mechanisms may support the GSS PRF function with security
contexts that are not fully established, but applications MUST assume
that authentication, mutual or otherwise, has not completed until the
security context is fully established
Williams Expires December 30, 2004 [Page 7]
Internet-Draft A PRF Extension for the GSS-API July 2004
5. References
5.1 Normative References
[GGM1] Goldreich, O., Goldwasser, S. and S. Micali, "How to
Construct Random Functions", October 1986.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
5.2 Informative References
[GGM2] Goldreich, O., Goldwasser, S. and S. Micali, "On the
Cryptographic Applications of Random Functions", 1985.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
Author's Address
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
EMail: Nicolas.Williams@sun.com
Williams Expires December 30, 2004 [Page 8]
Internet-Draft A PRF Extension for the GSS-API July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Williams Expires December 30, 2004 [Page 9]

560
doc/standardisation/draft-ietf-kitten-gssapi-store-cred-00.txt Normal file
View File

@@ -0,0 +1,560 @@
NETWORK WORKING GROUP N. Williams
Internet-Draft Sun
Expires: August 15, 2005 February 14, 2005
GSS-API Extension for Storing Delegated Credentials
draft-ietf-kitten-gssapi-store-cred-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document defines a new function for the GSS-API which allows
applications to store delegated (and other) credentials in the
implicit GSS-API credential store. This is needed for GSS-API
applications to use delegated credentials as they would use other
credentials.
Williams Expires August 15, 2005 [Page 1]
Internet-Draft GSS_Store_cred() February 2005
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 5
4. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security considerations . . . . . . . . . . . . . . . . . . . 9
7. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Williams Expires August 15, 2005 [Page 2]
Internet-Draft GSS_Store_cred() February 2005
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Williams Expires August 15, 2005 [Page 3]
Internet-Draft GSS_Store_cred() February 2005
2. Introduction
The GSS-API [RFC2743] clearly assumes that credentials exist in an
implicit store whence they can be acquired using GSS_Acquire_cred()
and GSS_Add_cred() or through use of the default credential.
Multiple credential stores may exist on a given host, but only one
store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any
given time.
This assumption can be seen in sections 1.1.1.2 and 1.1.1.3 of
[RFC2743] as well as in section 3.5 of [RFC2744].
Note to the RFC editor: please remove this note before publication.]
Applications may be able to change the credential store from which
credentials can be acquired, either by changing user contexts (where
the applications have the privilege to do so) or by other means
(where a user may have multiple credential stores).
Some GSS-API acceptor applications always change user contexts, after
accepting a GSS-API security context and making appropriate
authorization checks, to the user context corresponding to the
initiator principal name or to a context requested by the initiator.
The means by which credential stores are managed are generally beyond
the scope of the GSS-API.
In the case of delegated credential handles however, such credentials
do not exist in the acceptor's credential store or in the credential
stores of the user contexts to which the acceptor application might
change - which is precisely the raison d'etre of credential
delegation. But the GSS-API provides no mechanism by which delegated
credential handles can be made available for acquisition through
GSS_Acquire_cred()/GSS_Add_cred(). The GSS-API also does not provide
any credential import/export interfaces like the GSS-API context
import/export interfaces.
Thus acceptors are limited to making only direct use of delegated
credential handles and only with GSS_Init_sec_context(),
GSS_Inquire_cred*() and GSS_Release_cred(). This limitation is
particularly onerous on Unix systems where a call to exec() to
replace the process image obliterates the delegated credentials
handle.
In order to make delegated credentials generally as useful as
credentials that can be acquired with GSS_Acquire_cred() and
GSS_Add_cred() a primitive is needed which allows storing of
credentials in the implicit credential store. This primitive we call
"GSS_Store_cred()."
Williams Expires August 15, 2005 [Page 4]
Internet-Draft GSS_Store_cred() February 2005
3. GSS_Store_cred()
Inputs:
o input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST
NOT be GSS_C_NO_CREDENTIAL
o cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
2=ACCEPT-ONLY
o desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID then
store all the elements of the input_cred_handle, otherwise store
only the element of the corresponding mechanism
o overwrite_cred BOOLEAN, -- if TRUE replace any credential for the
same principal in the credential store
o default_cred BOOLEAN -- if TRUE make the stored credential
available as the default credential (for acquisition with
GSS_C_NO_NAME as the desired name or for use as
GSS_C_NO_CREDENTIAL)
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of
mechanism OIDs for which credential elements were successfully
stored
o cred_usage_stored INTEGER -- like cred_usage, but indicates what
kind of credential was stored (useful when the cred_usage input
parameter is set to INITIATE-AND-ACCEPT)
Return major_status codes:
o GSS_S_COMPLETE indicates that the credentials were successfully
stored.
o GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials had
expired or expired before they could be stored.
o GSS_S_NO_CRED indicates that no input credentials were given.
o GSS_S_UNAVAILABLE indicates that the credential store is not
available.
o GSS_S_DUPLICATE_ELEMENT indicates that an element of the input
credential could not be stored because a credential for the same
principal exists in the current credential store and the
overwrite_cred input argument was FALSE.
o GSS_S_FAILURE indicates that the credential could not be stored
for some other reason. The minor status code may provide more
information if a non-GSS_C_NULL_OID desired_mech_element was
given.
GSS_Store_cred() is used to store, in the current credential store, a
given credential that has either been acquired from a different
credential store or been accepted as a delegated credential.
Williams Expires August 15, 2005 [Page 5]
Internet-Draft GSS_Store_cred() February 2005
Specific mechanism elements of a credential can be stored one at a
time by specifying a non-GSS_C_NULL_OID mechanism OID as the
desired_mech_element input argument, in which case the minor status
output SHOULD have a mechanism-specific value when the major status
is not GSS_S_COMPLETE.
The initiator, acceptor or both usages of the input credential may be
stored as per the cred_usage input argument.
The credential elements that were actually stored, when the major
status is GSS_S_COMPLETE, are indicated through the cred_usage_stored
and mech_elements_stored function outputs.
If credentials already exist in the current store for the principal
of the input_cred_handle, then those credentials are not replaced
with the input credentials unless the overwrite_cred input argument
is TRUE.
Finally, if the current credential store has no default credential
(that is, no credential that could be acquired for GSS_C_NO_NAME) or
if the default_cred input argument is TRUE, and the input credential
can be successfully stored, then the input credential will be
available for acquisition with GSS_C_NO_NAME as the desired name
input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as
GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(),
GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and
GSS_Accept_sec_context().
Williams Expires August 15, 2005 [Page 6]
Internet-Draft GSS_Store_cred() February 2005
4. C-Bindings
The C-bindings for GSS_Store_cred() make use of types from and are
designed based on the style of the GSS-APIv2 C-Bindings [RFC2744].
OM_uint32 gss_store_cred(
OM_uint32 *minor_status,
gss_cred_id_t input_cred,
gss_cred_usage_t cred_usage,
const gss_OID desired_mech,
OM_uint32 overwrite_cred,
OM_uint32 default_cred,
gss_OID_set *elements_stored,
gss_cred_usage_t *cred_usage_stored)
Figure 1
The two boolean arguments, 'overwrite_cred' and 'default_cred' are
typed as OM_uint32; 0 corresponds to FALSE, non-zero values
correspond to TRUE.
Williams Expires August 15, 2005 [Page 7]
Internet-Draft GSS_Store_cred() February 2005
5. Examples
The intended usage of GSS_Store_cred() is to make delegated
credentials available to child processes of GSS-API acceptor
applications. Example pseudo-code:
/*
* <GSS_Accept_sec_context() loop resulting in GSS_S_COMPLETE,
* an initiator name (hereafter, "src_name") and a delegated
* credential handle (hereafter "deleg_cred").>
*
* <"requested_username" is a username derived from the
* initiator name or explicitly requested by the initiator
* application.>
*/
...
if (authorize_gss_client(src_name, requested_username)) {
/*
* For Unix-type platforms this may mean calling setuid() and
* it may or may not also mean setting/unsetting such
* environment variables as KRB5CCNAME and what not.
*/
if (change_user_context(requested_username))
(void) gss_store_creds(&minor_status, deleg_cred,
GSS_C_INITIATE, actual_mech,
0, 1, NULL, NULL);
}
else ...
}
else ...
Williams Expires August 15, 2005 [Page 8]
Internet-Draft GSS_Store_cred() February 2005
6. Security considerations
Acceptor applications MUST only store delegated credentials into
appropriate credential stores and only after proper authorization of
the authenticated initiator principal to the requested service(s).
Acceptor applications that have no use for delegated credentials MUST
release them (such acceptor applications that use the GSS-API
C-Bindings may simply provide a NULL value for the
delegated_cred_handle argument to gss_accept_sec_context()).
7 Normative
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
Author's Address
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
EMail: Nicolas.Williams@sun.com
Williams Expires August 15, 2005 [Page 9]
Internet-Draft GSS_Store_cred() February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Williams Expires August 15, 2005 [Page 10]

1121
doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-00.txt Normal file
View File

File diff suppressed because it is too large Load Diff

393
doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-02.txt Normal file
View File

@@ -0,0 +1,393 @@
NETWORK WORKING GROUP N. Williams
Internet-Draft Sun
Expires: December 30, 2004 July 2004
A PRF for the Kerberos V GSS-API Mechanism
draft-ietf-kitten-krb5-gssapi-prf-02.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines the Pseudo-Random Function (PRF) for the
Kerberos V mechanism for the Generic Security Service Application
Programming Interface (GSS-API), based on the PRF defined for the
Kerberos V cryptographic framework, for keying application protocols
given an established Kerberos V GSS-API security context.
Williams Expires December 30, 2004 [Page 1]
Internet-Draft A PRF for the Kerberos V Mech July 2004
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . . 3
2. Kerberos V GSS Mechanism PRF . . . . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
4. Normative References . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
Intellectual Property and Copyright Statements . . . . . . . . . 7
Williams Expires December 30, 2004 [Page 2]
Internet-Draft A PRF for the Kerberos V Mech July 2004
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Williams Expires December 30, 2004 [Page 3]
Internet-Draft A PRF for the Kerberos V Mech July 2004
2. Kerberos V GSS Mechanism PRF
The GSS-API PRF [GSS-PRF] function for the Kerberos V mechanism [CFX]
shall be the output of a PRF+ function based on the enctype's PRF
function keyed with the negotiated session key of the security
context and key usage X (TBD).
The security context MUST be fully established, else the mechanism
MUST fail with GSS_S_UNAVAILABLE as the major status code and
GSS_KRB5_S_KG_CTX_INCOMPLETE as the minor status code.
This PRF+ MUST be keyed with a key derived, with key usage (TBD),
from the session used by the initiator and acceptor, after the
security context is fully established, to derive keys for per-message
tokens. For the current Kerberos V mechanism [CFX] this means that
the PRF+ MUST be keyed with the acceptor-asserted subkey, if it did
assert such a key, or the initiator's sub-session key otherwise.
The PRF+ function is a simple counter-based extension of the Kerberos
V pseudo-random function [KRB5-CRYPTO] for the enctype of the
security context's keys:
PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
Tn = pseudo-random-function(K, n || S)
where '||' is the concatenation operator, 'n' is encoded as a
network byte order 32-bit unsigned binary number, and where
truncate(L, S) truncates the input octet string S to length L.
The maximum output size of the Kerberos V mechanism's GSS-API PRF
then is, necessarily, 2^32 octets.
Implementations MUST support output size of up to 2^14 octets at
least.
If the implementation cannot produce the desired output then it MUST
output what it can.
The minimum input octet string length that implementations MUST
support is also 2^14 octets. If the input octet string is longer
than the maximum that an implementation can process then the
implementation MUST fail with GSS_S_FAILURE as the major status code
and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status code.
Williams Expires December 30, 2004 [Page 4]
Internet-Draft A PRF for the Kerberos V Mech July 2004
3. Security Considerations
Kerberos V enctypes' PRF functions use a key derived from contexts'
session keys and should preserve the forward security properties of
the mechanisms' key exchanges.
Legacy Kerberos V enctypes may be weak, particularly the single-DES
enctypes.
See also [GSS-PRF] for generic security considerations of
GSS_Pseudo_random().
The computational cost of computing this PRF+ may vary depending on
the Kerberos V enctypes being used, but generally the computation of
this PRF+ gets more expensive as the input and output octet string
lengths grow (note that the use of a counter in the PRF+ construction
allows for parallelization). This means that if an application can
be tricked into providing very large input octet strings and
requesting very long output octet strings then that may constitue a
denial of service attack on the application; therefore applications
SHOULD place appropriate limits on the size of any input octet
strings received from their peers without integrity protection.
4 Normative References
[CFX] Zhu, L., Jaganathan, K. and S. Hartman, "The Kerberos
Version 5 GSS-API Mechanism: Version 2".
[GSS-PRF] Williams, N., "A PRF API extension for the GSS-API".
[KRB5-CRYPTO]
Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
Author's Address
Nicolas Williams
Sun Microsystems
Williams Expires December 30, 2004 [Page 5]
Internet-Draft A PRF for the Kerberos V Mech July 2004
5300 Riata Trace Ct
Austin, TX 78727
US
EMail: Nicolas.Williams@sun.com
Williams Expires December 30, 2004 [Page 6]
Internet-Draft A PRF for the Kerberos V Mech July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Williams Expires December 30, 2004 [Page 7]