idnits 2.17.1 draft-ietf-kitten-rfc2853bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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. -- The abstract seems to indicate that this document obsoletes RFC2853, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 16, 2009) is 5547 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 4018 ** Obsolete normative reference: RFC 2853 (Obsoleted by RFC 5653) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). 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 Intended status: Standards Track S. Malkani 5 Expires: August 20, 2009 Sun Microsystems 6 February 16, 2009 8 Generic Security Service API Version 2 : Java Bindings Update 9 draft-ietf-kitten-rfc2853bis-05.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 20, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 The Generic Security Services Application Program Interface (GSS-API) 49 offers application programmers uniform access to security services 50 atop a variety of underlying cryptographic mechanisms. This document 51 updates the Java bindings for the GSS-API that are specified in 52 "Generic Security Service API version 2 : Java Bindings" (RFC2853). 53 This document obsoletes RFC 2853 by making specific and incremental 54 clarifications and corrections to it in response to identification of 55 transcription errors and implementation experience. 57 The GSS-API is described at a language independent conceptual level 58 in "Generic Security Service Application Program Interface Version 2, 59 Update 1" (RFC2743). The GSS-API allows a caller application to 60 authenticate a principal identity, to delegate rights to a peer, and 61 to apply security services such as confidentiality and integrity on a 62 per-message basis. Examples of security mechanisms defined for GSS- 63 API are "The Simple Public-Key GSS-API Mechanism" (RFC2025) and "The 64 Kerberos Version 5 GSS-API Mechanism (RFC4121). 66 Table of Contents 68 1. Conventions Used in This Document . . . . . . . . . . . . 7 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . 7 70 3. GSS-API Operational Paradigm . . . . . . . . . . . . . . 8 71 4. Additional Controls . . . . . . . . . . . . . . . . . . . 9 72 4.1. Delegation . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 11 74 4.3. Replay and Out-of-Sequence Detection . . . . . . . . . . 11 75 4.4. Anonymous Authentication . . . . . . . . . . . . . . . . 12 76 4.5. Confidentiality . . . . . . . . . . . . . . . . . . . . . 13 77 4.6. Inter-process Context Transfer . . . . . . . . . . . . . 13 78 4.7. The Use of Incomplete Contexts . . . . . . . . . . . . . 14 79 5. Calling Conventions . . . . . . . . . . . . . . . . . . . 14 80 5.1. Package Name . . . . . . . . . . . . . . . . . . . . . . 15 81 5.2. Provider Framework . . . . . . . . . . . . . . . . . . . 15 82 5.3. Integer Types . . . . . . . . . . . . . . . . . . . . . . 16 83 5.4. Opaque Data Types . . . . . . . . . . . . . . . . . . . . 16 84 5.5. Strings . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 5.6. Object Identifiers . . . . . . . . . . . . . . . . . . . 16 86 5.7. Object Identifier Sets . . . . . . . . . . . . . . . . . 16 87 5.8. Credentials . . . . . . . . . . . . . . . . . . . . . . . 17 88 5.9. Contexts . . . . . . . . . . . . . . . . . . . . . . . . 19 89 5.10. Authentication Tokens . . . . . . . . . . . . . . . . . . 19 90 5.11. Interprocess Tokens . . . . . . . . . . . . . . . . . . . 19 91 5.12. Error Reporting . . . . . . . . . . . . . . . . . . . . . 20 92 5.12.1. GSS Status Codes . . . . . . . . . . . . . . . . . . . . 20 93 5.12.2. Mechanism-Specific Status Codes . . . . . . . . . . . . . 23 94 5.12.3. Supplementary Status Codes . . . . . . . . . . . . . . . 23 95 5.13. Names . . . . . . . . . . . . . . . . . . . . . . . . . . 23 96 5.14. Channel Bindings . . . . . . . . . . . . . . . . . . . . 26 97 5.15. Stream Objects . . . . . . . . . . . . . . . . . . . . . 27 98 5.16. Optional Parameters . . . . . . . . . . . . . . . . . . . 27 99 6. Introduction to GSS-API Classes and Interfaces . . . . . 27 100 6.1. GSSManager class . . . . . . . . . . . . . . . . . . . . 28 101 6.2. GSSName interface . . . . . . . . . . . . . . . . . . . . 29 102 6.3. GSSCredential interface . . . . . . . . . . . . . . . . . 29 103 6.4. GSSContext interface . . . . . . . . . . . . . . . . . . 30 104 6.5. MessageProp class . . . . . . . . . . . . . . . . . . . . 31 105 6.6. GSSException class . . . . . . . . . . . . . . . . . . . 31 106 6.7. Oid class . . . . . . . . . . . . . . . . . . . . . . . . 32 107 6.8. ChannelBinding class . . . . . . . . . . . . . . . . . . 32 108 7. Detailed GSS-API Class Description . . . . . . . . . . . 32 109 7.1. public abstract class GSSManager . . . . . . . . . . . . 32 110 7.1.1. Example Code . . . . . . . . . . . . . . . . . . . . . . 33 111 7.1.2. getInstance . . . . . . . . . . . . . . . . . . . . . . . 34 112 7.1.3. getMechs . . . . . . . . . . . . . . . . . . . . . . . . 34 113 7.1.4. getNamesForMech . . . . . . . . . . . . . . . . . . . . . 34 114 7.1.5. getMechsForName . . . . . . . . . . . . . . . . . . . . . 34 115 7.1.6. createName . . . . . . . . . . . . . . . . . . . . . . . 35 116 7.1.7. createName . . . . . . . . . . . . . . . . . . . . . . . 35 117 7.1.8. createName . . . . . . . . . . . . . . . . . . . . . . . 36 118 7.1.9. createName . . . . . . . . . . . . . . . . . . . . . . . 36 119 7.1.10. createCredential . . . . . . . . . . . . . . . . . . . . 37 120 7.1.11. createCredential . . . . . . . . . . . . . . . . . . . . 37 121 7.1.12. createCredential . . . . . . . . . . . . . . . . . . . . 38 122 7.1.13. createContext . . . . . . . . . . . . . . . . . . . . . . 38 123 7.1.14. createContext . . . . . . . . . . . . . . . . . . . . . . 39 124 7.1.15. createContext . . . . . . . . . . . . . . . . . . . . . . 39 125 7.1.16. addProviderAtFront . . . . . . . . . . . . . . . . . . . 39 126 7.1.17. Example Code . . . . . . . . . . . . . . . . . . . . . . 40 127 7.1.18. addProviderAtEnd . . . . . . . . . . . . . . . . . . . . 41 128 7.1.19. Example Code . . . . . . . . . . . . . . . . . . . . . . 42 129 7.2. public interface GSSName . . . . . . . . . . . . . . . . 42 130 7.2.1. Example Code . . . . . . . . . . . . . . . . . . . . . . 43 131 7.2.2. Static Constants . . . . . . . . . . . . . . . . . . . . 43 132 7.2.3. equals . . . . . . . . . . . . . . . . . . . . . . . . . 44 133 7.2.4. equals . . . . . . . . . . . . . . . . . . . . . . . . . 45 134 7.2.5. canonicalize . . . . . . . . . . . . . . . . . . . . . . 45 135 7.2.6. export . . . . . . . . . . . . . . . . . . . . . . . . . 45 136 7.2.7. toString . . . . . . . . . . . . . . . . . . . . . . . . 45 137 7.2.8. getStringNameType . . . . . . . . . . . . . . . . . . . . 46 138 7.2.9. isAnonymous . . . . . . . . . . . . . . . . . . . . . . . 46 139 7.2.10. isMN . . . . . . . . . . . . . . . . . . . . . . . . . . 46 140 7.3. public interface GSSCredential implements Cloneable . . . 46 141 7.3.1. Example Code . . . . . . . . . . . . . . . . . . . . . . 47 142 7.3.2. Static Constants . . . . . . . . . . . . . . . . . . . . 48 143 7.3.3. dispose . . . . . . . . . . . . . . . . . . . . . . . . . 48 144 7.3.4. getName . . . . . . . . . . . . . . . . . . . . . . . . . 48 145 7.3.5. getName . . . . . . . . . . . . . . . . . . . . . . . . . 48 146 7.3.6. getRemainingLifetime . . . . . . . . . . . . . . . . . . 49 147 7.3.7. getRemainingInitLifetime . . . . . . . . . . . . . . . . 49 148 7.3.8. getRemainingAcceptLifetime . . . . . . . . . . . . . . . 49 149 7.3.9. getUsage . . . . . . . . . . . . . . . . . . . . . . . . 50 150 7.3.10. getUsage . . . . . . . . . . . . . . . . . . . . . . . . 50 151 7.3.11. getMechs . . . . . . . . . . . . . . . . . . . . . . . . 50 152 7.3.12. add . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 153 7.3.13. equals . . . . . . . . . . . . . . . . . . . . . . . . . 51 154 7.4. public interface GSSContext . . . . . . . . . . . . . . . 51 155 7.4.1. Example Code . . . . . . . . . . . . . . . . . . . . . . 52 156 7.4.2. Static Constants . . . . . . . . . . . . . . . . . . . . 54 157 7.4.3. initSecContext . . . . . . . . . . . . . . . . . . . . . 54 158 7.4.4. Example Code . . . . . . . . . . . . . . . . . . . . . . 55 159 7.4.5. initSecContext . . . . . . . . . . . . . . . . . . . . . 55 160 7.4.6. Example Code . . . . . . . . . . . . . . . . . . . . . . 56 161 7.4.7. acceptSecContext . . . . . . . . . . . . . . . . . . . . 57 162 7.4.8. Example Code . . . . . . . . . . . . . . . . . . . . . . 58 163 7.4.9. acceptSecContext . . . . . . . . . . . . . . . . . . . . 58 164 7.4.10. Example Code . . . . . . . . . . . . . . . . . . . . . . 59 165 7.4.11. isEstablished . . . . . . . . . . . . . . . . . . . . . . 60 166 7.4.12. dispose . . . . . . . . . . . . . . . . . . . . . . . . . 60 167 7.4.13. getWrapSizeLimit . . . . . . . . . . . . . . . . . . . . 60 168 7.4.14. wrap . . . . . . . . . . . . . . . . . . . . . . . . . . 61 169 7.4.15. wrap . . . . . . . . . . . . . . . . . . . . . . . . . . 62 170 7.4.16. unwrap . . . . . . . . . . . . . . . . . . . . . . . . . 63 171 7.4.17. unwrap . . . . . . . . . . . . . . . . . . . . . . . . . 63 172 7.4.18. getMIC . . . . . . . . . . . . . . . . . . . . . . . . . 64 173 7.4.19. getMIC . . . . . . . . . . . . . . . . . . . . . . . . . 65 174 7.4.20. verifyMIC . . . . . . . . . . . . . . . . . . . . . . . . 65 175 7.4.21. verifyMIC . . . . . . . . . . . . . . . . . . . . . . . . 66 176 7.4.22. export . . . . . . . . . . . . . . . . . . . . . . . . . 67 177 7.4.23. requestMutualAuth . . . . . . . . . . . . . . . . . . . . 68 178 7.4.24. requestReplayDet . . . . . . . . . . . . . . . . . . . . 68 179 7.4.25. requestSequenceDet . . . . . . . . . . . . . . . . . . . 68 180 7.4.26. requestCredDeleg . . . . . . . . . . . . . . . . . . . . 68 181 7.4.27. requestAnonymity . . . . . . . . . . . . . . . . . . . . 69 182 7.4.28. requestConf . . . . . . . . . . . . . . . . . . . . . . . 69 183 7.4.29. requestInteg . . . . . . . . . . . . . . . . . . . . . . 69 184 7.4.30. requestLifetime . . . . . . . . . . . . . . . . . . . . . 69 185 7.4.31. setChannelBinding . . . . . . . . . . . . . . . . . . . . 70 186 7.4.32. getCredDelegState . . . . . . . . . . . . . . . . . . . . 70 187 7.4.33. getMutualAuthState . . . . . . . . . . . . . . . . . . . 70 188 7.4.34. getReplayDetState . . . . . . . . . . . . . . . . . . . . 70 189 7.4.35. getSequenceDetState . . . . . . . . . . . . . . . . . . . 71 190 7.4.36. getAnonymityState . . . . . . . . . . . . . . . . . . . . 71 191 7.4.37. isTransferable . . . . . . . . . . . . . . . . . . . . . 71 192 7.4.38. isProtReady . . . . . . . . . . . . . . . . . . . . . . . 71 193 7.4.39. getConfState . . . . . . . . . . . . . . . . . . . . . . 71 194 7.4.40. getIntegState . . . . . . . . . . . . . . . . . . . . . . 72 195 7.4.41. getLifetime . . . . . . . . . . . . . . . . . . . . . . . 72 196 7.4.42. getSrcName . . . . . . . . . . . . . . . . . . . . . . . 72 197 7.4.43. getTargName . . . . . . . . . . . . . . . . . . . . . . . 72 198 7.4.44. getMech . . . . . . . . . . . . . . . . . . . . . . . . . 72 199 7.4.45. getDelegCred . . . . . . . . . . . . . . . . . . . . . . 72 200 7.4.46. isInitiator . . . . . . . . . . . . . . . . . . . . . . . 73 201 7.5. public class MessageProp . . . . . . . . . . . . . . . . 73 202 7.5.1. Constructors . . . . . . . . . . . . . . . . . . . . . . 73 203 7.5.2. getQOP . . . . . . . . . . . . . . . . . . . . . . . . . 74 204 7.5.3. getPrivacy . . . . . . . . . . . . . . . . . . . . . . . 74 205 7.5.4. getMinorStatus . . . . . . . . . . . . . . . . . . . . . 74 206 7.5.5. getMinorString . . . . . . . . . . . . . . . . . . . . . 74 207 7.5.6. setQOP . . . . . . . . . . . . . . . . . . . . . . . . . 74 208 7.5.7. setPrivacy . . . . . . . . . . . . . . . . . . . . . . . 74 209 7.5.8. isDuplicateToken . . . . . . . . . . . . . . . . . . . . 75 210 7.5.9. isOldToken . . . . . . . . . . . . . . . . . . . . . . . 75 211 7.5.10. isUnseqToken . . . . . . . . . . . . . . . . . . . . . . 75 212 7.5.11. isGapToken . . . . . . . . . . . . . . . . . . . . . . . 75 213 7.5.12. setSupplementaryStates . . . . . . . . . . . . . . . . . 75 214 7.6. public class ChannelBinding . . . . . . . . . . . . . . . 76 215 7.6.1. Constructors . . . . . . . . . . . . . . . . . . . . . . 76 216 7.6.2. getInitiatorAddress . . . . . . . . . . . . . . . . . . . 77 217 7.6.3. getAcceptorAddress . . . . . . . . . . . . . . . . . . . 77 218 7.6.4. getApplicationData . . . . . . . . . . . . . . . . . . . 77 219 7.6.5. equals . . . . . . . . . . . . . . . . . . . . . . . . . 77 220 7.7. public class Oid . . . . . . . . . . . . . . . . . . . . 78 221 7.7.1. Constructors . . . . . . . . . . . . . . . . . . . . . . 78 222 7.7.2. toString . . . . . . . . . . . . . . . . . . . . . . . . 79 223 7.7.3. equals . . . . . . . . . . . . . . . . . . . . . . . . . 79 224 7.7.4. getDER . . . . . . . . . . . . . . . . . . . . . . . . . 79 225 7.7.5. containedIn . . . . . . . . . . . . . . . . . . . . . . . 79 226 7.8. public class GSSException extends Exception . . . . . . . 79 227 7.8.1. Static Constants . . . . . . . . . . . . . . . . . . . . 80 228 7.8.2. Constructors . . . . . . . . . . . . . . . . . . . . . . 82 229 7.8.3. getMajor . . . . . . . . . . . . . . . . . . . . . . . . 83 230 7.8.4. getMinor . . . . . . . . . . . . . . . . . . . . . . . . 83 231 7.8.5. getMajorString . . . . . . . . . . . . . . . . . . . . . 83 232 7.8.6. getMinorString . . . . . . . . . . . . . . . . . . . . . 83 233 7.8.7. setMinor . . . . . . . . . . . . . . . . . . . . . . . . 83 234 7.8.8. toString . . . . . . . . . . . . . . . . . . . . . . . . 84 235 7.8.9. getMessage . . . . . . . . . . . . . . . . . . . . . . . 84 236 8. Sample Applications . . . . . . . . . . . . . . . . . . . 84 237 8.1. Simple GSS Context Initiator . . . . . . . . . . . . . . 84 238 8.2. Simple GSS Context Acceptor . . . . . . . . . . . . . . . 88 239 9. Security Considerations . . . . . . . . . . . . . . . . . 92 240 10. IANA Considerations . . . . . . . . . . . . . . . . . . . 92 241 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 93 242 12. Changes since RFC 2853 . . . . . . . . . . . . . . . . . 93 243 13. References . . . . . . . . . . . . . . . . . . . . . . . 94 244 13.1. Normative References . . . . . . . . . . . . . . . . . . 94 245 13.2. Informative References . . . . . . . . . . . . . . . . . 94 246 Authors' Addresses . . . . . . . . . . . . . . . . . . . 94 248 1. Conventions Used in This Document 250 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 251 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 252 document are to be interpreted as described in [RFC2119]. 254 2. Introduction 256 This document specifies Java language bindings for the Generic 257 Security Services Application Programming Interface Version 2 (GSS- 258 API). GSS-API Version 2 is described in a language independent 259 format in RFC 2743 [GSSAPIv2-UPDATE]. The GSS-API allows a caller 260 application to authenticate a principal identity, to delegate rights 261 to a peer, and to apply security services such as confidentiality and 262 integrity on a per-message basis. 264 This document and its predecessor RFC 2853 [RFC2853] leverage the 265 work done by the WG in the area of RFC 2743 [GSSAPIv2-UPDATE] and the 266 C-bindings RFC 2744 [GSSAPI-Cbind]. Whenever appropriate, text has 267 been used from the C-bindings RFC 2744 to explain generic concepts 268 and provide direction to the implementors. 270 The design goals of this API have been to satisfy all the 271 functionality defined in RFC 2743 [GSSAPIv2-UPDATE] and to provide 272 these services in an object oriented method. The specification also 273 aims to satisfy the needs of both types of Java application 274 developers, those who would like access to a "system-wide" GSS-API 275 implementation, as well as those who would want to provide their own 276 "custom" implementation. 278 A "system-wide" implementation is one that is available to all 279 applications in the form of a library package. It may be the 280 standard package in the Java runtime environment (JRE) being used or 281 it may be additionally installed and accessible to any application 282 via the CLASSPATH. 284 A "custom" implementation of the GSS-API, on the other hand, is one 285 that would, in most cases, be bundled with the application during 286 distribution. It is expected that such an implementation would be 287 meant to provide for some particular need of the application, such as 288 support for some specific mechanism. 290 The design of this API also aims to provide a flexible framework to 291 add and manage GSS-API mechanisms. GSS-API leverages the Java 292 Cryptography Architecture (JCA) provider model to support the 293 plugability of mechanisms. Mechanisms can be added on a "system- 294 wide" basis, where all users of the framework will have them 295 available. The specification also allows for the addition of 296 mechanisms per-instance of the GSS-API. 298 Lastly, this specification presents an API that will naturally fit 299 within the operation environment of the Java platform. Readers are 300 assumed to be familiar with both the GSS-API and the Java platform. 302 3. GSS-API Operational Paradigm 304 The Generic Security Service Application Programming Interface 305 Version 2 [GSSAPIv2-UPDATE] defines a generic security API to calling 306 applications. It allows a communicating application to authenticate 307 the user associated with another application, to delegate rights to 308 another application, and to apply security services such as 309 confidentiality and integrity on a per-message basis. 311 There are four stages to using GSS-API: 313 1) The application acquires a set of credentials with which it may 314 prove its identity to other processes. The application's credentials 315 vouch for its global identity, which may or may not be related to any 316 local username under which it may be running. 318 2) A pair of communicating applications establish a joint security 319 context using their credentials. The security context encapsulates 320 shared state information, which is required in order that per-message 321 security services may be provided. Examples of state information 322 that might be shared between applications as part of a security 323 context are cryptographic keys, and message sequence numbers. As 324 part of the establishment of a security context, the context 325 initiator is authenticated to the responder, and may require that the 326 responder is authenticated back to the initiator. The initiator may 327 optionally give the responder the right to initiate further security 328 contexts, acting as an agent or delegate of the initiator. This 329 transfer of rights is termed "delegation", and is achieved by 330 creating a set of credentials, similar to those used by the 331 initiating application, but which may be used by the responder. 333 A GSSContext object is used to establish and maintain the shared 334 information that makes up the security context. Certain GSSContext 335 methods will generate a token, which applications treat as 336 cryptographically protected, opaque data. The caller of such 337 GSSContext method is responsible for transferring the token to the 338 peer application, encapsulated if necessary in an application-to- 339 application protocol. On receipt of such a token, the peer 340 application should pass it to a corresponding GSSContext method which 341 will decode the token and extract the information, updating the 342 security context state information accordingly. 344 3) Per-message services are invoked on a GSSContext object to apply 345 either: 347 integrity and data origin authentication, or 349 confidentiality, integrity and data origin authentication 351 to application data, which are treated by GSS-API as arbitrary octet- 352 strings. An application transmitting a message that it wishes to 353 protect will call the appropriate GSSContext method (getMIC or wrap) 354 to apply protection, and send the resulting token to the receiving 355 application. The receiver will pass the received token (and, in the 356 case of data protected by getMIC, the accompanying message-data) to 357 the corresponding decoding method of the GSSContext interface 358 (verifyMIC or unwrap) to remove the protection and validate the data. 360 4) At the completion of a communications session (which may extend 361 across several transport connections), each application uses a 362 GSSContext method to invalidate the security context and release any 363 system or cryptographic resources held. Multiple contexts may also 364 be used (either successively or simultaneously) within a single 365 communications association, at the discretion of the applications. 367 4. Additional Controls 369 This section discusses the optional services that a context initiator 370 may request of the GSS-API before the context establishment. Each of 371 these services is requested by calling the appropriate mutator method 372 in the GSSContext object before the first call to init is performed. 373 Only the context initiator can request context flags. 375 The optional services defined are: 377 Delegation The (usually temporary) transfer of rights from 378 initiator to acceptor, enabling the acceptor to authenticate 379 itself as an agent of the initiator. 381 Mutual Authentication In addition to the initiator authenticating 382 its identity to the context acceptor, the context acceptor should 383 also authenticate itself to the initiator. 385 Replay Detection In addition to providing message integrity 386 services, GSSContext per-message operations of getMIC and wrap 387 should include message numbering information to enable verifyMIC 388 and unwrap to detect if a message has been duplicated. 390 Out-of-Sequence Detection In addition to providing message 391 integrity services, GSSContext per-message operations (getMIC and 392 wrap) should include message sequencing information to enable 393 verifyMIC and unwrap to detect if a message has been received out 394 of sequence. 396 Anonymous Authentication The establishment of the security context 397 should not reveal the initiator's identity to the context 398 acceptor. 400 Some mechanisms may not support all optional services, and some 401 mechanisms may only support some services in conjunction with others. 402 The GSSContext interface offers query methods to allow the 403 verification by the calling application of which services will be 404 available from the context when the establishment phase is complete. 405 In general, if the security mechanism is capable of providing a 406 requested service, it should do so even if additional services must 407 be enabled in order to provide the requested service. If the 408 mechanism is incapable of providing a requested service, it should 409 proceed without the service leaving the application to abort the 410 context establishment process if it considers the requested service 411 to be mandatory. 413 Some mechanisms may specify that support for some services is 414 optional, and that implementors of the mechanism need not provide it. 415 This is most commonly true of the confidentiality service, often 416 because of legal restrictions on the use of data-encryption, but may 417 apply to any of the services. Such mechanisms are required to send 418 at least one token from acceptor to initiator during context 419 establishment when the initiator indicates a desire to use such a 420 service, so that the initiating GSS-API can correctly indicate 421 whether the service is supported by the acceptor's GSS-API. 423 4.1. Delegation 425 The GSS-API allows delegation to be controlled by the initiating 426 application via the requestCredDeleg method before the first call to 427 init has been issued. Some mechanisms do not support delegation, and 428 for such mechanisms attempts by an application to enable delegation 429 are ignored. 431 The acceptor of a security context, for which the initiator enabled 432 delegation, can check if delegation was enabled by using the 433 getCredDelegState method of the GSSContext interface. In cases when 434 it is, the delegated credential object can be obtained by calling the 435 getDelegCred method. The obtained GSSCredential object may then be 436 used to initiate subsequent GSS-API security contexts as an agent or 437 delegate of the initiator. If the original initiator's identity is 438 "A" and the delegate's identity is "B", then, depending on the 439 underlying mechanism, the identity embodied by the delegated 440 credential may be either "A" or "B acting for A". 442 For many mechanisms that support delegation, a simple boolean does 443 not provide enough control. Examples of additional aspects of 444 delegation control that a mechanism might provide to an application 445 are duration of delegation, network addresses from which delegation 446 is valid, and constraints on the tasks that may be performed by a 447 delegate. Such controls are presently outside the scope of the GSS- 448 API. GSS-API implementations supporting mechanisms offering 449 additional controls should provide extension routines that allow 450 these controls to be exercised (perhaps by modifying the initiator's 451 GSS-API credential object prior to its use in establishing a 452 context). However, the simple delegation control provided by GSS-API 453 should always be able to over-ride other mechanism-specific 454 delegation controls. If the application instructs the GSSContext 455 object that delegation is not desired, then the implementation must 456 not permit delegation to occur. This is an exception to the general 457 rule that a mechanism may enable services even if they are not 458 requested - delegation may only be provided at the explicit request 459 of the application. 461 4.2. Mutual Authentication 463 Usually, a context acceptor will require that a context initiator 464 authenticate itself so that the acceptor may make an access-control 465 decision prior to performing a service for the initiator. In some 466 cases, the initiator may also request that the acceptor authenticate 467 itself. GSS-API allows the initiating application to request this 468 mutual authentication service by calling the requestMutualAuth method 469 of the GSSContext interface with a "true" parameter before making the 470 first call to init. The initiating application is informed as to 471 whether or not the context acceptor has authenticated itself. Note 472 that some mechanisms may not support mutual authentication, and other 473 mechanisms may always perform mutual authentication, whether or not 474 the initiating application requests it. In particular, mutual 475 authentication may be required by some mechanisms in order to support 476 replay or out-of-sequence message detection, and for such mechanisms 477 a request for either of these services will automatically enable 478 mutual authentication. 480 4.3. Replay and Out-of-Sequence Detection 482 The GSS-API may provide detection of mis-ordered messages once a 483 security context has been established. Protection may be applied to 484 messages by either application, by calling either getMIC or wrap 485 methods of the GSSContext interface, and verified by the peer 486 application by calling verifyMIC or unwrap for the peer's GSSContext 487 object. 489 The getMIC method calculates a cryptographic checksum of an 490 application message, and returns that checksum in a token. The 491 application should pass both the token and the message to the peer 492 application, which presents them to the verifyMIC method of the 493 peer's GSSContext object. 495 The wrap method calculates a cryptographic checksum of an application 496 message, and places both the checksum and the message inside a single 497 token. The application should pass the token to the peer 498 application, which presents it to the unwrap method of the peer's 499 GSSContext object to extract the message and verify the checksum. 501 Either pair of routines may be capable of detecting out-of-sequence 502 message delivery, or duplication of messages. Details of such mis- 503 ordered messages are indicated through supplementary query methods of 504 the MessageProp object that is filled in by each of these routines. 506 A mechanism need not maintain a list of all tokens that have been 507 processed in order to support these status codes. A typical 508 mechanism might retain information about only the most recent "N" 509 tokens processed, allowing it to distinguish duplicates and missing 510 tokens within the most recent "N" messages; the receipt of a token 511 older than the most recent "N" would result in the isOldToken method 512 of the instance of MessageProp to return "true". 514 4.4. Anonymous Authentication 516 In certain situations, an application may wish to initiate the 517 authentication process to authenticate a peer, without revealing its 518 own identity. As an example, consider an application providing 519 access to a database containing medical information, and offering 520 unrestricted access to the service. A client of such a service might 521 wish to authenticate the service (in order to establish trust in any 522 information retrieved from it), but might not wish the service to be 523 able to obtain the client's identity (perhaps due to privacy concerns 524 about the specific inquiries, or perhaps simply to avoid being placed 525 on mailing-lists). 527 In normal use of the GSS-API, the initiator's identity is made 528 available to the acceptor as a result of the context establishment 529 process. However, context initiators may request that their identity 530 not be revealed to the context acceptor. Many mechanisms do not 531 support anonymous authentication, and for such mechanisms the request 532 will not be honored. An authentication token will still be 533 generated, but the application is always informed if a requested 534 service is unavailable, and has the option to abort context 535 establishment if anonymity is valued above the other security 536 services that would require a context to be established. 538 In addition to informing the application that a context is 539 established anonymously (via the isAnonymous method of the GSSContext 540 class), the getSrcName method of the acceptor's GSSContext object 541 will, for such contexts, return a reserved internal-form name, 542 defined by the implementation. 544 The toString method for a GSSName object representing an anonymous 545 entity will return a printable name. The returned value will be 546 syntactically distinguishable from any valid principal name supported 547 by the implementation. The associated name-type object identifier 548 will be an oid representing the value of NT_ANONYMOUS. This name- 549 type oid will be defined as a public, static Oid object of the 550 GSSName class. The printable form of an anonymous name should be 551 chosen such that it implies anonymity, since this name may appear in, 552 for example, audit logs. For example, the string "" might 553 be a good choice, if no valid printable names supported by the 554 implementation can begin with "<" and end with ">". 556 When using the equal method of the GSSName interface, and one of the 557 operands is a GSSName instance representing an anonymous entity, the 558 method must return "false". 560 4.5. Confidentiality 562 If a GSSContext supports the confidentiality service, wrap method may 563 be used to encrypt application messages. Messages are selectively 564 encrypted, under the control of the setPrivacy method of the 565 MessageProp object used in the wrap method. 567 4.6. Inter-process Context Transfer 569 GSS-API V2 provides functionality which allows a security context to 570 be transferred between processes on a single machine. These are 571 implemented using the export method of GSSContext and a byte array 572 constructor of the same class. The most common use for such a 573 feature is a client-server design where the server is implemented as 574 a single process that accepts incoming security contexts, which then 575 launches child processes to deal with the data on these contexts. In 576 such a design, the child processes must have access to the security 577 context object created within the parent so that they can use per- 578 message protection services and delete the security context when the 579 communication session ends. 581 Since the security context data structure is expected to contain 582 sequencing information, it is impractical in general to share a 583 context between processes. Thus GSSContext interface provides an 584 export method that the process, which currently owns the context, can 585 call to declare that it has no intention to use the context 586 subsequently, and to create an inter-process token containing 587 information needed by the adopting process to successfully re-create 588 the context. After successful completion of export, the original 589 security context is made inaccessible to the calling process by GSS- 590 API and any further usage of this object will result in failures. 591 The originating process transfers the inter-process token to the 592 adopting process, which creates a new GSSContext object using the 593 byte array constructor. The properties of the context are equivalent 594 to that of the original context. 596 The inter-process token may contain sensitive data from the original 597 security context (including cryptographic keys). Applications using 598 inter-process tokens to transfer security contexts must take 599 appropriate steps to protect these tokens in transit. 601 Implementations are not required to support the inter-process 602 transfer of security contexts. Calling the isTransferable method of 603 the GSSContext interface will indicate if the context object is 604 transferable. 606 4.7. The Use of Incomplete Contexts 608 Some mechanisms may allow the per-message services to be used before 609 the context establishment process is complete. For example, a 610 mechanism may include sufficient information in its initial context- 611 level tokens for the context acceptor to immediately decode messages 612 protected with wrap or getMIC. For such a mechanism, the initiating 613 application need not wait until subsequent context-level tokens have 614 been sent and received before invoking the per-message protection 615 services. 617 An application can invoke the isProtReady method of the GSSContext 618 class to determine if the per-message services are available in 619 advance of complete context establishment. Applications wishing to 620 use per-message protection services on partially-established contexts 621 should query this method before attempting to invoke wrap or getMIC. 623 5. Calling Conventions 625 Java provides the implementors with not just a syntax for the 626 language, but also an operational environment. For example, memory 627 is automatically managed and does not require application 628 intervention. These language features have allowed for a simpler API 629 and have led to the elimination of certain GSS-API functions. 631 Moreover, the JCA defines a provider model which allows for 632 implementation independent access to security services. Using this 633 model, applications can seamlessly switch between different 634 implementations and dynamically add new services. The GSS-API 635 specification leverages these concepts by the usage of providers for 636 the mechanism implementations. 638 5.1. Package Name 640 The classes and interfaces defined in this document reside in the 641 package called "org.ietf.jgss". Applications that wish to make use 642 of this API should import this package name as shown in section 8. 644 5.2. Provider Framework 646 The Java security API's use a provider architecture that allows 647 applications to be implementation independent and security API 648 implementations to be modular and extensible. The 649 java.security.Provider class is an abstract class that a vendor 650 extends. This class maps various properties that represent different 651 security services that are available to the names of the actual 652 vendor classes that implement those services. When requesting a 653 service, an application simply specifies the desired provider and the 654 API delegates the request to service classes available from that 655 provider. 657 Using the Java security provider model insulates applications from 658 implementation details of the services they wish to use. 659 Applications can switch between providers easily and new providers 660 can be added as needed, even at runtime. 662 The GSS-API may use providers to find components for specific 663 underlying security mechanisms. For instance, a particular provider 664 might contain components that will allow the GSS-API to support the 665 Kerberos v5 mechanism [RFC4121] and another might contain components 666 to support the SPKM [RFC2025] mechanism. By delegating mechanism 667 specific functionality to the components obtained from providers, the 668 GSS-API can be extended to support an arbitrary list of mechanism. 670 How the GSS-API locates and queries these providers is beyond the 671 scope of this document and is being deferred to a Service Provider 672 Interface (SPI) specification. The availability of such a SPI 673 specification is not mandatory for the adoption of this API 674 specification nor is it mandatory to use providers in the 675 implementation of a GSS-API framework. However, by using the 676 provider framework together with an SPI specification one can create 677 an extensible and implementation independent GSS-API framework. 679 5.3. Integer Types 681 All numeric values are declared as "int" primitive Java type. The 682 Java specification guarantees that this will be a 32 bit two's 683 complement signed number. 685 Throughout this API, the "boolean" primitive Java type is used 686 wherever a boolean value is required or returned. 688 5.4. Opaque Data Types 690 Java byte arrays are used to represent opaque data types which are 691 consumed and produced by the GSS-API in the forms of tokens. Java 692 arrays contain a length field which enables the users to easily 693 determine their size. The language has automatic garbage collection 694 which alleviates the need by developers to release memory and 695 simplifies buffer ownership issues. 697 5.5. Strings 699 The String object will be used to represent all textual data. The 700 Java String object, transparently treats all characters as two-byte 701 Unicode characters which allows support for many locals. All 702 routines returning or accepting textual data will use the String 703 object. 705 5.6. Object Identifiers 707 An Oid object will be used to represent Universal Object Identifiers 708 (Oids). Oids are ISO-defined, hierarchically globally-interpretable 709 identifiers used within the GSS-API framework to identify security 710 mechanisms and name formats. The Oid object can be created from a 711 string representation of its dot notation (e.g. "1.3.6.1.5.6.2") as 712 well as from its ASN.1 DER encoding. Methods are also provided to 713 test equality and provide the DER representation for the object. 715 An important feature of the Oid class is that its instances are 716 immutable - i.e. there are no methods defined that allow one to 717 change the contents of an Oid. This property allows one to treat 718 these objects as "statics" without the need to perform copies. 720 Certain routines allow the usage of a default oid. A "null" value 721 can be used in those cases. 723 5.7. Object Identifier Sets 724 The Java bindings represents object identifiers sets as arrays of Oid 725 objects. All Java arrays contain a length field which allows for 726 easy manipulation and reference. 728 In order to support the full functionality of RFC 2743 729 [GSSAPIv2-UPDATE], the Oid class includes a method which checks for 730 existence of an Oid object within a specified array. This is 731 equivalent in functionality to gss_test_oid_set_member. The use of 732 Java arrays and Java's automatic garbage collection has eliminated 733 the need for the following routines: gss_create_empty_oid_set, 734 gss_release_oid_set, and gss_add_oid_set_member. Java GSS-API 735 implementations will not contain them. Java's automatic garbage 736 collection and the immutable property of the Oid object eliminates 737 the memory management issues of the C counterpart. 739 When ever a default value for an Object Identifier Set is required, a 740 "null" value can be used. Please consult the detailed method 741 description for details. 743 5.8. Credentials 745 GSS-API credentials are represented by the GSSCredential interface. 746 The interface contains several constructs to allow for the creation 747 of most common credential objects for the initiator and the acceptor. 748 Comparisons are performed using the interface's "equals" method. The 749 following general description of GSS-API credentials is included from 750 the C-bindings specification: 752 GSS-API credentials can contain mechanism-specific principal 753 authentication data for multiple mechanisms. A GSS-API credential is 754 composed of a set of credential-elements, each of which is applicable 755 to a single mechanism. A credential may contain at most one 756 credential-element for each supported mechanism. A credential- 757 element identifies the data needed by a single mechanism to 758 authenticate a single principal, and conceptually contains two 759 credential-references that describe the actual mechanism-specific 760 authentication data, one to be used by GSS-API for initiating 761 contexts, and one to be used for accepting contexts. For mechanisms 762 that do not distinguish between acceptor and initiator credentials, 763 both references would point to the same underlying mechanism-specific 764 authentication data. 766 Credentials describe a set of mechanism-specific principals, and give 767 their holder the ability to act as any of those principals. All 768 principal identities asserted by a single GSS-API credential should 769 belong to the same entity, although enforcement of this property is 770 an implementation-specific matter. A single GSSCredential object 771 represents all the credential elements that have been acquired. 773 The creation's of an GSSContext object allows the value of "null" to 774 be specified as the GSSCredential input parameter. This will 775 indicate a desire by the application to act as a default principal. 776 While individual GSS-API implementations are free to determine such 777 default behavior as appropriate to the mechanism, the following 778 default behavior by these routines is recommended for portability: 780 For the initiator side of the context: 782 1) If there is only a single principal capable of initiating security 783 contexts for the chosen mechanism that the application is authorized 784 to act on behalf of, then that principal shall be used, otherwise 786 2) If the platform maintains a concept of a default network- identity 787 for the chosen mechanism, and if the application is authorized to act 788 on behalf of that identity for the purpose of initiating security 789 contexts, then the principal corresponding to that identity shall be 790 used, otherwise 792 3) If the platform maintains a concept of a default local identity, 793 and provides a means to map local identities into network-identities 794 for the chosen mechanism, and if the application is authorized to act 795 on behalf of the network- identity image of the default local 796 identity for the purpose of initiating security contexts using the 797 chosen mechanism, then the principal corresponding to that identity 798 shall be used, otherwise 800 4) A user-configurable default identity should be used. 802 and for the acceptor side of the context 804 1) If there is only a single authorized principal identity capable of 805 accepting security contexts for the chosen mechanism, then that 806 principal shall be used, otherwise 808 2) If the mechanism can determine the identity of the target 809 principal by examining the context-establishment token processed 810 during the accept method, and if the accepting application is 811 authorized to act as that principal for the purpose of accepting 812 security contexts using the chosen mechanism, then that principal 813 identity shall be used, otherwise 815 3) If the mechanism supports context acceptance by any principal, and 816 if mutual authentication was not requested, any principal that the 817 application is authorized to accept security contexts under using the 818 chosen mechanism may be used, otherwise 820 4) A user-configurable default identity shall be used. 822 The purpose of the above rules is to allow security contexts to be 823 established by both initiator and acceptor using the default behavior 824 whenever possible. Applications requesting default behavior are 825 likely to be more portable across mechanisms and implementations than 826 ones that instantiate an GSSCredential object representing a specific 827 identity. 829 5.9. Contexts 831 The GSSContext interface is used to represent one end of a GSS-API 832 security context, storing state information appropriate to that end 833 of the peer communication, including cryptographic state information. 834 The instantiation of the context object is done differently by the 835 initiator and the acceptor. After the context has been instantiated, 836 the initiator may choose to set various context options which will 837 determine the characteristics of the desired security context. When 838 all the application desired characteristics have been set, the 839 initiator will call the initSecContext method which will produce a 840 token for consumption by the peer's acceptSecContext method. It is 841 the responsibility of the application to deliver the authentication 842 token(s) between the peer applications for processing. Upon 843 completion of the context establishment phase, context attributes can 844 be retrieved, by both the initiator and acceptor, using the accessor 845 methods. These will reflect the actual attributes of the established 846 context. At this point the context can be used by the application to 847 apply cryptographic services to its data. 849 5.10. Authentication Tokens 851 A token is a caller-opaque type that GSS-API uses to maintain 852 synchronization between each end of the GSS-API security context. 853 The token is a cryptographically protected octet-string, generated by 854 the underlying mechanism at one end of a GSS-API security context for 855 use by the peer mechanism at the other end. Encapsulation (if 856 required) within the application protocol and transfer of the token 857 are the responsibility of the peer applications. 859 Java GSS-API uses byte arrays to represent authentication tokens. 860 Overloaded methods exist which allow the caller to supply input and 861 output streams which will be used for the reading and writing of the 862 token data. 864 5.11. Interprocess Tokens 866 Certain GSS-API routines are intended to transfer data between 867 processes in multi-process programs. These routines use a caller- 868 opaque octet-string, generated by the GSS-API in one process for use 869 by the GSS-API in another process. The calling application is 870 responsible for transferring such tokens between processes. Note 871 that, while GSS-API implementors are encouraged to avoid placing 872 sensitive information within interprocess tokens, or to 873 cryptographically protect them, many implementations will be unable 874 to avoid placing key material or other sensitive data within them. 875 It is the application's responsibility to ensure that interprocess 876 tokens are protected in transit, and transferred only to processes 877 that are trustworthy. An interprocess token is represented using a 878 byte array emitted from the export method of the GSSContext 879 interface. The receiver of the interprocess token would initialize 880 an GSSContext object with this token to create a new context. Once a 881 context has been exported, the GSSContext object is invalidated and 882 is no longer available. 884 5.12. Error Reporting 886 RFC 2743 [GSSAPIv2-UPDATE] defined the usage of major and minor 887 status values for signaling of GSS-API errors. The major code, also 888 called GSS status code, is used to signal errors at the GSS-API level 889 independent of the underlying mechanism(s). The minor status value 890 or Mechanism status code, is a mechanism defined error value 891 indicating a mechanism specific error code. 893 Java GSS-API uses exceptions implemented by the GSSException class to 894 signal both minor and major error values. Both mechanism specific 895 errors and GSS-API level errors are signaled through instances of 896 this class. The usage of exceptions replaces the need for major and 897 minor codes to be used within the API calls. GSSException class also 898 contains methods to obtain textual representations for both the major 899 and minor values, which is equivalent to the functionality of 900 gss_display_status. 902 5.12.1. GSS Status Codes 904 GSS status codes indicate errors that are independent of the 905 underlying mechanism(s) used to provide the security service. The 906 errors that can be indicated via a GSS status code are generic API 907 routine errors (errors that are defined in the GSS-API 908 specification). These bindings take advantage of the Java exceptions 909 mechanism, thus eliminating the need for calling errors. 911 A GSS status code indicates a single fatal generic API error from the 912 routine that has thrown the GSSException. Using exceptions announces 913 that a fatal error has occurred during the execution of the method. 914 The GSS-API operational model also allows for the signaling of 915 supplementary status information from the per-message calls. These 916 need to be handled as return values since using exceptions is not 917 appropriate for informatory or warning-like information. The methods 918 that are capable of producing supplementary information are the two 919 per-message methods GSSContext.verifyMIC() and GSSContext.unwrap(). 920 These methods fill the supplementary status codes in the MessageProp 921 object that was passed in. 923 A GSSException object, along with providing the functionality for 924 setting of the various error codes and translating them into textual 925 representation, also contains the definitions of all the numeric 926 error values. The following table lists the definitions of error 927 codes: 929 Table: GSS Status Codes 931 Name Value Meaning 933 BAD_BINDINGS 1 Incorrect channel bindings were 934 supplied. 936 BAD_MECH 2 An unsupported mechanism 937 was requested. 939 BAD_NAME 3 An invalid name was supplied. 941 BAD_NAMETYPE 4 A supplied name was of an 942 unsupported type. 944 BAD_STATUS 5 An invalid status code was 945 supplied. 947 BAD_MIC 6 A token had an invalid MIC. 949 CONTEXT_EXPIRED 7 The context has expired. 951 CREDENTIALS_EXPIRED 8 The referenced credentials 952 have expired. 954 DEFECTIVE_CREDENTIAL 9 A supplied credential was 955 invalid. 957 DEFECTIVE_TOKEN 10 A supplied token was invalid. 959 FAILURE 11 Miscellaneous failure, 960 unspecified at the GSS-API 961 level. 963 NO_CONTEXT 12 Invalid context has been 964 supplied. 966 NO_CRED 13 No credentials were supplied, or 967 the credentials were unavailable 968 or inaccessible. 970 BAD_QOP 14 The quality-of-protection 971 requested could not be provided. 973 UNAUTHORIZED 15 The operation is forbidden by 974 the local security policy. 976 UNAVAILABLE 16 The operation or option is 977 unavailable. 979 DUPLICATE_ELEMENT 17 The requested credential 980 element already exists. 982 NAME_NOT_MN 18 The provided name was not a 983 mechanism name. 985 The following four status codes (DUPLICATE_TOKEN, OLD_TOKEN, 986 UNSEQ_TOKEN, and GAP_TOKEN) are contained in a GSSException 987 only if detected during context establishment, in which case it 988 is a fatal error. (During per-message calls, these values are 989 indicated as supplementary information contained in the 990 MessageProp object.) They are: 992 DUPLICATE_TOKEN 19 The token was a duplicate of an 993 earlier version. 995 OLD_TOKEN 20 The token's validity period has 996 expired. 998 UNSEQ_TOKEN 21 A later token has already been 999 processed. 1001 GAP_TOKEN 22 The expected token was not 1002 received. 1004 The GSS major status code of FAILURE is used to indicate that the 1005 underlying mechanism detected an error for which no specific GSS 1006 status code is defined. The mechanism-specific status code can 1007 provide more details about the error. 1009 The different major status codes that can be contained in the 1010 GSSException object thrown by the methods in this specification are 1011 the same as the major status codes returned by the corresponding 1012 calls in RFC 2743 [GSSAPIv2-UPDATE]. 1014 5.12.2. Mechanism-Specific Status Codes 1016 Mechanism-specific status codes are communicated in two ways, they 1017 are part of any GSSException thrown from the mechanism specific layer 1018 to signal a fatal error, or they are part of the MessageProp object 1019 that the per-message calls use to signal non-fatal errors. 1021 A default value of 0 in either the GSSException object or the 1022 MessageProp object will be used to represent the absence of any 1023 mechanism specific status code. 1025 5.12.3. Supplementary Status Codes 1027 Supplementary status codes are confined to the per-message methods of 1028 the GSSContext interface. Because of the informative nature of these 1029 errors it is not appropriate to use exceptions to signal them. 1030 Instead, the per-message operations of the GSSContext interface 1031 return these values in a MessageProp object. 1033 The MessageProp class defines query methods which return boolean 1034 values indicating the following supplementary states: 1036 Table: Supplementary Status Methods 1038 Method Name Meaning when "true" is returned 1040 isDuplicateToken The token was a duplicate of an 1041 earlier token. 1043 isOldToken The token's validity period has 1044 expired. 1046 isUnseqToken A later token has already been 1047 processed. 1049 isGapToken An expected per-message token was 1050 not received. 1052 "true" return value for any of the above methods indicates that the 1053 token exhibited the specified property. The application must 1054 determine the appropriate course of action for these supplementary 1055 values. They are not treated as errors by the GSS-API. 1057 5.13. Names 1059 A name is used to identify a person or entity. GSS-API authenticates 1060 the relationship between a name and the entity claiming the name. 1062 Since different authentication mechanisms may employ different 1063 namespaces for identifying their principals, GSS-API's naming support 1064 is necessarily complex in multi-mechanism environments (or even in 1065 some single-mechanism environments where the underlying mechanism 1066 supports multiple namespaces). 1068 Two distinct conceptual representations are defined for names: 1070 1) A GSS-API form represented by implementations of the GSSName 1071 interface: A single GSSName object may contain multiple names from 1072 different namespaces, but all names should refer to the same entity. 1073 An example of such an internal name would be the name returned from a 1074 call to the getName method of the GSSCredential interface, when 1075 applied to a credential containing credential elements for multiple 1076 authentication mechanisms employing different namespaces. This 1077 GSSName object will contain a distinct name for the entity for each 1078 authentication mechanism. 1080 For GSS-API implementations supporting multiple namespaces, GSSName 1081 implementations must contain sufficient information to determine the 1082 namespace to which each primitive name belongs. 1084 2) Mechanism-specific contiguous byte array and string forms: 1085 Different GSSName initialization methods are provided to handle both 1086 byte array and string formats and to accommodate various calling 1087 applications and name types. These formats are capable of containing 1088 only a single name (from a single namespace). Contiguous string 1089 names are always accompanied by an object identifier specifying the 1090 namespace to which the name belongs, and their format is dependent on 1091 the authentication mechanism that employs that name. The string name 1092 forms are assumed to be printable, and may therefore be used by GSS- 1093 API applications for communication with their users. The byte array 1094 name formats are assumed to be in non-printable formats (e.g. the 1095 byte array returned from the export method of the GSSName interface). 1097 A GSSName object can be converted to a contiguous representation by 1098 using the toString method. This will guarantee that the name will be 1099 converted to a printable format. Different initialization methods in 1100 the GSSName interface are defined allowing support for multiple 1101 syntaxes for each supported namespace, and allowing users the freedom 1102 to choose a preferred name representation. The toString method 1103 should use an implementation-chosen printable syntax for each 1104 supported name-type. To obtain the printable name type, 1105 getStringNameType method can be used. 1107 There is no guarantee that calling the toString method on the GSSName 1108 interface will produce the same string form as the original imported 1109 string name. Furthermore, it is possible that the name was not even 1110 constructed from a string representation. The same applies to name- 1111 space identifiers which may not necessarily survive unchanged after a 1112 journey through the internal name-form. An example of this might be 1113 a mechanism that authenticates X.500 names, but provides an 1114 algorithmic mapping of Internet DNS names into X.500. That 1115 mechanism's implementation of GSSName might, when presented with a 1116 DNS name, generate an internal name that contained both the original 1117 DNS name and the equivalent X.500 name. Alternatively, it might only 1118 store the X.500 name. In the latter case, the toString method of 1119 GSSName would most likely generate a printable X.500 name, rather 1120 than the original DNS name. 1122 The context acceptor can obtain a GSSName object representing the 1123 entity performing the context initiation (through the usage of 1124 getSrcName method). Since this name has been authenticated by a 1125 single mechanism, it contains only a single name (even if the 1126 internal name presented by the context initiator to the GSSContext 1127 object had multiple components). Such names are termed internal 1128 mechanism names, or "MN"s and the names emitted by GSSContext 1129 interface in the getSrcName and getTargName are always of this type. 1130 Since some applications may require MNs without wanting to incur the 1131 overhead of an authentication operation, creation methods are 1132 provided that take not only the name buffer and name type, but also 1133 the mechanism oid for which this name should be created. When 1134 dealing with an existing GSSName object, the canonicalize method may 1135 be invoked to convert a general internal name into an MN. 1137 GSSName objects can be compared using their equal method, which 1138 returns "true" if the two names being compared refer to the same 1139 entity. This is the preferred way to perform name comparisons 1140 instead of using the printable names that a given GSS-API 1141 implementation may support. Since GSS-API assumes that all primitive 1142 names contained within a given internal name refer to the same 1143 entity, equal can return "true" if the two names have at least one 1144 primitive name in common. If the implementation embodies knowledge 1145 of equivalence relationships between names taken from different 1146 namespaces, this knowledge may also allow successful comparisons of 1147 internal names containing no overlapping primitive elements. 1149 When used in large access control lists, the overhead of creating an 1150 GSSName object on each name and invoking the equal method on each 1151 name from the ACL may be prohibitive. As an alternative way of 1152 supporting this case, GSS-API defines a special form of the 1153 contiguous byte array name which may be compared directly (byte by 1154 byte). Contiguous names suitable for comparison are generated by the 1155 export method. Exported names may be re-imported by using the byte 1156 array constructor and specifying the NT_EXPORT_NAME as the name type 1157 object identifier. The resulting GSSName name will also be a MN. 1159 The GSSName interface defines public static Oid objects representing 1160 the standard name types. Structurally, an exported name object 1161 consists of a header containing an OID identifying the mechanism that 1162 authenticated the name, and a trailer containing the name itself, 1163 where the syntax of the trailer is defined by the individual 1164 mechanism specification. Detailed description of the format is 1165 specified in the language-independent GSS-API specification 1166 [GSSAPIv2-UPDATE]. 1168 Note that the results obtained by using the equals method will in 1169 general be different from those obtained by invoking canonicalize and 1170 export, and then comparing the byte array output. The first series 1171 of operation determines whether two (unauthenticated) names identify 1172 the same principal; the second whether a particular mechanism would 1173 authenticate them as the same principal. These two operations will 1174 in general give the same results only for MNs. 1176 It is important to note that the above are guidelines as how GSSName 1177 implementations should behave, and are not intended to be specific 1178 requirements of how names objects must be implemented. The mechanism 1179 designers are free to decide on the details of their implementations 1180 of the GSSName interface as long as the behavior satisfies the above 1181 guidelines. 1183 5.14. Channel Bindings 1185 GSS-API supports the use of user-specified tags to identify a given 1186 context to the peer application. These tags are intended to be used 1187 to identify the particular communications channel that carries the 1188 context. Channel bindings are communicated to the GSS-API using the 1189 ChannelBinding object. The application may use byte arrays to 1190 specify the application data to be used in the channel binding as 1191 well as using instances of the InetAddress. The InetAddress for the 1192 initiator and/or acceptor can be used within an instance of a 1193 ChannelBinding. ChannelBinding can be set for the GSSContext object 1194 using the setChannelBinding method before the first call to init or 1195 accept has been performed. Unless the setChannelBinding method has 1196 been used to set the ChannelBinding for a GSSContext object, "null" 1197 ChannelBinding will be assumed. InetAddress is currently the only 1198 address type defined within the Java platform and as such, it is the 1199 only one supported within the ChannelBinding class. Applications 1200 that use other types of addresses can include them as part of the 1201 application specific data. 1203 Conceptually, the GSS-API concatenates the initiator and acceptor 1204 address information, and the application supplied byte array to form 1205 an octet string. The mechanism calculates a MIC over this octet 1206 string and binds the MIC to the context establishment token emitted 1207 by init method of the GSSContext interface. The same bindings are 1208 set by the context acceptor for its GSSContext object and during 1209 processing of the accept method a MIC is calculated in the same way. 1210 The calculated MIC is compared with that found in the token, and if 1211 the MICs differ, accept will throw a GSSException with the major code 1212 set to BAD_BINDINGS, and the context will not be established. Some 1213 mechanisms may include the actual channel binding data in the token 1214 (rather than just a MIC); applications should therefore not use 1215 confidential data as channel-binding components. 1217 Individual mechanisms may impose additional constraints on addresses 1218 that may appear in channel bindings. For example, a mechanism may 1219 verify that the initiator address field of the channel binding 1220 contains the correct network address of the host system. Portable 1221 applications should therefore ensure that they either provide correct 1222 information for the address fields, or omit setting of the addressing 1223 information. 1225 5.15. Stream Objects 1227 The context object provides overloaded methods which use input and 1228 output streams as the means to convey authentication and per-message 1229 GSS-API tokens. It is important to note that the streams are 1230 expected to contain the usual GSS-API tokens which would otherwise be 1231 handled through the usage of byte arrays. The tokens are expected to 1232 have a definite start and an end. The callers are responsible for 1233 ensuring that the supplied streams will not block, or expect to block 1234 until a full token is processed by the GSS-API method. Only a single 1235 GSS-API token will be processed per invocation of the stream based 1236 method. 1238 The usage of streams allows the callers to have control and 1239 management of the supplied buffers. Because streams are non- 1240 primitive objects, the callers can make the streams as complicated or 1241 as simple as desired simply by using the streams defined in the 1242 java.io package or creating their own through the use of inheritance. 1243 This will allow for the application's greatest flexibility. 1245 5.16. Optional Parameters 1247 Whenever the application wishes to omit an optional parameter the 1248 "null" value shall be used. The detailed method descriptions 1249 indicate which parameters are optional. Methods overloading has also 1250 been used as a technique to indicate default parameters. 1252 6. Introduction to GSS-API Classes and Interfaces 1253 This section presents a brief description of the classes and 1254 interfaces that constitute the GSS-API. The implementations of these 1255 are obtained from the CLASSPATH defined by the application. If Java 1256 GSS becomes part of the standard Java API's then these classes will 1257 be available by default on all systems as part of the JRE's system 1258 classes. 1260 This section also shows the corresponding RFC 2743 [GSSAPIv2-UPDATE] 1261 functionality implemented by each of the classes. Detailed 1262 description of these classes and their methods is presented in 1263 section 7. 1265 6.1. GSSManager class 1267 This abstract class serves as a factory to instantiate 1268 implementations of the GSS-API interfaces and also provides methods 1269 to make queries about underlying security mechanisms. 1271 A default implementation can be obtained using the static method 1272 getInstance(). Applications that desire to provide their own 1273 implementation of the GSSManager class can simply extend the abstract 1274 class themselves. 1276 This class contains equivalents of the following RFC 2743 1277 [GSSAPIv2-UPDATE] routines: 1279 gss_import_name Create an internal name from 7.1.6- 1280 the supplied information. 7.1.9 1282 gss_acquire_cred Acquire credential 7.1.10- 1283 for use. 7.1.12 1285 gss_import_sec_context Create a previously exported 7.1.15 1286 context. 1288 gss_indicate_mechs List the mechanisms 7.1.3 1289 supported by this GSS-API 1290 implementation. 1292 gss_inquire_mechs_for_name List the mechanisms 7.1.5 1293 supporting the 1294 specified name type. 1296 gss_inquire_names_for_mech List the name types 7.1.4 1297 supported by the 1298 specified mechanism. 1300 6.2. GSSName interface 1302 GSS-API names are represented in the Java bindings through the 1303 GSSName interface. Different name formats and their definitions are 1304 identified with universal Object Identifiers (oids). The format of 1305 the names can be derived based on the unique oid of each name type. 1306 The following GSS-API routines are provided by the GSSName interface: 1308 RFC 2743 Routine Function Section(s) 1310 gss_display_name Covert internal name 7.2.7 1311 representation to text format. 1313 gss_compare_name Compare two internal names. 7.2.3, 1314 7.2.4 1316 gss_release_name Release resources associated N/A 1317 with the internal name. 1319 gss_canonicalize_name Convert an internal name to a 7.2.5 1320 mechanism name. 1322 gss_export_name Convert a mechanism name to 7.2.6 1323 export format. 1325 gss_duplicate_name Create a copy of the internal N/A 1326 name. 1328 The gss_release_name call is not provided as Java does its own 1329 garbage collection. The gss_duplicate_name call is also redundant; 1330 the GSSName interface has no mutator methods that can change the 1331 state of the object so it is safe for sharing across threads. 1333 6.3. GSSCredential interface 1335 The GSSCredential interface is responsible for the encapsulation of 1336 GSS-API credentials. Credentials identify a single entity and 1337 provide the necessary cryptographic information to enable the 1338 creation of a context on behalf of that entity. A single credential 1339 may contain multiple mechanism specific credentials, each referred to 1340 as a credential element. The GSSCredential interface provides the 1341 functionality of the following GSS-API routines: 1343 RFC 2743 Routine Function Section(s) 1345 gss_add_cred Constructs credentials 7.3.12 1346 incrementally. 1348 gss_inquire_cred Obtain information about 7.3.4- 1349 credential. 7.3.11 1351 gss_inquire_cred_by_mech Obtain per-mechanism 7.3.5- 1352 information about 7.3.10 1353 a credential. 1355 gss_release_cred Disposes of credentials 7.3.3 1356 after use. 1358 6.4. GSSContext interface 1360 This interface encapsulates the functionality of context-level calls 1361 required for security context establishment and management between 1362 peers as well as the per-message services offered to applications. A 1363 context is established between a pair of peers and allows the usage 1364 of security services on a per-message basis on application data. It 1365 is created over a single security mechanism. The GSSContext 1366 interface provides the functionality of the following GSS-API 1367 routines: 1369 RFC 2743 Routine Function Section(s) 1371 gss_init_sec_context Initiate the creation of a 7.4.3- 1372 security context with a peer. 7.4.6 1374 gss_accept_sec_context Accept a security context 7.4.7- 1375 initiated by a peer. 7.4.10 1377 gss_delete_sec_context Destroy a security context. 7.4.12 1379 gss_context_time Obtain remaining context 7.4.41 1380 time. 1382 gss_inquire_context Obtain context 7.4.32- 1383 characteristics. 7.3.46 1385 gss_wrap_size_limit Determine token-size limit 7.4.13 1386 for gss_wrap. 1388 gss_export_sec_context Transfer security context 7.4.22 1389 to another process. 1391 gss_get_mic Calculate a cryptographic 7.4.18, 1392 Message Integrity Code (MIC) 7.4.19 1393 for a message. 1395 gss_verify_mic Verify integrity on a received 7.4.20, 1396 message. 7.4.21 1398 gss_wrap Attach a MIC to a message and 7.4.14, 1399 optionally encrypt the message 7.4.15 1400 content. 1402 gss_unwrap Obtain a previously wrapped 7.4.16, 1403 application message verifying 7.4.17 1404 its integrity and optionally 1405 decrypting it. 1407 The functionality offered by the gss_process_context_token routine 1408 has not been included in the Java bindings specification. The 1409 corresponding functionality of gss_delete_sec_context has also been 1410 modified to not return any peer tokens. This has been proposed in 1411 accordance to the recommendations stated in RFC 2743 1412 [GSSAPIv2-UPDATE]. GSSContext does offer the functionality of 1413 destroying the locally-stored context information. 1415 6.5. MessageProp class 1417 This helper class is used in the per-message operations on the 1418 context. An instance of this class is created by the application and 1419 then passed into the per-message calls. In some cases, the 1420 application conveys information to the GSS-API implementation through 1421 this object and in other cases the GSS-API returns information to the 1422 application by setting it in this object. See the description of the 1423 per-message operations wrap, unwrap, getMIC, and verifyMIC in the 1424 GSSContext interfaces for details. 1426 6.6. GSSException class 1428 Exceptions are used in the Java bindings to signal fatal errors to 1429 the calling applications. This replaces the major and minor codes 1430 used in the C-bindings specification as a method of signaling 1431 failures. The GSSException class handles both minor and major codes, 1432 as well as their translation into textual representation. All GSS- 1433 API methods are declared as throwing this exception. 1435 RFC 2743 Routine Function Section 1437 gss_display_status Retrieve textual 7.8.5, 7.8.6, 1438 representation of error 7.8.8, 7.8.9 1439 codes. 1441 6.7. Oid class 1443 This utility class is used to represent Universal Object Identifiers 1444 and their associated operations. GSS-API uses object identifiers to 1445 distinguish between security mechanisms and name types. This class, 1446 aside from being used whenever an object identifier is needed, 1447 implements the following GSS-API functionality: 1449 RFC 2743 Routine Function Section 1451 gss_test_oid_set_member Determine if the specified oid 7.7.5 1452 is part of a set of oids. 1454 6.8. ChannelBinding class 1456 An instance of this class is used to specify channel binding 1457 information to the GSSContext object before the start of a security 1458 context establishment. The application may use a byte array to 1459 specify application data to be used in the channel binding as well as 1460 use instances of the InetAddress. InetAddress is currently the only 1461 address type defined within the Java platform and as such, it is the 1462 only one supported within the ChannelBinding class. Applications 1463 that use other types of addresses can include them as part of the 1464 application data. 1466 7. Detailed GSS-API Class Description 1468 This section lists a detailed description of all the public methods 1469 that each of the GSS-API classes and interfaces must provide. 1471 7.1. public abstract class GSSManager 1473 The GSSManager class is an abstract class that serves as a factory 1474 for three GSS interfaces: GSSName, GSSCredential, and GSSContext. It 1475 also provides methods for applications to determine what mechanisms 1476 are available from the GSS implementation and what nametypes these 1477 mechanisms support. An instance of the default GSSManager subclass 1478 may be obtained through the static method getInstance(), but 1479 applications are free to instantiate other subclasses of GSSManager. 1481 All but one method in this class are declared abstract. This means 1482 that subclasses have to provide the complete implementation for those 1483 methods. The only exception to this is the static method 1484 getInstance() which will have platform specific code to return an 1485 instance of the default subclass. 1487 Platform providers of GSS are required not to add any constructors to 1488 this class, private, public, or protected. This will ensure that all 1489 subclasses invoke only the default constructor provided to the base 1490 class by the compiler. 1492 A subclass extending the GSSManager abstract class may be implemented 1493 as a modular provider based layer that utilizes some well known 1494 service provider specification. The GSSManager API provides the 1495 application with methods to set provider preferences on such an 1496 implementation. These methods also allow the implementation to throw 1497 a well-defined exception in case provider based configuration is not 1498 supported. Applications that expect to be portable should be aware 1499 of this and recover cleanly by catching the exception. 1501 It is envisioned that there will be three most common ways in which 1502 providers will be used: 1504 1) The application does not care about what provider is used (the 1505 default case). 1507 2) The application wants a particular provider to be used 1508 preferentially, either for a particular mechanism or all the time, 1509 irrespective of mechanism. 1511 3) The application wants to use the locally configured providers as 1512 far as possible but if support is missing for one or more mechanisms 1513 then it wants to fall back on its own provider. 1515 The GSSManager class has two methods that enable these modes of 1516 usage: addProviderAtFront() and addProviderAtEnd(). These methods 1517 have the effect of creating an ordered list of pairs 1518 where each pair indicates a preference of provider for a given oid. 1520 The use of these methods does not require any knowledge of whatever 1521 service provider specification the GSSManager subclass follows. It 1522 is hoped that these methods will serve the needs of most 1523 applications. Additional methods may be added to an extended 1524 GSSManager that could be part of a service provider specification 1525 that is standardized later. 1527 7.1.1. Example Code 1529 GSSManager mgr = GSSManager.getInstance(); 1531 // What mechs are available to us? 1532 Oid[] supportedMechs = mgr.getMechs(); 1534 // Set a preference for the provider to be used when support 1535 // is needed for the mechanisms: 1536 // "1.2.840.113554.1.2.2" and "1.3.6.1.5.5.1.1". 1538 Oid krb = new Oid("1.2.840.113554.1.2.2"); 1539 Oid spkm1 = new Oid("1.3.6.1.5.5.1.1"); 1541 Provider p = (Provider) (new com.foo.security.Provider()); 1543 mgr.addProviderAtFront(p, krb); 1544 mgr.addProviderAtFront(p, spkm1); 1546 // What name types does this spkm implementation support? 1547 Oid[] nameTypes = mgr.getNamesForMech(spkm1); 1549 7.1.2. getInstance 1551 public static GSSManager getInstance() 1553 Returns the default GSSManager implementation. 1555 7.1.3. getMechs 1557 public abstract Oid[] getMechs() 1559 Returns an array of Oid objects indicating the mechanisms available 1560 to GSS-API callers. A "null" value is returned when no mechanism are 1561 available (an example of this would be when mechanism are dynamically 1562 configured, and currently no mechanisms are installed). 1564 7.1.4. getNamesForMech 1566 public abstract Oid[] getNamesForMech(Oid mech) 1567 throws GSSException 1569 Returns name type Oid's supported by the specified mechanism. 1571 Parameters: 1573 mech The Oid object for the mechanism to query. 1575 7.1.5. getMechsForName 1577 public abstract Oid[] getMechsForName(Oid nameType) 1579 Returns an array of Oid objects corresponding to the mechanisms that 1580 support the specific name type. "null" is returned when no mechanisms 1581 are found to support the specified name type. 1583 Parameters: 1585 nameType The Oid object for the name type. 1587 7.1.6. createName 1589 public abstract GSSName createName(String nameStr, Oid nameType) 1590 throws GSSException 1592 Factory method to convert a contiguous string name from the specified 1593 namespace to a GSSName object. In general, the GSSName object 1594 created will not be an MN; two examples that are exceptions to this 1595 are when the namespace type parameter indicates NT_EXPORT_NAME or 1596 when the GSS-API implementation is not multi-mechanism. 1598 Parameters: 1600 nameStr The string representing a printable form of the name to 1601 create. 1603 nameType The Oid specifying the namespace of the printable name 1604 supplied. Note that nameType serves to describe and qualify the 1605 interpretation of the input nameStr, it does not necessarily imply 1606 a type for the output GSSName implementation. "null" value can be 1607 used to specify that a mechanism specific default printable syntax 1608 should be assumed by each mechanism that examines nameStr. 1610 7.1.7. createName 1612 public abstract GSSName createName(byte[] name, Oid nameType) 1613 throws GSSException 1615 Factory method to convert a contiguous byte array containing a name 1616 from the specified namespace to a GSSName object. In general, the 1617 GSSName object created will not be an MN; two examples that are 1618 exceptions to this are when the namespace type parameter indicates 1619 NT_EXPORT_NAME or when the GSS-API implementation is not multi- 1620 mechanism. 1622 Parameters: 1624 name The byte array containing the name to create. 1626 nameType The Oid specifying the namespace of the name supplied in 1627 the byte array. Note that nameType serves to describe and qualify 1628 the interpretation of the input name byte array, it does not 1629 necessarily imply a type for the output GSSName implementation. 1630 "null" value can be used to specify that a mechanism specific 1631 default syntax should be assumed by each mechanism that examines 1632 the byte array. 1634 7.1.8. createName 1636 public abstract GSSName createName(String nameStr, Oid nameType, 1637 Oid mech) throws GSSException 1639 Factory method to convert a contiguous string name from the specified 1640 namespace to an GSSName object that is a mechanism name (MN). In 1641 other words, this method is a utility that does the equivalent of two 1642 steps: the createName described in 7.1.6 and then also the 1643 GSSName.canonicalize() described in 7.2.5. 1645 Parameters: 1647 nameStr The string representing a printable form of the name to 1648 create. 1650 nameType The Oid specifying the namespace of the printable name 1651 supplied. Note that nameType serves to describe and qualify the 1652 interpretation of the input nameStr, it does not necessarily imply 1653 a type for the output GSSName implementation. "null" value can be 1654 used to specify that a mechanism specific default printable syntax 1655 should be assumed when the mechanism examines nameStr. 1657 mech Oid specifying the mechanism for which this name should be 1658 created. 1660 7.1.9. createName 1662 public abstract GSSName createName(byte[] name, Oid nameType, 1663 Oid mech) throws GSSException 1665 Factory method to convert a contiguous byte array containing a name 1666 from the specified namespace to a GSSName object that is an MN. In 1667 other words, this method is a utility that does the equivalent of two 1668 steps: the createName described in 7.1.7 and then also the 1669 GSSName.canonicalize() described in 7.2.5. 1671 Parameters: 1673 name The byte array representing the name to create. 1675 nameType The Oid specifying the namespace of the name supplied in 1676 the byte array. Note that nameType serves to describe and qualify 1677 the interpretation of the input name byte array, it does not 1678 necessarily imply a type for the output GSSName implementation. 1679 "null" value can be used to specify that a mechanism specific 1680 default syntax should be assumed by each mechanism that examines 1681 the byte array. 1683 mech Oid specifying the mechanism for which this name should be 1684 created. 1686 7.1.10. createCredential 1688 public abstract GSSCredential createCredential(int usage) 1689 throws GSSException 1691 Factory method for acquiring default credentials. This will cause 1692 the GSS-API to use system specific defaults for the set of 1693 mechanisms, name, and a DEFAULT lifetime. 1695 Parameters: 1697 usage The intended usage for this credential object.The value of 1698 this parameter must be one of: 1699 GSSCredential.INITIATE_AND_ACCEPT(0), 1700 GSSCredential.INITIATE_ONLY(1), GSSCredential.ACCEPT_ONLY(2) 1702 7.1.11. createCredential 1704 public abstract GSSCredential createCredential(GSSName aName, 1705 int lifetime, Oid mech, int usage) 1706 throws GSSException 1708 Factory method for acquiring a single mechanism credential. 1710 Parameters: 1712 aName Name of the principal for whom this credential is to be 1713 acquired. Use "null" to specify the default principal. 1715 lifetime The number of seconds that credentials should remain 1716 valid. Use GSSCredential.INDEFINITE_LIFETIME to request that the 1717 credentials have the maximum permitted lifetime. Use 1718 GSSCredential.DEFAULT_LIFETIME to request default credential 1719 lifetime. 1721 mech The oid of the desired mechanism. Use "(Oid) null" to 1722 request the default mechanism(s). 1724 usage The intended usage for this credential object. The value of 1725 this parameter must be one of: 1726 GSSCredential.INITIATE_AND_ACCEPT(0), 1727 GSSCredential.INITIATE_ONLY(1), GSSCredential.ACCEPT_ONLY(2) 1729 7.1.12. createCredential 1731 public abstract GSSCredential createCredential(GSSName aName, 1732 int lifetime, Oid[] mechs, int usage) 1733 throws GSSException 1735 Factory method for acquiring credentials over a set of mechanisms. 1736 Acquires credentials for each of the mechanisms specified in the 1737 array called mechs. To determine the list of mechanisms' for which 1738 the acquisition of credentials succeeded, the caller should use the 1739 GSSCredential.getMechs() method. 1741 Parameters: 1743 aName Name of the principal for whom this credential is to be 1744 acquired. Use "null" to specify the default principal. 1746 lifetime The number of seconds that credentials should remain 1747 valid. Use GSSCredential.INDEFINITE_LIFETIME to request that the 1748 credentials have the maximum permitted lifetime. Use 1749 GSSCredential.DEFAULT_LIFETIME to request default credential 1750 lifetime. 1752 mechs The array of mechanisms over which the credential is to be 1753 acquired. Use "(Oid[]) null" for requesting a system specific 1754 default set of mechanisms. 1756 usage The intended usage for this credential object. The value of 1757 this parameter must be one of: 1758 GSSCredential.INITIATE_AND_ACCEPT(0), 1759 GSSCredential.INITIATE_ONLY(1), GSSCredential.ACCEPT_ONLY(2) 1761 7.1.13. createContext 1763 public abstract GSSContext createContext(GSSName peer, Oid mech, 1764 GSSCredential myCred, int lifetime) 1765 throws GSSException 1767 Factory method for creating a context on the initiator's side. 1768 Context flags may be modified through the mutator methods prior to 1769 calling GSSContext.initSecContext(). 1771 Parameters: 1773 peer Name of the target peer. 1775 mech Oid of the desired mechanism. Use "(Oid) null" to request 1776 the default mechanism. 1778 myCred Credentials of the initiator. Use "null" to act as a 1779 default initiator principal. 1781 lifetime The request lifetime, in seconds, for the context. Use 1782 GSSContext.INDEFINITE_LIFETIME and GSSContext.DEFAULT_LIFETIME to 1783 request indefinite or default context lifetime. 1785 7.1.14. createContext 1787 public abstract GSSContext createContext(GSSCredential myCred) 1788 throws GSSException 1790 Factory method for creating a context on the acceptor' side. The 1791 context's properties will be determined from the input token supplied 1792 to the accept method. 1794 Parameters: 1796 myCred Credentials for the acceptor. Use "null" to act as a 1797 default acceptor principal. 1799 7.1.15. createContext 1801 public abstract GSSContext createContext(byte[] interProcessToken) 1802 throws GSSException 1804 Factory method for creating a previously exported context. The 1805 context properties will be determined from the input token and can't 1806 be modified through the set methods. 1808 Parameters: 1810 interProcessToken The token previously emitted from the export 1811 method. 1813 7.1.16. addProviderAtFront 1815 public abstract void addProviderAtFront(Provider p, Oid mech) 1816 throws GSSException 1818 This method is used to indicate to the GSSManager that the 1819 application would like a particular provider to be used ahead of all 1820 others when support is desired for the given mechanism. When a value 1821 of null is used instead of an Oid for the mechanism, the GSSManager 1822 must use the indicated provider ahead of all others no matter what 1823 the mechanism is. Only when the indicated provider does not support 1824 the needed mechanism should the GSSManager move on to a different 1825 provider. 1827 Calling this method repeatedly preserves the older settings but 1828 lowers them in preference thus forming an ordered list of provider 1829 and Oid pairs that grows at the top. 1831 Calling addProviderAtFront with a null Oid will remove all previous 1832 preferences that were set for this provider in the GSSManager 1833 instance. Calling addProviderAtFront with a non-null Oid will remove 1834 any previous preference that was set using this mechanism and this 1835 provider together. 1837 If the GSSManager implementation does not support an SPI with a 1838 pluggable provider architecture it should throw a GSSException with 1839 the status code GSSException.UNAVAILABLE to indicate that the 1840 operation is unavailable. 1842 Parameters: 1844 p The provider instance that should be used whenever support is 1845 needed for mech. 1847 mech The mechanism for which the provider is being set 1849 7.1.17. Example Code 1851 Suppose an application desired that the provider A always be checked 1852 first when any mechanism is needed, it would call: 1854 GSSManager mgr = GSSManager.getInstance(); 1855 // mgr may at this point have its own pre-configured list 1856 // of provider preferences. The following will prepend to 1857 // any such list: 1859 mgr.addProviderAtFront(A, null); 1861 Now if it also desired that the mechanism of Oid m1 always be 1862 obtained from the provider B before the previously set A was checked, 1863 it would call: 1865 mgr.addProviderAtFront(B, m1); 1867 The GSSManager would then first check with B if m1 was needed. In 1868 case B did not provide support for m1, the GSSManager would continue 1869 on to check with A. If any mechanism m2 is needed where m2 is 1870 different from m1 then the GSSManager would skip B and check with A 1871 directly. 1873 Suppose at a later time the following call is made to the same 1874 GSSManager instance: 1876 mgr.addProviderAtFront(B, null) 1878 then the previous setting with the pair (B, m1) is subsumed by this 1879 and should be removed. Effectively the list of preferences now 1880 becomes {(B, null), (A, null), ... //followed by the pre-configured 1881 list. 1883 Please note, however, that the following call: 1885 mgr.addProviderAtFront(A, m3) 1887 does not subsume the previous setting of (A, null) and the list will 1888 effectively become {(A, m3), (B, null), (A, null), ...} 1890 7.1.18. addProviderAtEnd 1892 public abstract void addProviderAtEnd(Provider p, Oid mech) 1893 throws GSSException 1895 This method is used to indicate to the GSSManager that the 1896 application would like a particular provider to be used if no other 1897 provider can be found that supports the given mechanism. When a 1898 value of null is used instead of an Oid for the mechanism, the 1899 GSSManager must use the indicated provider for any mechanism. 1901 Calling this method repeatedly preserves the older settings but 1902 raises them above newer ones in preference thus forming an ordered 1903 list of providers and Oid pairs that grows at the bottom. Thus the 1904 older provider settings will be utilized first before this one is. 1906 If there are any previously existing preferences that conflict with 1907 the preference being set here, then the GSSManager should ignore this 1908 request. 1910 If the GSSManager implementation does not support an SPI with a 1911 pluggable provider architecture it should throw a GSSException with 1912 the status code GSSException.UNAVAILABLE to indicate that the 1913 operation is unavailable. 1915 Parameters: 1917 p The provider instance that should be used whenever support is 1918 needed for mech. 1920 mech The mechanism for which the provider is being set 1922 7.1.19. Example Code 1924 Suppose an application desired that when a mechanism of Oid m1 is 1925 needed the system default providers always be checked first, and only 1926 when they do not support m1 should a provider A be checked. It would 1927 then make the call: 1929 GSSManager mgr = GSSManager.getInstance(); 1931 mgr.addProviderAtEnd(A, m1); 1933 Now, if it also desired that for all mechanisms the provider B be 1934 checked after all configured providers have been checked, it would 1935 then call: 1937 mgr.addProviderAtEnd(B, null); 1939 Effectively the list of preferences now becomes {..., (A, m1), (B, 1940 null)}. 1942 Suppose at a later time the following call is made to the same 1943 GSSManager instance: 1945 mgr.addProviderAtEnd(B, m2) 1947 then the previous setting with the pair (B, null) subsumes this and 1948 therefore this request should be ignored. The same would happen if a 1949 request is made for the already existing pairs of (A, m1) or (B, 1950 null). 1952 Please note, however, that the following call: 1954 mgr.addProviderAtEnd(A, null) 1956 is not subsumed by the previous setting of (A, m1) and the list will 1957 effectively become {..., (A, m1), (B, null), (A, null)} 1959 7.2. public interface GSSName 1961 This interface encapsulates a single GSS-API principal entity. 1962 Different name formats and their definitions are identified with 1963 universal Object Identifiers (Oids). The format of the names can be 1964 derived based on the unique oid of its namespace type. 1966 7.2.1. Example Code 1968 Included below are code examples utilizing the GSSName interface. 1969 The code below creates a GSSName, converts it to a mechanism name 1970 (MN), performs a comparison, obtains a printable representation of 1971 the name, exports it and then re-imports to obtain a new GSSName. 1973 GSSManager mgr = GSSManager.getInstance(); 1975 // create a host based service name 1976 GSSName name = mgr.createName("service@host", 1977 GSSName.NT_HOSTBASED_SERVICE); 1979 Oid krb5 = new Oid("1.2.840.113554.1.2.2"); 1981 GSSName mechName = name.canonicalize(krb5); 1983 // the above two steps are equivalent to the following 1984 GSSName mechName = mgr.createName("service@host", 1985 GSSName.NT_HOSTBASED_SERVICE, krb5); 1987 // perform name comparison 1988 if (name.equals(mechName)) 1989 print("Names are equals."); 1991 // obtain textual representation of name and its printable 1992 // name type 1993 print(mechName.toString() + 1994 mechName.getStringNameType().toString()); 1996 // export and re-import the name 1997 byte[] exportName = mechName.export(); 1999 // create a new name object from the exported buffer 2000 GSSName newName = mgr.createName(exportName, 2001 GSSName.NT_EXPORT_NAME); 2003 7.2.2. Static Constants 2005 public static final Oid NT_HOSTBASED_SERVICE 2007 Oid indicating a host-based service name form. It is used to 2008 represent services associated with host computers. This name form is 2009 constructed using two elements, "service" and "hostname", as follows: 2011 service@hostname 2013 Values for the "service" element are registered with the IANA. It 2014 represents the following value: { iso(1) member-body(2) Unites 2015 States(840) mit(113554) infosys(1) gssapi(2) generic(1) 2016 service_name(4) } 2018 public static final Oid NT_USER_NAME 2020 Name type to indicate a named user on a local system. It represents 2021 the following value: { iso(1) member-body(2) United States(840) 2022 mit(113554) infosys(1) gssapi(2) generic(1) user_name(1) } 2024 public static final Oid NT_MACHINE_UID_NAME 2026 Name type to indicate a numeric user identifier corresponding to a 2027 user on a local system. (e.g. Uid). It represents the following 2028 value: { iso(1) member-body(2) United States(840) mit(113554) 2029 infosys(1) gssapi(2) generic(1) machine_uid_name(2) } 2031 public static final Oid NT_STRING_UID_NAME 2033 Name type to indicate a string of digits representing the numeric 2034 user identifier of a user on a local system. It represents the 2035 following value: { iso(1) member-body(2) United States(840) 2036 mit(113554) infosys(1) gssapi(2) generic(1) string_uid_name(3) } 2038 public static final Oid NT_ANONYMOUS 2040 Name type for representing an anonymous entity. It represents the 2041 following value: { iso(1), org(3), dod(6), internet(1), security(5), 2042 nametypes(6), gss-anonymous-name(3) } 2044 public static final Oid NT_EXPORT_NAME 2046 Name type used to indicate an exported name produced by the export 2047 method. It represents the following value: { iso(1), org(3), dod(6), 2048 internet(1), security(5), nametypes(6), gss-api-exported-name(4) } 2050 7.2.3. equals 2052 public boolean equals(GSSName another) throws GSSException 2054 Compares two GSSName objects to determine whether they refer to the 2055 same entity. This method may throw a GSSException when the names 2056 cannot be compared. If either of the names represents an anonymous 2057 entity, the method will return "false". 2059 Parameters: 2061 another GSSName object to compare with. 2063 7.2.4. equals 2065 public boolean equals(Object another) 2067 A variation of the equals method described in 7.2.3 that is provided 2068 to override the Object.equals() method that the implementing class 2069 will inherit. The behavior is exactly the same as that in 7.2.3 2070 except that no GSSException is thrown; instead, false will be 2071 returned in the situation where an error occurs. (Note that the Java 2072 language specification requires that two objects that are equal 2073 according to the equals(Object) method must return the same integer 2074 result when the hashCode() method is called on them.) 2076 Parameters: 2078 another GSSName object to compare with. 2080 7.2.5. canonicalize 2082 public GSSName canonicalize(Oid mech) throws GSSException 2084 Creates a mechanism name (MN) from an arbitrary internal name. This 2085 is equivalent to using the factory methods described in 7.1.8 or 2086 7.1.9 that take the mechanism name as one of their parameters. 2088 Parameters: 2090 mech The oid for the mechanism for which the canonical form of the 2091 name is requested. 2093 7.2.6. export 2095 public byte[] export() throws GSSException 2097 Returns a canonical contiguous byte representation of a mechanism 2098 name (MN), suitable for direct, byte by byte comparison by 2099 authorization functions. If the name is not an MN, implementations 2100 may throw a GSSException with the NAME_NOT_MN status code. If an 2101 implementation chooses not to throw an exception, it should use some 2102 system specific default mechanism to canonicalize the name and then 2103 export it. The format of the header of the output buffer is 2104 specified in RFC 2743 [GSSAPIv2-UPDATE]. 2106 7.2.7. toString 2108 public String toString() 2110 Returns a textual representation of the GSSName object. To retrieve 2111 the printed name format, which determines the syntax of the returned 2112 string, the getStringNameType method can be used. 2114 7.2.8. getStringNameType 2116 public Oid getStringNameType() throws GSSException 2118 Returns the oid representing the type of name returned through the 2119 toString method. Using this oid, the syntax of the printable name 2120 can be determined. 2122 7.2.9. isAnonymous 2124 public boolean isAnonymous() 2126 Tests if this name object represents an anonymous entity. Returns 2127 "true" if this is an anonymous name. 2129 7.2.10. isMN 2131 public boolean isMN() 2133 Tests if this name object contains only one mechanism element and is 2134 thus a mechanism name as defined by RFC 2743 [GSSAPIv2-UPDATE]. 2136 7.3. public interface GSSCredential implements Cloneable 2138 This interface encapsulates the GSS-API credentials for an entity. A 2139 credential contains all the necessary cryptographic information to 2140 enable the creation of a context on behalf of the entity that it 2141 represents. It may contain multiple, distinct, mechanism specific 2142 credential elements, each containing information for a specific 2143 security mechanism, but all referring to the same entity. 2145 A credential may be used to perform context initiation, acceptance, 2146 or both. 2148 GSS-API implementations must impose a local access-control policy on 2149 callers to prevent unauthorized callers from acquiring credentials to 2150 which they are not entitled. GSS-API credential creation is not 2151 intended to provide a "login to the network" function, as such a 2152 function would involve the creation of new credentials rather than 2153 merely acquiring a handle to existing credentials. Such functions, 2154 if required, should be defined in implementation-specific extensions 2155 to the API. 2157 If credential acquisition is time-consuming for a mechanism, the 2158 mechanism may choose to delay the actual acquisition until the 2159 credential is required (e.g. by GSSContext). Such mechanism- 2160 specific implementation decisions should be invisible to the calling 2161 application; thus the query methods immediately following the 2162 creation of a credential object must return valid credential data, 2163 and may therefore incur the overhead of a deferred credential 2164 acquisition. 2166 Applications will create a credential object passing the desired 2167 parameters. The application can then use the query methods to obtain 2168 specific information about the instantiated credential object 2169 (equivalent to the gss_inquire routines). When the credential is no 2170 longer needed, the application should call the dispose (equivalent to 2171 gss_release_cred) method to release any resources held by the 2172 credential object and to destroy any cryptographically sensitive 2173 information. 2175 Classes implementing this interface also implement the Cloneable 2176 interface. This indicates the the class will support the clone() 2177 method that will allow the creation of duplicate credentials. This 2178 is useful when called just before the add() call to retain a copy of 2179 the original credential. 2181 7.3.1. Example Code 2183 This example code demonstrates the creation of a GSSCredential 2184 implementation for a specific entity, querying of its fields, and its 2185 release when it is no longer needed. 2187 GSSManager mgr = GSSManager.getInstance(); 2189 // start by creating a name object for the entity 2190 GSSName name = mgr.createName("userName", GSSName.NT_USER_NAME); 2192 // now acquire credentials for the entity 2193 GSSCredential cred = mgr.createCredential(name, 2194 GSSCredential.ACCEPT_ONLY); 2196 // display credential information - name, remaining lifetime, 2197 // and the mechanisms it has been acquired over 2198 print(cred.getName().toString()); 2199 print(cred.getRemainingLifetime()); 2201 Oid[] mechs = cred.getMechs(); 2202 if (mechs != null) { 2203 for (int i = 0; i < mechs.length; i++) 2204 print(mechs[i].toString()); 2205 } 2206 // release system resources held by the credential 2207 cred.dispose(); 2209 7.3.2. Static Constants 2211 public static final int INITIATE_AND_ACCEPT 2213 Credential usage flag requesting that it be able to be used for both 2214 context initiation and acceptance. The value of this constant is 0. 2216 public static final int INITIATE_ONLY 2218 Credential usage flag requesting that it be able to be used for 2219 context initiation only. The value of this constant is 1. 2221 public static final int ACCEPT_ONLY 2223 Credential usage flag requesting that it be able to be used for 2224 context acceptance only. The value of this constant is 2. 2226 public static final int DEFAULT_LIFETIME 2228 A lifetime constant representing the default credential lifetime. 2229 The value of this constant is 0. 2231 public static final int INDEFINITE_LIFETIME 2233 A lifetime constant representing indefinite credential lifetime. The 2234 value of this constant is the maximum integer value in Java - 2235 Integer.MAX_VALUE. 2237 7.3.3. dispose 2239 public void dispose() throws GSSException 2241 Releases any sensitive information that the GSSCredential object may 2242 be containing. Applications should call this method as soon as the 2243 credential is no longer needed to minimize the time any sensitive 2244 information is maintained. 2246 7.3.4. getName 2248 public GSSName getName() throws GSSException 2250 Retrieves the name of the entity that the credential asserts. 2252 7.3.5. getName 2253 public GSSName getName(Oid mechOID) throws GSSException 2255 Retrieves a mechanism name of the entity that the credential asserts. 2256 Equivalent to calling canonicalize() on the name returned by 7.3.4. 2258 Parameters: 2260 mechOID The mechanism for which information should be returned. 2262 7.3.6. getRemainingLifetime 2264 public int getRemainingLifetime() throws GSSException 2266 Returns the remaining lifetime in seconds for a credential. The 2267 remaining lifetime is the minimum lifetime for any of the underlying 2268 credential mechanisms. A return value of 2269 GSSCredential.INDEFINITE_LIFETIME indicates that the credential does 2270 not expire. A return value of 0 indicates that the credential is 2271 already expired. 2273 7.3.7. getRemainingInitLifetime 2275 public int getRemainingInitLifetime(Oid mech) throws GSSException 2277 Returns the remaining lifetime is seconds for the credential to 2278 remain capable of initiating security contexts under the specified 2279 mechanism. A return value of GSSCredential.INDEFINITE_LIFETIME 2280 indicates that the credential does not expire for context initiation. 2281 A return value of 0 indicates that the credential is already expired. 2283 Parameters: 2285 mechOID The mechanism for which information should be returned. 2287 7.3.8. getRemainingAcceptLifetime 2289 public int getRemainingAcceptLifetime(Oid mech) throws GSSException 2291 Returns the remaining lifetime is seconds for the credential to 2292 remain capable of accepting security contexts under the specified 2293 mechanism. A return value of GSSCredential.INDEFINITE_LIFETIME 2294 indicates that the credential does not expire for context acceptance. 2295 A return value of 0 indicates that the credential is already expired. 2297 Parameters: 2299 mechOID The mechanism for which information should be returned. 2301 7.3.9. getUsage 2303 public int getUsage() throws GSSException 2305 Returns the credential usage flag as a union over all mechanisms. 2306 The return value will be one of GSSCredential.INITIATE_AND_ACCEPT(0), 2307 GSSCredential.INITIATE_ONLY(1), or GSSCredential.ACCEPT_ONLY(2). 2309 7.3.10. getUsage 2311 public int getUsage(Oid mechOID) throws GSSException 2313 Returns the credential usage flag for the specified mechanism only. 2314 The return value will be one of GSSCredential.INITIATE_AND_ACCEPT(0), 2315 GSSCredential.INITIATE_ONLY(1), or GSSCredential.ACCEPT_ONLY(2). 2317 Parameters: 2319 mechOID The mechanism for which information should be returned. 2321 7.3.11. getMechs 2323 public Oid[] getMechs() throws GSSException 2325 Returns an array of mechanisms supported by this credential. 2327 7.3.12. add 2329 public void add(GSSName aName, int initLifetime, int acceptLifetime, 2330 Oid mech, int usage) throws GSSException 2332 Adds a mechanism specific credential-element to an existing 2333 credential. This method allows the construction of credentials one 2334 mechanism at a time. 2336 This routine is envisioned to be used mainly by context acceptors 2337 during the creation of acceptance credentials which are to be used 2338 with a variety of clients using different security mechanisms. 2340 This routine adds the new credential element "in-place". To add the 2341 element in a new credential, first call clone() to obtain a copy of 2342 this credential, then call its add() method. 2344 Parameters: 2346 aName Name of the principal for whom this credential is to be 2347 acquired. Use "null" to specify the default principal. 2349 initLifetime The number of seconds that credentials should remain 2350 valid for initiating of security contexts. Use 2351 GSSCredential.INDEFINITE_LIFETIME to request that the credentials 2352 have the maximum permitted lifetime. Use 2353 GSSCredential.DEFAULT_LIFETIME to request default credential 2354 lifetime. 2356 acceptLifetime The number of seconds that credentials should 2357 remain valid for accepting of security contexts. Use 2358 GSSCredential.INDEFINITE_LIFETIME to request that the credentials 2359 have the maximum permitted lifetime. Use 2360 GSSCredential.DEFAULT_LIFETIME to request default credential 2361 lifetime. 2363 mech The mechanisms over which the credential is to be acquired. 2365 usage The intended usage for this credential object. The value of 2366 this parameter must be one of: 2367 GSSCredential.INITIATE_AND_ACCEPT(0), 2368 GSSCredential.INITIATE_ONLY(1), GSSCredential.ACCEPT_ONLY(2) 2370 7.3.13. equals 2372 public boolean equals(Object another) 2374 Tests if this GSSCredential refers to the same entity as the supplied 2375 object. The two credentials must be acquired over the same 2376 mechanisms and must refer to the same principal. Returns "true" if 2377 the two GSSCredentials refer to the same entity; "false" otherwise. 2378 (Note that the Java language specification [JLS] requires that two 2379 objects that are equal according to the equals(Object) method must 2380 return the same integer result when the hashCode() method is called 2381 on them.) 2383 Parameters: 2385 another Another GSSCredential object for comparison. 2387 7.4. public interface GSSContext 2389 This interface encapsulates the GSS-API security context and provides 2390 the security services (wrap, unwrap, getMIC, verifyMIC) that are 2391 available over the context. Security contexts are established 2392 between peers using locally acquired credentials. Multiple contexts 2393 may exist simultaneously between a pair of peers, using the same or 2394 different set of credentials. GSS-API functions in a manner 2395 independent of the underlying transport protocol and depends on its 2396 calling application to transport its tokens between peers. 2398 Before the context establishment phase is initiated, the context 2399 initiator may request specific characteristics desired of the 2400 established context. These can be set using the set methods. After 2401 the context is established, the caller can check the actual 2402 characteristic and services offered by the context using the query 2403 methods. 2405 The context establishment phase begins with the first call to the 2406 init method by the context initiator. During this phase the 2407 initSecContext and acceptSecContext methods will produce GSS-API 2408 authentication tokens which the calling application needs to send to 2409 its peer. If an error occurs at any point, an exception will get 2410 thrown and the code will start executing in a catch block. If not, 2411 the normal flow of code continues and the application can make a call 2412 to the isEstablished() method. If this method returns false it 2413 indicates that a token is needed from its peer in order to continue 2414 the context establishment phase. A return value of true signals that 2415 the local end of the context is established. This may still require 2416 that a token be sent to the peer, if one is produced by GSS-API. 2417 During the context establishment phase, the isProtReady() method may 2418 be called to determine if the context can be used for the per-message 2419 operations. This allows applications to use per-message operations 2420 on contexts which aren't fully established. 2422 After the context has been established or the isProtReady() method 2423 returns "true", the query routines can be invoked to determine the 2424 actual characteristics and services of the established context. The 2425 application can also start using the per-message methods of wrap and 2426 getMIC to obtain cryptographic operations on application supplied 2427 data. 2429 When the context is no longer needed, the application should call 2430 dispose to release any system resources the context may be using. 2432 7.4.1. Example Code 2434 The example code presented below demonstrates the usage of the 2435 GSSContext interface for the initiating peer. Different operations 2436 on the GSSContext object are presented, including: object 2437 instantiation, setting of desired flags, context establishment, query 2438 of actual context flags, per-message operations on application data, 2439 and finally context deletion. 2441 GSSManager mgr = GSSManager.getInstance(); 2443 // start by creating the name for a service entity 2444 GSSName targetName = mgr.createName("service@host", 2445 GSSName.NT_HOSTBASED_SERVICE); 2447 // create a context using default credentials for the above entity 2448 // and the implementation specific default mechanism 2449 GSSContext context = mgr.createContext(targetName, 2450 null, /* default mechanism */ 2451 null, /* default credentials */ 2452 GSSContext.INDEFINITE_LIFETIME); 2454 // set desired context options - all others are false by default 2455 context.requestConf(true); 2456 context.requestMutualAuth(true); 2457 context.requestReplayDet(true); 2458 context.requestSequenceDet(true); 2460 // establish a context between peers - using byte arrays 2461 byte[]inTok = new byte[0]; 2463 try { 2464 do { 2465 byte[] outTok = context.initSecContext(inTok, 0, 2466 inTok.length); 2468 // send the token if present 2469 if (outTok != null) 2470 sendToken(outTok); 2472 // check if we should expect more tokens 2473 if (context.isEstablished()) 2474 break; 2476 // another token expected from peer 2477 inTok = readToken(); 2479 } while (true); 2481 } catch (GSSException e) { 2482 print("GSSAPI error: " + e.getMessage()); 2483 } 2485 // display context information 2486 print("Remaining lifetime in seconds = " + context.getLifetime()); 2487 print("Context mechanism = " + context.getMech().toString()); 2488 print("Initiator = " + context.getSrcName().toString()); 2489 print("Acceptor = " + context.getTargName().toString()); 2491 if (context.getConfState()) 2492 print("Confidentiality security service available"); 2494 if (context.getIntegState()) 2495 print("Integrity security service available"); 2497 // perform wrap on an application supplied message, appMsg, 2498 // using QOP = 0, and requesting privacy service 2499 byte[] appMsg ... 2501 MessageProp mProp = new MessageProp(0, true); 2503 byte[] tok = context.wrap(appMsg, 0, appMsg.length, mProp); 2505 if (mProp.getPrivacy()) 2506 print("Message protected with privacy."); 2508 sendToken(tok); 2510 // release the local-end of the context 2511 context.dispose(); 2513 7.4.2. Static Constants 2515 public static final int DEFAULT_LIFETIME 2517 A lifetime constant representing the default context lifetime. The 2518 value of this constant is 0. 2520 public static final int INDEFINITE_LIFETIME 2522 A lifetime constant representing indefinite context lifetime. The 2523 value of this constant is the maximum integer value in Java - 2524 Integer.MAX_VALUE. 2526 7.4.3. initSecContext 2528 public byte[] initSecContext(byte[] inputBuf, int offset, int len) 2529 throws GSSException 2531 Called by the context initiator to start the context creation 2532 process. This is equivalent to the stream based method except that 2533 the token buffers are handled as byte arrays instead of using stream 2534 objects. This method may return an output token which the 2535 application will need to send to the peer for processing by the 2536 accept call. Typically, the application would do so by calling the 2537 flush() method on an OutputStream that encapsulates the connection 2538 between the two peers. The application can call isEstablished() to 2539 determine if the context establishment phase is complete for this 2540 peer. A return value of "false" from isEstablished() indicates that 2541 more tokens are expected to be supplied to the initSecContext() 2542 method. Note that it is possible that the initSecContext() method 2543 return a token for the peer, and isEstablished() return "true" also. 2544 This indicates that the token needs to be sent to the peer, but the 2545 local end of the context is now fully established. 2547 Upon completion of the context establishment, the available context 2548 options may be queried through the get methods. 2550 Parameters: 2552 inputBuf Token generated by the peer. This parameter is ignored 2553 on the first call. 2555 offset The offset within the inputBuf where the token begins. 2557 len The length of the token within the inputBuf (starting at the 2558 offset). 2560 7.4.4. Example Code 2562 // Create a new GSSContext implementation object. 2563 // GSSContext wrapper implements interface GSSContext. 2564 GSSContext context = mgr.createContext(...); 2566 byte[] inTok = new byte[0]; 2568 try { 2569 do { 2570 byte[] outTok = context.initSecContext(inTok, 0, 2571 inTok.length); 2573 // send the token if present 2574 if (outTok != null) 2575 sendToken(outTok); 2577 // check if we should expect more tokens 2578 if (context.isEstablished()) 2579 break; 2581 // another token expected from peer 2582 inTok = readToken(); 2583 } while (true); 2585 } catch (GSSException e) { 2586 print("GSSAPI error: " + e.getMessage()); 2587 } 2589 7.4.5. initSecContext 2590 public int initSecContext(InputStream inStream, 2591 OutputStream outStream) throws GSSException 2593 Called by the context initiator to start the context creation 2594 process. This is equivalent to the byte array based method. This 2595 method may write an output token to the outStream, which the 2596 application will need to send to the peer for processing by the 2597 accept call. Typically, the application would do so by calling the 2598 flush() method on an OutputStream that encapsulates the connection 2599 between the two peers. The application can call isEstablished() to 2600 determine if the context establishment phase is complete for this 2601 peer. A return value of "false" from isEstablished indicates that 2602 more tokens are expected to be supplied to the initSecContext method. 2603 Note that it is possible that the initSecContext() method return a 2604 token for the peer, and isEstablished() return "true" also. This 2605 indicates that the token needs to be sent to the peer, but the local 2606 end of the context is now fully established. 2608 The GSS-API authentication tokens contain a definitive start and end. 2609 This method will attempt to read one of these tokens per invocation, 2610 and may block on the stream if only part of the token is available. 2612 Upon completion of the context establishment, the available context 2613 options may be queried through the get methods. 2615 Parameters: 2617 inStream Contains the token generated by the peer. This parameter 2618 is ignored on the first call. 2620 outStream Output stream where the output token will be written. 2621 During the final stage of context establishment, there may be no 2622 bytes written. 2624 7.4.6. Example Code 2626 This sample code merely demonstrates the token exchange during the 2627 context establishment phase. It is expected that most Java 2628 applications will use custom implementations of the Input and Output 2629 streams that encapsulate the communication routines. For instance, a 2630 simple read on the application InputStream, when called by the 2631 Context, might cause a token to be read from the peer, and a simple 2632 flush() on the application OutputStream might cause a previously 2633 written token to be transmitted to the peer. 2635 // Create a new GSSContext implementation object. 2636 // GSSContext wrapper implements interface GSSContext. 2637 GSSContext context = mgr.createContext(...); 2638 // use standard java.io stream objects 2639 ByteArrayOutputStream os = new ByteArrayOutputStream(); 2640 ByteArrayInputStream is = null; 2642 try { 2643 do { 2644 context.initSecContext(is, os); 2646 // send token if present 2647 if (os.size() > 0) 2648 sendToken(os); 2650 // check if we should expect more tokens 2651 if (context.isEstablished()) 2652 break; 2654 // another token expected from peer 2655 is = recvToken(); 2657 } while (true); 2659 } catch (GSSException e) { 2660 print("GSSAPI error: " + e.getMessage()); 2661 } 2663 7.4.7. acceptSecContext 2665 public byte[] acceptSecContext(byte[] inTok, int offset, int len) 2666 throws GSSException 2668 Called by the context acceptor upon receiving a token from the peer. 2669 This call is equivalent to the stream based method except that the 2670 token buffers are handled as byte arrays instead of using stream 2671 objects. 2673 This method may return an output token which the application will 2674 need to send to the peer for further processing by the init call. 2676 "null" return value indicates that no token needs to be sent to the 2677 peer. The application can call isEstablished() to determine if the 2678 context establishment phase is complete for this peer. A return 2679 value of "false" from isEstablished() indicates that more tokens are 2680 expected to be supplied to this method. 2682 Note that it is possible that acceptSecContext() return a token for 2683 the peer, and isEstablished() return "true" also. This indicates 2684 that the token needs to be sent to the peer, but the local end of the 2685 context is now fully established. 2687 Upon completion of the context establishment, the available context 2688 options may be queried through the get methods. 2690 Parameters: 2692 inTok Token generated by the peer. 2694 offset The offset within the inTok where the token begins. 2696 len The length of the token within the inTok (starting at the 2697 offset). 2699 7.4.8. Example Code 2701 // acquire server credentials 2702 GSSCredential server = mgr.createCredential(...); 2704 // create acceptor GSS-API context from the default provider 2705 GSSContext context = mgr.createContext(server, null); 2707 try { 2708 do { 2709 byte[] inTok = readToken(); 2711 byte[] outTok = context.acceptSecContext(inTok, 0, 2712 inTok.length); 2714 // possibly send token to peer 2715 if (outTok != null) 2716 sendToken(outTok); 2718 // check if local context establishment is complete 2719 if (context.isEstablished()) 2720 break; 2721 } while (true); 2723 } catch (GSSException e) { 2724 print("GSS-API error: " + e.getMessage()); 2725 } 2727 7.4.9. acceptSecContext 2729 public void acceptSecContext(InputStream inStream, 2730 OutputStream outStream) throws GSSException 2732 Called by the context acceptor upon receiving a token from the peer. 2733 This call is equivalent to the byte array method. It may write an 2734 output token to the outStream, which the application will need to 2735 send to the peer for processing by its initSecContext method. 2736 Typically, the application would do so by calling the flush() method 2737 on an OutputStream that encapsulates the connection between the two 2738 peers. The application can call isEstablished() to determine if the 2739 context establishment phase is complete for this peer. A return 2740 value of "false" from isEstablished() indicates that more tokens are 2741 expected to be supplied to this method. 2743 Note that it is possible that acceptSecContext() return a token for 2744 the peer, and isEstablished() return "true" also. This indicates 2745 that the token needs to be sent to the peer, but the local end of the 2746 context is now fully established. 2748 The GSS-API authentication tokens contain a definitive start and end. 2749 This method will attempt to read one of these tokens per invocation, 2750 and may block on the stream if only part of the token is available. 2752 Upon completion of the context establishment, the available context 2753 options may be queried through the get methods. 2755 Parameters: 2757 inStream Contains the token generated by the peer. 2759 outStream Output stream where the output token will be written. 2760 During the final stage of context establishment, there may be no 2761 bytes written. 2763 7.4.10. Example Code 2765 This sample code merely demonstrates the token exchange during the 2766 context establishment phase. It is expected that most Java 2767 applications will use custom implementations of the Input and Output 2768 streams that encapsulate the communication routines. For instance, a 2769 simple read on the application InputStream, when called by the 2770 Context, might cause a token to be read from the peer, and a simple 2771 flush() on the application OutputStream might cause a previously 2772 written token to be transmitted to the peer. 2774 // acquire server credentials 2775 GSSCredential server = mgr.createCredential(...); 2777 // create acceptor GSS-API context from the default provider 2778 GSSContext context = mgr.createContext(server, null); 2780 // use standard java.io stream objects 2781 ByteArrayOutputStream os = new ByteArrayOutputStream(); 2782 ByteArrayInputStream is = null; 2783 try { 2784 do { 2786 is = recvToken(); 2788 context.acceptSecContext(is, os); 2790 // possibly send token to peer 2791 if (os.size() > 0) 2792 sendToken(os); 2794 // check if local context establishment is complete 2795 if (context.isEstablished()) 2796 break; 2797 } while (true); 2799 } catch (GSSException e) { 2800 print("GSS-API error: " + e.getMessage()); 2801 } 2803 7.4.11. isEstablished 2805 public boolean isEstablished() 2807 Used during context establishment to determine the state of the 2808 context. Returns "true" if this is a fully established context on 2809 the caller's side and no more tokens are needed from the peer. 2810 Should be called after a call to initSecContext() or 2811 acceptSecContext() when no GSSException is thrown. 2813 7.4.12. dispose 2815 public void dispose() throws GSSException 2817 Releases any system resources and cryptographic information stored in 2818 the context object. This will invalidate the context. 2820 7.4.13. getWrapSizeLimit 2822 public int getWrapSizeLimit(int qop, boolean confReq, 2823 int maxTokenSize) throws GSSException 2825 Returns the maximum message size that, if presented to the wrap 2826 method with the same confReq and qop parameters, will result in an 2827 output token containing no more than the maxTokenSize bytes. 2829 This call is intended for use by applications that communicate over 2830 protocols that impose a maximum message size. It enables the 2831 application to fragment messages prior to applying protection. 2833 GSS-API implementations are recommended but not required to detect 2834 invalid QOP values when getWrapSizeLimit is called. This routine 2835 guarantees only a maximum message size, not the availability of 2836 specific QOP values for message protection. 2838 Successful completion of this call does not guarantee that wrap will 2839 be able to protect a message of the computed length, since this 2840 ability may depend on the availability of system resources at the 2841 time that wrap is called. However, if the implementation itself 2842 imposes an upper limit on the length of messages that may be 2843 processed by wrap, the implementation should not return a value that 2844 is greater than this length. 2846 Parameters: 2848 qop Indicates the level of protection wrap will be asked to 2849 provide. 2851 confReq Indicates if wrap will be asked to provide privacy 2852 service. 2854 maxTokenSize The desired maximum size of the token emitted by 2855 wrap. 2857 7.4.14. wrap 2859 public byte[] wrap(byte[] inBuf, int offset, int len, 2860 MessageProp msgProp) throws GSSException 2862 Applies per-message security services over the established security 2863 context. The method will return a token with a cryptographic MIC and 2864 may optionally encrypt the specified inBuf. This method is 2865 equivalent in functionality to its stream counterpart. The returned 2866 byte array will contain both the MIC and the message. 2868 The MessageProp object is instantiated by the application and used to 2869 specify a QOP value which selects cryptographic algorithms, and a 2870 privacy service to optionally encrypt the message. The underlying 2871 mechanism that is used in the call may not be able to provide the 2872 privacy service. It sets the actual privacy service that it does 2873 provide in this MessageProp object which the caller should then query 2874 upon return. If the mechanism is not able to provide the requested 2875 QOP, it throws a GSSException with the BAD_QOP code. 2877 Since some application-level protocols may wish to use tokens emitted 2878 by wrap to provide "secure framing", implementations should support 2879 the wrapping of zero-length messages. 2881 The application will be responsible for sending the token to the 2882 peer. 2884 Parameters: 2886 inBuf Application data to be protected. 2888 offset The offset within the inBuf where the data begins. 2890 len The length of the data within the inBuf (starting at the 2891 offset). 2893 msgProp Instance of MessageProp that is used by the application to 2894 set the desired QOP and privacy state. Set the desired QOP to 0 2895 to request the default QOP. Upon return from this method, this 2896 object will contain the the actual privacy state that was applied 2897 to the message by the underlying mechanism. 2899 7.4.15. wrap 2901 public void wrap(InputStream inStream, OutputStream outStream, 2902 MessageProp msgProp) throws GSSException 2904 Allows to apply per-message security services over the established 2905 security context. The method will produce a token with a 2906 cryptographic MIC and may optionally encrypt the message in inStream. 2907 The outStream will contain both the MIC and the message. 2909 The MessageProp object is instantiated by the application and used to 2910 specify a QOP value which selects cryptographic algorithms, and a 2911 privacy service to optionally encrypt the message. The underlying 2912 mechanism that is used in the call may not be able to provide the 2913 privacy service. It sets the actual privacy service that it does 2914 provide in this MessageProp object which the caller should then query 2915 upon return. If the mechanism is not able to provide the requested 2916 QOP, it throws a GSSException with the BAD_QOP code. 2918 Since some application-level protocols may wish to use tokens emitted 2919 by wrap to provide "secure framing", implementations should support 2920 the wrapping of zero-length messages. 2922 The application will be responsible for sending the token to the 2923 peer. 2925 Parameters: 2927 inStream Input stream containing the application data to be 2928 protected. 2930 outStream The output stream to write the protected message to. 2931 The application is responsible for sending this to the other peer 2932 for processing in its unwrap method. 2934 msgProp Instance of MessageProp that is used by the application to 2935 set the desired QOP and privacy state. Set the desired QOP to 0 2936 to request the default QOP. Upon return from this method, this 2937 object will contain the the actual privacy state that was applied 2938 to the message by the underlying mechanism. 2940 7.4.16. unwrap 2942 public byte[] unwrap(byte[] inBuf, int offset, int len, 2943 MessageProp msgProp) throws GSSException 2945 Used by the peer application to process tokens generated with the 2946 wrap call. This call is equal in functionality to its stream 2947 counterpart. The method will return the message supplied in the peer 2948 application to the wrap call, verifying the embedded MIC. 2950 The MessageProp object is instantiated by the application and is used 2951 by the underlying mechanism to return information to the caller such 2952 as the QOP, whether confidentiality was applied to the message, and 2953 other supplementary message state information. 2955 Since some application-level protocols may wish to use tokens emitted 2956 by wrap to provide "secure framing", implementations should support 2957 the wrapping and unwrapping of zero-length messages. 2959 Parameters: 2961 inBuf GSS-API wrap token received from peer. 2963 offset The offset within the inBuf where the token begins. 2965 len The length of the token within the inBuf (starting at the 2966 offset). 2968 msgProp Upon return from the method, this object will contain the 2969 applied QOP, the privacy state of the message, and supplementary 2970 information described in 5.12.3 stating whether the token was a 2971 duplicate, old, out of sequence or arriving after a gap. 2973 7.4.17. unwrap 2974 public void unwrap(InputStream inStream, OutputStream outStream, 2975 MessageProp msgProp) throws GSSException 2977 Used by the peer application to process tokens generated with the 2978 wrap call. This call is equal in functionality to its byte array 2979 counterpart. It will produce the message supplied in the peer 2980 application to the wrap call, verifying the embedded MIC. 2982 The MessageProp object is instantiated by the application and is used 2983 by the underlying mechanism to return information to the caller such 2984 as the QOP, whether confidentiality was applied to the message, and 2985 other supplementary message state information. 2987 Since some application-level protocols may wish to use tokens emitted 2988 by wrap to provide "secure framing", implementations should support 2989 the wrapping and unwrapping of zero-length messages. 2991 Parameters: 2993 inStream Input stream containing the GSS-API wrap token received 2994 from the peer. 2996 outStream The output stream to write the application message to. 2998 msgProp Upon return from the method, this object will contain the 2999 applied QOP, the privacy state of the message, and supplementary 3000 information described in 5.12.3 stating whether the token was a 3001 duplicate, old, out of sequence or arriving after a gap. 3003 7.4.18. getMIC 3005 public byte[] getMIC(byte[] inMsg, int offset, int len, 3006 MessageProp msgProp) throws GSSException 3008 Returns a token containing a cryptographic MIC for the supplied 3009 message, for transfer to the peer application. Unlike wrap, which 3010 encapsulates the user message in the returned token, only the message 3011 MIC is returned in the output token. This method is identical in 3012 functionality to its stream counterpart. 3014 Note that privacy can only be applied through the wrap call. 3016 Since some application-level protocols may wish to use tokens emitted 3017 by getMIC to provide "secure framing", implementations should support 3018 derivation of MICs from zero-length messages. 3020 Parameters: 3022 inMsg Message to generate MIC over. 3024 offset The offset within the inMsg where the token begins. 3026 len The length of the token within the inMsg (starting at the 3027 offset). 3029 msgProp Instance of MessageProp that is used by the application to 3030 set the desired QOP. Set the desired QOP to 0 in msgProp to 3031 request the default QOP. Alternatively pass in "null" for msgProp 3032 to request default QOP. 3034 7.4.19. getMIC 3036 public void getMIC(InputStream inStream, OutputStream outStream, 3037 MessageProp msgProp) throws GSSException 3039 Produces a token containing a cryptographic MIC for the supplied 3040 message, for transfer to the peer application. Unlike wrap, which 3041 encapsulates the user message in the returned token, only the message 3042 MIC is produced in the output token. This method is identical in 3043 functionality to its byte array counterpart. 3045 Note that privacy can only be applied through the wrap call. 3047 Since some application-level protocols may wish to use tokens emitted 3048 by getMIC to provide "secure framing", implementations should support 3049 derivation of MICs from zero-length messages. 3051 Parameters: 3053 inStream Input stream containing the message to generate MIC over. 3055 outStream Output stream to write the GSS-API output token to. 3057 msgProp Instance of MessageProp that is used by the application to 3058 set the desired QOP. Set the desired QOP to 0 in msgProp to 3059 request the default QOP. Alternatively pass in "null" for msgProp 3060 to request default QOP. 3062 7.4.20. verifyMIC 3064 public void verifyMIC(byte[] inTok, int tokOffset, int tokLen, 3065 byte[] inMsg, int msgOffset, int msgLen, 3066 MessageProp msgProp) throws GSSException 3068 Verifies the cryptographic MIC, contained in the token parameter, 3069 over the supplied message. This method is equivalent in 3070 functionality to its stream counterpart. 3072 The MessageProp object is instantiated by the application and is used 3073 by the underlying mechanism to return information to the caller such 3074 as the QOP indicating the strength of protection that was applied to 3075 the message and other supplementary message state information. 3077 Since some application-level protocols may wish to use tokens emitted 3078 by getMIC to provide "secure framing", implementations should support 3079 the calculation and verification of MICs over zero-length messages. 3081 Parameters: 3083 inTok Token generated by peer's getMIC method. 3085 tokOffset The offset within the inTok where the token begins. 3087 tokLen The length of the token within the inTok (starting at the 3088 offset). 3090 inMsg Application message to verify the cryptographic MIC over. 3092 msgOffset The offset within the inMsg where the message begins. 3094 msgLen The length of the message within the inMsg (starting at the 3095 offset). 3097 msgProp Upon return from the method, this object will contain the 3098 applied QOP and supplementary information described in 5.12.3 3099 stating whether the token was a duplicate, old, out of sequence or 3100 arriving after a gap. The confidentiality state will be set to 3101 "false". 3103 7.4.21. verifyMIC 3105 public void verifyMIC(InputStream tokStream, InputStream msgStream, 3106 MessageProp msgProp) throws GSSException 3108 Verifies the cryptographic MIC, contained in the token parameter, 3109 over the supplied message. This method is equivalent in 3110 functionality to its byte array counterpart. 3112 The MessageProp object is instantiated by the application and is used 3113 by the underlying mechanism to return information to the caller such 3114 as the QOP indicating the strength of protection that was applied to 3115 the message and other supplementary message state information. 3117 Since some application-level protocols may wish to use tokens emitted 3118 by getMIC to provide "secure framing", implementations should support 3119 the calculation and verification of MICs over zero-length messages. 3121 Parameters: 3123 tokStream Input stream containing the token generated by peer's 3124 getMIC method. 3126 msgStream Input stream containing the application message to 3127 verify the cryptographic MIC over. 3129 msgProp Upon return from the method, this object will contain the 3130 applied QOP and supplementary information described in 5.12.3 3131 stating whether the token was a duplicate, old, out of sequence or 3132 arriving after a gap. The confidentiality state will be set to 3133 "false". 3135 7.4.22. export 3137 public byte[] export() throws GSSException 3139 Provided to support the sharing of work between multiple processes. 3140 This routine will typically be used by the context-acceptor, in an 3141 application where a single process receives incoming connection 3142 requests and accepts security contexts over them, then passes the 3143 established context to one or more other processes for message 3144 exchange. 3146 This method deactivates the security context and creates an 3147 interprocess token which, when passed to the byte array constructor 3148 of the GSSContext interface in another process, will re-activate the 3149 context in the second process. Only a single instantiation of a 3150 given context may be active at any one time; a subsequent attempt by 3151 a context exporter to access the exported security context will fail. 3153 The implementation may constrain the set of processes by which the 3154 interprocess token may be imported, either as a function of local 3155 security policy, or as a result of implementation decisions. For 3156 example, some implementations may constrain contexts to be passed 3157 only between processes that run under the same account, or which are 3158 part of the same process group. 3160 The interprocess token may contain security-sensitive information 3161 (for example cryptographic keys). While mechanisms are encouraged to 3162 either avoid placing such sensitive information within interprocess 3163 tokens, or to encrypt the token before returning it to the 3164 application, in a typical GSS-API implementation this may not be 3165 possible. Thus the application must take care to protect the 3166 interprocess token, and ensure that any process to which the token is 3167 transferred is trustworthy. 3169 7.4.23. requestMutualAuth 3171 public void requestMutualAuth(boolean state) throws GSSException 3173 Sets the request state of the mutual authentication flag for the 3174 context. This method is only valid before the context creation 3175 process begins and only for the initiator. 3177 Parameters: 3179 state Boolean representing if mutual authentication should be 3180 requested during context establishment. 3182 7.4.24. requestReplayDet 3184 public void requestReplayDet(boolean state) throws GSSException 3186 Sets the request state of the replay detection service for the 3187 context. This method is only valid before the context creation 3188 process begins and only for the initiator. 3190 Parameters: 3192 state Boolean representing if replay detection is desired over the 3193 established context. 3195 7.4.25. requestSequenceDet 3197 public void requestSequenceDet(boolean state) throws GSSException 3199 Sets the request state for the sequence checking service of the 3200 context. This method is only valid before the context creation 3201 process begins and only for the initiator. 3203 Parameters: 3205 state Boolean representing if sequence detection is desired over 3206 the established context. 3208 7.4.26. requestCredDeleg 3210 public void requestCredDeleg(boolean state) throws GSSException 3212 Sets the request state for the credential delegation flag for the 3213 context. This method is only valid before the context creation 3214 process begins and only for the initiator. 3216 Parameters: 3218 state Boolean representing if credential delegation is desired. 3220 7.4.27. requestAnonymity 3222 public void requestAnonymity(boolean state) throws GSSException 3224 Requests anonymous support over the context. This method is only 3225 valid before the context creation process begins and only for the 3226 initiator. 3228 Parameters: 3230 state Boolean representing if anonymity support is requested. 3232 7.4.28. requestConf 3234 public void requestConf(boolean state) throws GSSException 3236 Requests that confidentiality service be available over the context. 3237 This method is only valid before the context creation process begins 3238 and only for the initiator. 3240 Parameters: 3242 state Boolean indicating if confidentiality services are to be 3243 requested for the context. 3245 7.4.29. requestInteg 3247 public void requestInteg(boolean state) throws GSSException 3249 Requests that integrity services be available over the context. This 3250 method is only valid before the context creation process begins and 3251 only for the initiator. 3253 Parameters: 3255 state Boolean indicating if integrity services are to be requested 3256 for the context. 3258 7.4.30. requestLifetime 3260 public void requestLifetime(int lifetime) throws GSSException 3261 Sets the desired lifetime for the context in seconds. This method is 3262 only valid before the context creation process begins and only for 3263 the initiator. Use GSSContext.INDEFINITE_LIFETIME and 3264 GSSContext.DEFAULT_LIFETIME to request indefinite or default context 3265 lifetime. 3267 Parameters: 3269 lifetime The desired context lifetime in seconds. 3271 7.4.31. setChannelBinding 3273 public void setChannelBinding(ChannelBinding cb) throws GSSException 3275 Sets the channel bindings to be used during context establishment. 3276 This method is only valid before the context creation process begins. 3278 Parameters: 3280 cb Channel bindings to be used. 3282 7.4.32. getCredDelegState 3284 public boolean getCredDelegState() 3286 Returns the state of the delegated credentials for the context. When 3287 issued before context establishment is completed or when the 3288 isProtReady method returns "false", it returns the desired state, 3289 otherwise it will indicate the actual state over the established 3290 context. 3292 7.4.33. getMutualAuthState 3294 public boolean getMutualAuthState() 3296 Returns the state of the mutual authentication option for the 3297 context. When issued before context establishment completes or when 3298 the isProtReady method returns "false", it returns the desired state, 3299 otherwise it will indicate the actual state over the established 3300 context. 3302 7.4.34. getReplayDetState 3304 public boolean getReplayDetState() 3306 Returns the state of the replay detection option for the context. 3307 When issued before context establishment completes or when the 3308 isProtReady method returns "false", it returns the desired state, 3309 otherwise it will indicate the actual state over the established 3310 context. 3312 7.4.35. getSequenceDetState 3314 public boolean getSequenceDetState() 3316 Returns the state of the sequence detection option for the context. 3317 When issued before context establishment completes or when the 3318 isProtReady method returns "false", it returns the desired state, 3319 otherwise it will indicate the actual state over the established 3320 context. 3322 7.4.36. getAnonymityState 3324 public boolean getAnonymityState() 3326 Returns "true" if this is an anonymous context. When issued before 3327 context establishment completes or when the isProtReady method 3328 returns "false", it returns the desired state, otherwise it will 3329 indicate the actual state over the established context. 3331 7.4.37. isTransferable 3333 public boolean isTransferable() throws GSSException 3335 Returns "true" if the context is transferable to other processes 3336 through the use of the export method. This call is only valid on 3337 fully established contexts. 3339 7.4.38. isProtReady 3341 public boolean isProtReady() 3343 Returns "true" if the per message operations can be applied over the 3344 context. Some mechanisms may allow the usage of per-message 3345 operations before the context is fully established. This will also 3346 indicate that the get methods will return actual context state 3347 characteristics instead of the desired ones. 3349 7.4.39. getConfState 3351 public boolean getConfState() 3353 Returns the confidentiality service state over the context. When 3354 issued before context establishment completes or when the isProtReady 3355 method returns "false", it returns the desired state, otherwise it 3356 will indicate the actual state over the established context. 3358 7.4.40. getIntegState 3360 public boolean getIntegState() 3362 Returns the integrity service state over the context. When issued 3363 before context establishment completes or when the isProtReady method 3364 returns "false", it returns the desired state, otherwise it will 3365 indicate the actual state over the established context. 3367 7.4.41. getLifetime 3369 public int getLifetime() 3371 Returns the context lifetime in seconds. When issued before context 3372 establishment completes or when the isProtReady method returns 3373 "false", it returns the desired lifetime, otherwise it will indicate 3374 the remaining lifetime for the context. 3376 7.4.42. getSrcName 3378 public GSSName getSrcName() throws GSSException 3380 Returns the name of the context initiator. This call is valid only 3381 after the context is fully established or the isProtReady method 3382 returns "true". It is guaranteed to return an MN. 3384 7.4.43. getTargName 3386 public GSSName getTargName() throws GSSException 3388 Returns the name of the context target (acceptor). This call is 3389 valid only after the context is fully established or the isProtReady 3390 method returns "true". It is guaranteed to return an MN. 3392 7.4.44. getMech 3394 public Oid getMech() throws GSSException 3396 Returns the mechanism oid for this context. This method may be 3397 called before the context is fully established, but the mechanism 3398 returned may change on successive calls in negotiated mechanism case. 3400 7.4.45. getDelegCred 3402 public GSSCredential getDelegCred() throws GSSException 3404 Returns the delegated credential object on the acceptor's side. To 3405 check for availability of delegated credentials call 3406 getDelegCredState. This call is only valid on fully established 3407 contexts. 3409 7.4.46. isInitiator 3411 public boolean isInitiator() throws GSSException 3413 Returns "true" if this is the initiator of the context. This call is 3414 only valid after the context creation process has started. 3416 7.5. public class MessageProp 3418 This is a utility class used within the per-message GSSContext 3419 methods to convey per-message properties. 3421 When used with the GSSContext interface's wrap and getMIC methods, an 3422 instance of this class is used to indicate the desired QOP and to 3423 request if confidentiality services are to be applied to caller 3424 supplied data (wrap only). To request default QOP, the value of 0 3425 should be used for QOP. 3427 When used with the unwrap and verifyMIC methods of the GSSContext 3428 interface, an instance of this class will be used to indicate the 3429 applied QOP and confidentiality services over the supplied message. 3430 In the case of verifyMIC, the confidentiality state will always be 3431 "false". Upon return from these methods, this object will also 3432 contain any supplementary status values applicable to the processed 3433 token. The supplementary status values can indicate old tokens, out 3434 of sequence tokens, gap tokens or duplicate tokens. 3436 7.5.1. Constructors 3438 public MessageProp(boolean privState) 3440 Constructor which sets QOP to 0 indicating that the default QOP is 3441 requested. 3443 Parameters: 3445 privState The desired privacy state. "true" for privacy and 3446 "false" for integrity only. 3448 public MessageProp(int qop, boolean privState) 3450 Constructor which sets the values for the qop and privacy state. 3452 Parameters: 3454 qop The desired QOP. Use 0 to request a default QOP. 3456 privState The desired privacy state. "true" for privacy and 3457 "false" for integrity only. 3459 7.5.2. getQOP 3461 public int getQOP() 3463 Retrieves the QOP value. 3465 7.5.3. getPrivacy 3467 public boolean getPrivacy() 3469 Retrieves the privacy state. 3471 7.5.4. getMinorStatus 3473 public int getMinorStatus() 3475 Retrieves the minor status that the underlying mechanism might have 3476 set. 3478 7.5.5. getMinorString 3480 public String getMinorString() 3482 Returns a string explaining the mechanism specific error code. null 3483 will be returned when no mechanism error code has been set. 3485 7.5.6. setQOP 3487 public void setQOP(int qopVal) 3489 Sets the QOP value. 3491 Parameters: 3493 qopVal The QOP value to be set. Use 0 to request a default QOP 3494 value. 3496 7.5.7. setPrivacy 3498 public void setPrivacy(boolean privState) 3500 Sets the privacy state. 3502 Parameters: 3504 privState The privacy state to set. 3506 7.5.8. isDuplicateToken 3508 public boolean isDuplicateToken() 3510 Returns "true" if this is a duplicate of an earlier token. 3512 7.5.9. isOldToken 3514 public boolean isOldToken() 3516 Returns "true" if the token's validity period has expired. 3518 7.5.10. isUnseqToken 3520 public boolean isUnseqToken() 3522 Returns "true" if a later token has already been processed. 3524 7.5.11. isGapToken 3526 public boolean isGapToken() 3528 Returns "true" if an expected per-message token was not received. 3530 7.5.12. setSupplementaryStates 3532 public void setSupplementaryStates(boolean duplicate, 3533 boolean old, boolean unseq, boolean gap, 3534 int minorStatus, String minorString) 3536 This method sets the state for the supplementary information flags 3537 and the minor status in MessageProp. It is not used by the 3538 application but by the GSS implementation to return this information 3539 to the caller of a per-message context method. 3541 Parameters: 3543 duplicate true if the token was a duplicate of an earlier token, 3544 false otherwise 3546 old true if the token's validity period has expired, false 3547 otherwise 3549 unseq true if a later token has already been processed, false 3550 otherwise 3552 gap true if one or more predecessor tokens have not yet been 3553 successfully processed, false otherwise 3555 minorStatus the integer minor status code that the underlying 3556 mechanism wants to set 3558 minorString the textual representation of the minorStatus value 3560 7.6. public class ChannelBinding 3562 The GSS-API accommodates the concept of caller-provided channel 3563 binding information. Channel bindings are used to strengthen the 3564 quality with which peer entity authentication is provided during 3565 context establishment. They enable the GSS-API callers to bind the 3566 establishment of the security context to relevant characteristics 3567 like addresses or to application specific data. 3569 The caller initiating the security context must determine the 3570 appropriate channel binding values to set in the GSSContext object. 3571 The acceptor must provide an identical binding in order to validate 3572 that received tokens possess correct channel-related characteristics. 3574 Use of channel bindings is optional in GSS-API. Since channel- 3575 binding information may be transmitted in context establishment 3576 tokens, applications should therefore not use confidential data as 3577 channel-binding components. 3579 7.6.1. Constructors 3581 public ChannelBinding(InetAddress initAddr, InetAddress acceptAddr, 3582 byte[] appData) 3584 Create a ChannelBinding object with user supplied address information 3585 and data. "null" values can be used for any fields which the 3586 application does not want to specify. 3588 Parameters: 3590 initAddr The address of the context initiator. "null" value can be 3591 supplied to indicate that the application does not want to set 3592 this value. 3594 acceptAddr The address of the context acceptor. "null" value can 3595 be supplied to indicate that the application does not want to set 3596 this value. 3598 appData Application supplied data to be used as part of the 3599 channel bindings. "null" value can be supplied to indicate that 3600 the application does not want to set this value. 3602 public ChannelBinding(byte[] appData) 3604 Creates a ChannelBinding object without any addressing information. 3606 Parameters: 3608 appData Application supplied data to be used as part of the 3609 channel bindings. 3611 7.6.2. getInitiatorAddress 3613 public InetAddress getInitiatorAddress() 3615 Returns the initiator's address for this channel binding. "null" is 3616 returned if the address has not been set. 3618 7.6.3. getAcceptorAddress 3620 public InetAddress getAcceptorAddress() 3622 Returns the acceptor's address for this channel binding. "null" is 3623 returned if the address has not been set. 3625 7.6.4. getApplicationData 3627 public byte[] getApplicationData() 3629 Returns application data being used as part of the ChannelBinding. 3630 "null" is returned if no application data has been specified for the 3631 channel binding. 3633 7.6.5. equals 3635 public boolean equals(Object obj) 3637 Returns "true" if two channel bindings match. (Note that the Java 3638 language specification requires that two objects that are equal 3639 according to the equals(Object) method must return the same integer 3640 result when the hashCode() method is called on them.) 3642 Parameters: 3644 obj Another channel binding to compare with. 3646 7.7. public class Oid 3648 This class represents Universal Object Identifiers (Oids) and their 3649 associated operations. 3651 Oids are hierarchically globally-interpretable identifiers used 3652 within the GSS-API framework to identify mechanisms and name formats. 3654 The structure and encoding of Oids is defined in ISOIEC-8824 and 3655 ISOIEC-8825. For example the Oid representation of Kerberos V5 3656 mechanism is "1.2.840.113554.1.2.2" 3658 The GSSName name class contains public static Oid objects 3659 representing the standard name types defined in GSS-API. 3661 7.7.1. Constructors 3663 public Oid(String strOid) throws GSSException 3665 Creates an Oid object from a string representation of its integer 3666 components (e.g. "1.2.840.113554.1.2.2"). 3668 Parameters: 3670 strOid The string representation for the oid. 3672 public Oid(InputStream derOid) throws GSSException 3674 Creates an Oid object from its DER encoding. This refers to the full 3675 encoding including tag and length. The structure and encoding of 3676 Oids is defined in ISOIEC-8824 and ISOIEC-8825. This method is 3677 identical in functionality to its byte array counterpart. 3679 Parameters: 3681 derOid Stream containing the DER encoded oid. 3683 public Oid(byte[] DEROid) throws GSSException 3685 Creates an Oid object from its DER encoding. This refers to the full 3686 encoding including tag and length. The structure and encoding of 3687 Oids is defined in ISOIEC-8824 and ISOIEC-8825. This method is 3688 identical in functionality to its byte array counterpart. 3690 Parameters: 3692 derOid Byte array storing a DER encoded oid. 3694 7.7.2. toString 3696 public String toString() 3698 Returns a string representation of the oid's integer components in 3699 dot separated notation (e.g. "1.2.840.113554.1.2.2"). 3701 7.7.3. equals 3703 public boolean equals(Object Obj) 3705 Returns "true" if the two Oid objects represent the same oid value. 3706 (Note that the Java language specification [JLS] requires that two 3707 objects that are equal according to the equals(Object) method must 3708 return the same integer result when the hashCode() method is called 3709 on them.) 3711 Parameters: 3713 obj Another Oid object to compare with. 3715 7.7.4. getDER 3717 public byte[] getDER() 3719 Returns the full ASN.1 DER encoding for this oid object, which 3720 includes the tag and length. 3722 7.7.5. containedIn 3724 public boolean containedIn(Oid[] oids) 3726 A utility method to test if an Oid object is contained within the 3727 supplied Oid object array. 3729 Parameters: 3731 oids An array of oids to search. 3733 7.8. public class GSSException extends Exception 3735 This exception is thrown whenever a fatal GSS-API error occurs 3736 including mechanism specific errors. It may contain both, the major 3737 and minor, GSS-API status codes. The mechanism implementers are 3738 responsible for setting appropriate minor status codes when throwing 3739 this exception. Aside from delivering the numeric error code(s) to 3740 the caller, this class performs the mapping from their numeric values 3741 to textual representations. All Java GSS-API methods are declared 3742 throwing this exception. 3744 All implementations are encouraged to use the Java 3745 internationalization techniques to provide local translations of the 3746 message strings. 3748 7.8.1. Static Constants 3750 All valid major GSS-API error code values are declared as constants 3751 in this class. 3753 public static final int BAD_BINDINGS 3755 Channel bindings mismatch error. The value of this constant is 1. 3757 public static final int BAD_MECH 3759 Unsupported mechanism requested error. The value of this constant is 3760 2 3762 public static final int BAD_NAME 3764 Invalid name provided error. The value of this constant is 3. 3766 public static final int BAD_NAMETYPE 3768 Name of unsupported type provided error. The value of this constant 3769 is 4. 3771 public static final int BAD_STATUS 3773 Invalid status code error - this is the default status value. The 3774 value of this constant is 5. 3776 public static final int BAD_MIC 3778 Token had invalid integrity check error. The value of this constant 3779 is 6. 3781 public static final int CONTEXT_EXPIRED 3783 Specified security context expired error. The value of this constant 3784 is 7. 3786 public static final int CREDENTIALS_EXPIRED 3788 Expired credentials detected error. The value of this constant is 8. 3790 public static final int DEFECTIVE_CREDENTIAL 3792 Defective credential error. The value of this constant is 9. 3794 public static final int DEFECTIVE_TOKEN 3796 Defective token error. The value of this constant is 10. 3798 public static final int FAILURE 3800 General failure, unspecified at GSS-API level. The value of this 3801 constant is 11. 3803 public static final int NO_CONTEXT 3805 Invalid security context error. The value of this constant is 12. 3807 public static final int NO_CRED 3809 Invalid credentials error. The value of this constant is 13. 3811 public static final int BAD_QOP 3813 Unsupported QOP value error. The value of this constant is 14. 3815 public static final int UNAUTHORIZED 3817 Operation unauthorized error. The value of this constant is 15. 3819 public static final int UNAVAILABLE 3821 Operation unavailable error. The value of this constant is 16. 3823 public static final int DUPLICATE_ELEMENT 3825 Duplicate credential element requested error. The value of this 3826 constant is 17. 3828 public static final int NAME_NOT_MN 3830 Name contains multi-mechanism elements error. The value of this 3831 constant is 18. 3833 public static final int DUPLICATE_TOKEN 3835 The token was a duplicate of an earlier token. This is contained in 3836 an exception only when detected during context establishment, in 3837 which case it is considered a fatal error. (Non-fatal supplementary 3838 codes are indicated via the MessageProp object.) The value of this 3839 constant is 19. 3841 public static final int OLD_TOKEN 3843 The token's validity period has expired. This is contained in an 3844 exception only when detected during context establishment, in which 3845 case it is considered a fatal error. (Non-fatal supplementary codes 3846 are indicated via the MessageProp object.) The value of this 3847 constant is 20. 3849 public static final int UNSEQ_TOKEN 3851 A later token has already been processed. This is contained in an 3852 exception only when detected during context establishment, in which 3853 case it is considered a fatal error. (Non-fatal supplementary codes 3854 are indicated via the MessageProp object.) The value of this 3855 constant is 21. 3857 public static final int GAP_TOKEN 3859 An expected per-message token was not received. This is contained in 3860 an exception only when detected during context establishment, in 3861 which case it is considered a fatal error. (Non-fatal supplementary 3862 codes are indicated via the MessageProp object.) The value of this 3863 constant is 22. 3865 7.8.2. Constructors 3867 public GSSException(int majorCode) 3869 Creates a GSSException object with a specified major code. 3871 Parameters: 3873 majorCode The GSS error code causing this exception to be thrown. 3875 public GSSException(int majorCode, int minorCode, String minorString) 3877 Creates a GSSException object with the specified major code, minor 3878 code, and minor code textual explanation. This constructor is to be 3879 used when the exception is originating from the security mechanism. 3880 It allows to specify the GSS code and the mechanism code. 3882 Parameters: 3884 majorCode The GSS error code causing this exception to be thrown. 3886 minorCode The mechanism error code causing this exception to be 3887 thrown. 3889 minorString The textual explanation of the mechanism error code. 3891 7.8.3. getMajor 3893 public int getMajor() 3895 Returns the major code representing the GSS error code that caused 3896 this exception to be thrown. 3898 7.8.4. getMinor 3900 public int getMinor() 3902 Returns the mechanism error code that caused this exception. The 3903 minor code is set by the underlying mechanism. Value of 0 indicates 3904 that mechanism error code is not set. 3906 7.8.5. getMajorString 3908 public String getMajorString() 3910 Returns a string explaining the GSS major error code causing this 3911 exception to be thrown. 3913 7.8.6. getMinorString 3915 public String getMinorString() 3917 Returns a string explaining the mechanism specific error code. null 3918 will be returned when no mechanism error code has been set. 3920 7.8.7. setMinor 3922 public void setMinor(int minorCode, String message) 3924 Used internally by the GSS-API implementation and the underlying 3925 mechanisms to set the minor code and its textual representation. 3927 Parameters: 3929 minorCode The mechanism specific error code. 3931 message A textual explanation of the mechanism error code. 3933 7.8.8. toString 3934 public String toString() 3936 Returns a textual representation of both the major and minor status 3937 codes. 3939 7.8.9. getMessage 3941 public String getMessage() 3943 Returns a detailed message of this exception. Overrides 3944 Throwable.getMessage. It is customary in Java to use this method to 3945 obtain exception information. 3947 8. Sample Applications 3949 8.1. Simple GSS Context Initiator 3951 import org.ietf.jgss.*; 3953 /** 3954 * This is a partial sketch for a simple client program that acts 3955 * as a GSS context initiator. It illustrates how to use the Java 3956 * bindings for the GSS-API specified in 3957 * Generic Security Service API Version 2 : Java bindings 3958 * 3959 * 3960 * This code sketch assumes the existence of a GSS-API 3961 * implementation that supports the mechanism that it will need 3962 * and is present as a library package (org.ietf.jgss) either as 3963 * part of the standard JRE or in the CLASSPATH the application 3964 * specifies. 3965 */ 3967 public class SimpleClient { 3969 private String serviceName; // name of peer (ie. server) 3970 private GSSCredential clientCred = null; 3971 private GSSContext context = null; 3972 private Oid mech; // underlying mechanism to use 3974 private GSSManager mgr = GSSManager.getInstance(); 3976 ... 3977 ... 3979 private void clientActions() { 3980 initializeGSS(); 3981 establishContext(); 3982 doCommunication(); 3983 } 3985 /** 3986 * Acquire credentials for the client. 3987 */ 3988 private void initializeGSS() { 3990 try { 3992 clientCred = mgr.createCredential(null /*default princ*/, 3993 GSSCredential.INDEFINITE_LIFETIME /* max lifetime */, 3994 mech /* mechanism to use */, 3995 GSSCredential.INITIATE_ONLY /* init context */); 3997 print("GSSCredential created for " + 3998 cred.getName().toString()); 3999 print("Credential lifetime (sec)=" + 4000 cred.getRemainingLifetime()); 4001 } catch (GSSException e) { 4002 print("GSS-API error in credential acquisition: " 4003 + e.getMessage()); 4004 ... 4005 ... 4006 } 4008 ... 4009 ... 4010 } 4012 /** 4013 * Does the security context establishment with the 4014 * server. 4015 */ 4016 private void establishContext() { 4018 byte[] inToken = new byte[0]; 4019 byte[] outToken = null; 4021 try { 4023 GSSName peer = mgr.createName(serviceName, 4024 GSSName.NT_HOSTBASED_SERVICE); 4025 context = mgr.createContext(peer, mech, gssCred, 4026 GSSContext.INDEFINITE_LIFETIME/*lifetime*/); 4028 // Will need to support confidentiality 4029 context.requestConf(true); 4031 while (!context.isEstablished()) { 4033 outToken = context.initSecContext(inToken, 0, 4034 inToken.length); 4036 if (outToken != null) 4037 writeGSSToken(outToken); 4039 if (!context.isEstablished()) 4040 inToken = readGSSToken(); 4041 } 4043 GSSName peer = context.getSrcName(); 4044 print("Security context established with " + peer + 4045 " using underlying mechanism " + mech.toString()); 4046 } catch (GSSException e) { 4047 print("GSS-API error during context establishment: " 4048 + e.getMessage()); 4049 ... 4050 ... 4051 } 4053 ... 4054 ... 4055 } 4057 /** 4058 * Sends some data to the server and reads back the 4059 * response. 4060 */ 4061 private void doCommunication() { 4062 byte[] inToken = null; 4063 byte[] outToken = null; 4064 byte[] buffer; 4066 // Container for multiple input-output arguments to and 4067 // from the per-message routines (e.g., wrap/unwrap). 4068 MessageProp messgInfo = new MessageProp(); 4070 try { 4072 /* 4073 * Now send some bytes to the server to be 4074 * processed. They will be integrity protected but 4075 * not encrypted for privacy. 4076 */ 4078 buffer = readFromFile(); 4080 // Set privacy to false and use the default QOP 4081 messgInfo.setPrivacy(false); 4083 outToken = context.wrap(buffer, 0, buffer.length, 4084 messgInfo); 4086 writeGSSToken(outToken); 4088 /* 4089 * Now read the response from the server. 4090 */ 4092 inToken = readGSSToken(); 4093 buffer = context.unwrap(inToken, 0, 4094 inToken.length, messgInfo); 4095 // All ok if no exception was thrown! 4097 GSSName peer = context.getSrcName(); 4099 print("Message from " + peer.toString() 4100 + " arrived."); 4101 print("Was it encrypted? " + 4102 messgInfo.getPrivacy()); 4103 print("Duplicate Token? " + 4104 messgInfo.isDuplicateToken()); 4105 print("Old Token? " + 4106 messgInfo.isOldToken()); 4107 print("Unsequenced Token? " + 4108 messgInfo.isUnseqToken()); 4109 print("Gap Token? " + 4110 messgInfo.isGapToken()); 4112 ... 4113 ... 4115 } catch (GSSException e) { 4116 print("GSS-API error in per-message calls: " 4117 + e.getMessage()); 4118 ... 4119 ... 4121 } 4123 ... 4125 ... 4127 } // end of doCommunication method 4129 ... 4130 ... 4132 } // end of class SimpleClient 4134 8.2. Simple GSS Context Acceptor 4136 import org.ietf.jgss.*; 4138 /** 4139 * This is a partial sketch for a simple server program that acts 4140 * as a GSS context acceptor. It illustrates how to use the Java 4141 * bindings for the GSS-API specified in 4142 * Generic Security Service API Version 2 : Java bindings 4143 * 4144 * This code sketch assumes the existence of a GSS-API 4145 * implementation that supports the mechanisms that it will need 4146 * and is present as a library package (org.ietf.jgss) either as 4147 * part of the standard JRE or in the CLASSPATH the application 4148 * specifies. 4149 */ 4151 import org.ietf.jgss.*; 4153 public class SimpleServer { 4155 private String serviceName; 4156 private GSSName name; 4157 private GSSCredential cred; 4159 private GSSManager mgr; 4161 ... 4162 ... 4164 /** 4165 * Wait for client connections, establish security contexts 4166 * and provide service. 4167 */ 4168 private void loop() { 4170 ... 4171 ... 4173 mgr = GSSManager.getInstance(); 4174 name = mgr.createName(serviceName, 4175 GSSName.NT_HOSTBASED_SERVICE); 4177 cred = mgr.createCredential(name, 4178 GSSCredential.INDEFINITE_LIFETIME, 4179 null, 4180 GSSCredential.ACCEPT_ONLY); 4182 // Loop infinitely 4183 while (true) { 4185 Socket s = serverSock.accept(); 4187 // Start a new thread to serve this connection 4188 Thread serverThread = new ServerThread(s); 4189 serverThread.start(); 4191 } 4192 } 4194 /** 4195 * Inner class ServerThread whose run() method provides the 4196 * secure service to a connection. 4197 */ 4199 private class ServerThread extends Thread { 4201 ... 4202 ... 4204 /** 4205 * Deals with the connection from one client. It also 4206 * handles all GSSException's thrown while talking to 4207 * this client. 4208 */ 4209 public void run() { 4211 byte[] inToken = null; 4212 byte[] outToken = null; 4213 byte[] buffer; 4215 GSSName peer; 4217 // Container for multiple input-output arguments to 4218 // and from the per-message routines 4219 // (i.e. wrap/unwrap). 4220 MessageProp supplInfo = new MessageProp(); 4221 GSSContext secContext = null; 4223 try { 4225 // Now do the context establishment loop 4227 GSSContext context = mgr.createContext(cred); 4229 while (!context.isEstablished()) { 4231 inToken = readGSSToken(); 4233 outToken = context.acceptSecContext(inToken, 4234 0, inToken.length); 4236 if (outToken != null) 4237 writeGSSToken(outToken); 4239 } 4241 // SimpleServer wants confidentiality to be 4242 // available. Check for it. 4243 if (!context.getConfState()){ 4244 ... 4245 ... 4246 } 4248 GSSName peer = context.getSrcName(); 4249 Oid mech = context.getMech(); 4250 print("Security context established with " + 4251 peer.toString() + 4252 " using underlying mechanism " + 4253 mech.toString() + 4254 " from Provider " + 4255 context.getProvider().getName()); 4257 // Now read the bytes sent by the client to be 4258 // processed. 4259 inToken = readGSSToken(); 4261 // Unwrap the message 4262 buffer = context.unwrap(inToken, 0, 4263 inToken.length, supplInfo); 4264 // All ok if no exception was thrown! 4266 // Print other supplementary per-message status 4267 // information 4269 print("Message from " + 4270 peer.toString() + " arrived."); 4271 print("Was it encrypted? " + 4272 supplInfo.getPrivacy()); 4273 print("Duplicate Token? " + 4274 supplInfo.isDuplicateToken()); 4275 print("Old Token? " + supplInfo.isOldToken()); 4276 print("Unsequenced Token? " + 4277 supplInfo.isUnseqToken()); 4278 print("Gap Token? " + supplInfo.isGapToken()); 4280 /* 4281 * Now process the bytes and send back an 4282 * encrypted response. 4283 */ 4285 buffer = serverProcess(buffer); 4287 // Encipher it and send it across 4289 supplInfo.setPrivacy(true); // privacy requested 4290 supplInfo.setQOP(0); // default QOP 4291 outToken = context.wrap(buffer, 0, buffer.length, 4292 supplInfo); 4293 writeGSSToken(outToken); 4295 } catch (GSSException e) { 4296 print("GSS-API Error: " + e.getMessage()); 4297 // Alternatively, could call e.getMajorMessage() 4298 // and e.getMinorMessage() 4299 print("Abandoning security context."); 4301 ... 4302 ... 4304 } 4306 ... 4307 ... 4309 } // end of run method in ServerThread 4311 } // end of inner class ServerThread 4313 ... 4314 ... 4316 } // end of class SimpleServer 4318 9. Security Considerations 4320 The Java language security model allows platform providers to have 4321 policy based fine-grained access control over any resource that an 4322 application wants. When using a Java security manager (such as, but 4323 not limited to, the case of applets running in browsers) the 4324 application code is in a sandbox by default. 4326 Administrators of the platform JRE determine what permissions, if 4327 any, are to be given to source from different codebases. Thus the 4328 administrator has to be aware of any special requirements that the 4329 GSS provider might have for system resources. For instance, a 4330 Kerberos provider might wish to make a network connection to the KDC 4331 to obtain initial credentials. This would not be allowed under the 4332 sandbox unless the administrator had granted permissions for this. 4333 Also note that this granting and checking of permissions happens 4334 transparently to the application and is outside the scope of this 4335 document. 4337 The Java language allows administrators to pre-configure a list of 4338 security service providers in the /lib/security/java.security 4339 file. At runtime, the system approaches these providers in order of 4340 preference when looking for security related services. Applications 4341 have a means to modify this list through methods in the "Security" 4342 class in the "java.security" package. However, since these 4343 modifications would be visible in the entire JVM and thus affect all 4344 code executing in it, this operation is not available in the sandbox 4345 and requires special permissions to perform. Thus when a GSS 4346 application has special needs that are met by a particular security 4347 provider, it has two choices: 4349 1) To install the provider on a JVM wide basis using the 4350 java.security.Security class and then depend on the system to find 4351 the right provider automatically when the need arises. (This would 4352 require the application to be granted a "insertProvider 4353 SecurityPermission".) 4355 2) To pass an instance of the provider to the local instance of 4356 GSSManager so that only factory calls going through that GSSManager 4357 use the desired provider. (This would not require any permissions.) 4359 10. IANA Considerations 4361 This document has no IANA considerations currently. 4363 11. Acknowledgments 4365 This proposed API leverages earlier work performed by the IETF's CAT 4366 WG as outlined in both RFC 2743 [GSSAPIv2-UPDATE] and RFC 2744 4367 [GSSAPI-Cbind]. Many conceptual definitions, implementation 4368 directions, and explanations have been included from these documents. 4370 We would like to thank Mike Eisler, Lin Ling, Ram Marti, Michael 4371 Saltz and other members of Sun's development team for their helpful 4372 input, comments and suggestions. 4374 We would also like to thank Joe Salowey, and Michael Smith for many 4375 insightful ideas and suggestions that have contributed to this 4376 document. 4378 12. Changes since RFC 2853 4380 This document has following changes: 4382 1) Major GSS Status Code Constant Values 4384 RFC 2853 listed all the GSS status code values in two different 4385 sections: section 4.12.1 defined numeric values for them, and section 4386 6.8.1 defined them as static constants in the GSSException class 4387 without assigning any values. Due to an inconsistent ordering 4388 between these two sections, all of the GSS major status codes 4389 resulted in misalignment, and a subsequent disagreement between 4390 deployed implementations. 4392 This document defines the numeric values of the GSS status codes in 4393 both sections, while maintaining the original ordering from section 4394 6.8.1 of RFC 2853 [RFC2853], and obsoletes the GSS status code values 4395 defined in 4.12.1. The relevant sections in this document are 4396 sections 5.12.1 and 7.8.1. 4398 2) GSS Credential Usage Constant Values 4400 RFC 2853 section 6.3.2 defines static constants for the GSSCredential 4401 usage flags. However, the values of these constants were not defined 4402 anywhere in RFC 2853 [RFC2853]. 4404 This document defines the credential usage values in section 7.3.2. 4405 The original ordering of these values from section 6.3.2 of RFC 2853 4406 [RFC2853] is maintained. 4408 3) GSS Host-Based Service Name 4409 RFC 2853 [RFC2853] section 6.2.2 defines the static constant for the 4410 GSS host-based service OID NT_HOSTBASED_SERVICE, using a deprecated 4411 OID value. 4413 This document updates the NT_HOSTBASED_SERVICE OID value in section 4414 7.2.2 to be consistent with the C-bindings in RFC 2744 4415 [GSSAPI-Cbind]. 4417 13. References 4419 13.1. Normative References 4421 [GSSAPI-Cbind] 4422 Wray, J., "Generic Security Service API Version 2 : 4423 C-bindings", RFC 2744, January 2000. 4425 [GSSAPIv2-UPDATE] 4426 Linn, J., "Generic Security Service Application Program 4427 Interface, Version 2, Update 1", RFC 2743, January 2000. 4429 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism", 4430 RFC 2025, October 1996. 4432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4433 Requirement Levels", BCP 14, RFC 2119, March 1997. 4435 [RFC2853] Kabat, J. and M. Upadhyay, "Generic Security Service 4436 Application Program Interface : Java Bindings", RFC 2853, 4437 June 2000. 4439 [RFC4121] Zhu, L. and S. Hartman, "The Kerberos Version 5 Generic 4440 Security Service Application Program Interface (GSS-API) 4441 Mechanism: Version 2", RFC 4121, July 2005. 4443 13.2. Informative References 4445 [JLS] Gosling, J., "The Java Language Specification", 4446 JLS langspec. 4448 Authors' Addresses 4450 Mayank D. Upadhyay 4451 Google Inc. 4452 1600 Amphitheatre Parkway 4453 Mountain View, CA 94043 4454 USA 4455 Email: mayank+ietf-2853@google.com 4457 Seema Malkani 4458 Sun Microsystems, Inc. 4459 4140 Network Circle 4460 Santa Clara, CA 95054 4461 USA 4463 Email: Seema.Malkani@sun.com