idnits 2.17.1 draft-ietf-kitten-rfc5653bis-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 9, 2018) is 2266 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2853 (Obsoleted by RFC 5653) ** Obsolete normative reference: RFC 5653 (Obsoleted by RFC 8353) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Upadhyay 3 Internet-Draft Google 4 Obsoletes: 5653 (if approved) S. Malkani 5 Intended status: Standards Track ActivIdentity 6 Expires: August 13, 2018 W. Wang 7 Oracle 8 February 9, 2018 10 Generic Security Service API Version 2: Java Bindings Update 11 draft-ietf-kitten-rfc5653bis-07 13 Abstract 15 The Generic Security Services Application Program Interface (GSS-API) 16 offers application programmers uniform access to security services 17 atop a variety of underlying cryptographic mechanisms. This document 18 updates the Java bindings for the GSS-API that are specified in 19 "Generic Security Service API Version 2 : Java Bindings Update" (RFC 20 5653). This document obsoletes RFC 5653 by adding a new output token 21 field to the GSSException class so that when the initSecContext or 22 acceptSecContext methods of the GSSContext class fails it has a 23 chance to emit an error token which can be sent to the peer for 24 debugging or informational purpose. The stream-based GSSContext 25 methods are also removed in this version. 27 The GSS-API is described at a language-independent conceptual level 28 in "Generic Security Service Application Program Interface Version 2, 29 Update 1" (RFC 2743). The GSS-API allows a caller application to 30 authenticate a principal identity, to delegate rights to a peer, and 31 to apply security services such as confidentiality and integrity on a 32 per-message basis. Examples of security mechanisms defined for GSS- 33 API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The 34 Kerberos Version 5 Generic Security Service Application Program 35 Interface (GSS-API) Mechanism: Version 2" (RFC 4121). 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on August 13, 2018. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 This document may contain material from IETF Documents or IETF 70 Contributions published or made publicly available before November 71 10, 2008. The person(s) controlling the copyright in some of this 72 material may not have granted the IETF Trust the right to allow 73 modifications of such material outside the IETF Standards Process. 74 Without obtaining an adequate license from the person(s) controlling 75 the copyright in such materials, this document may not be modified 76 outside the IETF Standards Process, and derivative works of it may 77 not be created outside the IETF Standards Process, except to format 78 it for publication as an RFC or to translate it into languages other 79 than English. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 84 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 7 85 3. GSS-API Operational Paradigm . . . . . . . . . . . . . . . . 7 86 4. Additional Controls . . . . . . . . . . . . . . . . . . . . . 8 87 4.1. Delegation . . . . . . . . . . . . . . . . . . . . . . . 10 88 4.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 10 89 4.3. Replay and Out-of-Sequence Detection . . . . . . . . . . 11 90 4.4. Anonymous Authentication . . . . . . . . . . . . . . . . 12 91 4.5. Integrity and Confidentiality . . . . . . . . . . . . . . 13 92 4.6. Inter-process Context Transfer . . . . . . . . . . . . . 13 93 4.7. The Use of Incomplete Contexts . . . . . . . . . . . . . 14 94 5. Calling Conventions . . . . . . . . . . . . . . . . . . . . . 14 95 5.1. Package Name . . . . . . . . . . . . . . . . . . . . . . 14 96 5.2. Provider Framework . . . . . . . . . . . . . . . . . . . 14 97 5.3. Integer Types . . . . . . . . . . . . . . . . . . . . . . 15 98 5.4. Opaque Data Types . . . . . . . . . . . . . . . . . . . . 15 99 5.5. Strings . . . . . . . . . . . . . . . . . . . . . . . . . 16 100 5.6. Object Identifiers . . . . . . . . . . . . . . . . . . . 16 101 5.7. Object Identifier Sets . . . . . . . . . . . . . . . . . 16 102 5.8. Credentials . . . . . . . . . . . . . . . . . . . . . . . 17 103 5.9. Contexts . . . . . . . . . . . . . . . . . . . . . . . . 18 104 5.10. Authentication Tokens . . . . . . . . . . . . . . . . . . 19 105 5.11. Inter-Process Tokens . . . . . . . . . . . . . . . . . . 19 106 5.12. Error Reporting . . . . . . . . . . . . . . . . . . . . . 20 107 5.12.1. GSS Status Codes . . . . . . . . . . . . . . . . . . 20 108 5.12.2. Mechanism-Specific Status Codes . . . . . . . . . . 22 109 5.12.3. Supplementary Status Codes . . . . . . . . . . . . . 23 110 5.13. Names . . . . . . . . . . . . . . . . . . . . . . . . . . 23 111 5.14. Channel Bindings . . . . . . . . . . . . . . . . . . . . 26 112 5.15. Optional Parameters . . . . . . . . . . . . . . . . . . . 27 113 6. Introduction to GSS-API Classes and Interfaces . . . . . . . 27 114 6.1. GSSManager Class . . . . . . . . . . . . . . . . . . . . 27 115 6.2. GSSName Interface . . . . . . . . . . . . . . . . . . . . 28 116 6.3. GSSCredential Interface . . . . . . . . . . . . . . . . . 29 117 6.4. GSSContext Interface . . . . . . . . . . . . . . . . . . 30 118 6.5. MessageProp Class . . . . . . . . . . . . . . . . . . . . 32 119 6.6. GSSException Class . . . . . . . . . . . . . . . . . . . 32 120 6.7. Oid Class . . . . . . . . . . . . . . . . . . . . . . . . 32 121 6.8. ChannelBinding Class . . . . . . . . . . . . . . . . . . 32 122 7. Detailed GSS-API Class Description . . . . . . . . . . . . . 33 123 7.1. public abstract class GSSManager . . . . . . . . . . . . 33 124 7.1.1. getInstance . . . . . . . . . . . . . . . . . . . . . 34 125 7.1.2. getMechs . . . . . . . . . . . . . . . . . . . . . . 34 126 7.1.3. getNamesForMech . . . . . . . . . . . . . . . . . . . 34 127 7.1.4. getMechsForName . . . . . . . . . . . . . . . . . . . 35 128 7.1.5. createName . . . . . . . . . . . . . . . . . . . . . 35 129 7.1.6. createName . . . . . . . . . . . . . . . . . . . . . 35 130 7.1.7. createName . . . . . . . . . . . . . . . . . . . . . 36 131 7.1.8. createName . . . . . . . . . . . . . . . . . . . . . 37 132 7.1.9. createCredential . . . . . . . . . . . . . . . . . . 37 133 7.1.10. createCredential . . . . . . . . . . . . . . . . . . 38 134 7.1.11. createCredential . . . . . . . . . . . . . . . . . . 38 135 7.1.12. createContext . . . . . . . . . . . . . . . . . . . . 39 136 7.1.13. createContext . . . . . . . . . . . . . . . . . . . . 40 137 7.1.14. createContext . . . . . . . . . . . . . . . . . . . . 40 138 7.1.15. addProviderAtFront . . . . . . . . . . . . . . . . . 40 139 7.1.15.1. addProviderAtFront Example Code . . . . . . . . 41 140 7.1.16. addProviderAtEnd . . . . . . . . . . . . . . . . . . 42 141 7.1.16.1. addProviderAtEnd Example Code . . . . . . . . . 43 142 7.1.17. Example Code . . . . . . . . . . . . . . . . . . . . 44 143 7.2. public interface GSSName . . . . . . . . . . . . . . . . 44 144 7.2.1. Static Constants . . . . . . . . . . . . . . . . . . 44 145 7.2.2. equals . . . . . . . . . . . . . . . . . . . . . . . 45 146 7.2.3. equals . . . . . . . . . . . . . . . . . . . . . . . 45 147 7.2.4. canonicalize . . . . . . . . . . . . . . . . . . . . 46 148 7.2.5. export . . . . . . . . . . . . . . . . . . . . . . . 46 149 7.2.6. toString . . . . . . . . . . . . . . . . . . . . . . 46 150 7.2.7. getStringNameType . . . . . . . . . . . . . . . . . . 47 151 7.2.8. isAnonymous . . . . . . . . . . . . . . . . . . . . . 47 152 7.2.9. isMN . . . . . . . . . . . . . . . . . . . . . . . . 47 153 7.2.10. Example Code . . . . . . . . . . . . . . . . . . . . 47 154 7.3. public interface GSSCredential implements Cloneable . . . 48 155 7.3.1. Static Constants . . . . . . . . . . . . . . . . . . 49 156 7.3.2. dispose . . . . . . . . . . . . . . . . . . . . . . . 50 157 7.3.3. getName . . . . . . . . . . . . . . . . . . . . . . . 50 158 7.3.4. getName . . . . . . . . . . . . . . . . . . . . . . . 50 159 7.3.5. getRemainingLifetime . . . . . . . . . . . . . . . . 50 160 7.3.6. getRemainingInitLifetime . . . . . . . . . . . . . . 51 161 7.3.7. getRemainingAcceptLifetime . . . . . . . . . . . . . 51 162 7.3.8. getUsage . . . . . . . . . . . . . . . . . . . . . . 51 163 7.3.9. getUsage . . . . . . . . . . . . . . . . . . . . . . 52 164 7.3.10. getMechs . . . . . . . . . . . . . . . . . . . . . . 52 165 7.3.11. add . . . . . . . . . . . . . . . . . . . . . . . . . 52 166 7.3.12. equals . . . . . . . . . . . . . . . . . . . . . . . 53 167 7.3.13. Example Code . . . . . . . . . . . . . . . . . . . . 53 168 7.4. public interface GSSContext . . . . . . . . . . . . . . . 54 169 7.4.1. Static Constants . . . . . . . . . . . . . . . . . . 55 170 7.4.2. initSecContext . . . . . . . . . . . . . . . . . . . 55 171 7.4.3. acceptSecContext . . . . . . . . . . . . . . . . . . 56 172 7.4.4. isEstablished . . . . . . . . . . . . . . . . . . . . 57 173 7.4.5. dispose . . . . . . . . . . . . . . . . . . . . . . . 57 174 7.4.6. getWrapSizeLimit . . . . . . . . . . . . . . . . . . 57 175 7.4.7. wrap . . . . . . . . . . . . . . . . . . . . . . . . 58 176 7.4.8. unwrap . . . . . . . . . . . . . . . . . . . . . . . 59 177 7.4.9. getMIC . . . . . . . . . . . . . . . . . . . . . . . 60 178 7.4.10. verifyMIC . . . . . . . . . . . . . . . . . . . . . . 60 179 7.4.11. export . . . . . . . . . . . . . . . . . . . . . . . 61 180 7.4.12. requestMutualAuth . . . . . . . . . . . . . . . . . . 62 181 7.4.13. requestReplayDet . . . . . . . . . . . . . . . . . . 62 182 7.4.14. requestSequenceDet . . . . . . . . . . . . . . . . . 62 183 7.4.15. requestCredDeleg . . . . . . . . . . . . . . . . . . 63 184 7.4.16. requestAnonymity . . . . . . . . . . . . . . . . . . 63 185 7.4.17. requestConf . . . . . . . . . . . . . . . . . . . . . 63 186 7.4.18. requestInteg . . . . . . . . . . . . . . . . . . . . 64 187 7.4.19. requestLifetime . . . . . . . . . . . . . . . . . . . 64 188 7.4.20. setChannelBinding . . . . . . . . . . . . . . . . . . 64 189 7.4.21. getCredDelegState . . . . . . . . . . . . . . . . . . 64 190 7.4.22. getMutualAuthState . . . . . . . . . . . . . . . . . 65 191 7.4.23. getReplayDetState . . . . . . . . . . . . . . . . . . 65 192 7.4.24. getSequenceDetState . . . . . . . . . . . . . . . . . 65 193 7.4.25. getAnonymityState . . . . . . . . . . . . . . . . . . 65 194 7.4.26. isTransferable . . . . . . . . . . . . . . . . . . . 65 195 7.4.27. isProtReady . . . . . . . . . . . . . . . . . . . . . 66 196 7.4.28. getConfState . . . . . . . . . . . . . . . . . . . . 66 197 7.4.29. getIntegState . . . . . . . . . . . . . . . . . . . . 66 198 7.4.30. getLifetime . . . . . . . . . . . . . . . . . . . . . 66 199 7.4.31. getSrcName . . . . . . . . . . . . . . . . . . . . . 66 200 7.4.32. getTargName . . . . . . . . . . . . . . . . . . . . . 67 201 7.4.33. getMech . . . . . . . . . . . . . . . . . . . . . . . 67 202 7.4.34. getDelegCred . . . . . . . . . . . . . . . . . . . . 67 203 7.4.35. isInitiator . . . . . . . . . . . . . . . . . . . . . 67 204 7.4.36. Example Code . . . . . . . . . . . . . . . . . . . . 67 205 7.5. public class MessageProp . . . . . . . . . . . . . . . . 69 206 7.5.1. Constructors . . . . . . . . . . . . . . . . . . . . 70 207 7.5.2. getQOP . . . . . . . . . . . . . . . . . . . . . . . 70 208 7.5.3. getPrivacy . . . . . . . . . . . . . . . . . . . . . 70 209 7.5.4. getMinorStatus . . . . . . . . . . . . . . . . . . . 70 210 7.5.5. getMinorString . . . . . . . . . . . . . . . . . . . 70 211 7.5.6. setQOP . . . . . . . . . . . . . . . . . . . . . . . 71 212 7.5.7. setPrivacy . . . . . . . . . . . . . . . . . . . . . 71 213 7.5.8. isDuplicateToken . . . . . . . . . . . . . . . . . . 71 214 7.5.9. isOldToken . . . . . . . . . . . . . . . . . . . . . 71 215 7.5.10. isUnseqToken . . . . . . . . . . . . . . . . . . . . 71 216 7.5.11. isGapToken . . . . . . . . . . . . . . . . . . . . . 71 217 7.5.12. setSupplementaryStates . . . . . . . . . . . . . . . 72 218 7.6. public class ChannelBinding . . . . . . . . . . . . . . . 72 219 7.6.1. Constructors . . . . . . . . . . . . . . . . . . . . 73 220 7.6.2. getInitiatorAddress . . . . . . . . . . . . . . . . . 73 221 7.6.3. getAcceptorAddress . . . . . . . . . . . . . . . . . 73 222 7.6.4. getApplicationData . . . . . . . . . . . . . . . . . 74 223 7.6.5. equals . . . . . . . . . . . . . . . . . . . . . . . 74 224 7.7. public class Oid . . . . . . . . . . . . . . . . . . . . 74 225 7.7.1. Constructors . . . . . . . . . . . . . . . . . . . . 74 226 7.7.2. toString . . . . . . . . . . . . . . . . . . . . . . 75 227 7.7.3. equals . . . . . . . . . . . . . . . . . . . . . . . 75 228 7.7.4. getDER . . . . . . . . . . . . . . . . . . . . . . . 76 229 7.7.5. containedIn . . . . . . . . . . . . . . . . . . . . . 76 230 7.8. public class GSSException extends Exception . . . . . . . 76 231 7.8.1. Static Constants . . . . . . . . . . . . . . . . . . 76 232 7.8.2. Constructors . . . . . . . . . . . . . . . . . . . . 79 233 7.8.3. getMajor . . . . . . . . . . . . . . . . . . . . . . 80 234 7.8.4. getMinor . . . . . . . . . . . . . . . . . . . . . . 80 235 7.8.5. getMajorString . . . . . . . . . . . . . . . . . . . 80 236 7.8.6. getMinorString . . . . . . . . . . . . . . . . . . . 80 237 7.8.7. getOutputToken . . . . . . . . . . . . . . . . . . . 81 238 7.8.8. setMinor . . . . . . . . . . . . . . . . . . . . . . 81 239 7.8.9. toString . . . . . . . . . . . . . . . . . . . . . . 81 240 7.8.10. getMessage . . . . . . . . . . . . . . . . . . . . . 81 242 8. Sample Applications . . . . . . . . . . . . . . . . . . . . . 81 243 8.1. Simple GSS Context Initiator . . . . . . . . . . . . . . 82 244 8.2. Simple GSS Context Acceptor . . . . . . . . . . . . . . . 85 245 9. Security Considerations . . . . . . . . . . . . . . . . . . . 89 246 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 90 247 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 90 248 12. Changes since RFC 5653 . . . . . . . . . . . . . . . . . . . 90 249 13. Changes since RFC 2853 . . . . . . . . . . . . . . . . . . . 92 250 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 251 14.1. Normative References . . . . . . . . . . . . . . . . . . 92 252 14.2. Informative References . . . . . . . . . . . . . . . . . 93 253 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94 255 1. Introduction 257 This document specifies Java language bindings for the Generic 258 Security Services Application Programming Interface version 2 (GSS- 259 API). GSS-API version 2 is described in a language-independent 260 format in RFC 2743 [RFC2743]. The GSS-API allows a caller 261 application to authenticate a principal identity, to delegate rights 262 to a peer, and to apply security services such as confidentiality and 263 integrity on a per-message basis. 265 This document and its predecessor, RFC 2853 [RFC2853] and RFC 5653 266 [RFC5653], leverage the work done by the working group (WG) in the 267 area of RFC 2743 [RFC2743] and the C-bindings of RFC 2744 [RFC2744]. 268 Whenever appropriate, text has been used from the C-bindings document 269 (RFC 2744) to explain generic concepts and provide direction to the 270 implementors. 272 The design goals of this API have been to satisfy all the 273 functionality defined in RFC 2743 [RFC2743] and to provide these 274 services in an object-oriented method. The specification also aims 275 to satisfy the needs of both types of Java application developers, 276 those who would like access to a "system-wide" GSS-API 277 implementation, as well as those who would want to provide their own 278 "custom" implementation. 280 A system-wide implementation is one that is available to all 281 applications in the form of a library package. It may be the 282 standard package in the Java runtime environment (JRE) being used or 283 it may be additionally installed and accessible to any application 284 via the CLASSPATH. 286 A custom implementation of the GSS-API, on the other hand, is one 287 that would, in most cases, be bundled with the application during 288 distribution. It is expected that such an implementation would be 289 meant to provide for some particular need of the application, such as 290 support for some specific mechanism. 292 The design of this API also aims to provide a flexible framework to 293 add and manage GSS-API mechanisms. GSS-API leverages the Java 294 Cryptography Architecture (JCA) provider model to support the 295 plugability of mechanisms. Mechanisms can be added on a system-wide 296 basis, where all users of the framework will have them available. 297 The specification also allows for the addition of mechanisms per- 298 instance of the GSS-API. 300 Lastly, this specification presents an API that will naturally fit 301 within the operation environment of the Java platform. Readers are 302 assumed to be familiar with both the GSS-API and the Java platform. 304 2. Notational Conventions 306 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 307 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 308 "OPTIONAL" in this document are to be interpreted as described in BCP 309 14 [RFC2119] [RFC8174] when, and only when, they appear in all 310 capitals, as shown here. 312 3. GSS-API Operational Paradigm 314 "Generic Security Service Application Programming Interface, Version 315 2" [RFC2743] defines a generic security API to calling applications. 316 It allows a communicating application to authenticate the user 317 associated with another application, to delegate rights to another 318 application, and to apply security services such as confidentiality 319 and integrity on a per-message basis. 321 There are four stages to using GSS-API: 323 1) The application acquires a set of credentials with which it may 324 prove its identity to other processes. The application's 325 credentials vouch for its global identity, which may or may not be 326 related to any local username under which it may be running. 328 2) A pair of communicating applications establish a joint security 329 context using their credentials. The security context 330 encapsulates shared state information, which is required in order 331 that per-message security services may be provided. Examples of 332 state information that might be shared between applications as 333 part of a security context are cryptographic keys and message 334 sequence numbers. As part of the establishment of a security 335 context, the context initiator is authenticated to the responder, 336 and may require that the responder is authenticated back to the 337 initiator. The initiator may optionally give the responder the 338 right to initiate further security contexts, acting as an agent or 339 delegate of the initiator. This transfer of rights is termed 340 "delegation", and is achieved by creating a set of credentials, 341 similar to those used by the initiating application, but which may 342 be used by the responder. 344 A GSSContext object is used to establish and maintain the shared 345 information that makes up the security context. Certain 346 GSSContext methods will generate a token, which applications treat 347 as cryptographically protected, opaque data. The caller of such a 348 GSSContext method is responsible for transferring the token to the 349 peer application, encapsulated if necessary in an application-to- 350 application protocol. On receipt of such a token, the peer 351 application should pass it to a corresponding GSSContext method 352 which will decode the token and extract the information, updating 353 the security context state information accordingly. 355 3) Per-message services are invoked on a GSSContext object to apply 356 either: 358 integrity and data origin authentication, or 360 confidentiality, integrity and data origin authentication 362 to application data, which are treated by GSS-API as arbitrary 363 octet-strings. An application transmitting a message that it 364 wishes to protect will call the appropriate GSSContext method 365 (getMIC or wrap) to apply protection, and send the resulting token 366 to the receiving application. The receiver will pass the received 367 token (and, in the case of data protected by getMIC, the 368 accompanying message-data) to the corresponding decoding method of 369 the GSSContext interface (verifyMIC or unwrap) to remove the 370 protection and validate the data. 372 4) At the completion of a communications session (which may extend 373 across several transport connections), each application uses a 374 GSSContext method to invalidate the security context and release 375 any system or cryptographic resources held. Multiple contexts may 376 also be used (either successively or simultaneously) within a 377 single communications association, at the discretion of the 378 applications. 380 4. Additional Controls 382 This section discusses the OPTIONAL services that a context initiator 383 may request of the GSS-API before the context establishment. Each of 384 these services is requested by calling the appropriate mutator method 385 in the GSSContext object before the first call to init is performed. 386 Only the context initiator can request context flags. 388 The OPTIONAL services defined are: 390 Delegation: The (usually temporary) transfer of rights from 391 initiator to acceptor, enabling the acceptor to authenticate 392 itself as an agent of the initiator. 394 Mutual Authentication: In addition to the initiator authenticating 395 its identity to the context acceptor, the context acceptor SHOULD 396 also authenticate itself to the initiator. 398 Replay Detection: In addition to providing message integrity 399 services, GSSContext per-message operations of getMIC and wrap 400 SHOULD include message numbering information to enable verifyMIC 401 and unwrap to detect if a message has been duplicated. 403 Out-of-Sequence Detection: In addition to providing message 404 integrity services, GSSContext per-message operations (getMIC and 405 wrap) SHOULD include message sequencing information to enable 406 verifyMIC and unwrap to detect if a message has been received out 407 of sequence. 409 Anonymous Authentication: The establishment of the security 410 context SHOULD NOT reveal the initiator's identity to the context 411 acceptor. 413 Some mechanisms may not support all OPTIONAL services, and some 414 mechanisms may only support some services in conjunction with others. 415 The GSSContext interface offers query methods to allow the 416 verification by the calling application of which services will be 417 available from the context when the establishment phase is complete. 418 In general, if the security mechanism is capable of providing a 419 requested service, it SHOULD do so even if additional services must 420 be enabled in order to provide the requested service. If the 421 mechanism is incapable of providing a requested service, it SHOULD 422 proceed without the service leaving the application to abort the 423 context establishment process if it considers the requested service 424 to be mandatory. 426 Some mechanisms MAY specify that support for some services is 427 optional, and that implementors of the mechanism need not provide it. 428 This is most commonly true of the confidentiality service, often 429 because of legal restrictions on the use of data-encryption, but may 430 apply to any of the services. Such mechanisms are required to send 431 at least one token from acceptor to initiator during context 432 establishment when the initiator indicates a desire to use such a 433 service, so that the initiating GSS-API can correctly indicate 434 whether the service is supported by the acceptor's GSS-API. 436 4.1. Delegation 438 The GSS-API allows delegation to be controlled by the initiating 439 application via the requestCredDeleg method before the first call to 440 init has been issued. Some mechanisms do not support delegation, and 441 for such mechanisms, attempts by an application to enable delegation 442 are ignored. 444 The acceptor of a security context, for which the initiator enabled 445 delegation, can check if delegation was enabled by using the 446 getCredDelegState method of the GSSContext interface. In cases when 447 it is enabled, the delegated credential object can be obtained by 448 calling the getDelegCred method. The obtained GSSCredential object 449 may then be used to initiate subsequent GSS-API security contexts as 450 an agent or delegate of the initiator. If the original initiator's 451 identity is "A" and the delegate's identity is "B", then, depending 452 on the underlying mechanism, the identity embodied by the delegated 453 credential may be either "A" or "B acting for A". 455 For many mechanisms that support delegation, a simple boolean does 456 not provide enough control. Examples of additional aspects of 457 delegation control that a mechanism might provide to an application 458 are duration of delegation, network addresses from which delegation 459 is valid, and constraints on the tasks that may be performed by a 460 delegate. Such controls are presently outside the scope of the GSS- 461 API. GSS-API implementations supporting mechanisms offering 462 additional controls SHOULD provide extension routines that allow 463 these controls to be exercised (perhaps by modifying the initiator's 464 GSS-API credential object prior to its use in establishing a 465 context). However, the simple delegation control provided by GSS-API 466 SHOULD always be able to override other mechanism-specific delegation 467 controls. If the application instructs the GSSContext object that 468 delegation is not desired, then the implementation MUST NOT permit 469 delegation to occur. This is an exception to the general rule that a 470 mechanism may enable services even if they are not requested -- 471 delegation may only be provided at the explicit request of the 472 application. 474 4.2. Mutual Authentication 476 Usually, a context acceptor will require that a context initiator 477 authenticate itself so that the acceptor may make an access-control 478 decision prior to performing a service for the initiator. In some 479 cases, the initiator may also request that the acceptor authenticate 480 itself. GSS-API allows the initiating application to request this 481 mutual authentication service by calling the requestMutualAuth method 482 of the GSSContext interface with a "true" parameter before making the 483 first call to init. The initiating application is informed as to 484 whether or not the context acceptor has authenticated itself. Note 485 that some mechanisms may not support mutual authentication, and other 486 mechanisms may always perform mutual authentication, whether or not 487 the initiating application requests it. In particular, mutual 488 authentication may be required by some mechanisms in order to support 489 replay or out-of-sequence message detection, and for such mechanisms, 490 a request for either of these services will automatically enable 491 mutual authentication. 493 4.3. Replay and Out-of-Sequence Detection 495 The GSS-API MAY provide detection of mis-ordered messages once a 496 security context has been established. Protection MAY be applied to 497 messages by either application, by calling either getMIC or wrap 498 methods of the GSSContext interface, and verified by the peer 499 application by calling verifyMIC or unwrap for the peer's GSSContext 500 object. 502 The getMIC method calculates a cryptographic checksum (authentication 503 tag) of an application message, and returns that checksum in a token. 504 The application SHOULD pass both the token and the message to the 505 peer application, which presents them to the verifyMIC method of the 506 peer's GSSContext object. 508 The wrap method calculates a cryptographic checksum of an application 509 message, and places both the checksum and the message inside a single 510 token. The application SHOULD pass the token to the peer 511 application, which presents it to the unwrap method of the peer's 512 GSSContext object to extract the message and verify the checksum. 514 Either pair of routines may be capable of detecting out-of-sequence 515 message delivery or the duplication of messages. Details of such 516 mis-ordered messages are indicated through supplementary query 517 methods of the MessageProp object that is filled in by each of these 518 routines. 520 A mechanism need not maintain a list of all tokens that have been 521 processed in order to support these status codes. A typical 522 mechanism might retain information about only the most recent "N" 523 tokens processed, allowing it to distinguish duplicates and missing 524 tokens within the most recent "N" messages; the receipt of a token 525 older than the most recent "N" would result in the isOldToken method 526 of the instance of MessageProp to return "true". 528 4.4. Anonymous Authentication 530 In certain situations, an application may wish to initiate the 531 authentication process to authenticate a peer, without revealing its 532 own identity. As an example, consider an application providing 533 access to a database containing medical information and offering 534 unrestricted access to the service. A client of such a service might 535 wish to authenticate the service (in order to establish trust in any 536 information retrieved from it), but might not wish the service to be 537 able to obtain the client's identity (perhaps due to privacy concerns 538 about the specific inquiries, or perhaps simply to avoid being placed 539 on mailing-lists). 541 In normal use of the GSS-API, the initiator's identity is made 542 available to the acceptor as a result of the context establishment 543 process. However, context initiators may request that their identity 544 not be revealed to the context acceptor. Many mechanisms do not 545 support anonymous authentication, and for such mechanisms, the 546 request will not be honored. An authentication token will still be 547 generated, but the application is always informed if a requested 548 service is unavailable, and has the option to abort context 549 establishment if anonymity is valued above the other security 550 services that would require a context to be established. 552 In addition to informing the application that a context is 553 established anonymously (via the isAnonymous method of the GSSContext 554 class), the getSrcName method of the acceptor's GSSContext object 555 will, for such contexts, return a reserved internal-form name, 556 defined by the implementation. 558 The toString method for a GSSName object representing an anonymous 559 entity will return a printable name. The returned value will be 560 syntactically distinguishable from any valid principal name supported 561 by the implementation. The associated name-type object identifier 562 will be an oid representing the value of NT_ANONYMOUS. This name- 563 type oid will be defined as a public, static Oid object of the 564 GSSName class. The printable form of an anonymous name SHOULD be 565 chosen such that it implies anonymity, since this name may appear in, 566 for example, audit logs. For example, the string "" might 567 be a good choice, if no valid printable names supported by the 568 implementation can begin with "<" and end with ">". 570 When using the equal method of the GSSName interface, and one of the 571 operands is a GSSName instance representing an anonymous entity, the 572 method MUST return "false". 574 4.5. Integrity and Confidentiality 576 If a GSSContext supports the integrity service, getMic method may be 577 used to create message integrity check tokens on application 578 messages. 580 If a GSSContext supports the confidentiality service, wrap method may 581 be used to encrypt application messages. Messages are selectively 582 encrypted, under the control of the setPrivacy method of the 583 MessageProp object used in the wrap method. Confidentiality will be 584 applied if the privacy state is set to true. 586 4.6. Inter-process Context Transfer 588 GSS-APIv2 provides functionality that allows a security context to be 589 transferred between processes on a single machine. These are 590 implemented using the export method of GSSContext and a byte array 591 constructor of the same class. The most common use for such a 592 feature is a client-server design where the server is implemented as 593 a single process that accepts incoming security contexts, which then 594 launches child processes to deal with the data on these contexts. In 595 such a design, the child processes must have access to the security 596 context object created within the parent so that they can use per- 597 message protection services and delete the security context when the 598 communication session ends. 600 Since the security context data structure is expected to contain 601 sequencing information, it is impractical in general to share a 602 context between processes. Thus, the GSSContext interface provides 603 an export method that the process, which currently owns the context, 604 can call to declare that it has no intention to use the context 605 subsequently, and to create an inter-process token containing 606 information needed by the adopting process to successfully recreate 607 the context. After successful completion of export, the original 608 security context is made inaccessible to the calling process by GSS- 609 API, and any further usage of this object will result in failures. 610 The originating process transfers the inter-process token to the 611 adopting process, which creates a new GSSContext object using the 612 byte array constructor. The properties of the context are equivalent 613 to that of the original context. 615 The inter-process token MAY contain sensitive data from the original 616 security context (including cryptographic keys). Applications using 617 inter-process tokens to transfer security contexts MUST take 618 appropriate steps to protect these tokens in transit. 620 Implementations are not required to support the inter-process 621 transfer of security contexts. Calling the isTransferable method of 622 the GSSContext interface will indicate if the context object is 623 transferable. 625 4.7. The Use of Incomplete Contexts 627 Some mechanisms may allow the per-message services to be used before 628 the context establishment process is complete. For example, a 629 mechanism may include sufficient information in its initial context- 630 level tokens for the context acceptor to immediately decode messages 631 protected with wrap or getMIC. For such a mechanism, the initiating 632 application need not wait until subsequent context-level tokens have 633 been sent and received before invoking the per-message protection 634 services. 636 An application can invoke the isProtReady method of the GSSContext 637 class to determine if the per-message services are available in 638 advance of complete context establishment. Applications wishing to 639 use per-message protection services on partially established contexts 640 SHOULD query this method before attempting to invoke wrap or getMIC. 642 5. Calling Conventions 644 Java provides the implementors with not just a syntax for the 645 language, but also an operational environment. For example, memory 646 is automatically managed and does not require application 647 intervention. These language features have allowed for a simpler API 648 and have led to the elimination of certain GSS-API functions. 650 Moreover, the JCA defines a provider model that allows for 651 implementation-independent access to security services. Using this 652 model, applications can seamlessly switch between different 653 implementations and dynamically add new services. The GSS-API 654 specification leverages these concepts by the usage of providers for 655 the mechanism implementations. 657 5.1. Package Name 659 The classes and interfaces defined in this document reside in the 660 package called "org.ietf.jgss". Applications that wish to make use 661 of this API should import this package name as shown in section 8. 663 5.2. Provider Framework 665 The Java security API's use a provider architecture that allows 666 applications to be implementation independent and security API 667 implementations to be modular and extensible. The 668 java.security.Provider class is an abstract class that a vendor 669 extends. This class maps various properties that represent different 670 security services that are available to the names of the actual 671 vendor classes that implement those services. When requesting a 672 service, an application simply specifies the desired provider and the 673 API delegates the request to service classes available from that 674 provider. 676 Using the Java security provider model insulates applications from 677 implementation details of the services they wish to use. 678 Applications can switch between providers easily and new providers 679 can be added as needed, even at runtime. 681 The GSS-API may use providers to find components for specific 682 underlying security mechanisms. For instance, a particular provider 683 might contain components that will allow the GSS-API to support the 684 Kerberos v5 mechanism [RFC4121] and another might contain components 685 to support the Simple Public-Key GSS-API Mechanism (SPKM) [RFC2025]. 686 By delegating mechanism-specific functionality to the components 687 obtained from providers, the GSS-API can be extended to support an 688 arbitrary list of mechanism. 690 How the GSS-API locates and queries these providers is beyond the 691 scope of this document and is being deferred to a Service Provider 692 Interface (SPI) specification. The availability of such an SPI 693 specification is not mandatory for the adoption of this API 694 specification nor is it mandatory to use providers in the 695 implementation of a GSS-API framework. However, by using the 696 provider framework together with an SPI specification, one can create 697 an extensible and implementation-independent GSS-API framework. 699 5.3. Integer Types 701 All numeric values are declared as "int" primitive Java type. The 702 Java specification guarantees that this will be a 32-bit two's 703 complement signed number. 705 Throughout this API, the "boolean" primitive Java type is used 706 wherever a boolean value is required or returned. 708 5.4. Opaque Data Types 710 Java byte arrays are used to represent opaque data types that are 711 consumed and produced by the GSS-API in the form of tokens. Java 712 arrays contain a length field that enables the users to easily 713 determine their size. The language has automatic garbage collection 714 that alleviates the need by developers to release memory and 715 simplifies buffer ownership issues. 717 5.5. Strings 719 The String object will be used to represent all textual data. The 720 Java String object transparently treats all characters as two-byte 721 Unicode characters, which allows support for many locals. All 722 routines returning or accepting textual data will use the String 723 object. 725 5.6. Object Identifiers 727 An Oid object will be used to represent Universal Object Identifiers 728 (Oids). Oids are ISO-defined, hierarchically globally interpretable 729 identifiers used within the GSS-API framework to identify security 730 mechanisms and name formats. The Oid object can be created from a 731 string representation of its dot notation (e.g., "1.3.6.1.5.6.2") as 732 well as from its ASN.1 DER encoding. Methods are also provided to 733 test equality and provide the DER representation for the object. 735 An important feature of the Oid class is that its instances are 736 immutable -- i.e., there are no methods defined that allow one to 737 change the contents of an Oid. This property allows one to treat 738 these objects as "statics" without the need to perform copies. 740 Certain routines allow the usage of a default oid. A "null" value 741 can be used in those cases. 743 5.7. Object Identifier Sets 745 The Java bindings represent object identifier sets as arrays of Oid 746 objects. All Java arrays contain a length field, which allows for 747 easy manipulation and reference. 749 In order to support the full functionality of RFC 2743 [RFC2743], the 750 Oid class includes a method that checks for existence of an Oid 751 object within a specified array. This is equivalent in functionality 752 to gss_test_oid_set_member. The use of Java arrays and Java's 753 automatic garbage collection has eliminated the need for the 754 following routines: gss_create_empty_oid_set, gss_release_oid_set, 755 and gss_add_oid_set_member. Java GSS-API implementations will not 756 contain them. Java's automatic garbage collection and the immutable 757 property of the Oid object eliminates the memory management issues of 758 the C counterpart. 760 Whenever a default value for an Object Identifier Set is required, a 761 "null" value can be used. Please consult the detailed method 762 description for details. 764 5.8. Credentials 766 GSS-API credentials are represented by the GSSCredential interface. 767 The interface contains several constructs to allow for the creation 768 of most common credential objects for the initiator and the acceptor. 769 Comparisons are performed using the interface's "equals" method. The 770 following general description of GSS-API credentials is included from 771 the C-bindings specification: 773 GSS-API credentials can contain mechanism-specific principal 774 authentication data for multiple mechanisms. A GSS-API credential 775 is composed of a set of credential-elements, each of which is 776 applicable to a single mechanism. A credential may contain at 777 most one credential-element for each supported mechanism. A 778 credential-element identifies the data needed by a single 779 mechanism to authenticate a single principal, and conceptually 780 contains two credential-references that describe the actual 781 mechanism-specific authentication data, one to be used by GSS-API 782 for initiating contexts, and one to be used for accepting 783 contexts. For mechanisms that do not distinguish between acceptor 784 and initiator credentials, both references would point to the same 785 underlying mechanism-specific authentication data. 787 Credentials describe a set of mechanism-specific principals, and give 788 their holder the ability to act as any of those principals. All 789 principal identities asserted by a single GSS-API credential SHOULD 790 belong to the same entity, although enforcement of this property is 791 an implementation-specific matter. A single GSSCredential object 792 represents all the credential elements that have been acquired. 794 The creation of an GSSContext object allows the value of "null" to be 795 specified as the GSSCredential input parameter. This will indicate a 796 desire by the application to act as a default principal. While 797 individual GSS-API implementations are free to determine such default 798 behavior as appropriate to the mechanism, the following default 799 behavior by these routines is RECOMMENDED for portability: 801 For the initiator side of the context: 803 1) If there is only a single principal capable of initiating security 804 contexts for the chosen mechanism that the application is 805 authorized to act on behalf of, then that principal shall be used; 806 otherwise, 808 2) If the platform maintains a concept of a default network-identity 809 for the chosen mechanism, and if the application is authorized to 810 act on behalf of that identity for the purpose of initiating 811 security contexts, then the principal corresponding to that 812 identity shall be used; otherwise, 814 3) If the platform maintains a concept of a default local identity, 815 and provides a means to map local identities into network- 816 identities for the chosen mechanism, and if the application is 817 authorized to act on behalf of the network-identity image of the 818 default local identity for the purpose of initiating security 819 contexts using the chosen mechanism, then the principal 820 corresponding to that identity shall be used; otherwise, 822 4) A user-configurable default identity should be used. 824 For the acceptor side of the context: 826 1) If there is only a single authorized principal identity capable of 827 accepting security contexts for the chosen mechanism, then that 828 principal shall be used; otherwise, 830 2) If the mechanism can determine the identity of the target 831 principal by examining the context-establishment token processed 832 during the accept method, and if the accepting application is 833 authorized to act as that principal for the purpose of accepting 834 security contexts using the chosen mechanism, then that principal 835 identity shall be used; otherwise, 837 3) If the mechanism supports context acceptance by any principal, and 838 if mutual authentication was not requested, any principal that the 839 application is authorized to accept security contexts under using 840 the chosen mechanism may be used; otherwise, 842 4) A user-configurable default identity shall be used. 844 The purpose of the above rules is to allow security contexts to be 845 established by both initiator and acceptor using the default behavior 846 whenever possible. Applications requesting default behavior are 847 likely to be more portable across mechanisms and implementations than 848 ones that instantiate an GSSCredential object representing a specific 849 identity. 851 5.9. Contexts 853 The GSSContext interface is used to represent one end of a GSS-API 854 security context, storing state information appropriate to that end 855 of the peer communication, including cryptographic state information. 856 The instantiation of the context object is done differently by the 857 initiator and the acceptor. After the context has been instantiated, 858 the initiator MAY choose to set various context options that will 859 determine the characteristics of the desired security context. When 860 all the application-desired characteristics have been set, the 861 initiator will call the initSecContext method, which will produce a 862 token for consumption by the peer's acceptSecContext method. It is 863 the responsibility of the application to deliver the authentication 864 token(s) between the peer applications for processing. Upon 865 completion of the context-establishment phase, context attributes can 866 be retrieved, by both the initiator and acceptor, using the accessor 867 methods. These will reflect the actual attributes of the established 868 context and might not match the initiator-requested values. If any 869 retrieved attribute does not match the desired value but it is 870 necessary for the application protocol, the application SHOULD 871 destroy the security context and not use it for application traffic. 872 Otherwise, at this point, the context can be used by the application 873 to apply cryptographic services to its data. 875 5.10. Authentication Tokens 877 A token is a caller-opaque type that GSS-API uses to maintain 878 synchronization between each end of the GSS-API security context. 879 The token is a cryptographically protected octet-string, generated by 880 the underlying mechanism at one end of a GSS-API security context for 881 use by the peer mechanism at the other end. Encapsulation (if 882 required) within the application protocol and transfer of the token 883 are the responsibility of the peer applications. 885 Java GSS-API uses byte arrays to represent authentication tokens. 887 5.11. Inter-Process Tokens 889 Certain GSS-API routines are intended to transfer data between 890 processes in multi-process programs. These routines use a caller- 891 opaque octet-string, generated by the GSS-API in one process for use 892 by the GSS-API in another process. The calling application is 893 responsible for transferring such tokens between processes. Note 894 that, while GSS-API implementors are encouraged to avoid placing 895 sensitive information within inter-process tokens, or to 896 cryptographically protect them, many implementations will be unable 897 to avoid placing key material or other sensitive data within them. 898 It is the application's responsibility to ensure that inter-process 899 tokens are protected in transit, and transferred only to processes 900 that are trustworthy. An inter-process token is represented using a 901 byte array emitted from the export method of the GSSContext 902 interface. The receiver of the inter-process token would initialize 903 an GSSContext object with this token to create a new context. Once a 904 context has been exported, the GSSContext object is invalidated and 905 is no longer available. 907 5.12. Error Reporting 909 RFC 2743 [RFC2743] defined the usage of major and minor status values 910 for the signaling of GSS-API errors. The major code, also called GSS 911 status code, is used to signal errors at the GSS-API level, 912 independent of the underlying mechanism(s). The minor status value 913 or Mechanism status code, is a mechanism-defined error value 914 indicating a mechanism-specific error code. 916 Java GSS-API uses exceptions implemented by the GSSException class to 917 signal both minor and major error values. Both mechanism-specific 918 errors and GSS-API level errors are signaled through instances of 919 this class. The usage of exceptions replaces the need for major and 920 minor codes to be used within the API calls. The GSSException class 921 also contains methods to obtain textual representations for both the 922 major and minor values, which is equivalent to the functionality of 923 gss_display_status. A GSSException object MAY also include an output 924 token that SHOULD be sent to the peer. 926 If an exception is thrown during context establishment, the context 927 negotiation has failed and the GSSContext object MUST be abandoned. 928 If it is thrown in a per-message call, the context MAY remain useful. 930 5.12.1. GSS Status Codes 932 GSS status codes indicate errors that are independent of the 933 underlying mechanism(s) used to provide the security service. The 934 errors that can be indicated via a GSS status code are generic API 935 routine errors (errors that are defined in the GSS-API 936 specification). These bindings take advantage of the Java exceptions 937 mechanism, thus, eliminating the need for calling errors. 939 A GSS status code indicates a single fatal generic API error from the 940 routine that has thrown the GSSException. Using exceptions announces 941 that a fatal error has occurred during the execution of the method. 942 The GSS-API operational model also allows for the signaling of 943 supplementary status information from the per-message calls. These 944 need to be handled as return values since using exceptions is not 945 appropriate for informatory or warning-like information. The methods 946 that are capable of producing supplementary information are the two 947 per-message methods GSSContext.verifyMIC() and GSSContext.unwrap(). 948 These methods fill the supplementary status codes in the MessageProp 949 object that was passed in. 951 A GSSException object, along with providing the functionality for 952 setting of the various error codes and translating them into textual 953 representation, also contains the definitions of all the numeric 954 error values. The following table lists the definitions of error 955 codes: 957 Table: GSS Status Codes 959 +----------------------+-------+------------------------------------+ 960 | Name | Value | Meaning | 961 +----------------------+-------+------------------------------------+ 962 | BAD_BINDINGS | 1 | Incorrect channel bindings were | 963 | | | supplied. | 964 | | | | 965 | BAD_MECH | 2 | An unsupported mechanism was | 966 | | | requested. | 967 | | | | 968 | BAD_NAME | 3 | An invalid name was supplied. | 969 | | | | 970 | BAD_NAMETYPE | 4 | A supplied name was of an | 971 | | | unsupported type. | 972 | | | | 973 | BAD_STATUS | 5 | An invalid status code was | 974 | | | supplied. | 975 | | | | 976 | BAD_MIC | 6 | A token had an invalid MIC. | 977 | | | | 978 | CONTEXT_EXPIRED | 7 | The context has expired. | 979 | | | | 980 | CREDENTIALS_EXPIRED | 8 | The referenced credentials have | 981 | | | expired. | 982 | | | | 983 | DEFECTIVE_CREDENTIAL | 9 | A supplied credential was invalid. | 984 | | | | 985 | DEFECTIVE_TOKEN | 10 | A supplied token was invalid. | 986 | | | | 987 | FAILURE | 11 | Miscellaneous failure, unspecified | 988 | | | at the GSS-API level. | 989 | | | | 990 | NO_CONTEXT | 12 | Invalid context has been supplied. | 991 | | | | 992 | NO_CRED | 13 | No credentials were supplied, or | 993 | | | the credentials were unavailable | 994 | | | or inaccessible. | 995 | | | | 996 | BAD_QOP | 14 | The quality-of-protection (QOP) | 997 | | | requested could not be provided. | 998 | | | | 999 | UNAUTHORIZED | 15 | The operation is forbidden by the | 1000 | | | local security policy. | 1001 | | | | 1002 | UNAVAILABLE | 16 | The operation or option is | 1003 | | | unavailable. | 1004 | | | | 1005 | DUPLICATE_ELEMENT | 17 | The requested credential element | 1006 | | | already exists. | 1007 | | | | 1008 | NAME_NOT_MN | 18 | The provided name was not a | 1009 | | | mechanism name. | 1010 +----------------------+-------+------------------------------------+ 1012 The following four status codes (DUPLICATE_TOKEN, OLD_TOKEN, 1013 UNSEQ_TOKEN, and GAP_TOKEN) are contained in a GSSException only if 1014 detected during context establishment, in which case it is a fatal 1015 error. (During per-message calls, these values are indicated as 1016 supplementary information contained in the MessageProp object.) They 1017 are: 1019 +-----------------+-------+-----------------------------------------+ 1020 | Name | Value | Meaning | 1021 +-----------------+-------+-----------------------------------------+ 1022 | DUPLICATE_TOKEN | 19 | The token was a duplicate of an earlier | 1023 | | | version. | 1024 | | | | 1025 | OLD_TOKEN | 20 | The token's validity period has | 1026 | | | expired. | 1027 | | | | 1028 | UNSEQ_TOKEN | 21 | A later token has already been | 1029 | | | processed. | 1030 | | | | 1031 | GAP_TOKEN | 22 | The expected token was not received. | 1032 +-----------------+-------+-----------------------------------------+ 1034 The GSS major status code of FAILURE is used to indicate that the 1035 underlying mechanism detected an error for which no specific GSS 1036 status code is defined. The mechanism-specific status code can 1037 provide more details about the error. 1039 The different major status codes that can be contained in the 1040 GSSException object thrown by the methods in this specification are 1041 the same as the major status codes returned by the corresponding 1042 calls in RFC 2743 [RFC2743]. 1044 5.12.2. Mechanism-Specific Status Codes 1046 Mechanism-specific status codes are communicated in two ways, they 1047 are part of any GSSException thrown from the mechanism-specific layer 1048 to signal a fatal error, or they are part of the MessageProp object 1049 that the per-message calls use to signal non-fatal errors. 1051 A default value of 0 in either the GSSException object or the 1052 MessageProp object will be used to represent the absence of any 1053 mechanism-specific status code. 1055 5.12.3. Supplementary Status Codes 1057 Supplementary status codes are confined to the per-message methods of 1058 the GSSContext interface. Because of the informative nature of these 1059 errors it is not appropriate to use exceptions to signal them. 1060 Instead, the per-message operations of the GSSContext interface 1061 return these values in a MessageProp object. 1063 The MessageProp class defines query methods that return boolean 1064 values indicating the following supplementary states: 1066 Table: Supplementary Status Methods 1068 +------------------+------------------------------------------------+ 1069 | Method Name | Meaning when "true" is returned | 1070 +------------------+------------------------------------------------+ 1071 | isDuplicateToken | The token was a duplicate of an earlier token. | 1072 | | | 1073 | isOldToken | The token's validity period has expired. | 1074 | | | 1075 | isUnseqToken | A later token has already been processed. | 1076 | | | 1077 | isGapToken | An expected per-message token was not | 1078 | | received. | 1079 +------------------+------------------------------------------------+ 1081 A "true" return value for any of the above methods indicates that the 1082 token exhibited the specified property. The application MUST 1083 determine the appropriate course of action for these supplementary 1084 values. They are not treated as errors by the GSS-API. 1086 5.13. Names 1088 A name is used to identify a person or entity. GSS-API authenticates 1089 the relationship between a name and the entity claiming the name. 1091 Since different authentication mechanisms may employ different 1092 namespaces for identifying their principals, GSS-API's naming support 1093 is necessarily complex in multi-mechanism environments (or even in 1094 some single-mechanism environments where the underlying mechanism 1095 supports multiple namespaces). 1097 Two distinct conceptual representations are defined for names: 1099 1) A GSS-API form represented by implementations of the GSSName 1100 interface: A single GSSName object MAY contain multiple names from 1101 different namespaces, but all names SHOULD refer to the same 1102 entity. An example of such an internal name would be the name 1103 returned from a call to the getName method of the GSSCredential 1104 interface, when applied to a credential containing credential 1105 elements for multiple authentication mechanisms employing 1106 different namespaces. This GSSName object will contain a distinct 1107 name for the entity for each authentication mechanism. 1109 For GSS-API implementations supporting multiple namespaces, 1110 GSSName implementations MUST contain sufficient information to 1111 determine the namespace to which each primitive name belongs. 1113 2) Mechanism-specific contiguous byte array and string forms: 1114 Different GSSName initialization methods are provided to handle 1115 both byte array and string formats and to accommodate various 1116 calling applications and name types. These formats are capable of 1117 containing only a single name (from a single namespace). 1118 Contiguous string names are always accompanied by an object 1119 identifier specifying the namespace to which the name belongs, and 1120 their format is dependent on the authentication mechanism that 1121 employs that name. The string name forms are assumed to be 1122 printable, and may therefore be used by GSS-API applications for 1123 communication with their users. The byte array name formats are 1124 assumed to be in non-printable formats (e.g., the byte array 1125 returned from the export method of the GSSName interface). 1127 A GSSName object can be converted to a contiguous representation by 1128 using the toString method. This will guarantee that the name will be 1129 converted to a printable format. Different initialization methods in 1130 the GSSName interface are defined allowing support for multiple 1131 syntaxes for each supported namespace, and allowing users the freedom 1132 to choose a preferred name representation. The toString method 1133 SHOULD use an implementation-chosen printable syntax for each 1134 supported name type. To obtain the printable name type, 1135 getStringNameType method can be used. 1137 There is no guarantee that calling the toString method on the GSSName 1138 interface will produce the same string form as the original imported 1139 string name. Furthermore, it is possible that the name was not even 1140 constructed from a string representation. The same applies to 1141 namespace identifiers, which may not necessarily survive unchanged 1142 after a journey through the internal name form. An example of this 1143 might be a mechanism that authenticates X.500 names, but provides an 1144 algorithmic mapping of Internet DNS names into X.500. That 1145 mechanism's implementation of GSSName might, when presented with a 1146 DNS name, generate an internal name that contained both the original 1147 DNS name and the equivalent X.500 name. Alternatively, it might only 1148 store the X.500 name. In the latter case, the toString method of 1149 GSSName would most likely generate a printable X.500 name, rather 1150 than the original DNS name. 1152 The context acceptor can obtain a GSSName object representing the 1153 entity performing the context initiation (through the usage of 1154 getSrcName method). Since this name has been authenticated by a 1155 single mechanism, it contains only a single name (even if the 1156 internal name presented by the context initiator to the GSSContext 1157 object had multiple components). Such names are termed internal- 1158 mechanism names (or MNs), and the names emitted by GSSContext 1159 interface in the getSrcName and getTargName are always of this type. 1160 Since some applications may require MNs without wanting to incur the 1161 overhead of an authentication operation, creation methods are 1162 provided that take not only the name buffer and name type, but also 1163 the mechanism oid for which this name should be created. When 1164 dealing with an existing GSSName object, the canonicalize method may 1165 be invoked to convert a general internal name into an MN. 1167 GSSName objects can be compared using their equal method, which 1168 returns "true" if the two names being compared refer to the same 1169 entity. This is the preferred way to perform name comparisons 1170 instead of using the printable names that a given GSS-API 1171 implementation may support. Since GSS-API assumes that all primitive 1172 names contained within a given internal name refer to the same 1173 entity, equal can return "true" if the two names have at least one 1174 primitive name in common. If the implementation embodies knowledge 1175 of equivalence relationships between names taken from different 1176 namespaces, this knowledge may also allow successful comparisons of 1177 internal names containing no overlapping primitive elements. 1178 However, applications SHOULD note that to avoid surpising behavior, 1179 it is best to ensure that the names being compared are either both 1180 mechanism names for the same mechanism, or both internal names that 1181 are not mechanism names. This holds whether the equals method is 1182 used directly, or the export method is used to generate byte strings 1183 that are then compared byte-by-byte. 1185 When used in large access control lists, the overhead of creating a 1186 GSSName object on each name and invoking the equal method on each 1187 name from the Access Control List (ACL) may be prohibitive. As an 1188 alternative way of supporting this case, GSS-API defines a special 1189 form of the contiguous byte array name, which MAY be compared 1190 directly (byte by byte). Contiguous names suitable for comparison 1191 are generated by the export method. Exported names MAY be re- 1192 imported by using the byte array constructor and specifying the 1193 NT_EXPORT_NAME as the name type object identifier. The resulting 1194 GSSName name will also be a MN. 1196 The GSSName interface defines public static Oid objects representing 1197 the standard name types. Structurally, an exported name object 1198 consists of a header containing an OID identifying the mechanism that 1199 authenticated the name, and a trailer containing the name itself, 1200 where the syntax of the trailer is defined by the individual 1201 mechanism specification. Detailed description of the format is 1202 specified in the language-independent GSS-API specification 1203 [RFC2743]. 1205 Note that the results obtained by using the equals method will in 1206 general be different from those obtained by invoking canonicalize and 1207 export, and then comparing the byte array output. The first series 1208 of operation determines whether two (unauthenticated) names identify 1209 the same principal; the second whether a particular mechanism would 1210 authenticate them as the same principal. These two operations will 1211 in general give the same results only for MNs. 1213 It is important to note that the above are guidelines as to how 1214 GSSName implementations SHOULD behave, and are not intended to be 1215 specific requirements of how name objects must be implemented. The 1216 mechanism designers are free to decide on the details of their 1217 implementations of the GSSName interface as long as the behavior 1218 satisfies the above guidelines. 1220 5.14. Channel Bindings 1222 GSS-API supports the use of user-specified tags to identify a given 1223 context to the peer application. These tags are intended to be used 1224 to identify the particular communications channel that carries the 1225 context. Channel bindings are communicated to the GSS-API using the 1226 ChannelBinding object. The application MAY use byte arrays to 1227 specify the application data to be used in the channel binding as 1228 well as using instances of the InetAddress. The InetAddress for the 1229 initiator and/or acceptor can be used within an instance of a 1230 ChannelBinding. ChannelBinding can be set for the GSSContext object 1231 using the setChannelBinding method before the first call to init or 1232 accept has been performed. Unless the setChannelBinding method has 1233 been used to set the ChannelBinding for a GSSContext object, "null" 1234 ChannelBinding will be assumed. InetAddress is currently the only 1235 address type defined within the Java platform and as such, it is the 1236 only one supported within the ChannelBinding class. Applications 1237 that use other types of addresses can include them as part of the 1238 application-specific data. 1240 Conceptually, the GSS-API concatenates the initiator and acceptor 1241 address information, and the application-supplied byte array to form 1242 an octet-string. The mechanism calculates a Message Integrity Code 1243 (MIC) over this octet-string and binds the MIC to the context 1244 establishment token emitted by the init method of the GSSContext 1245 interface. The same bindings are set by the context acceptor for its 1246 GSSContext object and during processing of the accept method, a MIC 1247 is calculated in the same way. The calculated MIC is compared with 1248 that found in the token, and if the MICs differ, accept will throw a 1249 GSSException with the major code set to BAD_BINDINGS, and the context 1250 will not be established. Some mechanisms may include the actual 1251 channel binding data in the token (rather than just a MIC); 1252 applications SHOULD therefore not use confidential data as channel- 1253 binding components. 1255 Individual mechanisms may impose additional constraints on addresses 1256 that may appear in channel bindings. For example, a mechanism may 1257 verify that the initiator address field of the channel binding 1258 contains the correct network address of the host system. Portable 1259 applications SHOULD therefore ensure that they either provide correct 1260 information for the address fields, or omit the setting of the 1261 addressing information. 1263 5.15. Optional Parameters 1265 Whenever the application wishes to omit an optional parameter the 1266 "null" value SHALL be used. The detailed method descriptions 1267 indicate which parameters are optional. Method overloading has also 1268 been used as a technique to indicate default parameters. 1270 6. Introduction to GSS-API Classes and Interfaces 1272 This section presents a brief description of the classes and 1273 interfaces that constitute the GSS-API. The implementations of these 1274 are obtained from the CLASSPATH defined by the application. If Java 1275 GSS becomes part of the standard Java APIs, then these classes will 1276 be available by default on all systems as part of the JRE's system 1277 classes. 1279 This section also shows the corresponding RFC 2743 [RFC2743] 1280 functionality implemented by each of the classes. Detailed 1281 description of these classes and their methods is presented in 1282 section 7 1284 6.1. GSSManager Class 1286 This abstract class serves as a factory to instantiate 1287 implementations of the GSS-API interfaces and also provides methods 1288 to make queries about underlying security mechanisms. 1290 A default implementation can be obtained using the static method 1291 getInstance(). Applications that desire to provide their own 1292 implementation of the GSSManager class can simply extend the abstract 1293 class themselves. 1295 This class contains equivalents of the following RFC 2743 [RFC2743] 1296 routines: 1298 +----------------------------+-------------------------+------------+ 1299 | RFC 2743 Routine | Function | Section(s) | 1300 +----------------------------+-------------------------+------------+ 1301 | gss_import_name | Create an internal name | 7.1.5 - | 1302 | | from the supplied | 7.1.8 | 1303 | | information. | | 1304 | | | | 1305 | gss_acquire_cred | Acquire credential for | 7.1.9 - | 1306 | | use. | 7.1.11 | 1307 | | | | 1308 | gss_import_sec_context | Create a previously | 7.1.14 | 1309 | | exported context. | | 1310 | | | | 1311 | gss_indicate_mechs | List the mechanisms | 7.1.2 | 1312 | | supported by this GSS- | | 1313 | | API implementation. | | 1314 | | | | 1315 | gss_inquire_mechs_for_name | List the mechanisms | 7.1.4 | 1316 | | supporting the | | 1317 | | specified name type. | | 1318 | | | | 1319 | gss_inquire_names_for_mech | List the name types | 7.1.3 | 1320 | | supported by the | | 1321 | | specified mechanism. | | 1322 +----------------------------+-------------------------+------------+ 1324 6.2. GSSName Interface 1326 GSS-API names are represented in the Java bindings through the 1327 GSSName interface. Different name formats and their definitions are 1328 identified with Universal Object Identifiers (oids). The format of 1329 the names can be derived based on the unique oid of each name type. 1330 The following GSS-API routines are provided by the GSSName interface: 1332 +-----------------------+------------------------------+------------+ 1333 | RFC 2743 Routine | Function | Section(s) | 1334 +-----------------------+------------------------------+------------+ 1335 | gss_display_name | Convert internal name | 7.2.6 | 1336 | | representation to text | | 1337 | | format. | | 1338 | | | | 1339 | gss_compare_name | Compare two internal names. | 7.2.2, | 1340 | | | 7.2.3 | 1341 | | | | 1342 | gss_release_name | Release resources associated | N/A | 1343 | | with the internal name. | | 1344 | | | | 1345 | gss_canonicalize_name | Convert an internal name to | 7.2.4 | 1346 | | a mechanism name. | | 1347 | | | | 1348 | gss_export_name | Convert a mechanism name to | 7.2.5 | 1349 | | export format. | | 1350 | | | | 1351 | gss_duplicate_name | Create a copy of the | N/A | 1352 | | internal name. | | 1353 +-----------------------+------------------------------+------------+ 1355 The gss_release_name call is not provided as Java does its own 1356 garbage collection. The gss_duplicate_name call is also redundant; 1357 the GSSName interface has no mutator methods that can change the 1358 state of the object so it is safe for sharing across threads. 1360 6.3. GSSCredential Interface 1362 The GSSCredential interface is responsible for the encapsulation of 1363 GSS-API credentials. Credentials identify a single entity and 1364 provide the necessary cryptographic information to enable the 1365 creation of a context on behalf of that entity. A single credential 1366 may contain multiple mechanism-specific credentials, each referred to 1367 as a credential element. The GSSCredential interface provides the 1368 functionality of the following GSS-API routines: 1370 +--------------------------+---------------------------+------------+ 1371 | RFC 2743 Routine | Function | Section(s) | 1372 +--------------------------+---------------------------+------------+ 1373 | gss_add_cred | Constructs credentials | 7.3.11 | 1374 | | incrementally. | | 1375 | | | | 1376 | gss_inquire_cred | Obtain information about | 7.3.3 - | 1377 | | credential. | 7.3.10 | 1378 | | | | 1379 | gss_inquire_cred_by_mech | Obtain per-mechanism | 7.3.4 - | 1380 | | information about a | 7.3.9 | 1381 | | credential. | | 1382 | | | | 1383 | gss_release_cred | Dispose of credentials | 7.3.2 | 1384 | | after use. | | 1385 +--------------------------+---------------------------+------------+ 1387 6.4. GSSContext Interface 1389 This interface encapsulates the functionality of context-level calls 1390 required for security context establishment and management between 1391 peers as well as the per-message services offered to applications. A 1392 context is established between a pair of peers and allows the usage 1393 of security services on a per-message basis on application data. It 1394 is created over a single security mechanism. The GSSContext 1395 interface provides the functionality of the following GSS-API 1396 routines: 1398 +------------------------+-----------------------------+------------+ 1399 | RFC 2743 Routine | Function | Section(s) | 1400 +------------------------+-----------------------------+------------+ 1401 | gss_init_sec_context | Initiate the creation of a | 7.4.2 | 1402 | | security context with a | | 1403 | | peer. | | 1404 | | | | 1405 | gss_accept_sec_context | Accept a security context | 7.4.3 | 1406 | | initiated by a peer. | | 1407 | | | | 1408 | gss_delete_sec_context | Destroy a security context. | 7.4.5 | 1409 | | | | 1410 | gss_context_time | Obtain remaining context | 7.4.30 | 1411 | | time. | | 1412 | | | | 1413 | gss_inquire_context | Obtain context | 7.4.21 - | 1414 | | characteristics. | 7.4.35 | 1415 | | | | 1416 | gss_wrap_size_limit | Determine token-size limit | 7.4.6 | 1417 | | for gss_wrap. | | 1418 | | | | 1419 | gss_export_sec_context | Transfer security context | 7.4.11 | 1420 | | to another process. | | 1421 | | | | 1422 | gss_get_mic | Calculate a cryptographic | 7.4.9 | 1423 | | Message Integrity Code | | 1424 | | (MIC) for a message. | | 1425 | | | | 1426 | gss_verify_mic | Verify integrity on a | 7.4.10 | 1427 | | received message. | | 1428 | | | | 1429 | gss_wrap | Attach a MIC to a message | 7.4.7 | 1430 | | and optionally encrypt the | | 1431 | | message content. | | 1432 | | | | 1433 | gss_unwrap | Obtain a previously wrapped | 7.4.8 | 1434 | | application message | | 1435 | | verifying its integrity and | | 1436 | | optionally decrypting it. | | 1437 +------------------------+-----------------------------+------------+ 1439 The functionality offered by the gss_process_context_token routine 1440 has not been included in the Java bindings specification. The 1441 corresponding functionality of gss_delete_sec_context has also been 1442 modified to not return any peer tokens. This has been proposed in 1443 accordance to the recommendations stated in RFC 2743 [RFC2743]. 1444 GSSContext does offer the functionality of destroying the locally 1445 stored context information. 1447 6.5. MessageProp Class 1449 This helper class is used in the per-message operations on the 1450 context. An instance of this class is created by the application and 1451 then passed into the per-message calls. In some cases, the 1452 application conveys information to the GSS-API implementation through 1453 this object and in other cases the GSS-API returns information to the 1454 application by setting it in this object. See the description of the 1455 per-message operations wrap, unwrap, getMIC, and verifyMIC in the 1456 GSSContext interfaces for details. 1458 6.6. GSSException Class 1460 Exceptions are used in the Java bindings to signal fatal errors to 1461 the calling applications. This replaces the major and minor codes 1462 used in the C-bindings specification as a method of signaling 1463 failures. The GSSException class handles both minor and major codes, 1464 as well as their translation into textual representation. All GSS- 1465 API methods are declared as throwing this exception. 1467 +--------------------+----------------------------+-----------------+ 1468 | RFC 2743 Routine | Function | Section | 1469 +--------------------+----------------------------+-----------------+ 1470 | gss_display_status | Retrieve textual | 7.8.5, 7.8.6, | 1471 | | representation of error | 7.8.9, 7.8.10 | 1472 | | codes. | | 1473 +--------------------+----------------------------+-----------------+ 1475 6.7. Oid Class 1477 This utility class is used to represent Universal Object Identifiers 1478 and their associated operations. GSS-API uses object identifiers to 1479 distinguish between security mechanisms and name types. This class, 1480 aside from being used whenever an object identifier is needed, 1481 implements the following GSS-API functionality: 1483 +-------------------------+-------------------------------+---------+ 1484 | RFC 2743 Routine | Function | Section | 1485 +-------------------------+-------------------------------+---------+ 1486 | gss_test_oid_set_member | Determine if the specified | 7.7.5 | 1487 | | oid is part of a set of oids. | | 1488 +-------------------------+-------------------------------+---------+ 1490 6.8. ChannelBinding Class 1492 An instance of this class is used to specify channel binding 1493 information to the GSSContext object before the start of a security 1494 context establishment. The application may use a byte array to 1495 specify application data to be used in the channel binding as well as 1496 to use instances of the InetAddress. InetAddress is currently the 1497 only address type defined within the Java platform and as such, it is 1498 the only one supported within the ChannelBinding class. Applications 1499 that use other types of addresses can include them as part of the 1500 application data. 1502 7. Detailed GSS-API Class Description 1504 This section lists a detailed description of all the public methods 1505 that each of the GSS-API classes and interfaces MUST provide. 1507 7.1. public abstract class GSSManager 1509 The GSSManager class is an abstract class that serves as a factory 1510 for three GSS interfaces: GSSName, GSSCredential, and GSSContext. It 1511 also provides methods for applications to determine what mechanisms 1512 are available from the GSS implementation and what name types these 1513 mechanisms support. An instance of the default GSSManager subclass 1514 MAY be obtained through the static method getInstance(), but 1515 applications are free to instantiate other subclasses of GSSManager. 1517 All but one method in this class are declared abstract. This means 1518 that subclasses have to provide the complete implementation for those 1519 methods. The only exception to this is the static method 1520 getInstance(), which will have platform-specific code to return an 1521 instance of the default subclass. 1523 Platform providers of GSS are REQUIRED not to add any constructors to 1524 this class, private, public, or protected. This will ensure that all 1525 subclasses invoke only the default constructor provided to the base 1526 class by the compiler. 1528 A subclass extending the GSSManager abstract class MAY be implemented 1529 as a modular provider-based layer that utilizes some well-known 1530 service provider specification. The GSSManager API provides the 1531 application with methods to set provider preferences on such an 1532 implementation. These methods also allow the implementation to throw 1533 a well-defined exception in case provider-based configuration is not 1534 supported. Applications that expect to be portable SHOULD be aware 1535 of this and recover cleanly by catching the exception. 1537 It is envisioned that there will be three most common ways in which 1538 providers will be used: 1540 1) The application does not care about what provider is used (the 1541 default case). 1543 2) The application wants a particular provider to be used 1544 preferentially, either for a particular mechanism or all the time, 1545 irrespective of the mechanism. 1547 3) The application wants to use the locally configured providers as 1548 far as possible, but if support is missing for one or more 1549 mechanisms, then it wants to fall back on its own provider. 1551 The GSSManager class has two methods that enable these modes of 1552 usage: addProviderAtFront() and addProviderAtEnd(). These methods 1553 have the effect of creating an ordered list of pairs 1554 where each pair indicates a preference of provider for a given oid. 1556 The use of these methods does not require any knowledge of whatever 1557 service provider specification the GSSManager subclass follows. It 1558 is hoped that these methods will serve the needs of most 1559 applications. Additional methods MAY be added to an extended 1560 GSSManager that could be part of a service provider specification 1561 that is standardized later. 1563 When neither of the methods is called, the implementation SHOULD 1564 choose a default provider for each mechanism it supports. 1566 7.1.1. getInstance 1568 public static GSSManager getInstance() 1570 Returns the default GSSManager implementation. 1572 7.1.2. getMechs 1574 public abstract Oid[] getMechs() 1576 Returns an array of Oid objects indicating the mechanisms available 1577 to GSS-API callers. A "null" value is returned when no mechanism are 1578 available (an example of this would be when mechanism are dynamically 1579 configured, and currently no mechanisms are installed). 1581 7.1.3. getNamesForMech 1583 public abstract Oid[] getNamesForMech(Oid mech) 1584 throws GSSException 1586 Returns name type Oid's supported by the specified mechanism. 1588 Parameters: 1590 mech The Oid object for the mechanism to query. 1592 7.1.4. getMechsForName 1594 public abstract Oid[] getMechsForName(Oid nameType) 1596 Returns an array of Oid objects corresponding to the mechanisms that 1597 support the specific name type. "null" is returned when no mechanisms 1598 are found to support the specified name type. 1600 Parameters: 1602 nameType The Oid object for the name type. 1604 7.1.5. createName 1606 public abstract GSSName createName(String nameStr, Oid nameType) 1607 throws GSSException 1609 Factory method to convert a contiguous string name from the specified 1610 namespace to a GSSName object. In general, the GSSName object 1611 created will not be an MN; two examples that are exceptions to this 1612 are when the namespace type parameter indicates NT_EXPORT_NAME or 1613 when the GSS-API implementation is not multi-mechanism. 1615 Parameters: 1617 nameStr The string representing a printable form of the 1618 name to create. 1620 nameType The Oid specifying the namespace of the printable 1621 name is supplied. Note that nameType serves to 1622 describe and qualify the interpretation of the 1623 input nameStr, it does not necessarily imply a 1624 type for the output GSSName implementation. The 1625 "null" value can be used to specify that a 1626 mechanism-specific default printable syntax 1627 SHOULD be assumed by each mechanism that examines 1628 nameStr. 1630 7.1.6. createName 1632 public abstract GSSName createName(byte[] name, Oid nameType) 1633 throws GSSException 1635 Factory method to convert a contiguous byte array containing a name 1636 from the specified namespace to a GSSName object. In general, the 1637 GSSName object created will not be an MN; two examples that are 1638 exceptions to this are when the namespace type parameter indicates 1639 NT_EXPORT_NAME or when the GSS-API implementation is not multi- 1640 mechanism. 1642 Parameters: 1644 name The byte array containing the name to create. 1646 nameType The Oid specifying the namespace of the name 1647 supplied in the byte array. Note that nameType 1648 serves to describe and qualify the interpretation 1649 of the input name byte array; it does not 1650 necessarily imply a type for the output GSSName 1651 implementation. The "null" value can be used to 1652 specify that a mechanism-specific default syntax 1653 SHOULD be assumed by each mechanism that examines 1654 the byte array. 1656 7.1.7. createName 1658 public abstract GSSName createName(String nameStr, Oid nameType, 1659 Oid mech) throws GSSException 1661 Factory method to convert a contiguous string name from the specified 1662 namespace to a GSSName object that is a mechanism name (MN). In 1663 other words, this method is a utility that does the equivalent of two 1664 steps: the createName described in section 7.1.5, and then also the 1665 GSSName.canonicalize() described in section 7.2.4. 1667 Parameters: 1669 nameStr The string representing a printable form of the 1670 name to create. 1672 nameType The Oid specifying the namespace of the printable 1673 name supplied. Note that nameType serves to 1674 describe and qualify the interpretation of the 1675 input nameStr; it does not necessarily imply a 1676 type for the output GSSName implementation. The 1677 "null" value can be used to specify that a 1678 mechanism-specific default printable syntax 1679 SHOULD be assumed when the mechanism examines 1680 nameStr. 1682 mech Oid specifying the mechanism for which this name 1683 should be created. 1685 7.1.8. createName 1687 public abstract GSSName createName(byte[] name, Oid nameType, 1688 Oid mech) throws GSSException 1690 Factory method to convert a contiguous byte array containing a name 1691 from the specified namespace to a GSSName object that is an MN. In 1692 other words, this method is a utility that does the equivalent of two 1693 steps: the createName described in section 7.1.6, and then also the 1694 GSSName.canonicalize() described in section 7.2.4. 1696 Parameters: 1698 name The byte array representing the name to create. 1700 nameType The Oid specifying the namespace of the name 1701 supplied in the byte array. Note that nameType 1702 serves to describe and qualify the interpretation 1703 of the input name byte array, it does not 1704 necessarily imply a type for the output GSSName 1705 implementation. The "null" value can be used to 1706 specify that a mechanism-specific default syntax 1707 SHOULD be assumed by each mechanism that examines 1708 the byte array. 1710 mech Oid specifying the mechanism for which this name 1711 should be created. 1713 7.1.9. createCredential 1715 public abstract GSSCredential createCredential(int usage) 1716 throws GSSException 1718 Factory method for acquiring default credentials. This will cause 1719 the GSS-API to use system-specific defaults for the set of 1720 mechanisms, name, and a DEFAULT lifetime. 1722 Parameters: 1724 usage The intended usage for this credential object. 1725 The value of this parameter MUST be one of: 1727 GSSCredential.INITIATE_AND_ACCEPT(0), 1728 GSSCredential.INITIATE_ONLY(1), or 1729 GSSCredential.ACCEPT_ONLY(2) 1731 7.1.10. createCredential 1733 public abstract GSSCredential createCredential(GSSName aName, 1734 int lifetime, Oid mech, int usage) 1735 throws GSSException 1737 Factory method for acquiring a single mechanism credential. 1739 Parameters: 1741 aName Name of the principal for whom this credential is 1742 to be acquired. Use "null" to specify the 1743 default principal. 1745 lifetime The number of seconds that credentials should 1746 remain valid. Use 1747 GSSCredential.INDEFINITE_LIFETIME to request that 1748 the credentials have the maximum permitted 1749 lifetime. Use GSSCredential.DEFAULT_LIFETIME to 1750 request default credential lifetime. 1752 mech The oid of the desired mechanism. Use "(Oid) 1753 null" to request the default mechanism(s). 1755 usage The intended usage for this credential object. 1756 The value of this parameter MUST be one of: 1758 GSSCredential.INITIATE_AND_ACCEPT(0), 1759 GSSCredential.INITIATE_ONLY(1), or 1760 GSSCredential.ACCEPT_ONLY(2) 1762 7.1.11. createCredential 1764 public abstract GSSCredential createCredential(GSSName aName, 1765 int lifetime, Oid[] mechs, int usage) 1766 throws GSSException 1768 Factory method for acquiring credentials over a set of mechanisms. 1769 Acquires credentials for each of the mechanisms specified in the 1770 array called mechs. To determine the list of mechanisms' for which 1771 the acquisition of credentials succeeded, the caller should use the 1772 GSSCredential.getMechs() method. 1774 Parameters: 1776 aName Name of the principal for whom this credential is 1777 to be acquired. Use "null" to specify the 1778 default principal. 1780 lifetime The number of seconds that credentials should 1781 remain valid. Use 1782 GSSCredential.INDEFINITE_LIFETIME to request that 1783 the credentials have the maximum permitted 1784 lifetime. Use GSSCredential.DEFAULT_LIFETIME to 1785 request default credential lifetime. 1787 mechs The array of mechanisms over which the credential 1788 is to be acquired. Use "(Oid[]) null" for 1789 requesting a system-specific default set of 1790 mechanisms. 1792 usage The intended usage for this credential object. 1793 The value of this parameter MUST be one of: 1795 GSSCredential.INITIATE_AND_ACCEPT(0), 1796 GSSCredential.INITIATE_ONLY(1), or 1797 GSSCredential.ACCEPT_ONLY(2) 1799 7.1.12. createContext 1801 public abstract GSSContext createContext(GSSName peer, Oid mech, 1802 GSSCredential myCred, int lifetime) 1803 throws GSSException 1805 Factory method for creating a context on the initiator's side. 1806 Context flags may be modified through the mutator methods prior to 1807 calling GSSContext.initSecContext(). 1809 Parameters: 1811 peer Name of the target peer. 1813 mech Oid of the desired mechanism. Use "(Oid) null" 1814 to request the default mechanism. 1816 myCred Credentials of the initiator. Use "null" to act 1817 as a default initiator principal. 1819 lifetime The request lifetime, in seconds, for the 1820 context. Use GSSContext.INDEFINITE_LIFETIME and 1821 GSSContext.DEFAULT_LIFETIME to request indefinite 1822 or default context lifetime. 1824 7.1.13. createContext 1826 public abstract GSSContext createContext(GSSCredential myCred) 1827 throws GSSException 1829 Factory method for creating a context on the acceptor' side. The 1830 context's properties will be determined from the input token supplied 1831 to the accept method. 1833 Parameters: 1835 myCred Credentials for the acceptor. Use "null" to act 1836 as a default acceptor principal. 1838 7.1.14. createContext 1840 public abstract GSSContext createContext(byte[] interProcessToken) 1841 throws GSSException 1843 Factory method for importing a previously exported context. The 1844 context properties will be determined from the input token and can't 1845 be modified through the set methods. 1847 Parameters: 1849 interProcessToken The token previously emitted from the export 1850 method. 1852 7.1.15. addProviderAtFront 1854 public abstract void addProviderAtFront(Provider p, Oid mech) 1855 throws GSSException 1857 This method is used to indicate to the GSSManager that the 1858 application would like a particular provider to be used ahead of all 1859 others when support is desired for the given mechanism. When a value 1860 of "null" is used instead of an Oid for the mechanism, the GSSManager 1861 MUST use the indicated provider ahead of all others no matter what 1862 the mechanism is. Only when the indicated provider does not support 1863 the needed mechanism should the GSSManager move on to a different 1864 provider. 1866 Calling this method repeatedly preserves the older settings but 1867 lowers them in preference thus forming an ordered list of provider 1868 and Oid pairs that grows at the top. 1870 Calling addProviderAtFront with a null Oid will remove all previous 1871 preferences that were set for this provider in the GSSManager 1872 instance. Calling addProviderAtFront with a non-null Oid will remove 1873 any previous preference that was set using this mechanism and this 1874 provider together. 1876 If the GSSManager implementation does not support an SPI with a 1877 pluggable provider architecture, it SHOULD throw a GSSException with 1878 the status code GSSException.UNAVAILABLE to indicate that the 1879 operation is unavailable. 1881 Parameters: 1883 p The provider instance that should be used 1884 whenever support is needed for mech. 1886 mech The mechanism for which the provider is being 1887 set. 1889 7.1.15.1. addProviderAtFront Example Code 1891 Suppose an application desired that the provider A always be checked 1892 first when any mechanism is needed, it would call: 1894 1895 GSSManager mgr = GSSManager.getInstance(); 1896 // mgr may at this point have its own pre-configured list 1897 // of provider preferences. The following will prepend to 1898 // any such list: 1900 mgr.addProviderAtFront(A, null); 1901 1903 Now if it also desired that the mechanism of Oid m1 always be 1904 obtained from the provider B before the previously set A was checked, 1905 it would call: 1907 1908 mgr.addProviderAtFront(B, m1); 1909 1911 The GSSManager would then first check with B if m1 was needed. In 1912 case B did not provide support for m1, the GSSManager would continue 1913 on to check with A. If any mechanism m2 is needed where m2 is 1914 different from m1, then the GSSManager would skip B and check with A 1915 directly. 1917 Suppose, at a later time, the following call is made to the same 1918 GSSManager instance: 1920 1921 mgr.addProviderAtFront(B, null) 1922 1924 then the previous setting with the pair (B, m1) is subsumed by this 1925 and SHOULD be removed. Effectively, the list of preferences now 1926 becomes {(B, null), (A, null), ... //followed by the pre-configured 1927 list}. 1929 Please note, however, that the following call: 1931 1932 mgr.addProviderAtFront(A, m3) 1933 1935 does not subsume the previous setting of (A, null), and the list will 1936 effectively become {(A, m3), (B, null), (A, null), ...} 1938 7.1.16. addProviderAtEnd 1940 public abstract void addProviderAtEnd(Provider p, Oid mech) 1941 throws GSSException 1943 This method is used to indicate to the GSSManager that the 1944 application would like a particular provider to be used if no other 1945 provider can be found that supports the given mechanism. When a 1946 value of "null" is used instead of an Oid for the mechanism, the 1947 GSSManager MUST use the indicated provider for any mechanism. 1949 Calling this method repeatedly preserves the older settings, but 1950 raises them above newer ones in preference thus forming an ordered 1951 list of providers and Oid pairs that grows at the bottom. Thus, the 1952 older provider settings will be utilized first before this one is. 1954 If there are any previously existing preferences that conflict with 1955 the preference being set here, then the GSSManager SHOULD ignore this 1956 request. 1958 If the GSSManager implementation does not support an SPI with a 1959 pluggable provider architecture, it SHOULD throw a GSSException with 1960 the status code GSSException.UNAVAILABLE to indicate that the 1961 operation is unavailable. 1963 Parameters: 1965 p The provider instance that should be used 1966 whenever support is needed for mech. 1968 mech The mechanism for which the provider is being 1969 set. 1971 7.1.16.1. addProviderAtEnd Example Code 1973 Suppose an application desired that when a mechanism of Oid m1 is 1974 needed, the system default providers always be checked first, and 1975 only when they do not support m1 should a provider A be checked. It 1976 would then make the call: 1978 1979 GSSManager mgr = GSSManager.getInstance(); 1981 mgr.addProviderAtEnd(A, m1); 1982 1984 Now, if it also desired that for all mechanisms the provider B be 1985 checked after all configured providers have been checked, it would 1986 then call: 1988 1989 mgr.addProviderAtEnd(B, null); 1990 1992 Effectively, the list of preferences now becomes {..., (A, m1), (B, 1993 null)}. 1995 Suppose, at a later time, the following call is made to the same 1996 GSSManager instance: 1998 1999 mgr.addProviderAtEnd(B, m2) 2000 2002 then the previous setting with the pair (B, null) subsumes this; 2003 therefore, this request SHOULD be ignored. The same would happen if 2004 a request is made for the already existing pairs of (A, m1) or (B, 2005 null). 2007 Please note, however, that the following call: 2009 2010 mgr.addProviderAtEnd(A, null) 2011 2013 is not subsumed by the previous setting of (A, m1) and the list will 2014 effectively become {..., (A, m1), (B, null), (A, null)}. 2016 7.1.17. Example Code 2018 2019 GSSManager mgr = GSSManager.getInstance(); 2021 // What mechs are available to us? 2023 Oid[] supportedMechs = mgr.getMechs(); 2025 // Set a preference for the provider to be used when support 2026 // is needed for the mechanisms: 2027 // "1.2.840.113554.1.2.2" and "1.3.6.1.5.5.1.1". 2029 Oid krb = new Oid("1.2.840.113554.1.2.2"); 2030 Oid spkm1 = new Oid("1.3.6.1.5.5.1.1"); 2032 Provider p = (Provider) (new com.foo.security.Provider()); 2034 mgr.addProviderAtFront(p, krb); 2035 mgr.addProviderAtFront(p, spkm1); 2037 // What name types does this spkm implementation support? 2038 Oid[] nameTypes = mgr.getNamesForMech(spkm1); 2039 2041 7.2. public interface GSSName 2043 This interface encapsulates a single GSS-API principal entity. 2044 Different name formats and their definitions are identified with 2045 Universal Object Identifiers (Oids). The format of the names can be 2046 derived based on the unique oid of its namespace type. 2048 7.2.1. Static Constants 2050 public static final Oid NT_HOSTBASED_SERVICE 2052 Oid indicating a host-based service name form. It is used to 2053 represent services associated with host computers. This name form is 2054 constructed using two elements, "service" and "hostname", as follows: 2056 service@hostname 2058 Values for the "service" element are registered with the IANA. It 2059 represents the following value: { iso(1) member-body(2) Unites 2060 States(840) mit(113554) infosys(1) gssapi(2) generic(1) 2061 service_name(4) } 2063 public static final Oid NT_USER_NAME 2064 Name type to indicate a named user on a local system. It represents 2065 the following value: { iso(1) member-body(2) United States(840) 2066 mit(113554) infosys(1) gssapi(2) generic(1) user_name(1) } 2068 public static final Oid NT_MACHINE_UID_NAME 2070 Name type to indicate a numeric user identifier corresponding to a 2071 user on a local system (e.g., Uid). It represents the following 2072 value: { iso(1) member-body(2) United States(840) mit(113554) 2073 infosys(1) gssapi(2) generic(1) machine_uid_name(2) } 2075 public static final Oid NT_STRING_UID_NAME 2077 Name type to indicate a string of digits representing the numeric 2078 user identifier of a user on a local system. It represents the 2079 following value: { iso(1) member-body(2) United States(840) 2080 mit(113554) infosys(1) gssapi(2) generic(1) string_uid_name(3) } 2082 public static final Oid NT_ANONYMOUS 2084 Name type for representing an anonymous entity. It represents the 2085 following value: { iso(1), org(3), dod(6), internet(1), security(5), 2086 nametypes(6), gss-anonymous-name(3) } 2088 public static final Oid NT_EXPORT_NAME 2090 Name type used to indicate an exported name produced by the export 2091 method. It represents the following value: { iso(1), org(3), dod(6), 2092 internet(1), security(5), nametypes(6), gss-api-exported-name(4) } 2094 7.2.2. equals 2096 public boolean equals(GSSName another) throws GSSException 2098 Compares two GSSName objects to determine whether they refer to the 2099 same entity. This method MAY throw a GSSException when the names 2100 cannot be compared. If either of the names represents an anonymous 2101 entity, the method will return "false". 2103 Parameters: 2105 another GSSName object with which to compare. 2107 7.2.3. equals 2109 public boolean equals(Object another) 2110 A variation of the equals method, described in section 7.2.2, that is 2111 provided to override the Object.equals() method that the implementing 2112 class will inherit. The behavior is exactly the same as that in 2113 section 7.2.2 except that no GSSException is thrown; instead, "false" 2114 will be returned in the situation where an error occurs. (Note that 2115 the Java language specification requires that two objects that are 2116 equal according to the equals(Object) method MUST return the same 2117 integer result when the hashCode() method is called on them.) 2119 Parameters: 2121 another GSSName object with which to compare. 2123 7.2.4. canonicalize 2125 public GSSName canonicalize(Oid mech) throws GSSException 2127 Creates a mechanism name (MN) from an arbitrary internal name. This 2128 is equivalent to using the factory methods described in sections 2129 7.1.7 or 7.1.8 that take the mechanism name as one of their 2130 parameters. 2132 Parameters: 2134 mech The oid for the mechanism for which the canonical 2135 form of the name is requested. 2137 7.2.5. export 2139 public byte[] export() throws GSSException 2141 Returns a canonical contiguous byte representation of a mechanism 2142 name (MN), suitable for direct, byte-by-byte comparison by 2143 authorization functions. If the name is not an MN, implementations 2144 MAY throw a GSSException with the NAME_NOT_MN status code. If an 2145 implementation chooses not to throw an exception, it SHOULD use some 2146 system-specific default mechanism to canonicalize the name and then 2147 export it. The format of the header of the output buffer is 2148 specified in RFC 2743 [RFC2743]. 2150 7.2.6. toString 2152 public String toString() 2154 Returns a textual representation of the GSSName object. To retrieve 2155 the printed name format, which determines the syntax of the returned 2156 string, the getStringNameType method can be used. 2158 7.2.7. getStringNameType 2160 public Oid getStringNameType() throws GSSException 2162 Returns the oid representing the type of name returned through the 2163 toString method. Using this oid, the syntax of the printable name 2164 can be determined. 2166 7.2.8. isAnonymous 2168 public boolean isAnonymous() 2170 Tests if this name object represents an anonymous entity. Returns 2171 "true" if this is an anonymous name. 2173 7.2.9. isMN 2175 public boolean isMN() 2177 Tests if this name object contains only one mechanism element and is 2178 thus a mechanism name as defined by RFC 2743 [RFC2743]. 2180 7.2.10. Example Code 2182 Included below are code examples utilizing the GSSName interface. 2183 The code below creates a GSSName, converts it to a mechanism name 2184 (MN), performs a comparison, obtains a printable representation of 2185 the name, exports it and then re-imports to obtain a new GSSName. 2187 2188 GSSManager mgr = GSSManager.getInstance(); 2190 // create a host-based service name 2191 GSSName name = mgr.createName("service@host", 2192 GSSName.NT_HOSTBASED_SERVICE); 2194 Oid krb5 = new Oid("1.2.840.113554.1.2.2"); 2196 GSSName mechName = name.canonicalize(krb5); 2198 // the above two steps are equivalent to the following 2199 GSSName mechName = mgr.createName("service@host", 2200 GSSName.NT_HOSTBASED_SERVICE, krb5); 2202 // perform name comparison 2203 if (name.equals(mechName)) 2204 print("Names are equals."); 2206 // obtain textual representation of name and its printable 2207 // name type 2208 print(mechName.toString() + 2209 mechName.getStringNameType().toString()); 2211 // export the name 2212 byte[] exportName = mechName.export(); 2214 // create a new name object from the exported buffer 2215 GSSName newName = mgr.createName(exportName, 2216 GSSName.NT_EXPORT_NAME); 2217 2219 7.3. public interface GSSCredential implements Cloneable 2221 This interface encapsulates the GSS-API credentials for an entity. A 2222 credential contains all the necessary cryptographic information to 2223 enable the creation of a context on behalf of the entity that it 2224 represents. It MAY contain multiple, distinct, mechanism-specific 2225 credential elements, each containing information for a specific 2226 security mechanism, but all referring to the same entity. 2228 A credential MAY be used to perform context initiation, acceptance, 2229 or both. 2231 GSS-API implementations MUST impose a local access-control policy on 2232 callers to prevent unauthorized callers from acquiring credentials to 2233 which they are not entitled. GSS-API credential creation is not 2234 intended to provide a "login to the network" function, as such a 2235 function would involve the creation of new credentials rather than 2236 merely acquiring a handle to existing credentials. Such functions, 2237 if required, SHOULD be defined in implementation-specific extensions 2238 to the API. 2240 If credential acquisition is time-consuming for a mechanism, the 2241 mechanism MAY choose to delay the actual acquisition until the 2242 credential is required (e.g., by GSSContext). Such mechanism- 2243 specific implementation decisions SHOULD be invisible to the calling 2244 application; thus, the query methods immediately following the 2245 creation of a credential object MUST return valid credential data, 2246 and may therefore incur the overhead of a deferred credential 2247 acquisition. 2249 Applications will create a credential object passing the desired 2250 parameters. The application can then use the query methods to obtain 2251 specific information about the instantiated credential object 2252 (equivalent to the gss_inquire routines). When the credential is no 2253 longer needed, the application SHOULD call the dispose (equivalent to 2254 gss_release_cred) method to release any resources held by the 2255 credential object and to destroy any cryptographically sensitive 2256 information. 2258 Classes implementing this interface also implement the Cloneable 2259 interface. This indicates that the class will support the clone() 2260 method that will allow the creation of duplicate credentials. This 2261 is useful when called just before the add() call to retain a copy of 2262 the original credential. 2264 7.3.1. Static Constants 2266 public static final int INITIATE_AND_ACCEPT 2268 Credential usage flag requesting that it be able to be used for both 2269 context initiation and acceptance. The value of this constant is 0. 2271 public static final int INITIATE_ONLY 2273 Credential usage flag requesting that it be able to be used for 2274 context initiation only. The value of this constant is 1. 2276 public static final int ACCEPT_ONLY 2278 Credential usage flag requesting that it be able to be used for 2279 context acceptance only. The value of this constant is 2. 2281 public static final int DEFAULT_LIFETIME 2282 A lifetime constant representing the default credential lifetime. 2283 The value of this constant is 0. 2285 public static final int INDEFINITE_LIFETIME 2287 A lifetime constant representing indefinite credential lifetime. The 2288 value of this constant is the maximum integer value in Java - 2289 Integer.MAX_VALUE. 2291 7.3.2. dispose 2293 public void dispose() throws GSSException 2295 Releases any sensitive information that the GSSCredential object may 2296 be containing. Applications SHOULD call this method as soon as the 2297 credential is no longer needed to minimize the time any sensitive 2298 information is maintained. 2300 7.3.3. getName 2302 public GSSName getName() throws GSSException 2304 Retrieves the name of the entity that the credential asserts. 2306 7.3.4. getName 2308 public GSSName getName(Oid mechOID) throws GSSException 2310 Retrieves a mechanism name of the entity that the credential asserts. 2311 Equivalent to calling canonicalize() on the name returned by section 2312 7.3.3. 2314 Parameters: 2316 mechOID The mechanism for which information should be 2317 returned. 2319 7.3.5. getRemainingLifetime 2321 public int getRemainingLifetime() throws GSSException 2323 Returns the remaining lifetime in seconds for a credential. The 2324 remaining lifetime is the minimum lifetime for any of the underlying 2325 credential mechanisms. A return value of 2326 GSSCredential.INDEFINITE_LIFETIME indicates that the credential does 2327 not expire. A return value of 0 indicates that the credential is 2328 already expired. 2330 7.3.6. getRemainingInitLifetime 2332 public int getRemainingInitLifetime(Oid mech) throws GSSException 2334 Returns the remaining lifetime in seconds for the credential to 2335 remain capable of initiating security contexts under the specified 2336 mechanism. A return value of GSSCredential.INDEFINITE_LIFETIME 2337 indicates that the credential does not expire for context initiation. 2338 A return value of 0 indicates that the credential is already expired. 2340 Parameters: 2342 mechOID The mechanism for which information should be 2343 returned. 2345 7.3.7. getRemainingAcceptLifetime 2347 public int getRemainingAcceptLifetime(Oid mech) throws GSSException 2349 Returns the remaining lifetime in seconds for the credential to 2350 remain capable of accepting security contexts under the specified 2351 mechanism. A return value of GSSCredential.INDEFINITE_LIFETIME 2352 indicates that the credential does not expire for context acceptance. 2353 A return value of 0 indicates that the credential is already expired. 2355 Parameters: 2357 mechOID The mechanism for which information should be 2358 returned. 2360 7.3.8. getUsage 2362 public int getUsage() throws GSSException 2364 Returns the credential usage flag as a union over all mechanisms. 2365 The return value will be one of GSSCredential.INITIATE_AND_ACCEPT(0), 2366 GSSCredential.INITIATE_ONLY(1), or GSSCredential.ACCEPT_ONLY(2). 2368 Specifically, GSSCredential.INITIATE_AND_ACCEPT(0) SHOULD be returned 2369 as long as there exists one credential element allowing context 2370 initiation and one credential element allowing context acceptance. 2371 These two credential elements are not necessarily the same one, nor 2372 do they need to use the same mechanism(s). 2374 7.3.9. getUsage 2376 public int getUsage(Oid mechOID) throws GSSException 2378 Returns the credential usage flag for the specified mechanism only. 2379 The return value will be one of GSSCredential.INITIATE_AND_ACCEPT(0), 2380 GSSCredential.INITIATE_ONLY(1), or GSSCredential.ACCEPT_ONLY(2). 2382 Parameters: 2384 mechOID The mechanism for which information should be 2385 returned. 2387 7.3.10. getMechs 2389 public Oid[] getMechs() throws GSSException 2391 Returns an array of mechanisms supported by this credential. 2393 7.3.11. add 2395 public void add(GSSName aName, int initLifetime, int acceptLifetime, 2396 Oid mech, int usage) throws GSSException 2398 Adds a mechanism-specific credential-element to an existing 2399 credential. This method allows the construction of credentials one 2400 mechanism at a time. 2402 This routine is envisioned to be used mainly by context acceptors 2403 during the creation of acceptance credentials, which are to be used 2404 with a variety of clients using different security mechanisms. 2406 This routine adds the new credential element "in-place". To add the 2407 element in a new credential, first call clone() to obtain a copy of 2408 this credential, then call its add() method. 2410 Parameters: 2412 aName Name of the principal for whom this credential is 2413 to be acquired. Use "null" to specify the 2414 default principal. 2416 initLifetime The number of seconds that credentials should 2417 remain valid for initiating of security contexts. 2418 Use GSSCredential.INDEFINITE_LIFETIME to request 2419 that the credentials have the maximum permitted 2420 lifetime. Use GSSCredential.DEFAULT_LIFETIME to 2421 request default credential lifetime. 2423 acceptLifetime The number of seconds that credentials should 2424 remain valid for accepting of security contexts. 2426 Use GSSCredential.INDEFINITE_LIFETIME to request 2427 that the credentials 2428 have the maximum permitted lifetime. Use 2429 GSSCredential.DEFAULT_LIFETIME to request default 2430 credential lifetime. 2432 mech The mechanisms over which the credential is to be 2433 acquired. 2435 usage The intended usage for this credential object. 2436 The value of this parameter MUST be one of: 2438 GSSCredential.INITIATE_AND_ACCEPT(0), 2439 GSSCredential.INITIATE_ONLY(1), or 2440 GSSCredential.ACCEPT_ONLY(2) 2442 7.3.12. equals 2444 public boolean equals(Object another) 2446 Tests if this GSSCredential refers to the same entity as the supplied 2447 object. The two credentials MUST be acquired over the same 2448 mechanisms and MUST refer to the same principal. Returns "true" if 2449 the two GSSCredentials refer to the same entity; "false" otherwise. 2450 (Note that the Java language specification [JLS] requires that two 2451 objects that are equal according to the equals(Object) method MUST 2452 return the same integer result when the hashCode() method is called 2453 on them.) 2455 Parameters: 2457 another Another GSSCredential object for comparison. 2459 7.3.13. Example Code 2461 This example code demonstrates the creation of a GSSCredential 2462 implementation for a specific entity, querying of its fields, and its 2463 release when it is no longer needed. 2465 2466 GSSManager mgr = GSSManager.getInstance(); 2468 // start by creating a name object for the entity 2469 GSSName name = mgr.createName("userName", GSSName.NT_USER_NAME); 2471 // now acquire credentials for the entity 2472 GSSCredential cred = mgr.createCredential(name, 2473 GSSCredential.ACCEPT_ONLY); 2475 // display credential information - name, remaining lifetime, 2476 // and the mechanisms it has been acquired over 2477 print(cred.getName().toString()); 2478 print(cred.getRemainingLifetime()); 2480 Oid[] mechs = cred.getMechs(); 2481 if (mechs != null) { 2482 for (int i = 0; i < mechs.length; i++) 2483 print(mechs[i].toString()); 2484 } 2485 // release system resources held by the credential 2486 cred.dispose(); 2487 2489 7.4. public interface GSSContext 2491 This interface encapsulates the GSS-API security context and provides 2492 the security services (wrap, unwrap, getMIC, verifyMIC) that are 2493 available over the context. Security contexts are established 2494 between peers using locally acquired credentials. Multiple contexts 2495 may exist simultaneously between a pair of peers, using the same or 2496 different set of credentials. GSS-API functions in a manner 2497 independent of the underlying transport protocol and depends on its 2498 calling application to transport its tokens between peers. 2500 Before the context establishment phase is initiated, the context 2501 initiator may request specific characteristics desired of the 2502 established context. These can be set using the set methods. After 2503 the context is established, the caller can check the actual 2504 characteristic and services offered by the context using the query 2505 methods. 2507 The context establishment phase begins with the first call to the 2508 init method by the context initiator. During this phase, the 2509 initSecContext and acceptSecContext methods will produce GSS-API 2510 authentication tokens, which the calling application needs to send to 2511 its peer. If an error occurs at any point, an exception will get 2512 thrown and the code will start executing in a catch block where the 2513 exception may contain an output token that should be sent to the peer 2514 for debugging or informational purpose. If not, the normal flow of 2515 code continues and the application can make a call to the 2516 isEstablished() method. If this method returns "false" it indicates 2517 that a token is needed from its peer in order to continue the context 2518 establishment phase. A return value of "true" signals that the local 2519 end of the context is established. This may still require that a 2520 token be sent to the peer, if one is produced by GSS-API. During the 2521 context establishment phase, the isProtReady() method may be called 2522 to determine if the context can be used for the per-message 2523 operations. This allows applications to use per-message operations 2524 on contexts that aren't fully established. 2526 After the context has been established or the isProtReady() method 2527 returns "true", the query routines can be invoked to determine the 2528 actual characteristics and services of the established context. The 2529 application can also start using the per-message methods of wrap and 2530 getMIC to obtain cryptographic operations on application supplied 2531 data. 2533 When the context is no longer needed, the application SHOULD call 2534 dispose to release any system resources the context may be using. 2536 7.4.1. Static Constants 2538 public static final int DEFAULT_LIFETIME 2540 A lifetime constant representing the default context lifetime. The 2541 value of this constant is 0. 2543 public static final int INDEFINITE_LIFETIME 2545 A lifetime constant representing indefinite context lifetime. The 2546 value of this constant is the maximum integer value in Java - 2547 Integer.MAX_VALUE. 2549 7.4.2. initSecContext 2551 public byte[] initSecContext(byte[] inputBuf, int offset, int len) 2552 throws GSSException 2554 Called by the context initiator to start the context creation 2555 process. This method MAY return an output token that the application 2556 will need to send to the peer for processing by the accept call. The 2557 application can call isEstablished() to determine if the context 2558 establishment phase is complete for this peer. A return value of 2559 "false" from isEstablished() indicates that more tokens are expected 2560 to be supplied to the initSecContext() method. Note that it is 2561 possible that the initSecContext() method will return a token for the 2562 peer and isEstablished() will return "true" also. This indicates 2563 that the token needs to be sent to the peer, but the local end of the 2564 context is now fully established. 2566 Upon completion of the context establishment, the available context 2567 options may be queried through the get methods. 2569 A GSSException will be thrown if the call fails. Users SHOULD call 2570 its getOutputToken() method to find out if there is a token that can 2571 be sent to the acceptor to communicate the reason for the error. 2573 Parameters: 2575 inputBuf Token generated by the peer. This parameter is 2576 ignored on the first call. 2578 offset The offset within the inputBuf where the token 2579 begins. 2581 len The length of the token within the inputBuf 2582 (starting at the offset). 2584 7.4.3. acceptSecContext 2586 public byte[] acceptSecContext(byte[] inTok, int offset, int len) 2587 throws GSSException 2589 Called by the context acceptor upon receiving a token from the peer. 2591 This method MAY return an output token that the application will need 2592 to send to the peer for further processing by the init call. 2594 The "null" return value indicates that no token needs to be sent to 2595 the peer. The application can call isEstablished() to determine if 2596 the context establishment phase is complete for this peer. A return 2597 value of "false" from isEstablished() indicates that more tokens are 2598 expected to be supplied to this method. 2600 Note that it is possible that acceptSecContext() will return a token 2601 for the peer and isEstablished() will return "true" also. This 2602 indicates that the token needs to be sent to the peer, but the local 2603 end of the context is now fully established. 2605 Upon completion of the context establishment, the available context 2606 options may be queried through the get methods. 2608 A GSSException will be thrown if the call fails. Users SHOULD call 2609 its getOutputToken() method to find out if there is a token that can 2610 be sent to the initiator to communicate the reason for the error. 2612 Parameters: 2614 inTok Token generated by the peer. 2616 offset The offset within the inTok where the token 2617 begins. 2619 len The length of the token within the inTok 2620 (starting at the offset). 2622 7.4.4. isEstablished 2624 public boolean isEstablished() 2626 Used during context establishment to determine the state of the 2627 context. Returns "true" if this is a fully established context on 2628 the caller's side and no more tokens are needed from the peer. 2629 Should be called after a call to initSecContext() or 2630 acceptSecContext() when no GSSException is thrown. 2632 7.4.5. dispose 2634 public void dispose() throws GSSException 2636 Releases any system resources and cryptographic information stored in 2637 the context object. This will invalidate the context. 2639 7.4.6. getWrapSizeLimit 2641 public int getWrapSizeLimit(int qop, boolean confReq, 2642 int maxTokenSize) throws GSSException 2644 Returns the maximum message size that, if presented to the wrap 2645 method with the same confReq and qop parameters, will result in an 2646 output token containing no more than the maxTokenSize bytes. 2648 This call is intended for use by applications that communicate over 2649 protocols that impose a maximum message size. It enables the 2650 application to fragment messages prior to applying protection. 2652 GSS-API implementations are RECOMMENDED but not required to detect 2653 invalid QOP values when getWrapSizeLimit is called. This routine 2654 guarantees only a maximum message size, not the availability of 2655 specific QOP values for message protection. 2657 Successful completion of this call does not guarantee that wrap will 2658 be able to protect a message of the computed length, since this 2659 ability may depend on the availability of system resources at the 2660 time that wrap is called. However, if the implementation itself 2661 imposes an upper limit on the length of messages that may be 2662 processed by wrap, the implementation SHOULD NOT return a value that 2663 is greater than this length. 2665 Parameters: 2667 qop Indicates the level of protection wrap will be 2668 asked to provide. 2670 confReq Indicates if wrap will be asked to provide 2671 privacy service. 2673 maxTokenSize The desired maximum size of the token emitted by 2674 wrap. 2676 7.4.7. wrap 2678 public byte[] wrap(byte[] inBuf, int offset, int len, 2679 MessageProp msgProp) throws GSSException 2681 Applies per-message security services over the established security 2682 context. The method will return a token with a cryptographic MIC and 2683 MAY optionally encrypt the specified inBuf. The returned byte array 2684 will contain both the MIC and the message. 2686 The MessageProp object is instantiated by the application and used to 2687 specify a QOP value that selects cryptographic algorithms, and a 2688 privacy service to optionally encrypt the message. The underlying 2689 mechanism that is used in the call may not be able to provide the 2690 privacy service. It sets the actual privacy service that it does 2691 provide in this MessageProp object, which the caller SHOULD then 2692 query upon return. If the mechanism is not able to provide the 2693 requested QOP, it throws a GSSException with the BAD_QOP code. 2695 Since some application-level protocols may wish to use tokens emitted 2696 by wrap to provide "secure framing", implementations SHOULD support 2697 the wrapping of zero-length messages. 2699 The application will be responsible for sending the token to the 2700 peer. 2702 Parameters: 2704 inBuf Application data to be protected. 2706 offset The offset within the inBuf where the data 2707 begins. 2709 len The length of the data within the inBuf (starting 2710 at the offset). 2712 msgProp Instance of MessageProp that is used by the 2713 application to set the desired QOP and privacy 2714 state. Set the desired QOP to 0 to request the 2715 default QOP. Upon return from this method, this 2716 object will contain the actual privacy state that 2717 was applied to the message by the underlying 2718 mechanism. 2720 7.4.8. unwrap 2722 public byte[] unwrap(byte[] inBuf, int offset, int len, 2723 MessageProp msgProp) throws GSSException 2725 Used by the peer application to process tokens generated with the 2726 wrap call. The method will return the message supplied in the peer 2727 application to the wrap call, verifying the embedded MIC. 2729 The MessageProp object is instantiated by the application and is used 2730 by the underlying mechanism to return information to the caller such 2731 as the QOP, whether confidentiality was applied to the message, and 2732 other supplementary message state information. 2734 Since some application-level protocols may wish to use tokens emitted 2735 by wrap to provide "secure framing", implementations SHOULD support 2736 the wrapping and unwrapping of zero-length messages. 2738 Parameters: 2740 inBuf GSS-API wrap token received from peer. 2742 offset The offset within the inBuf where the token 2743 begins. 2745 len The length of the token within the inBuf 2746 (starting at the offset). 2748 msgProp Upon return from the method, this object will 2749 contain the applied QOP, the privacy state of the 2750 message, and supplementary information, described 2751 in section 5.12.3, stating whether the token was 2752 a duplicate, old, out of sequence, or arriving 2753 after a gap. 2755 7.4.9. getMIC 2757 public byte[] getMIC(byte[] inMsg, int offset, int len, 2758 MessageProp msgProp) throws GSSException 2760 Returns a token containing a cryptographic MIC for the supplied 2761 message for transfer to the peer application. Unlike wrap, which 2762 encapsulates the user message in the returned token, only the message 2763 MIC is returned in the output token. 2765 Note that privacy can only be applied through the wrap call. 2767 Since some application-level protocols may wish to use tokens emitted 2768 by getMIC to provide "secure framing", implementations SHOULD support 2769 derivation of MICs from zero-length messages. 2771 Parameters: 2773 inMsg Message over which to generate MIC. 2775 offset The offset within the inMsg where the token 2776 begins. 2778 len The length of the token within the inMsg 2779 (starting at the offset). 2781 msgProp Instance of MessageProp that is used by the 2782 application to set the desired QOP. Set the 2783 desired QOP to 0 in msgProp to request the 2784 default QOP. Alternatively, pass in "null" for 2785 msgProp to request default QOP. 2787 7.4.10. verifyMIC 2789 public void verifyMIC(byte[] inTok, int tokOffset, int tokLen, 2790 byte[] inMsg, int msgOffset, int msgLen, 2791 MessageProp msgProp) throws GSSException 2793 Verifies the cryptographic MIC, contained in the token parameter, 2794 over the supplied message. 2796 The MessageProp object is instantiated by the application and is used 2797 by the underlying mechanism to return information to the caller such 2798 as the QOP indicating the strength of protection that was applied to 2799 the message and other supplementary message state information. 2801 Since some application-level protocols may wish to use tokens emitted 2802 by getMIC to provide "secure framing", implementations SHOULD support 2803 the calculation and verification of MICs over zero-length messages. 2805 Parameters: 2807 inTok Token generated by peer's getMIC method. 2809 tokOffset The offset within the inTok where the token 2810 begins. 2812 tokLen The length of the token within the inTok 2813 (starting at the offset). 2815 inMsg Application message over which to verify the 2816 cryptographic MIC. 2818 msgOffset The offset within the inMsg where the message 2819 begins. 2821 msgLen The length of the message within the inMsg 2822 (starting at the offset). 2824 msgProp Upon return from the method, this object will 2825 contain the applied QOP and supplementary 2826 information, described in section 5.12.3, stating 2827 whether the token was a duplicate, old, out of 2828 sequence, or arriving after a gap. The 2829 confidentiality state will be set to "false". 2831 7.4.11. export 2833 public byte[] export() throws GSSException 2835 Provided to support the sharing of work between multiple processes. 2836 This routine will typically be used by the context acceptor, in an 2837 application where a single process receives incoming connection 2838 requests and accepts security contexts over them, then passes the 2839 established context to one or more other processes for message 2840 exchange. 2842 This method deactivates the security context and creates an inter- 2843 process token which, when passed to the byte array constructor of the 2844 GSSContext interface in another process, will re-activate the context 2845 in the second process. Only a single instantiation of a given 2846 context may be active at any one time; a subsequent attempt by a 2847 context exporter to access the exported security context will fail. 2849 The implementation MAY constrain the set of processes by which the 2850 inter-process token may be imported, either as a function of local 2851 security policy, or as a result of implementation decisions. For 2852 example, some implementations may constrain contexts to be passed 2853 only between processes that run under the same account, or which are 2854 part of the same process group. 2856 The inter-process token MAY contain security-sensitive information 2857 (for example, cryptographic keys). While mechanisms are encouraged 2858 to either avoid placing such sensitive information within inter- 2859 process tokens or to encrypt the token before returning it to the 2860 application, in a typical GSS-API implementation, this may not be 2861 possible. Thus, the application MUST take care to protect the inter- 2862 process token, and ensure that any process to which the token is 2863 transferred is trustworthy. 2865 7.4.12. requestMutualAuth 2867 public void requestMutualAuth(boolean state) throws GSSException 2869 Sets the request state of the mutual authentication flag for the 2870 context. This method is only valid before the context creation 2871 process begins and only for the initiator. 2873 Parameters: 2875 state Boolean representing if mutual authentication 2876 should be requested during context establishment. 2878 7.4.13. requestReplayDet 2880 public void requestReplayDet(boolean state) throws GSSException 2882 Sets the request state of the replay detection service for the 2883 context. This method is only valid before the context creation 2884 process begins and only for the initiator. 2886 Parameters: 2888 state Boolean representing if replay detection is 2889 desired over the established context. 2891 7.4.14. requestSequenceDet 2893 public void requestSequenceDet(boolean state) throws GSSException 2894 Sets the request state for the sequence checking service of the 2895 context. This method is only valid before the context creation 2896 process begins and only for the initiator. 2898 Parameters: 2900 state Boolean representing if sequence detection is 2901 desired over the established context. 2903 7.4.15. requestCredDeleg 2905 public void requestCredDeleg(boolean state) throws GSSException 2907 Sets the request state for the credential delegation flag for the 2908 context. This method is only valid before the context creation 2909 process begins and only for the initiator. 2911 Parameters: 2913 state Boolean representing if credential delegation is 2914 desired. 2916 7.4.16. requestAnonymity 2918 public void requestAnonymity(boolean state) throws GSSException 2920 Requests anonymous support over the context. This method is only 2921 valid before the context creation process begins and only for the 2922 initiator. 2924 Parameters: 2926 state Boolean representing if anonymity support is 2927 requested. 2929 7.4.17. requestConf 2931 public void requestConf(boolean state) throws GSSException 2933 Requests that confidentiality service be available over the context. 2934 This method is only valid before the context creation process begins 2935 and only for the initiator. 2937 Parameters: 2939 state Boolean indicating if confidentiality services 2940 are to be requested for the context. 2942 7.4.18. requestInteg 2944 public void requestInteg(boolean state) throws GSSException 2946 Requests that integrity services be available over the context. This 2947 method is only valid before the context creation process begins and 2948 only for the initiator. 2950 Parameters: 2952 state Boolean indicating if integrity services are to 2953 be requested for the context. 2955 7.4.19. requestLifetime 2957 public void requestLifetime(int lifetime) throws GSSException 2959 Sets the desired lifetime for the context in seconds. This method is 2960 only valid before the context creation process begins and only for 2961 the initiator. Use GSSContext.INDEFINITE_LIFETIME and 2962 GSSContext.DEFAULT_LIFETIME to request indefinite or default context 2963 lifetime. 2965 Parameters: 2967 lifetime The desired context lifetime in seconds. 2969 7.4.20. setChannelBinding 2971 public void setChannelBinding(ChannelBinding cb) throws GSSException 2973 Sets the channel bindings to be used during context establishment. 2974 This method is only valid before the context creation process begins. 2976 Parameters: 2978 cb Channel bindings to be used. 2980 7.4.21. getCredDelegState 2982 public boolean getCredDelegState() 2984 Returns the state of the delegated credentials for the context. When 2985 issued before context establishment is completed or when the 2986 isProtReady method returns "false", it returns the desired state; 2987 otherwise, it will indicate the actual state over the established 2988 context. 2990 7.4.22. getMutualAuthState 2992 public boolean getMutualAuthState() 2994 Returns the state of the mutual authentication option for the 2995 context. When issued before context establishment completes or when 2996 the isProtReady method returns "false", it returns the desired state; 2997 otherwise, it will indicate the actual state over the established 2998 context. 3000 7.4.23. getReplayDetState 3002 public boolean getReplayDetState() 3004 Returns the state of the replay detection option for the context. 3005 When issued before context establishment completes or when the 3006 isProtReady method returns "false", it returns the desired state; 3007 otherwise, it will indicate the actual state over the established 3008 context. 3010 7.4.24. getSequenceDetState 3012 public boolean getSequenceDetState() 3014 Returns the state of the sequence detection option for the context. 3015 When issued before context establishment completes or when the 3016 isProtReady method returns "false", it returns the desired state; 3017 otherwise, it will indicate the actual state over the established 3018 context. 3020 7.4.25. getAnonymityState 3022 public boolean getAnonymityState() 3024 Returns "true" if this is an anonymous context. When issued before 3025 context establishment completes or when the isProtReady method 3026 returns "false", it returns the desired state; otherwise, it will 3027 indicate the actual state over the established context. 3029 7.4.26. isTransferable 3031 public boolean isTransferable() throws GSSException 3033 Returns "true" if the context is transferable to other processes 3034 through the use of the export method. This call is only valid on 3035 fully established contexts. 3037 7.4.27. isProtReady 3039 public boolean isProtReady() 3041 Returns "true" if the per-message operations can be applied over the 3042 context. Some mechanisms may allow the usage of per-message 3043 operations before the context is fully established. This will also 3044 indicate that the get methods will return actual context state 3045 characteristics instead of the desired ones. 3047 7.4.28. getConfState 3049 public boolean getConfState() 3051 Returns the confidentiality service state over the context. When 3052 issued before context establishment completes or when the isProtReady 3053 method returns "false", it returns the desired state; otherwise, it 3054 will indicate the actual state over the established context. 3056 7.4.29. getIntegState 3058 public boolean getIntegState() 3060 Returns the integrity service state over the context. When issued 3061 before context establishment completes or when the isProtReady method 3062 returns "false", it returns the desired state; otherwise, it will 3063 indicate the actual state over the established context. 3065 7.4.30. getLifetime 3067 public int getLifetime() 3069 Returns the context lifetime in seconds. When issued before context 3070 establishment completes or when the isProtReady method returns 3071 "false", it returns the desired lifetime; otherwise, it will indicate 3072 the remaining lifetime for the context. 3074 7.4.31. getSrcName 3076 public GSSName getSrcName() throws GSSException 3078 Returns the name of the context initiator. This call is valid only 3079 after the context is fully established or the isProtReady method 3080 returns "true". It is guaranteed to return an MN. 3082 7.4.32. getTargName 3084 public GSSName getTargName() throws GSSException 3086 Returns the name of the context target (acceptor). This call is 3087 valid only after the context is fully established or the isProtReady 3088 method returns "true". It is guaranteed to return an MN. 3090 7.4.33. getMech 3092 public Oid getMech() throws GSSException 3094 Returns the mechanism oid for this context. This method MAY be 3095 called before the context is fully established, but the mechanism 3096 returned MAY change on successive calls in negotiated mechanism case. 3098 7.4.34. getDelegCred 3100 public GSSCredential getDelegCred() throws GSSException 3102 Returns the delegated credential object on the acceptor's side. To 3103 check for availability of delegated credentials call 3104 getDelegCredState. This call is only valid on fully established 3105 contexts. 3107 7.4.35. isInitiator 3109 public boolean isInitiator() throws GSSException 3111 Returns "true" if this is the initiator of the context. This call is 3112 only valid after the context creation process has started. 3114 7.4.36. Example Code 3116 The example code presented below demonstrates the usage of the 3117 GSSContext interface for the initiating peer. Different operations 3118 on the GSSContext object are presented, including: object 3119 instantiation, setting of desired flags, context establishment, query 3120 of actual context flags, per-message operations on application data, 3121 and finally context deletion. 3123 3124 GSSManager mgr = GSSManager.getInstance(); 3126 // start by creating the name for a service entity 3127 GSSName targetName = mgr.createName("service@host", 3128 GSSName.NT_HOSTBASED_SERVICE); 3129 // create a context using default credentials for the above entity 3130 // and the implementation-specific default mechanism 3131 GSSContext context = mgr.createContext(targetName, 3132 null, /* default mechanism */ 3133 null, /* default credentials */ 3134 GSSContext.INDEFINITE_LIFETIME); 3136 // set desired context options - all others are "false" by default 3137 context.requestConf(true); 3138 context.requestMutualAuth(true); 3139 context.requestReplayDet(true); 3140 context.requestSequenceDet(true); 3142 // establish a context between peers - using byte arrays 3143 byte[]inTok = new byte[0]; 3145 try { 3146 do { 3147 byte[] outTok = context.initSecContext(inTok, 0, 3148 inTok.length); 3150 // send the token if present 3151 if (outTok != null) 3152 sendToken(outTok); 3154 // check if we should expect more tokens 3155 if (context.isEstablished()) 3156 break; 3158 // another token expected from peer 3159 inTok = readToken(); 3161 } while (true); 3163 } catch (GSSException e) { 3164 print("GSSAPI error: " + e.getMessage()); 3166 // If the exception contains an output token, 3167 // it should be sent to the acceptor. 3168 byte[] outTok = e.getOutputToken(); 3169 if (outTok != null) { 3170 sendToken(outTok); 3171 } 3173 return; 3174 } 3176 // display context information 3177 print("Remaining lifetime in seconds = " + context.getLifetime()); 3178 print("Context mechanism = " + context.getMech().toString()); 3179 print("Initiator = " + context.getSrcName().toString()); 3180 print("Acceptor = " + context.getTargName().toString()); 3182 if (context.getConfState()) 3183 print("Confidentiality security service available"); 3185 if (context.getIntegState()) 3186 print("Integrity security service available"); 3188 // perform wrap on an application-supplied message, appMsg, 3189 // using QOP = 0, and requesting privacy service 3190 byte[] appMsg ... 3192 MessageProp mProp = new MessageProp(0, true); 3194 byte[] tok = context.wrap(appMsg, 0, appMsg.length, mProp); 3196 if (mProp.getPrivacy()) 3197 print("Message protected with privacy."); 3199 sendToken(tok); 3201 // release the local end of the context 3202 context.dispose(); 3203 3205 7.5. public class MessageProp 3207 This is a utility class used within the per-message GSSContext 3208 methods to convey per-message properties. 3210 When used with the GSSContext interface's wrap and getMIC methods, an 3211 instance of this class is used to indicate the desired QOP and to 3212 request if confidentiality services are to be applied to caller 3213 supplied data (wrap only). To request default QOP, the value of 0 3214 should be used for QOP. A QOP is an integer value defined by an 3215 mechanism. 3217 When used with the unwrap and verifyMIC methods of the GSSContext 3218 interface, an instance of this class will be used to indicate the 3219 applied QOP and confidentiality services over the supplied message. 3220 In the case of verifyMIC, the confidentiality state will always be 3221 "false". Upon return from these methods, this object will also 3222 contain any supplementary status values applicable to the processed 3223 token. The supplementary status values can indicate old tokens, out 3224 of sequence tokens, gap tokens, or duplicate tokens. 3226 7.5.1. Constructors 3228 public MessageProp(boolean privState) 3230 Constructor that sets QOP to 0 indicating that the default QOP is 3231 requested. 3233 Parameters: 3235 privState The desired privacy state. "true" for privacy and 3236 "false" for integrity only. 3238 public MessageProp(int qop, boolean privState) 3240 Constructor that sets the values for the qop and privacy state. 3242 Parameters: 3244 qop The desired QOP. Use 0 to request a default QOP. 3246 privState The desired privacy state. "true" for privacy and 3247 "false" for integrity only. 3249 7.5.2. getQOP 3251 public int getQOP() 3253 Retrieves the QOP value. 3255 7.5.3. getPrivacy 3257 public boolean getPrivacy() 3259 Retrieves the privacy state. 3261 7.5.4. getMinorStatus 3263 public int getMinorStatus() 3265 Retrieves the minor status that the underlying mechanism might have 3266 set. 3268 7.5.5. getMinorString 3270 public String getMinorString() 3272 Returns a string explaining the mechanism-specific error code. "null" 3273 will be returned when no mechanism error code has been set. 3275 7.5.6. setQOP 3277 public void setQOP(int qopVal) 3279 Sets the QOP value. 3281 Parameters: 3283 qopVal The QOP value to be set. Use 0 to request a 3284 default QOP value. 3286 7.5.7. setPrivacy 3288 public void setPrivacy(boolean privState) 3290 Sets the privacy state. 3292 Parameters: 3294 privState The privacy state to set. 3296 7.5.8. isDuplicateToken 3298 public boolean isDuplicateToken() 3300 Returns "true" if this is a duplicate of an earlier token. 3302 7.5.9. isOldToken 3304 public boolean isOldToken() 3306 Returns "true" if the token's validity period has expired. 3308 7.5.10. isUnseqToken 3310 public boolean isUnseqToken() 3312 Returns "true" if a later token has already been processed. 3314 7.5.11. isGapToken 3316 public boolean isGapToken() 3318 Returns "true" if an expected per-message token was not received. 3320 7.5.12. setSupplementaryStates 3322 public void setSupplementaryStates(boolean duplicate, 3323 boolean old, boolean unseq, boolean gap, 3324 int minorStatus, String minorString) 3326 This method sets the state for the supplementary information flags 3327 and the minor status in MessageProp. It is not used by the 3328 application but by the GSS implementation to return this information 3329 to the caller of a per-message context method. 3331 Parameters: 3333 duplicate "true" if the token was a duplicate of an earlier 3334 token; otherwise, "false". 3336 old "true" if the token's validity period has 3337 expired; otherwise, "false". 3339 unseq "true" if a later token has already been 3340 processed; otherwise, "false". 3342 gap "true" if one or more predecessor tokens have not 3343 yet been successfully processed; otherwise, 3344 "false". 3346 minorStatus The integer minor status code that the underlying 3347 mechanism wants to set. 3349 minorString The textual representation of the minorStatus 3350 value. 3352 7.6. public class ChannelBinding 3354 The GSS-API accommodates the concept of caller-provided channel 3355 binding information. Channel bindings are used to strengthen the 3356 quality with which peer entity authentication is provided during 3357 context establishment. They enable the GSS-API callers to bind the 3358 establishment of the security context to relevant characteristics 3359 like addresses or to application-specific data. 3361 The caller initiating the security context MUST determine the 3362 appropriate channel binding values to set in the GSSContext object. 3363 The acceptor MUST provide an identical binding in order to validate 3364 that received tokens possess correct channel-related characteristics. 3366 Use of channel bindings is OPTIONAL in GSS-API. Since channel- 3367 binding information may be transmitted in context establishment 3368 tokens, applications SHOULD therefore not use confidential data as 3369 channel-binding components. 3371 7.6.1. Constructors 3373 public ChannelBinding(InetAddress initAddr, InetAddress acceptAddr, 3374 byte[] appData) 3376 Create a ChannelBinding object with user-supplied address information 3377 and data. "null" values can be used for any fields that the 3378 application does not want to specify. 3380 Parameters: 3382 initAddr The address of the context initiator. "null" 3383 value can be supplied to indicate that the 3384 application does not want to set this value. 3386 acceptAddr The address of the context acceptor. "null" value 3387 can be supplied to indicate that the application 3388 does not want to set this value. 3390 appData Application-supplied data to be used as part of 3391 the channel bindings. "null" value can be 3392 supplied to indicate that the application does 3393 not want to set this value. 3395 public ChannelBinding(byte[] appData) 3397 Creates a ChannelBinding object without any addressing information. 3399 Parameters: 3401 appData Application supplied data to be used as part of 3402 the channel bindings. 3404 7.6.2. getInitiatorAddress 3406 public InetAddress getInitiatorAddress() 3408 Returns the initiator's address for this channel binding. "null" is 3409 returned if the address has not been set. 3411 7.6.3. getAcceptorAddress 3413 public InetAddress getAcceptorAddress() 3414 Returns the acceptor's address for this channel binding. "null" is 3415 returned if the address has not been set. 3417 7.6.4. getApplicationData 3419 public byte[] getApplicationData() 3421 Returns application data being used as part of the ChannelBinding. 3422 "null" is returned if no application data has been specified for the 3423 channel binding. 3425 7.6.5. equals 3427 public boolean equals(Object obj) 3429 Returns "true" if two channel bindings match. (Note that the Java 3430 language specification requires that two objects that are equal 3431 according to the equals(Object) method MUST return the same integer 3432 result when the hashCode() method is called on them.) 3434 Parameters: 3436 obj Another channel binding with which to compare. 3438 7.7. public class Oid 3440 This class represents Universal Object Identifiers (Oids) and their 3441 associated operations. 3443 Oids are hierarchically globally interpretable identifiers used 3444 within the GSS-API framework to identify mechanisms and name formats. 3446 The structure and encoding of Oids is defined in ISOIEC-8824 and 3447 ISOIEC-8825. For example, the Oid representation of the Kerberos v5 3448 mechanism is "1.2.840.113554.1.2.2". 3450 The GSSName name class contains public static Oid objects 3451 representing the standard name types defined in GSS-API. 3453 7.7.1. Constructors 3455 public Oid(String strOid) throws GSSException 3457 Creates an Oid object from a string representation of its integer 3458 components (e.g., "1.2.840.113554.1.2.2"). 3460 Parameters: 3462 strOid The string representation for the oid. 3464 public Oid(InputStream derOid) throws GSSException 3466 Creates an Oid object from its DER encoding. This refers to the full 3467 encoding including tag and length. The structure and encoding of 3468 Oids is defined in ISOIEC-8824 and ISOIEC-8825. This method is 3469 identical in functionality to its byte array counterpart. 3471 Parameters: 3473 derOid Stream containing the DER-encoded oid. 3475 public Oid(byte[] DEROid) throws GSSException 3477 Creates an Oid object from its DER encoding. This refers to the full 3478 encoding including tag and length. The structure and encoding of 3479 Oids is defined in ISOIEC-8824 and ISOIEC-8825. This method is 3480 identical in functionality to its byte array counterpart. 3482 Parameters: 3484 derOid Byte array storing a DER-encoded oid. 3486 7.7.2. toString 3488 public String toString() 3490 Returns a string representation of the oid's integer components in 3491 dot separated notation (e.g., "1.2.840.113554.1.2.2"). 3493 7.7.3. equals 3495 public boolean equals(Object Obj) 3497 Returns "true" if the two Oid objects represent the same oid value. 3498 (Note that the Java language specification [JLS] requires that two 3499 objects that are equal according to the equals(Object) method MUST 3500 return the same integer result when the hashCode() method is called 3501 on them.) 3503 Parameters: 3505 obj Another Oid object with which to compare. 3507 7.7.4. getDER 3509 public byte[] getDER() 3511 Returns the full ASN.1 DER encoding for this oid object, which 3512 includes the tag and length. 3514 7.7.5. containedIn 3516 public boolean containedIn(Oid[] oids) 3518 A utility method to test if an Oid object is contained within the 3519 supplied Oid object array. 3521 Parameters: 3523 oids An array of oids to search. 3525 7.8. public class GSSException extends Exception 3527 This exception is thrown whenever a fatal GSS-API error occurs 3528 including mechanism-specific errors. It MAY contain both, the major 3529 and minor, GSS-API status codes. The mechanism implementors are 3530 responsible for setting appropriate minor status codes when throwing 3531 this exception. Aside from delivering the numeric error code(s) to 3532 the caller, this class performs the mapping from their numeric values 3533 to textual representations. This exception MAY also include an 3534 output token that SHOULD be sent to the peer. For example, when an 3535 initSecContext call fails due to a fatal error, the mechanism MAY 3536 define an error token that SHOULD be sent to the peer for debugging 3537 or informational purpose. All Java GSS-API methods are declared 3538 throwing this exception. 3540 All implementations are encouraged to use the Java 3541 internationalization techniques to provide local translations of the 3542 message strings. 3544 7.8.1. Static Constants 3546 All valid major GSS-API error code values are declared as constants 3547 in this class. 3549 public static final int BAD_BINDINGS 3551 Channel bindings mismatch error. The value of this constant is 1. 3553 public static final int BAD_MECH 3554 Unsupported mechanism requested error. The value of this constant is 3555 2. 3557 public static final int BAD_NAME 3559 Invalid name provided error. The value of this constant is 3. 3561 public static final int BAD_NAMETYPE 3563 Name of unsupported type provided error. The value of this constant 3564 is 4. 3566 public static final int BAD_STATUS 3568 Invalid status code error - this is the default status value. The 3569 value of this constant is 5. 3571 public static final int BAD_MIC 3573 Token had invalid integrity check error. The value of this constant 3574 is 6. 3576 public static final int CONTEXT_EXPIRED 3578 Specified security context expired error. The value of this constant 3579 is 7. 3581 public static final int CREDENTIALS_EXPIRED 3583 Expired credentials detected error. The value of this constant is 8. 3585 public static final int DEFECTIVE_CREDENTIAL 3587 Defective credential error. The value of this constant is 9. 3589 public static final int DEFECTIVE_TOKEN 3591 Defective token error. The value of this constant is 10. 3593 public static final int FAILURE 3595 General failure, unspecified at GSS-API level. The value of this 3596 constant is 11. 3598 public static final int NO_CONTEXT 3600 Invalid security context error. The value of this constant is 12. 3602 public static final int NO_CRED 3604 Invalid credentials error. The value of this constant is 13. 3606 public static final int BAD_QOP 3608 Unsupported QOP value error. The value of this constant is 14. 3610 public static final int UNAUTHORIZED 3612 Operation unauthorized error. The value of this constant is 15. 3614 public static final int UNAVAILABLE 3616 Operation unavailable error. The value of this constant is 16. 3618 public static final int DUPLICATE_ELEMENT 3620 Duplicate credential element requested error. The value of this 3621 constant is 17. 3623 public static final int NAME_NOT_MN 3625 Name contains multi-mechanism elements error. The value of this 3626 constant is 18. 3628 public static final int DUPLICATE_TOKEN 3630 The token was a duplicate of an earlier token. This is contained in 3631 an exception only when detected during context establishment, in 3632 which case it is considered a fatal error. (Non-fatal supplementary 3633 codes are indicated via the MessageProp object.) The value of this 3634 constant is 19. 3636 public static final int OLD_TOKEN 3638 The token's validity period has expired. This is contained in an 3639 exception only when detected during context establishment, in which 3640 case it is considered a fatal error. (Non-fatal supplementary codes 3641 are indicated via the MessageProp object.) The value of this 3642 constant is 20. 3644 public static final int UNSEQ_TOKEN 3646 A later token has already been processed. This is contained in an 3647 exception only when detected during context establishment, in which 3648 case it is considered a fatal error. (Non-fatal supplementary codes 3649 are indicated via the MessageProp object.) The value of this 3650 constant is 21. 3652 public static final int GAP_TOKEN 3654 An expected per-message token was not received. This is contained in 3655 an exception only when detected during context establishment, in 3656 which case it is considered a fatal error. (Non-fatal supplementary 3657 codes are indicated via the MessageProp object.) The value of this 3658 constant is 22. 3660 7.8.2. Constructors 3662 public GSSException(int majorCode) 3664 Creates a GSSException object with a specified major code. 3666 Calling this constructor is equivalent to calling 3667 GSSException(majorCode, null, 0, null, null). 3669 public GSSException(int majorCode, int minorCode, String minorString) 3671 Creates a GSSException object with the specified major code, minor 3672 code, and minor code textual explanation. This constructor is to be 3673 used when the exception is originating from the security mechanism. 3674 It allows to specify the GSS code and the mechanism code. 3676 Calling this constructor is equivalent to calling 3677 GSSException(majorCode, null, minorCode, minorString, null). 3679 public GSSException(int majorCode, String majorString, 3680 int minorCode, String minorString, 3681 byte[] outputToken) 3683 Creates a GSSException object with the specified major code, major 3684 code textual explanation, minor code, minor code textual explanation, 3685 and an output token. This is a general-purpose constructor that can 3686 be used to create any type of GSSException. 3688 Parameters: 3690 majorCode The GSS error code causing this exception to be 3691 thrown. 3693 majorString The textual explanation of the GSS error code. 3694 If null is provided, a default explanation that 3695 matches the majorCode will be set. 3697 minorCode The mechanism error code causing this exception 3698 to be thrown. Can be 0 if no mechanism error 3699 code is available. 3701 minorString The textual explanation of the mechanism error 3702 code. Can be null if no textual explanation is 3703 available. 3705 outputToken The output token that SHOULD be sent to the peer. 3706 Can be null if no such token is available. It 3707 MUST NOT be an empty array. When provided, the 3708 array will be cloned to protect against 3709 subsequent modifications. 3711 7.8.3. getMajor 3713 public int getMajor() 3715 Returns the major code representing the GSS error code that caused 3716 this exception to be thrown. 3718 7.8.4. getMinor 3720 public int getMinor() 3722 Returns the mechanism error code that caused this exception. The 3723 minor code is set by the underlying mechanism. Value of 0 indicates 3724 that mechanism error code is not set. 3726 7.8.5. getMajorString 3728 public String getMajorString() 3730 Returns a string explaining the GSS major error code causing this 3731 exception to be thrown. 3733 7.8.6. getMinorString 3735 public String getMinorString() 3737 Returns a string explaining the mechanism-specific error code. "null" 3738 will be returned when no string explaining the mechanism error code 3739 has been set. 3741 7.8.7. getOutputToken 3743 public byte[] getOutputToken 3745 Returns the output token in a new byte array. 3747 If the method (For example, GSSContext#initSecContext) that throws 3748 this GSSException needs to generate an output token that SHOULD be 3749 sent to the peer, that token will be stored in this GSSException and 3750 can be retrieved with this method. 3752 The return value MUST be null if no such token is generated. It MUST 3753 NOT be an empty byte array. 3755 7.8.8. setMinor 3757 public void setMinor(int minorCode, String message) 3759 Used internally by the GSS-API implementation and the underlying 3760 mechanisms to set the minor code and its textual representation. 3762 Parameters: 3764 minorCode The mechanism-specific error code. 3766 message A textual explanation of the mechanism error 3767 code. 3769 7.8.9. toString 3771 public String toString() 3773 Returns a textual representation of both the major and minor status 3774 codes. 3776 7.8.10. getMessage 3778 public String getMessage() 3780 Returns a detailed message of this exception. Overrides 3781 Throwable.getMessage. It is customary in Java to use this method to 3782 obtain exception information. 3784 8. Sample Applications 3785 8.1. Simple GSS Context Initiator 3787 3788 import org.ietf.jgss.*; 3790 /** 3791 * This is a partial sketch for a simple client program that acts 3792 * as a GSS context initiator. It illustrates how to use the Java 3793 * bindings for the GSS-API specified in 3794 * Generic Security Service API Version 2 : Java bindings 3795 * 3796 * 3797 * This code sketch assumes the existence of a GSS-API 3798 * implementation that supports the mechanism that it will need 3799 * and is present as a library package (org.ietf.jgss) either as 3800 * part of the standard JRE or in the CLASSPATH the application 3801 * specifies. 3802 */ 3804 public class SimpleClient { 3806 private String serviceName; // name of peer (i.e., server) 3807 private GSSCredential clientCred = null; 3808 private GSSContext context = null; 3809 private Oid mech; // underlying mechanism to use 3811 private GSSManager mgr = GSSManager.getInstance(); 3813 ... 3814 ... 3816 private void clientActions() { 3817 initializeGSS(); 3818 establishContext(); 3819 doCommunication(); 3820 } 3822 /** 3823 * Acquire credentials for the client. 3824 */ 3825 private void initializeGSS() { 3827 try { 3829 clientCred = mgr.createCredential(null /*default princ*/, 3830 GSSCredential.INDEFINITE_LIFETIME /* max lifetime */, 3831 mech /* mechanism to use */, 3832 GSSCredential.INITIATE_ONLY /* init context */); 3834 print("GSSCredential created for " + 3835 cred.getName().toString()); 3836 print("Credential lifetime (sec)=" + 3837 cred.getRemainingLifetime()); 3838 } catch (GSSException e) { 3839 print("GSS-API error in credential acquisition: " 3840 + e.getMessage()); 3841 ... 3842 ... 3843 } 3844 ... 3845 ... 3846 } 3848 /** 3849 * Does the security context establishment with the 3850 * server. 3851 */ 3852 private void establishContext() { 3854 byte[] inToken = new byte[0]; 3855 byte[] outToken = null; 3857 try { 3859 GSSName peer = mgr.createName(serviceName, 3860 GSSName.NT_HOSTBASED_SERVICE); 3861 context = mgr.createContext(peer, mech, gssCred, 3862 GSSContext.INDEFINITE_LIFETIME/*lifetime*/); 3864 // Will need to support confidentiality 3865 context.requestConf(true); 3867 while (!context.isEstablished()) { 3869 outToken = context.initSecContext(inToken, 0, 3870 inToken.length); 3872 if (outToken != null) 3873 writeGSSToken(outToken); 3875 if (!context.isEstablished()) 3876 inToken = readGSSToken(); 3877 } 3879 GSSName peer = context.getSrcName(); 3880 print("Security context established with " + peer + 3881 " using underlying mechanism " + mech.toString()); 3883 } catch (GSSException e) { 3884 print("GSS-API error during context establishment: " 3885 + e.getMessage()); 3887 // If the exception contains an output token, 3888 // it should be sent to the acceptor. 3889 byte[] outTok = e.getOutputToken(); 3890 if (outTok != null) { 3891 writeGSSToken(outTok); 3892 } 3893 ... 3894 ... 3895 } 3896 ... 3897 ... 3898 } 3900 /** 3901 * Sends some data to the server and reads back the 3902 * response. 3903 */ 3904 private void doCommunication() { 3905 byte[] inToken = null; 3906 byte[] outToken = null; 3907 byte[] buffer; 3909 // Container for multiple input-output arguments to and 3910 // from the per-message routines (e.g., wrap/unwrap). 3911 MessageProp messgInfo = new MessageProp(); 3913 try { 3915 /* 3916 * Now send some bytes to the server to be 3917 * processed. They will be integrity protected 3918 * but not encrypted for privacy. 3919 */ 3921 buffer = readFromFile(); 3923 // Set privacy to "false" and use the default QOP 3924 messgInfo.setPrivacy(false); 3926 outToken = context.wrap(buffer, 0, buffer.length, 3927 messgInfo); 3929 writeGSSToken(outToken); 3930 /* 3931 * Now read the response from the server. 3932 */ 3934 inToken = readGSSToken(); 3935 buffer = context.unwrap(inToken, 0, 3936 inToken.length, messgInfo); 3937 // All ok if no exception was thrown! 3939 GSSName peer = context.getSrcName(); 3941 print("Message from " + peer.toString() 3942 + " arrived."); 3943 print("Was it encrypted? " + 3944 messgInfo.getPrivacy()); 3945 print("Duplicate Token? " + 3946 messgInfo.isDuplicateToken()); 3947 print("Old Token? " + 3948 messgInfo.isOldToken()); 3949 print("Unsequenced Token? " + 3950 messgInfo.isUnseqToken()); 3951 print("Gap Token? " + 3952 messgInfo.isGapToken()); 3953 ... 3954 ... 3955 } catch (GSSException e) { 3956 print("GSS-API error in per-message calls: " 3957 + e.getMessage()); 3958 ... 3959 ... 3960 } 3961 ... 3962 ... 3963 } // end of doCommunication method 3965 ... 3966 ... 3968 } // end of class SimpleClient 3969 3971 8.2. Simple GSS Context Acceptor 3973 3974 import org.ietf.jgss.*; 3976 /** 3977 * This is a partial sketch for a simple server program that acts 3978 * as a GSS context acceptor. It illustrates how to use the Java 3979 * bindings for the GSS-API specified in 3980 * Generic Security Service API Version 2 : Java bindings. 3981 * 3982 * This code sketch assumes the existence of a GSS-API 3983 * implementation that supports the mechanisms that it will need 3984 * and is present as a library package (org.ietf.jgss) either as 3985 * part of the standard JRE or in the CLASSPATH the application 3986 * specifies. 3987 */ 3989 import org.ietf.jgss.*; 3991 public class SimpleServer { 3993 private String serviceName; 3994 private GSSName name; 3995 private GSSCredential cred; 3997 private GSSManager mgr; 3999 ... 4000 ... 4002 /** 4003 * Wait for client connections, establish security contexts 4004 * and provide service. 4005 */ 4006 private void loop() { 4007 ... 4008 ... 4009 mgr = GSSManager.getInstance(); 4011 name = mgr.createName(serviceName, 4012 GSSName.NT_HOSTBASED_SERVICE); 4014 cred = mgr.createCredential(name, 4015 GSSCredential.INDEFINITE_LIFETIME, 4016 null, 4017 GSSCredential.ACCEPT_ONLY); 4019 // Loop infinitely 4020 while (true) { 4021 Socket s = serverSock.accept(); 4023 // Start a new thread to serve this connection 4024 Thread serverThread = new ServerThread(s); 4025 serverThread.start(); 4027 } 4028 } 4030 /** 4031 * Inner class ServerThread whose run() method provides the 4032 * secure service to a connection. 4033 */ 4035 private class ServerThread extends Thread { 4037 ... 4038 ... 4040 /** 4041 * Deals with the connection from one client. It also 4042 * handles all GSSException's thrown while talking to 4043 * this client. 4044 */ 4045 public void run() { 4047 byte[] inToken = null; 4048 byte[] outToken = null; 4049 byte[] buffer; 4051 GSSName peer; 4053 // Container for multiple input-output arguments to 4054 // and from the per-message routines 4055 // (i.e., wrap/unwrap). 4056 MessageProp supplInfo = new MessageProp(); 4057 GSSContext secContext = null; 4059 try { 4060 // Now do the context establishment loop 4061 GSSContext context = mgr.createContext(cred); 4063 while (!context.isEstablished()) { 4065 inToken = readGSSToken(); 4066 outToken = context.acceptSecContext(inToken, 4067 0, inToken.length); 4068 if (outToken != null) 4069 writeGSSToken(outToken); 4070 } 4072 // SimpleServer wants confidentiality to be 4073 // available. Check for it. 4074 if (!context.getConfState()){ 4075 ... 4076 ... 4077 } 4079 GSSName peer = context.getSrcName(); 4080 Oid mech = context.getMech(); 4081 print("Security context established with " + 4082 peer.toString() + 4083 " using underlying mechanism " + 4084 mech.toString() + 4085 " from Provider " + 4086 context.getProvider().getName()); 4088 // Now read the bytes sent by the client to be 4089 // processed. 4090 inToken = readGSSToken(); 4092 // Unwrap the message 4093 buffer = context.unwrap(inToken, 0, 4094 inToken.length, supplInfo); 4095 // All ok if no exception was thrown! 4097 // Print other supplementary per-message status 4098 // information. 4100 print("Message from " + 4101 peer.toString() + " arrived."); 4102 print("Was it encrypted? " + 4103 supplInfo.getPrivacy()); 4104 print("Duplicate Token? " + 4105 supplInfo.isDuplicateToken()); 4106 print("Old Token? " + supplInfo.isOldToken()); 4107 print("Unsequenced Token? " + 4108 supplInfo.isUnseqToken()); 4109 print("Gap Token? " + supplInfo.isGapToken()); 4111 /* 4112 * Now process the bytes and send back an 4113 * encrypted response. 4114 */ 4116 buffer = serverProcess(buffer); 4118 // Encipher it and send it across 4120 supplInfo.setPrivacy(true); // privacy requested 4121 supplInfo.setQOP(0); // default QOP 4122 outToken = context.wrap(buffer, 0, buffer.length, 4123 supplInfo); 4124 writeGSSToken(outToken); 4126 } catch (GSSException e) { 4127 print("GSS-API Error: " + e.getMessage()); 4128 // Alternatively, could call e.getMajorMessage() 4129 // and e.getMinorMessage() 4131 // If the exception contains an output token, 4132 // it should be sent to the initiator. 4133 byte[] outTok = e.getOutputToken(); 4134 if (outTok != null) { 4135 writeGSSToken(outTok); 4136 } 4137 print("Abandoning security context."); 4138 ... 4139 ... 4140 } 4141 ... 4142 ... 4143 } // end of run method in ServerThread 4145 } // end of inner class ServerThread 4147 ... 4148 ... 4150 } // end of class SimpleServer 4151 4153 9. Security Considerations 4155 The Java language security model allows platform providers to have 4156 policy-based fine-grained access control over any resource that an 4157 application wants. When using a Java security manager (such as, but 4158 not limited to, the case of applets running in browsers) the 4159 application code is in a sandbox by default. 4161 Administrators of the platform JRE determine what permissions, if 4162 any, are to be given to source from different codebases. Thus, the 4163 administrator has to be aware of any special requirements that the 4164 GSS provider might have for system resources. For instance, a 4165 Kerberos provider might wish to make a network connection to the Key 4166 Distribution Center (KDC) to obtain initial credentials. This would 4167 not be allowed under the sandbox unless the administrator had granted 4168 permissions for this. Also, note that this granting and checking of 4169 permissions happens transparently to the application and is outside 4170 the scope of this document. 4172 The Java language allows administrators to pre-configure a list of 4173 security service providers in the /lib/security/java.security 4174 file. At runtime, the system approaches these providers in order of 4175 preference when looking for security related services. Applications 4176 have a means to modify this list through methods in the "Security" 4177 class in the "java.security" package. However, since these 4178 modifications would be visible in the entire Java Virtual Machine 4179 (JVM) and thus affect all code executing in it, this operation is not 4180 available in the sandbox and requires special permissions to perform. 4181 Thus, when a GSS application has special needs that are met by a 4182 particular security provider, it has two choices: 4184 1) To install the provider on a JVM-wide basis using the 4185 java.security.Security class and then depend on the system to find 4186 the right provider automatically when the need arises. (This 4187 would require the application to be granted a "insertProvider 4188 SecurityPermission".) 4190 2) To pass an instance of the provider to the local instance of 4191 GSSManager so that only factory calls going through that 4192 GSSManager use the desired provider. (This would not require any 4193 permissions.) 4195 10. IANA Considerations 4197 This document has no actions for IANA. 4199 11. Acknowledgments 4201 This proposed API leverages earlier work performed by the IETF's CAT 4202 WG as outlined in both RFC 2743 [RFC2743] and RFC 2744 [RFC2744]. 4203 Many conceptual definitions, implementation directions, and 4204 explanations have been included from these documents. 4206 We would like to thank Mike Eisler, Lin Ling, Ram Marti, Michael 4207 Saltz, and other members of Sun's development team for their helpful 4208 input, comments, and suggestions. 4210 We would also like to thank Joe Salowey, and Michael Smith for many 4211 insightful ideas and suggestions that have contributed to this 4212 document. 4214 12. Changes since RFC 5653 4216 This document has following changes: 4218 1) New error token embedded in GSSException 4219 There is a design flaw in the initSecContext and acceptSecContext 4220 methods of the GSSContext class defined in Generic Security 4221 Service API Version 2: Java Bindings Update [RFC5653]. 4223 The methods could either return a token (possibly null if no more 4224 tokens are needed) when the call succeeds or throw a GSSException 4225 if there is a failure, but NOT both. On the other hand, the C 4226 bindings of GSS-API [RFC2744] can return both, that is to say, a 4227 call to the GSS_Init_sec_context() function can return a major 4228 status code, and at the same time, fill in the output_token 4229 argument if there is one. 4231 Without the ability to emit an error token when there is a 4232 failure, a Java application has no mechanism to tell the other 4233 side what the error is. For example, a "reject" NegTokenResp 4234 token can never be transmitted for the SPNEGO mechanism [RFC4178]. 4236 While a Java method can never return a value and throw an 4237 exception at the same time, we can embed the error token inside 4238 the exception so that the caller has a chance to retrieve it. 4239 This update adds a new GSSException constructor to include this 4240 token inside a GSSException object, and a getOutputToken() method 4241 to retrieve the token. The specification for the initSecContext 4242 and acceptSecContext methods are updated to describe the new 4243 behavior. Various examples are also updated. 4245 New JGSS programs SHOULD make use of this new feature but it is 4246 not mandatory. A program that intends to run with both old and 4247 new GSS Java bindings can use reflection to check the availability 4248 of this new method and call it accordingly. 4250 2) Removing stream-based GSSContext methods 4252 The overloaded methods of GSSContext that use input and output 4253 streams as the means to convey authentication and per-message GSS- 4254 API tokens as described in Section 5.15 of RFC 5653 [RFC5653] are 4255 removed in this update as the wire protocol should be defined by 4256 an application and not a library. It's also impossible to 4257 implement these methods correctly when the token has no self- 4258 framing (where the end cannot be determined) or the library has no 4259 knowledge of the token format (for example, as a bridge talking to 4260 another GSS library). These methods include initSecContext 4261 (Section 7.4.5 of RFC 5653 [RFC5653]), acceptSecContext 4262 (Section 7.4.9 of RFC 5653 [RFC5653]), wrap (Section 7.4.15 of RFC 4263 5653 [RFC5653]), unwrap (Section 7.4.17 of RFC 5653 [RFC5653]), 4264 getMIC (Section 7.4.19 of RFC 5653 [RFC5653]), and verifyMIC 4265 (Section 7.4.21 of RFC 5653 [RFC5653]). 4267 13. Changes since RFC 2853 4269 This document has following changes: 4271 1) Major GSS Status Code Constant Values 4273 RFC 2853 listed all the GSS status code values in two different 4274 sections: section 4.12.1 defined numeric values for them, and 4275 section 6.8.1 defined them as static constants in the GSSException 4276 class without assigning any values. Due to an inconsistent 4277 ordering between these two sections, all of the GSS major status 4278 codes resulted in misalignment, and a subsequent disagreement 4279 between deployed implementations. 4281 This document defines the numeric values of the GSS status codes 4282 in both sections, while maintaining the original ordering from 4283 section 6.8.1 of RFC 2853 [RFC2853], and obsoletes the GSS status 4284 code values defined in section 4.12.1. The relevant sections in 4285 this document are sections 5.12.1 and 7.8.1. 4287 2) GSS Credential Usage Constant Values 4289 RFC 2853 section 6.3.2 defines static constants for the 4290 GSSCredential usage flags. However, the values of these constants 4291 were not defined anywhere in RFC 2853 [RFC2853]. 4293 This document defines the credential usage values in section 4294 7.3.1. The original ordering of these values from section 6.3.2 4295 of RFC 2853 [RFC2853] is maintained. 4297 3) GSS Host-Based Service Name 4299 RFC 2853 [RFC2853], section 6.2.2, defines the static constant for 4300 the GSS host-based service OID NT_HOSTBASED_SERVICE, using a 4301 deprecated OID value. 4303 This document updates the NT_HOSTBASED_SERVICE OID value in 4304 section 7.2.1 to be consistent with the C-bindings in RFC 2744 4305 [RFC2744]. 4307 14. References 4309 14.1. Normative References 4311 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 4312 (SPKM)", RFC 2025, DOI 10.17487/RFC2025, October 1996, 4313 . 4315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4316 Requirement Levels", BCP 14, RFC 2119, 4317 DOI 10.17487/RFC2119, March 1997, 4318 . 4320 [RFC2743] Linn, J., "Generic Security Service Application Program 4321 Interface Version 2, Update 1", RFC 2743, 4322 DOI 10.17487/RFC2743, January 2000, 4323 . 4325 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 4326 C-bindings", RFC 2744, DOI 10.17487/RFC2744, January 2000, 4327 . 4329 [RFC2853] Kabat, J. and M. Upadhyay, "Generic Security Service API 4330 Version 2 : Java Bindings", RFC 2853, 4331 DOI 10.17487/RFC2853, June 2000, 4332 . 4334 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 4335 Version 5 Generic Security Service Application Program 4336 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 4337 DOI 10.17487/RFC4121, July 2005, 4338 . 4340 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 4341 Simple and Protected Generic Security Service Application 4342 Program Interface (GSS-API) Negotiation Mechanism", 4343 RFC 4178, DOI 10.17487/RFC4178, October 2005, 4344 . 4346 [RFC5653] Upadhyay, M. and S. Malkani, "Generic Security Service API 4347 Version 2: Java Bindings Update", RFC 5653, 4348 DOI 10.17487/RFC5653, August 2009, 4349 . 4351 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4352 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4353 May 2017, . 4355 14.2. Informative References 4357 [JLS] Gosling, J., Joy, B., Steele, G., and G. Bracha, "The Java 4358 Language Specification", Third Edition, 2005, 4359 . 4361 Authors' Addresses 4363 Mayank D. Upadhyay 4364 Google Inc. 4365 1600 Amphitheatre Parkway 4366 Mountain View, CA 94043 4367 USA 4369 Email: m.d.upadhyay+ietf@gmail.com 4371 Seema Malkani 4372 ActivIdentity Corp. 4373 6623 Dumbarton Circle 4374 Fremont, California 94555 4375 USA 4377 Email: Seema.Malkani@gmail.com 4379 Wang Weijun 4380 Oracle 4381 Building No. 24, Zhongguancun Software Park 4382 Beijing 100193 4383 China 4385 Email: weijun.wang@oracle.com