idnits 2.17.1 draft-ietf-kitten-rfc2853bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4448. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4454. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 42 instances of lines with control characters in the document. ** The abstract seems to contain references ([SPKM], [KERBV5], [JGSS], [GSSAPIv2-UPDATE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 316 has weird spacing: '...ment of a sec...' == Line 378 has weird spacing: '...rmation to en...' == Line 1202 has weird spacing: '...ith the major...' == Line 4007 has weird spacing: '...chanism to us...' == 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 (January 27, 2006) is 6663 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) == Missing Reference: 'JGSS' is mentioned on line 257, but not defined == Missing Reference: 'GSSAPI-C' is mentioned on line 259, but not defined -- Looks like a reference, but probably isn't: '0' on line 4031 == Unused Reference: 'RFC2853' is defined on line 4389, but no explicit reference was found in the text == Unused Reference: 'GSSAPIv2' is defined on line 4393, but no explicit reference was found in the text == Unused Reference: 'GSSAPI-Cbind' is defined on line 4401, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2853 (Obsoleted by RFC 5653) ** Obsolete normative reference: RFC 2078 (ref. 'GSSAPIv2') (Obsoleted by RFC 2743) Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 10 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 Expires: July 31, 2006 S. Malkani 5 Sun Microsystems 6 January 27, 2006 8 Generic Security Service API Version 2 : Java Bindings Update 9 draft-ietf-kitten-rfc2853bis-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 31, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 The Generic Security Services Application Program Interface (GSS-API) 43 offers application programmers uniform access to security services 44 atop a variety of underlying cryptographic mechanisms. This document 45 updates the Java bindings for the GSS-API that are specified in RFC 46 2853 [JGSS]. This document obsoletes RFC 2853 [JGSS] by making 47 specific and incremental clarifications and corrections to it in 48 response to identification of transcription errors and implementation 49 experience. The only note-worthy changes are in sections 4.12.1, 50 6.3.2, and 6.8.1 of RFC 2853 [JGSS], which are replaced by the 51 sections 5.12.1, 7.3.2, and 7.8.1 of this document, where numerical 52 constants were either added or modified. 54 The GSS-API is described at a language independent conceptual level 55 in RFC 2743 [GSSAPIv2-UPDATE]. The GSS-API allows a caller 56 application to authenticate a principal identity, to delegate rights 57 to a peer, and to apply security services such as confidentiality and 58 integrity on a per-message basis. Examples of security mechanisms 59 defined for GSS-API are The Simple Public-Key GSS-API Mechanism 60 [SPKM] and The Kerberos Version 5 GSS-API Mechanism [KERBV5]. 62 Table of Contents 64 1. Conventions Used in This Document . . . . . . . . . . . . . 6 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3. GSS-API Operational Paradigm . . . . . . . . . . . . . . . . 8 67 4. Additional Controls . . . . . . . . . . . . . . . . . . . . 10 68 4.1 Delegation . . . . . . . . . . . . . . . . . . . . . . . . 11 69 4.2 Mutual Authentication . . . . . . . . . . . . . . . . . . 12 70 4.3 Replay and Out-of-Sequence Detection . . . . . . . . . . . 12 71 4.4 Anonymous Authentication . . . . . . . . . . . . . . . . . 13 72 4.5 Confidentiality . . . . . . . . . . . . . . . . . . . . . 14 73 4.6 Inter-process Context Transfer . . . . . . . . . . . . . . 14 74 4.7 The Use of Incomplete Contexts . . . . . . . . . . . . . . 15 75 5. Calling Conventions . . . . . . . . . . . . . . . . . . . . 16 76 5.1 Package Name . . . . . . . . . . . . . . . . . . . . . . . 16 77 5.2 Provider Framework . . . . . . . . . . . . . . . . . . . . 16 78 5.3 Integer Types . . . . . . . . . . . . . . . . . . . . . . 17 79 5.4 Opaque Data Types . . . . . . . . . . . . . . . . . . . . 17 80 5.5 Strings . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 5.6 Object Identifiers . . . . . . . . . . . . . . . . . . . . 17 82 5.7 Object Identifier Sets . . . . . . . . . . . . . . . . . . 18 83 5.8 Credentials . . . . . . . . . . . . . . . . . . . . . . . 18 84 5.9 Contexts . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 5.10 Authentication Tokens . . . . . . . . . . . . . . . . . 20 86 5.11 Interprocess Tokens . . . . . . . . . . . . . . . . . . 21 87 5.12 Error Reporting . . . . . . . . . . . . . . . . . . . . 21 88 5.12.1 GSS Status Codes . . . . . . . . . . . . . . . . . . 21 89 5.12.2 Mechanism-Specific Status Codes . . . . . . . . . . 24 90 5.12.3 Supplementary Status Codes . . . . . . . . . . . . . 24 91 5.13 Names . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 5.14 Channel Bindings . . . . . . . . . . . . . . . . . . . . 27 93 5.15 Stream Objects . . . . . . . . . . . . . . . . . . . . . 28 94 5.16 Optional Parameters . . . . . . . . . . . . . . . . . . 28 95 6. Introduction to GSS-API Classes and Interfaces . . . . . . . 30 96 6.1 GSSManager class . . . . . . . . . . . . . . . . . . . . . 30 97 6.2 GSSName interface . . . . . . . . . . . . . . . . . . . . 31 98 6.3 GSSCredential interface . . . . . . . . . . . . . . . . . 31 99 6.4 GSSContext interface . . . . . . . . . . . . . . . . . . . 32 100 6.5 MessageProp class . . . . . . . . . . . . . . . . . . . . 34 101 6.6 GSSException class . . . . . . . . . . . . . . . . . . . . 34 102 6.7 Oid class . . . . . . . . . . . . . . . . . . . . . . . . 34 103 6.8 ChannelBinding class . . . . . . . . . . . . . . . . . . . 35 104 7. Detailed GSS-API Class Description . . . . . . . . . . . . . 36 105 7.1 public abstract class GSSManager . . . . . . . . . . . . . 36 106 7.1.1 Example Code . . . . . . . . . . . . . . . . . . . . . 37 107 7.1.2 getInstance . . . . . . . . . . . . . . . . . . . . . 37 108 7.1.3 getMechs . . . . . . . . . . . . . . . . . . . . . . . 37 109 7.1.4 getNamesForMech . . . . . . . . . . . . . . . . . . . 38 110 7.1.5 getMechsForName . . . . . . . . . . . . . . . . . . . 38 111 7.1.6 createName . . . . . . . . . . . . . . . . . . . . . . 38 112 7.1.7 createName . . . . . . . . . . . . . . . . . . . . . . 39 113 7.1.8 createName . . . . . . . . . . . . . . . . . . . . . . 39 114 7.1.9 createName . . . . . . . . . . . . . . . . . . . . . . 40 115 7.1.10 createCredential . . . . . . . . . . . . . . . . . . 40 116 7.1.11 createCredential . . . . . . . . . . . . . . . . . . 41 117 7.1.12 createCredential . . . . . . . . . . . . . . . . . . 41 118 7.1.13 createContext . . . . . . . . . . . . . . . . . . . 42 119 7.1.14 createContext . . . . . . . . . . . . . . . . . . . 42 120 7.1.15 createContext . . . . . . . . . . . . . . . . . . . 43 121 7.1.16 addProviderAtFront . . . . . . . . . . . . . . . . . 43 122 7.1.17 Example Code . . . . . . . . . . . . . . . . . . . . 44 123 7.1.18 addProviderAtEnd . . . . . . . . . . . . . . . . . . 45 124 7.1.19 Example Code . . . . . . . . . . . . . . . . . . . . 45 125 7.2 public interface GSSName . . . . . . . . . . . . . . . . . 46 126 7.2.1 Example Code . . . . . . . . . . . . . . . . . . . . . 46 127 7.2.2 Static Constants . . . . . . . . . . . . . . . . . . . 47 128 7.2.3 equals . . . . . . . . . . . . . . . . . . . . . . . . 48 129 7.2.4 equals . . . . . . . . . . . . . . . . . . . . . . . . 48 130 7.2.5 canonicalize . . . . . . . . . . . . . . . . . . . . . 49 131 7.2.6 export . . . . . . . . . . . . . . . . . . . . . . . . 49 132 7.2.7 toString . . . . . . . . . . . . . . . . . . . . . . . 49 133 7.2.8 getStringNameType . . . . . . . . . . . . . . . . . . 50 134 7.2.9 isAnonymous . . . . . . . . . . . . . . . . . . . . . 50 135 7.2.10 isMN . . . . . . . . . . . . . . . . . . . . . . . . 50 136 7.3 public interface GSSCredential implements Cloneable . . . 50 137 7.3.1 Example Code . . . . . . . . . . . . . . . . . . . . . 51 138 7.3.2 Static Constants . . . . . . . . . . . . . . . . . . . 52 139 7.3.3 dispose . . . . . . . . . . . . . . . . . . . . . . . 52 140 7.3.4 getName . . . . . . . . . . . . . . . . . . . . . . . 52 141 7.3.5 getName . . . . . . . . . . . . . . . . . . . . . . . 52 142 7.3.6 getRemainingLifetime . . . . . . . . . . . . . . . . . 53 143 7.3.7 getRemainingInitLifetime . . . . . . . . . . . . . . . 53 144 7.3.8 getRemainingAcceptLifetime . . . . . . . . . . . . . . 53 145 7.3.9 getUsage . . . . . . . . . . . . . . . . . . . . . . . 54 146 7.3.10 getUsage . . . . . . . . . . . . . . . . . . . . . . 54 147 7.3.11 getMechs . . . . . . . . . . . . . . . . . . . . . . 54 148 7.3.12 add . . . . . . . . . . . . . . . . . . . . . . . . 54 149 7.3.13 equals . . . . . . . . . . . . . . . . . . . . . . . 55 150 7.4 public interface GSSContext . . . . . . . . . . . . . . . 55 151 7.4.1 Example Code . . . . . . . . . . . . . . . . . . . . . 56 152 7.4.2 Static Constants . . . . . . . . . . . . . . . . . . . 58 153 7.4.3 initSecContext . . . . . . . . . . . . . . . . . . . . 58 154 7.4.4 Example Code . . . . . . . . . . . . . . . . . . . . . 60 155 7.4.5 initSecContext . . . . . . . . . . . . . . . . . . . . 60 156 7.4.6 Example Code . . . . . . . . . . . . . . . . . . . . . 61 157 7.4.7 acceptSecContext . . . . . . . . . . . . . . . . . . . 62 158 7.4.8 Example Code . . . . . . . . . . . . . . . . . . . . . 63 159 7.4.9 acceptSecContext . . . . . . . . . . . . . . . . . . . 64 160 7.4.10 Example Code . . . . . . . . . . . . . . . . . . . . 64 161 7.4.11 isEstablished . . . . . . . . . . . . . . . . . . . 65 162 7.4.12 dispose . . . . . . . . . . . . . . . . . . . . . . 65 163 7.4.13 getWrapSizeLimit . . . . . . . . . . . . . . . . . . 66 164 7.4.14 wrap . . . . . . . . . . . . . . . . . . . . . . . . 66 165 7.4.15 wrap . . . . . . . . . . . . . . . . . . . . . . . . 67 166 7.4.16 unwrap . . . . . . . . . . . . . . . . . . . . . . . 68 167 7.4.17 unwrap . . . . . . . . . . . . . . . . . . . . . . . 69 168 7.4.18 getMIC . . . . . . . . . . . . . . . . . . . . . . . 70 169 7.4.19 getMIC . . . . . . . . . . . . . . . . . . . . . . . 70 170 7.4.20 verifyMIC . . . . . . . . . . . . . . . . . . . . . 71 171 7.4.21 verifyMIC . . . . . . . . . . . . . . . . . . . . . 72 172 7.4.22 export . . . . . . . . . . . . . . . . . . . . . . . 72 173 7.4.23 requestMutualAuth . . . . . . . . . . . . . . . . . 73 174 7.4.24 requestReplayDet . . . . . . . . . . . . . . . . . . 73 175 7.4.25 requestSequenceDet . . . . . . . . . . . . . . . . . 74 176 7.4.26 requestCredDeleg . . . . . . . . . . . . . . . . . . 74 177 7.4.27 requestAnonymity . . . . . . . . . . . . . . . . . . 74 178 7.4.28 requestConf . . . . . . . . . . . . . . . . . . . . 75 179 7.4.29 requestInteg . . . . . . . . . . . . . . . . . . . . 75 180 7.4.30 requestLifetime . . . . . . . . . . . . . . . . . . 75 181 7.4.31 setChannelBinding . . . . . . . . . . . . . . . . . 75 182 7.4.32 getCredDelegState . . . . . . . . . . . . . . . . . 76 183 7.4.33 getMutualAuthState . . . . . . . . . . . . . . . . . 76 184 7.4.34 getReplayDetState . . . . . . . . . . . . . . . . . 76 185 7.4.35 getSequenceDetState . . . . . . . . . . . . . . . . 76 186 7.4.36 getAnonymityState . . . . . . . . . . . . . . . . . 77 187 7.4.37 isTransferable . . . . . . . . . . . . . . . . . . . 77 188 7.4.38 isProtReady . . . . . . . . . . . . . . . . . . . . 77 189 7.4.39 getConfState . . . . . . . . . . . . . . . . . . . . 77 190 7.4.40 getIntegState . . . . . . . . . . . . . . . . . . . 77 191 7.4.41 getLifetime . . . . . . . . . . . . . . . . . . . . 77 192 7.4.42 getSrcName . . . . . . . . . . . . . . . . . . . . . 78 193 7.4.43 getTargName . . . . . . . . . . . . . . . . . . . . 78 194 7.4.44 getMech . . . . . . . . . . . . . . . . . . . . . . 78 195 7.4.45 getDelegCred . . . . . . . . . . . . . . . . . . . . 78 196 7.4.46 isInitiator . . . . . . . . . . . . . . . . . . . . 78 197 7.5 public class MessageProp . . . . . . . . . . . . . . . . . 78 198 7.5.1 Constructors . . . . . . . . . . . . . . . . . . . . . 79 199 7.5.2 getQOP . . . . . . . . . . . . . . . . . . . . . . . . 79 200 7.5.3 getPrivacy . . . . . . . . . . . . . . . . . . . . . . 80 201 7.5.4 getMinorStatus . . . . . . . . . . . . . . . . . . . . 80 202 7.5.5 getMinorString . . . . . . . . . . . . . . . . . . . . 80 203 7.5.6 setQOP . . . . . . . . . . . . . . . . . . . . . . . . 80 204 7.5.7 setPrivacy . . . . . . . . . . . . . . . . . . . . . . 80 205 7.5.8 isDuplicateToken . . . . . . . . . . . . . . . . . . . 80 206 7.5.9 isOldToken . . . . . . . . . . . . . . . . . . . . . . 81 207 7.5.10 isUnseqToken . . . . . . . . . . . . . . . . . . . . 81 208 7.5.11 isGapToken . . . . . . . . . . . . . . . . . . . . . 81 209 7.5.12 setSupplementaryStates . . . . . . . . . . . . . . . 81 210 7.6 public class ChannelBinding . . . . . . . . . . . . . . . 82 211 7.6.1 Constructors . . . . . . . . . . . . . . . . . . . . . 82 212 7.6.2 getInitiatorAddress . . . . . . . . . . . . . . . . . 83 213 7.6.3 getAcceptorAddress . . . . . . . . . . . . . . . . . . 83 214 7.6.4 getApplicationData . . . . . . . . . . . . . . . . . . 83 215 7.6.5 equals . . . . . . . . . . . . . . . . . . . . . . . . 83 216 7.7 public class Oid . . . . . . . . . . . . . . . . . . . . . 83 217 7.7.1 Constructors . . . . . . . . . . . . . . . . . . . . . 84 218 7.7.2 toString . . . . . . . . . . . . . . . . . . . . . . . 84 219 7.7.3 equals . . . . . . . . . . . . . . . . . . . . . . . . 85 220 7.7.4 getDER . . . . . . . . . . . . . . . . . . . . . . . . 85 221 7.7.5 containedIn . . . . . . . . . . . . . . . . . . . . . 85 222 7.8 public class GSSException extends Exception . . . . . . . 85 223 7.8.1 Static Constants . . . . . . . . . . . . . . . . . . . 86 224 7.8.2 Constructors . . . . . . . . . . . . . . . . . . . . . 88 225 7.8.3 getMajor . . . . . . . . . . . . . . . . . . . . . . . 89 226 7.8.4 getMinor . . . . . . . . . . . . . . . . . . . . . . . 89 227 7.8.5 getMajorString . . . . . . . . . . . . . . . . . . . . 89 228 7.8.6 getMinorString . . . . . . . . . . . . . . . . . . . . 89 229 7.8.7 setMinor . . . . . . . . . . . . . . . . . . . . . . . 89 230 7.8.8 toString . . . . . . . . . . . . . . . . . . . . . . . 89 231 7.8.9 getMessage . . . . . . . . . . . . . . . . . . . . . . 90 232 8. Sample Applications . . . . . . . . . . . . . . . . . . . . 91 233 8.1 Simple GSS Context Initiator . . . . . . . . . . . . . . . 91 234 8.2 Simple GSS Context Acceptor . . . . . . . . . . . . . . . 94 235 9. Security Considerations . . . . . . . . . . . . . . . . . . 99 236 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 100 237 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 100 238 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 101 239 Intellectual Property and Copyright Statements . . . . . . . 102 241 1. Conventions Used in This Document 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in [RFC2119]. 247 2. Introduction 249 This document specifies Java language bindings for the Generic 250 Security Services Application Programming Interface Version 2 (GSS- 251 API). GSS-API Version 2 is described in a language independent 252 format in RFC 2743 [GSSAPIv2-UPDATE]. The GSS-API allows a caller 253 application to authenticate a principal identity, to delegate rights 254 to a peer, and to apply security services such as confidentiality and 255 integrity on a per-message basis. 257 This document and its predecessor RFC 2853 [JGSS] leverage the work 258 done by the WG in the area of RFC 2743 [GSSAPIv2-UPDATE] and the 259 C-bindings RFC 2744 [GSSAPI-C]. Whenever appropriate, text has been 260 used from the C-bindings RFC 2744 to explain generic concepts and 261 provide direction to the implementors. 263 The design goals of this API have been to satisfy all the 264 functionality defined in RFC 2743 and to provide these services in an 265 object oriented method. The specification also aims to satisfy the 266 needs of both types of Java application developers, those who would 267 like access to a "system-wide" GSS-API implementation, as well as 268 those who would want to provide their own "custom" implementation. 270 A "system-wide" implementation is one that is available to all 271 applications in the form of a library package. It may be the 272 standard package in the Java runtime environment (JRE) being used or 273 it may be additionally installed and accessible to any application 274 via the CLASSPATH. 276 A "custom" implementation of the GSS-API, on the other hand, is one 277 that would, in most cases, be bundled with the application during 278 distribution. It is expected that such an implementation would be 279 meant to provide for some particular need of the application, such as 280 support for some specific mechanism. 282 The design of this API also aims to provide a flexible framework to 283 add and manage GSS-API mechanisms. GSS-API leverages the Java 284 Cryptography Architecture (JCA) provider model to support the 285 plugability of mechanisms. Mechanisms can be added on a "system- 286 wide" basis, where all users of the framework will have them 287 available. The specification also allows for the addition of 288 mechanisms per-instance of the GSS-API. 290 Lastly, this specification presents an API that will naturally fit 291 within the operation environment of the Java platform. Readers are 292 assumed to be familiar with both the GSS-API and the Java platform. 294 3. GSS-API Operational Paradigm 296 The Generic Security Service Application Programming Interface 297 Version 2 [GSSAPIv2-UPDATE] defines a generic security API to calling 298 applications. It allows a communicating application to authenticate 299 the user associated with another application, to delegate rights to 300 another application, and to apply security services such as 301 confidentiality and integrity on a per-message basis. 303 There are four stages to using GSS-API: 305 1) The application acquires a set of credentials with which it may 306 prove its identity to other processes. The application's credentials 307 vouch for its global identity, which may or may not be related to any 308 local username under which it may be running. 310 2) A pair of communicating applications establish a joint security 311 context using their credentials. The security context encapsulates 312 shared state information, which is required in order that per-message 313 security services may be provided. Examples of state information 314 that might be shared between applications as part of a security 315 context are cryptographic keys, and message sequence numbers. As 316 part of the establishment of a security context, the context 317 initiator is authenticated to the responder, and may require that the 318 responder is authenticated back to the initiator. The initiator may 319 optionally give the responder the right to initiate further security 320 contexts, acting as an agent or delegate of the initiator. This 321 transfer of rights is termed "delegation", and is achieved by 322 creating a set of credentials, similar to those used by the 323 initiating application, but which may be used by the responder. 325 A GSSContext object is used to establish and maintain the shared 326 information that makes up the security context. Certain GSSContext 327 methods will generate a token, which applications treat as 328 cryptographically protected, opaque data. The caller of such 329 GSSContext method is responsible for transferring the token to the 330 peer application, encapsulated if necessary in an application-to- 331 application protocol. On receipt of such a token, the peer 332 application should pass it to a corresponding GSSContext method which 333 will decode the token and extract the information, updating the 334 security context state information accordingly. 336 3) Per-message services are invoked on a GSSContext object to apply 337 either: 339 integrity and data origin authentication, or 341 confidentiality, integrity and data origin authentication 342 to application data, which are treated by GSS-API as arbitrary octet- 343 strings. An application transmitting a message that it wishes to 344 protect will call the appropriate GSSContext method (getMIC or wrap) 345 to apply protection, and send the resulting token to the receiving 346 application. The receiver will pass the received token (and, in the 347 case of data protected by getMIC, the accompanying message-data) to 348 the corresponding decoding method of the GSSContext interface 349 (verifyMIC or unwrap) to remove the protection and validate the data. 351 4) At the completion of a communications session (which may extend 352 across several transport connections), each application uses a 353 GSSContext method to invalidate the security context and release any 354 system or cryptographic resources held. Multiple contexts may also 355 be used (either successively or simultaneously) within a single 356 communications association, at the discretion of the applications. 358 4. Additional Controls 360 This section discusses the optional services that a context initiator 361 may request of the GSS-API before the context establishment. Each of 362 these services is requested by calling the appropriate mutator method 363 in the GSSContext object before the first call to init is performed. 364 Only the context initiator can request context flags. 366 The optional services defined are: 368 Delegation The (usually temporary) transfer of rights from 369 initiator to acceptor, enabling the acceptor to authenticate 370 itself as an agent of the initiator. 372 Mutual Authentication In addition to the initiator authenticating 373 its identity to the context acceptor, the context acceptor should 374 also authenticate itself to the initiator. 376 Replay Detection In addition to providing message integrity 377 services, GSSContext per-message operations of getMIC and wrap 378 should include message numbering information to enable verifyMIC 379 and unwrap to detect if a message has been duplicated. 381 Out-of-Sequence Detection In addition to providing message 382 integrity services, GSSContext per-message operations (getMIC and 383 wrap) should include message sequencing information to enable 384 verifyMIC and unwrap to detect if a message has been received out 385 of sequence. 387 Anonymous Authentication The establishment of the security context 388 should not reveal the initiator's identity to the context 389 acceptor. 391 Some mechanisms may not support all optional services, and some 392 mechanisms may only support some services in conjunction with others. 393 The GSSContext interface offers query methods to allow the 394 verification by the calling application of which services will be 395 available from the context when the establishment phase is complete. 396 In general, if the security mechanism is capable of providing a 397 requested service, it should do so even if additional services must 398 be enabled in order to provide the requested service. If the 399 mechanism is incapable of providing a requested service, it should 400 proceed without the service leaving the application to abort the 401 context establishment process if it considers the requested service 402 to be mandatory. 404 Some mechanisms may specify that support for some services is 405 optional, and that implementors of the mechanism need not provide it. 407 This is most commonly true of the confidentiality service, often 408 because of legal restrictions on the use of data-encryption, but may 409 apply to any of the services. Such mechanisms are required to send 410 at least one token from acceptor to initiator during context 411 establishment when the initiator indicates a desire to use such a 412 service, so that the initiating GSS-API can correctly indicate 413 whether the service is supported by the acceptor's GSS-API. 415 4.1 Delegation 417 The GSS-API allows delegation to be controlled by the initiating 418 application via the requestCredDeleg method before the first call to 419 init has been issued. Some mechanisms do not support delegation, and 420 for such mechanisms attempts by an application to enable delegation 421 are ignored. 423 The acceptor of a security context, for which the initiator enabled 424 delegation, can check if delegation was enabled by using the 425 getCredDelegState method of the GSSContext interface. In cases when 426 it is, the delegated credential object can be obtained by calling the 427 getDelegCred method. The obtained GSSCredential object may then be 428 used to initiate subsequent GSS-API security contexts as an agent or 429 delegate of the initiator. If the original initiator's identity is 430 "A" and the delegate's identity is "B", then, depending on the 431 underlying mechanism, the identity embodied by the delegated 432 credential may be either "A" or "B acting for A". 434 For many mechanisms that support delegation, a simple boolean does 435 not provide enough control. Examples of additional aspects of 436 delegation control that a mechanism might provide to an application 437 are duration of delegation, network addresses from which delegation 438 is valid, and constraints on the tasks that may be performed by a 439 delegate. Such controls are presently outside the scope of the GSS- 440 API. GSS-API implementations supporting mechanisms offering 441 additional controls should provide extension routines that allow 442 these controls to be exercised (perhaps by modifying the initiator's 443 GSS-API credential object prior to its use in establishing a 444 context). However, the simple delegation control provided by GSS-API 445 should always be able to over-ride other mechanism-specific 446 delegation controls. If the application instructs the GSSContext 447 object that delegation is not desired, then the implementation must 448 not permit delegation to occur. This is an exception to the general 449 rule that a mechanism may enable services even if they are not 450 requested - delegation may only be provided at the explicit request 451 of the application. 453 4.2 Mutual Authentication 455 Usually, a context acceptor will require that a context initiator 456 authenticate itself so that the acceptor may make an access-control 457 decision prior to performing a service for the initiator. In some 458 cases, the initiator may also request that the acceptor authenticate 459 itself. GSS-API allows the initiating application to request this 460 mutual authentication service by calling the requestMutualAuth method 461 of the GSSContext interface with a "true" parameter before making the 462 first call to init. The initiating application is informed as to 463 whether or not the context acceptor has authenticated itself. Note 464 that some mechanisms may not support mutual authentication, and other 465 mechanisms may always perform mutual authentication, whether or not 466 the initiating application requests it. In particular, mutual 467 authentication may be required by some mechanisms in order to support 468 replay or out-of-sequence message detection, and for such mechanisms 469 a request for either of these services will automatically enable 470 mutual authentication. 472 4.3 Replay and Out-of-Sequence Detection 474 The GSS-API may provide detection of mis-ordered messages once a 475 security context has been established. Protection may be applied to 476 messages by either application, by calling either getMIC or wrap 477 methods of the GSSContext interface, and verified by the peer 478 application by calling verifyMIC or unwrap for the peer's GSSContext 479 object. 481 The getMIC method calculates a cryptographic checksum of an 482 application message, and returns that checksum in a token. The 483 application should pass both the token and the message to the peer 484 application, which presents them to the verifyMIC method of the 485 peer's GSSContext object. 487 The wrap method calculates a cryptographic checksum of an application 488 message, and places both the checksum and the message inside a single 489 token. The application should pass the token to the peer 490 application, which presents it to the unwrap method of the peer's 491 GSSContext object to extract the message and verify the checksum. 493 Either pair of routines may be capable of detecting out-of-sequence 494 message delivery, or duplication of messages. Details of such mis- 495 ordered messages are indicated through supplementary query methods of 496 the MessageProp object that is filled in by each of these routines. 498 A mechanism need not maintain a list of all tokens that have been 499 processed in order to support these status codes. A typical 500 mechanism might retain information about only the most recent "N" 501 tokens processed, allowing it to distinguish duplicates and missing 502 tokens within the most recent "N" messages; the receipt of a token 503 older than the most recent "N" would result in the isOldToken method 504 of the instance of MessageProp to return "true". 506 4.4 Anonymous Authentication 508 In certain situations, an application may wish to initiate the 509 authentication process to authenticate a peer, without revealing its 510 own identity. As an example, consider an application providing 511 access to a database containing medical information, and offering 512 unrestricted access to the service. A client of such a service might 513 wish to authenticate the service (in order to establish trust in any 514 information retrieved from it), but might not wish the service to be 515 able to obtain the client's identity (perhaps due to privacy concerns 516 about the specific inquiries, or perhaps simply to avoid being placed 517 on mailing-lists). 519 In normal use of the GSS-API, the initiator's identity is made 520 available to the acceptor as a result of the context establishment 521 process. However, context initiators may request that their identity 522 not be revealed to the context acceptor. Many mechanisms do not 523 support anonymous authentication, and for such mechanisms the request 524 will not be honored. An authentication token will still be 525 generated, but the application is always informed if a requested 526 service is unavailable, and has the option to abort context 527 establishment if anonymity is valued above the other security 528 services that would require a context to be established. 530 In addition to informing the application that a context is 531 established anonymously (via the isAnonymous method of the GSSContext 532 class), the getSrcName method of the acceptor's GSSContext object 533 will, for such contexts, return a reserved internal-form name, 534 defined by the implementation. 536 The toString method for a GSSName object representing an anonymous 537 entity will return a printable name. The returned value will be 538 syntactically distinguishable from any valid principal name supported 539 by the implementation. The associated name-type object identifier 540 will be an oid representing the value of NT_ANONYMOUS. This name- 541 type oid will be defined as a public, static Oid object of the 542 GSSName class. The printable form of an anonymous name should be 543 chosen such that it implies anonymity, since this name may appear in, 544 for example, audit logs. For example, the string "" might 545 be a good choice, if no valid printable names supported by the 546 implementation can begin with "<" and end with ">". 548 When using the equal method of the GSSName interface, and one of the 549 operands is a GSSName instance representing an anonymous entity, the 550 method must return "false". 552 4.5 Confidentiality 554 If a GSSContext supports the confidentiality service, wrap method may 555 be used to encrypt application messages. Messages are selectively 556 encrypted, under the control of the setPrivacy method of the 557 MessageProp object used in the wrap method. 559 4.6 Inter-process Context Transfer 561 GSS-API V2 provides functionality which allows a security context to 562 be transferred between processes on a single machine. These are 563 implemented using the export method of GSSContext and a byte array 564 constructor of the same class. The most common use for such a 565 feature is a client-server design where the server is implemented as 566 a single process that accepts incoming security contexts, which then 567 launches child processes to deal with the data on these contexts. In 568 such a design, the child processes must have access to the security 569 context object created within the parent so that they can use per- 570 message protection services and delete the security context when the 571 communication session ends. 573 Since the security context data structure is expected to contain 574 sequencing information, it is impractical in general to share a 575 context between processes. Thus GSSContext interface provides an 576 export method that the process, which currently owns the context, can 577 call to declare that it has no intention to use the context 578 subsequently, and to create an inter-process token containing 579 information needed by the adopting process to successfully re-create 580 the context. After successful completion of export, the original 581 security context is made inaccessible to the calling process by GSS- 582 API and any further usage of this object will result in failures. 583 The originating process transfers the inter-process token to the 584 adopting process, which creates a new GSSContext object using the 585 byte array constructor. The properties of the context are equivalent 586 to that of the original context. 588 The inter-process token may contain sensitive data from the original 589 security context (including cryptographic keys). Applications using 590 inter-process tokens to transfer security contexts must take 591 appropriate steps to protect these tokens in transit. 593 Implementations are not required to support the inter-process 594 transfer of security contexts. Calling the isTransferable method of 595 the GSSContext interface will indicate if the context object is 596 transferable. 598 4.7 The Use of Incomplete Contexts 600 Some mechanisms may allow the per-message services to be used before 601 the context establishment process is complete. For example, a 602 mechanism may include sufficient information in its initial context- 603 level tokens for the context acceptor to immediately decode messages 604 protected with wrap or getMIC. For such a mechanism, the initiating 605 application need not wait until subsequent context-level tokens have 606 been sent and received before invoking the per-message protection 607 services. 609 An application can invoke the isProtReady method of the GSSContext 610 class to determine if the per-message services are available in 611 advance of complete context establishment. Applications wishing to 612 use per-message protection services on partially-established contexts 613 should query this method before attempting to invoke wrap or getMIC. 615 5. Calling Conventions 617 Java provides the implementors with not just a syntax for the 618 language, but also an operational environment. For example, memory 619 is automatically managed and does not require application 620 intervention. These language features have allowed for a simpler API 621 and have led to the elimination of certain GSS-API functions. 623 Moreover, the JCA defines a provider model which allows for 624 implementation independent access to security services. Using this 625 model, applications can seamlessly switch between different 626 implementations and dynamically add new services. The GSS-API 627 specification leverages these concepts by the usage of providers for 628 the mechanism implementations. 630 5.1 Package Name 632 The classes and interfaces defined in this document reside in the 633 package called "org.ietf.jgss". Applications that wish to make use 634 of this API should import this package name as shown in section 8. 636 5.2 Provider Framework 638 The Java security API's use a provider architecture that allows 639 applications to be implementation independent and security API 640 implementations to be modular and extensible. The 641 java.security.Provider class is an abstract class that a vendor 642 extends. This class maps various properties that represent different 643 security services that are available to the names of the actual 644 vendor classes that implement those services. When requesting a 645 service, an application simply specifies the desired provider and the 646 API delegates the request to service classes available from that 647 provider. 649 Using the Java security provider model insulates applications from 650 implementation details of the services they wish to use. 651 Applications can switch between providers easily and new providers 652 can be added as needed, even at runtime. 654 The GSS-API may use providers to find components for specific 655 underlying security mechanisms. For instance, a particular provider 656 might contain components that will allow the GSS-API to support the 657 Kerberos v5 mechanism and another might contain components to support 658 the SPKM mechanism. By delegating mechanism specific functionality 659 to the components obtained from providers the GSS-API can be extended 660 to support an arbitrary list of mechanism. 662 How the GSS-API locates and queries these providers is beyond the 663 scope of this document and is being deferred to a Service Provider 664 Interface (SPI) specification. The availability of such a SPI 665 specification is not mandatory for the adoption of this API 666 specification nor is it mandatory to use providers in the 667 implementation of a GSS-API framework. However, by using the 668 provider framework together with an SPI specification one can create 669 an extensible and implementation independent GSS-API framework. 671 5.3 Integer Types 673 All numeric values are declared as "int" primitive Java type. The 674 Java specification guarantees that this will be a 32 bit two's 675 complement signed number. 677 Throughout this API, the "boolean" primitive Java type is used 678 wherever a boolean value is required or returned. 680 5.4 Opaque Data Types 682 Java byte arrays are used to represent opaque data types which are 683 consumed and produced by the GSS-API in the forms of tokens. Java 684 arrays contain a length field which enables the users to easily 685 determine their size. The language has automatic garbage collection 686 which alleviates the need by developers to release memory and 687 simplifies buffer ownership issues. 689 5.5 Strings 691 The String object will be used to represent all textual data. The 692 Java String object, transparently treats all characters as two-byte 693 Unicode characters which allows support for many locals. All 694 routines returning or accepting textual data will use the String 695 object. 697 5.6 Object Identifiers 699 An Oid object will be used to represent Universal Object Identifiers 700 (Oids). Oids are ISO-defined, hierarchically globally-interpretable 701 identifiers used within the GSS-API framework to identify security 702 mechanisms and name formats. The Oid object can be created from a 703 string representation of its dot notation (e.g. "1.3.6.1.5.6.2") as 704 well as from its ASN.1 DER encoding. Methods are also provided to 705 test equality and provide the DER representation for the object. 707 An important feature of the Oid class is that its instances are 708 immutable - i.e. there are no methods defined that allow one to 709 change the contents of an Oid. This property allows one to treat 710 these objects as "statics" without the need to perform copies. 712 Certain routines allow the usage of a default oid. A "null" value 713 can be used in those cases. 715 5.7 Object Identifier Sets 717 The Java bindings represents object identifiers sets as arrays of Oid 718 objects. All Java arrays contain a length field which allows for 719 easy manipulation and reference. 721 In order to support the full functionality of RFC 2743, the Oid class 722 includes a method which checks for existence of an Oid object within 723 a specified array. This is equivalent in functionality to 724 gss_test_oid_set_member. The use of Java arrays and Java's automatic 725 garbage collection has eliminated the need for the following 726 routines: gss_create_empty_oid_set, gss_release_oid_set, and 727 gss_add_oid_set_member. Java GSS-API implementations will not 728 contain them. Java's automatic garbage collection and the immutable 729 property of the Oid object eliminates the complicated memory 730 management issues of the C counterpart. 732 When ever a default value for an Object Identifier Set is required, a 733 "null" value can be used. Please consult the detailed method 734 description for details. 736 5.8 Credentials 738 GSS-API credentials are represented by the GSSCredential interface. 739 The interface contains several constructs to allow for the creation 740 of most common credential objects for the initiator and the acceptor. 741 Comparisons are performed using the interface's "equals" method. The 742 following general description of GSS-API credentials is included from 743 the C-bindings specification: 745 GSS-API credentials can contain mechanism-specific principal 746 authentication data for multiple mechanisms. A GSS-API credential is 747 composed of a set of credential-elements, each of which is applicable 748 to a single mechanism. A credential may contain at most one 749 credential-element for each supported mechanism. A credential- 750 element identifies the data needed by a single mechanism to 751 authenticate a single principal, and conceptually contains two 752 credential-references that describe the actual mechanism-specific 753 authentication data, one to be used by GSS-API for initiating 754 contexts, and one to be used for accepting contexts. For mechanisms 755 that do not distinguish between acceptor and initiator credentials, 756 both references would point to the same underlying mechanism-specific 757 authentication data. 759 Credentials describe a set of mechanism-specific principals, and give 760 their holder the ability to act as any of those principals. All 761 principal identities asserted by a single GSS-API credential should 762 belong to the same entity, although enforcement of this property is 763 an implementation-specific matter. A single GSSCredential object 764 represents all the credential elements that have been acquired. 766 The creation's of an GSSContext object allows the value of "null" to 767 be specified as the GSSCredential input parameter. This will 768 indicate a desire by the application to act as a default principal. 769 While individual GSS-API implementations are free to determine such 770 default behavior as appropriate to the mechanism, the following 771 default behavior by these routines is recommended for portability: 773 For the initiator side of the context: 775 1) If there is only a single principal capable of initiating security 776 contexts for the chosen mechanism that the application is authorized 777 to act on behalf of, then that principal shall be used, otherwise 779 2) If the platform maintains a concept of a default network- identity 780 for the chosen mechanism, and if the application is authorized to act 781 on behalf of that identity for the purpose of initiating security 782 contexts, then the principal corresponding to that identity shall be 783 used, otherwise 785 3) If the platform maintains a concept of a default local identity, 786 and provides a means to map local identities into network-identities 787 for the chosen mechanism, and if the application is authorized to act 788 on behalf of the network- identity image of the default local 789 identity for the purpose of initiating security contexts using the 790 chosen mechanism, then the principal corresponding to that identity 791 shall be used, otherwise 793 4) A user-configurable default identity should be used. 795 and for the acceptor side of the context 797 1) If there is only a single authorized principal identity capable of 798 accepting security contexts for the chosen mechanism, then that 799 principal shall be used, otherwise 801 2) If the mechanism can determine the identity of the target 802 principal by examining the context-establishment token processed 803 during the accept method, and if the accepting application is 804 authorized to act as that principal for the purpose of accepting 805 security contexts using the chosen mechanism, then that principal 806 identity shall be used, otherwise 807 3) If the mechanism supports context acceptance by any principal, and 808 if mutual authentication was not requested, any principal that the 809 application is authorized to accept security contexts under using the 810 chosen mechanism may be used, otherwise 812 4) A user-configurable default identity shall be used. 814 The purpose of the above rules is to allow security contexts to be 815 established by both initiator and acceptor using the default behavior 816 whenever possible. Applications requesting default behavior are 817 likely to be more portable across mechanisms and implementations than 818 ones that instantiate an GSSCredential object representing a specific 819 identity. 821 5.9 Contexts 823 The GSSContext interface is used to represent one end of a GSS-API 824 security context, storing state information appropriate to that end 825 of the peer communication, including cryptographic state information. 826 The instantiation of the context object is done differently by the 827 initiator and the acceptor. After the context has been instantiated, 828 the initiator may choose to set various context options which will 829 determine the characteristics of the desired security context. When 830 all the application desired characteristics have been set, the 831 initiator will call the initSecContext method which will produce a 832 token for consumption by the peer's acceptSecContext method. It is 833 the responsibility of the application to deliver the authentication 834 token(s) between the peer applications for processing. Upon 835 completion of the context establishment phase, context attributes can 836 be retrieved, by both the initiator and acceptor, using the accessor 837 methods. These will reflect the actual attributes of the established 838 context. At this point the context can be used by the application to 839 apply cryptographic services to its data. 841 5.10 Authentication Tokens 843 A token is a caller-opaque type that GSS-API uses to maintain 844 synchronization between each end of the GSS-API security context. 845 The token is a cryptographically protected octet-string, generated by 846 the underlying mechanism at one end of a GSS-API security context for 847 use by the peer mechanism at the other end. Encapsulation (if 848 required) within the application protocol and transfer of the token 849 are the responsibility of the peer applications. 851 Java GSS-API uses byte arrays to represent authentication tokens. 852 Overloaded methods exist which allow the caller to supply input and 853 output streams which will be used for the reading and writing of the 854 token data. 856 5.11 Interprocess Tokens 858 Certain GSS-API routines are intended to transfer data between 859 processes in multi-process programs. These routines use a caller- 860 opaque octet-string, generated by the GSS-API in one process for use 861 by the GSS-API in another process. The calling application is 862 responsible for transferring such tokens between processes. Note 863 that, while GSS-API implementors are encouraged to avoid placing 864 sensitive information within interprocess tokens, or to 865 cryptographically protect them, many implementations will be unable 866 to avoid placing key material or other sensitive data within them. 867 It is the application's responsibility to ensure that interprocess 868 tokens are protected in transit, and transferred only to processes 869 that are trustworthy. An interprocess token is represented using a 870 byte array emitted from the export method of the GSSContext 871 interface. The receiver of the interprocess token would initialize 872 an GSSContext object with this token to create a new context. Once a 873 context has been exported, the GSSContext object is invalidated and 874 is no longer available. 876 5.12 Error Reporting 878 RFC 2743 defined the usage of major and minor status values for 879 signaling of GSS-API errors. The major code, also called GSS status 880 code, is used to signal errors at the GSS-API level independent of 881 the underlying mechanism(s). The minor status value or Mechanism 882 status code, is a mechanism defined error value indicating a 883 mechanism specific error code. 885 Java GSS-API uses exceptions implemented by the GSSException class to 886 signal both minor and major error values. Both mechanism specific 887 errors and GSS-API level errors are signaled through instances of 888 this class. The usage of exceptions replaces the need for major and 889 minor codes to be used within the API calls. GSSException class also 890 contains methods to obtain textual representations for both the major 891 and minor values, which is equivalent to the functionality of 892 gss_display_status. 894 5.12.1 GSS Status Codes 896 GSS status codes indicate errors that are independent of the 897 underlying mechanism(s) used to provide the security service. The 898 errors that can be indicated via a GSS status code are generic API 899 routine errors (errors that are defined in the GSS-API 900 specification). These bindings take advantage of the Java exceptions 901 mechanism, thus eliminating the need for calling errors. 903 A GSS status code indicates a single fatal generic API error from the 904 routine that has thrown the GSSException. Using exceptions announces 905 that a fatal error has occurred during the execution of the method. 906 The GSS-API operational model also allows for the signaling of 907 supplementary status information from the per-message calls. These 908 need to be handled as return values since using exceptions is not 909 appropriate for informatory or warning-like information. The methods 910 that are capable of producing supplementary information are the two 911 per-message methods GSSContext.verifyMIC() and GSSContext.unwrap(). 912 These methods fill the supplementary status codes in the MessageProp 913 object that was passed in. 915 A GSSException object, along with providing the functionality for 916 setting of the various error codes and translating them into textual 917 representation, also contains the definitions of all the numeric 918 error values. The following table lists the definitions of error 919 codes: 921 Table: GSS Status Codes 923 Name Value Meaning 925 BAD_BINDINGS 1 Incorrect channel bindings were 926 supplied. 928 BAD_MECH 2 An unsupported mechanism 929 was requested. 931 BAD_NAME 3 An invalid name was supplied. 933 BAD_NAMETYPE 4 A supplied name was of an 934 unsupported type. 936 BAD_STATUS 5 An invalid status code was 937 supplied. 939 BAD_MIC 6 A token had an invalid MIC. 941 CONTEXT_EXPIRED 7 The context has expired. 943 CREDENTIALS_EXPIRED 8 The referenced credentials 944 have expired. 946 DEFECTIVE_CREDENTIAL 9 A supplied credential was 947 invalid. 949 DEFECTIVE_TOKEN 10 A supplied token was invalid. 951 FAILURE 11 Miscellaneous failure, 952 unspecified at the GSS-API 953 level. 955 NO_CONTEXT 12 Invalid context has been 956 supplied. 958 NO_CRED 13 No credentials were supplied, or 959 the credentials were unavailable 960 or inaccessible. 962 BAD_QOP 14 The quality-of-protection 963 requested could not be provided. 965 UNAUTHORIZED 15 The operation is forbidden by 966 the local security policy. 968 UNAVAILABLE 16 The operation or option is 969 unavailable. 971 DUPLICATE_ELEMENT 17 The requested credential 972 element already exists. 974 NAME_NOT_MN 18 The provided name was not a 975 mechanism name. 977 The following four status codes (DUPLICATE_TOKEN, OLD_TOKEN, 978 UNSEQ_TOKEN, and GAP_TOKEN) are contained in a GSSException 979 only if detected during context establishment, in which case it 980 is a fatal error. (During per-message calls, these values are 981 indicated as supplementary information contained in the 982 MessageProp object.) They are: 984 DUPLICATE_TOKEN 19 The token was a duplicate of an 985 earlier version. 987 OLD_TOKEN 20 The token's validity period has 988 expired. 990 UNSEQ_TOKEN 21 A later token has already been 991 processed. 993 GAP_TOKEN 22 The expected token was not 994 received. 996 The GSS major status code of FAILURE is used to indicate that the 997 underlying mechanism detected an error for which no specific GSS 998 status code is defined. The mechanism-specific status code can 999 provide more details about the error. 1001 The different major status codes that can be contained in the 1002 GSSException object thrown by the methods in this specification are 1003 the same as the major status codes returned by the corresponding 1004 calls in RFC 2743 [GSSAPIv2-UPDATE]. 1006 5.12.2 Mechanism-Specific Status Codes 1008 Mechanism-specific status codes are communicated in two ways, they 1009 are part of any GSSException thrown from the mechanism specific layer 1010 to signal a fatal error, or they are part of the MessageProp object 1011 that the per-message calls use to signal non-fatal errors. 1013 A default value of 0 in either the GSSException object or the 1014 MessageProp object will be used to represent the absence of any 1015 mechanism specific status code. 1017 5.12.3 Supplementary Status Codes 1019 Supplementary status codes are confined to the per-message methods of 1020 the GSSContext interface. Because of the informative nature of these 1021 errors it is not appropriate to use exceptions to signal them. 1022 Instead, the per-message operations of the GSSContext interface 1023 return these values in a MessageProp object. 1025 The MessageProp class defines query methods which return boolean 1026 values indicating the following supplementary states: 1028 Table: Supplementary Status Methods 1030 Method Name Meaning when "true" is returned 1032 isDuplicateToken The token was a duplicate of an 1033 earlier token. 1035 isOldToken The token's validity period has 1036 expired. 1038 isUnseqToken A later token has already been 1039 processed. 1041 isGapToken An expected per-message token was 1042 not received. 1044 "true" return value for any of the above methods indicates that the 1045 token exhibited the specified property. The application must 1046 determine the appropriate course of action for these supplementary 1047 values. They are not treated as errors by the GSS-API. 1049 5.13 Names 1051 A name is used to identify a person or entity. GSS-API authenticates 1052 the relationship between a name and the entity claiming the name. 1054 Since different authentication mechanisms may employ different 1055 namespaces for identifying their principals, GSS-API's naming support 1056 is necessarily complex in multi-mechanism environments (or even in 1057 some single-mechanism environments where the underlying mechanism 1058 supports multiple namespaces). 1060 Two distinct conceptual representations are defined for names: 1062 1) A GSS-API form represented by implementations of the GSSName 1063 interface: A single GSSName object may contain multiple names from 1064 different namespaces, but all names should refer to the same entity. 1065 An example of such an internal name would be the name returned from a 1066 call to the getName method of the GSSCredential interface, when 1067 applied to a credential containing credential elements for multiple 1068 authentication mechanisms employing different namespaces. This 1069 GSSName object will contain a distinct name for the entity for each 1070 authentication mechanism. 1072 For GSS-API implementations supporting multiple namespaces, GSSName 1073 implementations must contain sufficient information to determine the 1074 namespace to which each primitive name belongs. 1076 2) Mechanism-specific contiguous byte array and string forms: 1077 Different GSSName initialization methods are provided to handle both 1078 byte array and string formats and to accommodate various calling 1079 applications and name types. These formats are capable of containing 1080 only a single name (from a single namespace). Contiguous string 1081 names are always accompanied by an object identifier specifying the 1082 namespace to which the name belongs, and their format is dependent on 1083 the authentication mechanism that employs that name. The string name 1084 forms are assumed to be printable, and may therefore be used by GSS- 1085 API applications for communication with their users. The byte array 1086 name formats are assumed to be in non-printable formats (e.g. the 1087 byte array returned from the export method of the GSSName interface). 1089 A GSSName object can be converted to a contiguous representation by 1090 using the toString method. This will guarantee that the name will be 1091 converted to a printable format. Different initialization methods in 1092 the GSSName interface are defined allowing support for multiple 1093 syntaxes for each supported namespace, and allowing users the freedom 1094 to choose a preferred name representation. The toString method 1095 should use an implementation-chosen printable syntax for each 1096 supported name-type. To obtain the printable name type, 1097 getStringNameType method can be used. 1099 There is no guarantee that calling the toString method on the GSSName 1100 interface will produce the same string form as the original imported 1101 string name. Furthermore, it is possible that the name was not even 1102 constructed from a string representation. The same applies to name- 1103 space identifiers which may not necessarily survive unchanged after a 1104 journey through the internal name-form. An example of this might be 1105 a mechanism that authenticates X.500 names, but provides an 1106 algorithmic mapping of Internet DNS names into X.500. That 1107 mechanism's implementation of GSSName might, when presented with a 1108 DNS name, generate an internal name that contained both the original 1109 DNS name and the equivalent X.500 name. Alternatively, it might only 1110 store the X.500 name. In the latter case, the toString method of 1111 GSSName would most likely generate a printable X.500 name, rather 1112 than the original DNS name. 1114 The context acceptor can obtain a GSSName object representing the 1115 entity performing the context initiation (through the usage of 1116 getSrcName method). Since this name has been authenticated by a 1117 single mechanism, it contains only a single name (even if the 1118 internal name presented by the context initiator to the GSSContext 1119 object had multiple components). Such names are termed internal 1120 mechanism names, or "MN"s and the names emitted by GSSContext 1121 interface in the getSrcName and getTargName are always of this type. 1122 Since some applications may require MNs without wanting to incur the 1123 overhead of an authentication operation, creation methods are 1124 provided that take not only the name buffer and name type, but also 1125 the mechanism oid for which this name should be created. When 1126 dealing with an existing GSSName object, the canonicalize method may 1127 be invoked to convert a general internal name into an MN. 1129 GSSName objects can be compared using their equal method, which 1130 returns "true" if the two names being compared refer to the same 1131 entity. This is the preferred way to perform name comparisons 1132 instead of using the printable names that a given GSS-API 1133 implementation may support. Since GSS-API assumes that all primitive 1134 names contained within a given internal name refer to the same 1135 entity, equal can return "true" if the two names have at least one 1136 primitive name in common. If the implementation embodies knowledge 1137 of equivalence relationships between names taken from different 1138 namespaces, this knowledge may also allow successful comparisons of 1139 internal names containing no overlapping primitive elements. 1141 When used in large access control lists, the overhead of creating an 1142 GSSName object on each name and invoking the equal method on each 1143 name from the ACL may be prohibitive. As an alternative way of 1144 supporting this case, GSS-API defines a special form of the 1145 contiguous byte array name which may be compared directly (byte by 1146 byte). Contiguous names suitable for comparison are generated by the 1147 export method. Exported names may be re-imported by using the byte 1148 array constructor and specifying the NT_EXPORT_NAME as the name type 1149 object identifier. The resulting GSSName name will also be a MN. 1150 The GSSName interface defines public static Oid objects representing 1151 the standard name types. Structurally, an exported name object 1152 consists of a header containing an OID identifying the mechanism that 1153 authenticated the name, and a trailer containing the name itself, 1154 where the syntax of the trailer is defined by the individual 1155 mechanism specification. Detailed description of the format is 1156 specified in the language-independent GSS-API specification 1157 [GSSAPIv2-UPDATE]. 1159 Note that the results obtained by using the equals method will in 1160 general be different from those obtained by invoking canonicalize and 1161 export, and then comparing the byte array output. The first series 1162 of operation determines whether two (unauthenticated) names identify 1163 the same principal; the second whether a particular mechanism would 1164 authenticate them as the same principal. These two operations will 1165 in general give the same results only for MNs. 1167 It is important to note that the above are guidelines as how GSSName 1168 implementations should behave, and are not intended to be specific 1169 requirements of how names objects must be implemented. The mechanism 1170 designers are free to decide on the details of their implementations 1171 of the GSSName interface as long as the behavior satisfies the above 1172 guidelines. 1174 5.14 Channel Bindings 1176 GSS-API supports the use of user-specified tags to identify a given 1177 context to the peer application. These tags are intended to be used 1178 to identify the particular communications channel that carries the 1179 context. Channel bindings are communicated to the GSS-API using the 1180 ChannelBinding object. The application may use byte arrays to 1181 specify the application data to be used in the channel binding as 1182 well as using instances of the InetAddress. The InetAddress for the 1183 initiator and/or acceptor can be used within an instance of a 1184 ChannelBinding. ChannelBinding can be set for the GSSContext object 1185 using the setChannelBinding method before the first call to init or 1186 accept has been performed. Unless the setChannelBinding method has 1187 been used to set the ChannelBinding for a GSSContext object, "null" 1188 ChannelBinding will be assumed. InetAddress is currently the only 1189 address type defined within the Java platform and as such, it is the 1190 only one supported within the ChannelBinding class. Applications 1191 that use other types of addresses can include them as part of the 1192 application specific data. 1194 Conceptually, the GSS-API concatenates the initiator and acceptor 1195 address information, and the application supplied byte array to form 1196 an octet string. The mechanism calculates a MIC over this octet 1197 string and binds the MIC to the context establishment token emitted 1198 by init method of the GSSContext interface. The same bindings are 1199 set by the context acceptor for its GSSContext object and during 1200 processing of the accept method a MIC is calculated in the same way. 1201 The calculated MIC is compared with that found in the token, and if 1202 the MICs differ, accept will throw a GSSException with the major 1203 code set to BAD_BINDINGS, and the context will not be established. 1204 Some mechanisms may include the actual channel binding data in the 1205 token (rather than just a MIC); applications should therefore not use 1206 confidential data as channel-binding components. 1208 Individual mechanisms may impose additional constraints on addresses 1209 that may appear in channel bindings. For example, a mechanism may 1210 verify that the initiator address field of the channel binding 1211 contains the correct network address of the host system. Portable 1212 applications should therefore ensure that they either provide correct 1213 information for the address fields, or omit setting of the addressing 1214 information. 1216 5.15 Stream Objects 1218 The context object provides overloaded methods which use input and 1219 output streams as the means to convey authentication and per-message 1220 GSS-API tokens. It is important to note that the streams are 1221 expected to contain the usual GSS-API tokens which would otherwise be 1222 handled through the usage of byte arrays. The tokens are expected to 1223 have a definite start and an end. The callers are responsible for 1224 ensuring that the supplied streams will not block, or expect to block 1225 until a full token is processed by the GSS-API method. Only a single 1226 GSS-API token will be processed per invocation of the stream based 1227 method. 1229 The usage of streams allows the callers to have control and 1230 management of the supplied buffers. Because streams are non- 1231 primitive objects, the callers can make the streams as complicated or 1232 as simple as desired simply by using the streams defined in the 1233 java.io package or creating their own through the use of inheritance. 1234 This will allow for the application's greatest flexibility. 1236 5.16 Optional Parameters 1238 Whenever the application wishes to omit an optional parameter the 1239 "null" value shall be used. The detailed method descriptions 1240 indicate which parameters are optional. Methods overloading has also 1241 been used as a technique to indicate default parameters. 1243 6. Introduction to GSS-API Classes and Interfaces 1245 This section presents a brief description of the classes and 1246 interfaces that constitute the GSS-API. The implementations of these 1247 are obtained from the CLASSPATH defined by the application. If Java 1248 GSS becomes part of the standard Java API's then these classes will 1249 be available by default on all systems as part of the JRE's system 1250 classes. 1252 This section also shows the corresponding RFC 2743 functionality 1253 implemented by each of the classes. Detailed description of these 1254 classes and their methods is presented in section 7. 1256 6.1 GSSManager class 1258 This abstract class serves as a factory to instantiate 1259 implementations of the GSS-API interfaces and also provides methods 1260 to make queries about underlying security mechanisms. 1262 A default implementation can be obtained using the static method 1263 getInstance(). Applications that desire to provide their own 1264 implementation of the GSSManager class can simply extend the abstract 1265 class themselves. 1267 This class contains equivalents of the following RFC 2743 routines: 1269 gss_import_name Create an internal name from 7.1.6- 1270 the supplied information. 7.1.9 1272 gss_acquire_cred Acquire credential 7.1.10- 1273 for use. 7.1.12 1275 gss_import_sec_context Create a previously exported 7.1.15 1276 context. 1278 gss_indicate_mechs List the mechanisms 7.1.3 1279 supported by this GSS-API 1280 implementation. 1282 gss_inquire_mechs_for_name List the mechanisms 7.1.5 1283 supporting the 1284 specified name type. 1286 gss_inquire_names_for_mech List the name types 7.1.4 1287 supported by the 1288 specified mechanism. 1290 Figure 3 1292 6.2 GSSName interface 1294 GSS-API names are represented in the Java bindings through the 1295 GSSName interface. Different name formats and their definitions are 1296 identified with universal Object Identifiers (oids). The format of 1297 the names can be derived based on the unique oid of each name type. 1298 The following GSS-API routines are provided by the GSSName interface: 1300 RFC 2743 Routine Function Section(s) 1302 gss_display_name Covert internal name 7.2.7 1303 representation to text format. 1305 gss_compare_name Compare two internal names. 7.2.3, 1306 7.2.4 1308 gss_release_name Release resources associated N/A 1309 with the internal name. 1311 gss_canonicalize_name Convert an internal name to a 7.2.5 1312 mechanism name. 1314 gss_export_name Convert a mechanism name to 7.2.6 1315 export format. 1317 gss_duplicate_name Create a copy of the internal N/A 1318 name. 1320 Figure 4 1322 The gss_release_name call is not provided as Java does its own 1323 garbage collection. The gss_duplicate_name call is also redundant; 1324 the GSSName interface has no mutator methods that can change the 1325 state of the object so it is safe for sharing. 1327 6.3 GSSCredential interface 1329 The GSSCredential interface is responsible for the encapsulation of 1330 GSS-API credentials. Credentials identify a single entity and 1331 provide the necessary cryptographic information to enable the 1332 creation of a context on behalf of that entity. A single credential 1333 may contain multiple mechanism specific credentials, each referred to 1334 as a credential element. The GSSCredential interface provides the 1335 functionality of the following GSS-API routines: 1337 RFC 2743 Routine Function Section(s) 1339 gss_add_cred Constructs credentials 7.3.12 1340 incrementally. 1342 gss_inquire_cred Obtain information about 7.3.4- 1343 credential. 7.3.11 1345 gss_inquire_cred_by_mech Obtain per-mechanism 7.3.5- 1346 information about 7.3.10 1347 a credential. 1349 gss_release_cred Disposes of credentials 7.3.3 1350 after use. 1352 Figure 5 1354 6.4 GSSContext interface 1356 This interface encapsulates the functionality of context-level calls 1357 required for security context establishment and management between 1358 peers as well as the per-message services offered to applications. A 1359 context is established between a pair of peers and allows the usage 1360 of security services on a per-message basis on application data. It 1361 is created over a single security mechanism. The GSSContext 1362 interface provides the functionality of the following GSS-API 1363 routines: 1365 RFC 2743 Routine Function Section(s) 1367 gss_init_sec_context Initiate the creation of a 7.4.3- 1368 security context with a peer. 7.4.6 1370 gss_accept_sec_context Accept a security context 7.4.7- 1371 initiated by a peer. 7.4.10 1373 gss_delete_sec_context Destroy a security context. 7.4.12 1375 gss_context_time Obtain remaining context 7.4.41 1376 time. 1378 gss_inquire_context Obtain context 7.4.32- 1379 characteristics. 7.3.46 1381 gss_wrap_size_limit Determine token-size limit 7.4.13 1382 for gss_wrap. 1384 gss_export_sec_context Transfer security context 7.4.22 1385 to another process. 1387 gss_get_mic Calculate a cryptographic 7.4.18, 1388 Message Integrity Code (MIC) 7.4.19 1389 for a message. 1391 gss_verify_mic Verify integrity on a received 7.4.20, 1392 message. 7.4.21 1394 gss_wrap Attach a MIC to a message and 7.4.14, 1395 optionally encrypt the message 7.4.15 1396 content. 1398 gss_unwrap Obtain a previously wrapped 7.4.16, 1399 application message verifying 7.4.17 1400 its integrity and optionally 1401 decrypting it. 1403 Figure 6 1405 The functionality offered by the gss_process_context_token routine 1406 has not been included in the Java bindings specification. The 1407 corresponding functionality of gss_delete_sec_context has also been 1408 modified to not return any peer tokens. This has been proposed in 1409 accordance to the recommendations stated in RFC 2743. GSSContext 1410 does offer the functionality of destroying the locally-stored context 1411 information. 1413 6.5 MessageProp class 1415 This helper class is used in the per-message operations on the 1416 context. An instance of this class is created by the application and 1417 then passed into the per-message calls. In some cases, the 1418 application conveys information to the GSS-API implementation through 1419 this object and in other cases the GSS-API returns information to the 1420 application by setting it in this object. See the description of the 1421 per-message operations wrap, unwrap, getMIC, and verifyMIC in the 1422 GSSContext interfaces for details. 1424 6.6 GSSException class 1426 Exceptions are used in the Java bindings to signal fatal errors to 1427 the calling applications. This replaces the major and minor codes 1428 used in the C-bindings specification as a method of signaling 1429 failures. The GSSException class handles both minor and major codes, 1430 as well as their translation into textual representation. All GSS- 1431 API methods are declared as throwing this exception. 1433 RFC 2743 Routine Function Section 1435 gss_display_status Retrieve textual 7.8.5, 7.8.6, 1436 representation of error 7.8.8, 7.8.9 1437 codes. 1439 Figure 7 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 Figure 8 1456 6.8 ChannelBinding class 1458 An instance of this class is used to specify channel binding 1459 information to the GSSContext object before the start of a security 1460 context establishment. The application may use a byte array to 1461 specify application data to be used in the channel binding as well as 1462 use instances of the InetAddress. InetAddress is currently the only 1463 address type defined within the Java platform and as such, it is the 1464 only one supported within the ChannelBinding class. Applications 1465 that use other types of addresses can include them as part of the 1466 application data. 1468 7. Detailed GSS-API Class Description 1470 This section lists a detailed description of all the public methods 1471 that each of the GSS-API classes and interfaces must provide. 1473 7.1 public abstract class GSSManager 1475 The GSSManager class is an abstract class that serves as a factory 1476 for three GSS interfaces: GSSName, GSSCredential, and GSSContext. It 1477 also provides methods for applications to determine what mechanisms 1478 are available from the GSS implementation and what nametypes these 1479 mechanisms support. An instance of the default GSSManager subclass 1480 may be obtained through the static method getInstance(), but 1481 applications are free to instantiate other subclasses of GSSManager. 1483 All but one method in this class are declared abstract. This means 1484 that subclasses have to provide the complete implementation for those 1485 methods. The only exception to this is the static method 1486 getInstance() which will have platform specific code to return an 1487 instance of the default subclass. 1489 Platform providers of GSS are required not to add any constructors to 1490 this class, private, public, or protected. This will ensure that all 1491 subclasses invoke only the default constructor provided to the base 1492 class by the compiler. 1494 A subclass extending the GSSManager abstract class may be implemented 1495 as a modular provider based layer that utilizes some well known 1496 service provider specification. The GSSManager API provides the 1497 application with methods to set provider preferences on such an 1498 implementation. These methods also allow the implementation to throw 1499 a well-defined exception in case provider based configuration is not 1500 supported. Applications that expect to be portable should be aware 1501 of this and recover cleanly by catching the exception. 1503 It is envisioned that there will be three most common ways in which 1504 providers will be used: 1506 1) The application does not care about what provider is used (the 1507 default case). 1509 2) The application wants a particular provider to be used 1510 preferentially, either for a particular mechanism or all the time, 1511 irrespective of mechanism. 1513 3) The application wants to use the locally configured providers as 1514 far as possible but if support is missing for one or more mechanisms 1515 then it wants to fall back on its own provider. 1517 The GSSManager class has two methods that enable these modes of 1518 usage: addProviderAtFront() and addProviderAtEnd(). These methods 1519 have the effect of creating an ordered list of pairs 1520 where each pair indicates a preference of provider for a given oid. 1522 The use of these methods does not require any knowledge of whatever 1523 service provider specification the GSSManager subclass follows. It 1524 is hoped that these methods will serve the needs of most 1525 applications. Additional methods may be added to an extended 1526 GSSManager that could be part of a service provider specification 1527 that is standardized later. 1529 7.1.1 Example Code 1531 GSSManager mgr = GSSManager.getInstance(); 1533 // What mechs are available to us? 1534 Oid[] supportedMechs = mgr.getMechs(); 1536 // Set a preference for the provider to be used when support 1537 // is needed for the mechanisms: 1538 // "1.2.840.113554.1.2.2" and "1.3.6.1.5.5.1.1". 1540 Oid krb = new Oid("1.2.840.113554.1.2.2"); 1541 Oid spkm1 = new Oid("1.3.6.1.5.5.1.1"); 1543 Provider p = (Provider) (new com.foo.security.Provider()); 1545 mgr.addProviderAtFront(p, krb); 1546 mgr.addProviderAtFront(p, spkm1); 1548 // What name types does this spkm implementation support? 1549 Oid[] nameTypes = mgr.getNamesForMech(spkm1); 1551 Figure 9 1553 7.1.2 getInstance 1555 public static GSSManager getInstance() 1557 Returns the default GSSManager implementation. 1559 7.1.3 getMechs 1561 public abstract Oid[] getMechs() 1563 Returns an array of Oid objects indicating the mechanisms available 1564 to GSS-API callers. A "null" value is returned when no mechanism are 1565 available (an example of this would be when mechanism are dynamically 1566 configured, and currently no mechanisms are installed). 1568 7.1.4 getNamesForMech 1570 public abstract Oid[] getNamesForMech(Oid mech) 1571 throws GSSException 1573 Returns name type Oid's supported by the specified mechanism. 1575 Parameters: 1577 mech The Oid object for the mechanism to query. 1579 7.1.5 getMechsForName 1581 public abstract Oid[] getMechsForName(Oid nameType) 1583 Returns an array of Oid objects corresponding to the mechanisms that 1584 support the specific name type. "null" is returned when no mechanisms 1585 are found to support the specified name type. 1587 Parameters: 1589 nameType The Oid object for the name type. 1591 7.1.6 createName 1593 public abstract GSSName createName(String nameStr, Oid nameType) 1594 throws GSSException 1596 Factory method to convert a contiguous string name from the specified 1597 namespace to a GSSName object. In general, the GSSName object 1598 created will not be an MN; two examples that are exceptions to this 1599 are when the namespace type parameter indicates NT_EXPORT_NAME or 1600 when the GSS-API implementation is not multi-mechanism. 1602 Parameters: 1604 nameStr The string representing a printable form of the name to 1605 create. 1607 nameType The Oid specifying the namespace of the printable name 1608 supplied. Note that nameType serves to describe and qualify the 1609 interpretation of the input nameStr, it does not necessarily imply 1610 a type for the output GSSName implementation. "null" value can be 1611 used to specify that a mechanism specific default printable syntax 1612 should be assumed by each mechanism that examines nameStr. 1614 7.1.7 createName 1616 public abstract GSSName createName(byte[] name, Oid nameType) 1617 throws GSSException 1619 Factory method to convert a contiguous byte array containing a name 1620 from the specified namespace to a GSSName object. In general, the 1621 GSSName object created will not be an MN; two examples that are 1622 exceptions to this are when the namespace type parameter indicates 1623 NT_EXPORT_NAME or when the GSS-API implementation is not multi- 1624 mechanism. 1626 Parameters: 1628 name The byte array containing the name to create. 1630 nameType The Oid specifying the namespace of the name supplied 1631 in the byte array. Note that nameType serves to describe and 1632 qualify the interpretation of the input name byte array, it does 1633 not necessarily imply a type for the output GSSName 1634 implementation. "null" value can be used to specify that a 1635 mechanism specific default syntax should be assumed by each 1636 mechanism that examines the byte array. 1638 7.1.8 createName 1640 public abstract GSSName createName(String nameStr, Oid nameType, 1641 Oid mech) throws GSSException 1643 Factory method to convert a contiguous string name from the specified 1644 namespace to an GSSName object that is a mechanism name (MN). In 1645 other words, this method is a utility that does the equivalent of two 1646 steps: the createName described in 7.1.6 and then also the 1647 GSSName.canonicalize() described in 7.2.5. 1649 Parameters: 1651 nameStr The string representing a printable form of the name to 1652 create. 1654 nameType The Oid specifying the namespace of the printable name 1655 supplied. Note that nameType serves to describe and qualify the 1656 interpretation of the input nameStr, it does not necessarily imply 1657 a type for the output GSSName implementation. "null" value can be 1658 used to specify that a mechanism specific default printable syntax 1659 should be assumed when the mechanism examines nameStr. 1661 mech Oid specifying the mechanism for which this name should 1662 be created. 1664 7.1.9 createName 1666 public abstract GSSName createName(byte[] name, Oid nameType, 1667 Oid mech) throws GSSException 1669 Factory method to convert a contiguous byte array containing a name 1670 from the specified namespace to a GSSName object that is an MN. In 1671 other words, this method is a utility that does the equivalent of two 1672 steps: the createName described in 7.1.7 and then also the 1673 GSSName.canonicalize() described in 7.2.5. 1675 Parameters: 1677 name The byte array representing the name to create. 1679 nameType The Oid specifying the namespace of the name supplied in 1680 the byte array. Note that nameType serves to describe and qualify 1681 the interpretation of the input name byte array, it does not 1682 necessarily imply a type for the output GSSName implementation. 1683 "null" value can be used to specify that a mechanism specific 1684 default syntax should be assumed by each mechanism that examines 1685 the byte array. 1687 mech Oid specifying the mechanism for which this name should 1688 be created. 1690 7.1.10 createCredential 1692 public abstract GSSCredential createCredential(int usage) 1693 throws GSSException 1695 Factory method for acquiring default credentials. This will cause 1696 the GSS-API to use system specific defaults for the set of 1697 mechanisms, name, and a DEFAULT lifetime. 1699 Parameters: 1701 usage The intended usage for this credential object.The value 1702 of this parameter must be one of: 1703 GSSCredential.INITIATE_AND_ACCEPT(0), 1704 GSSCredential.INITIATE_ONLY(1), GSSCredential.ACCEPT_ONLY(2) 1706 7.1.11 createCredential 1708 public abstract GSSCredential createCredential(GSSName aName, 1709 int lifetime, Oid mech, int usage) 1710 throws GSSException 1712 Factory method for acquiring a single mechanism credential. 1714 Parameters: 1716 aName Name of the principal for whom this credential is to be 1717 acquired. Use "null" to specify the default principal. 1719 lifetime The number of seconds that credentials should remain 1720 valid. Use GSSCredential.INDEFINITE_LIFETIME to request that the 1721 credentials have the maximum permitted lifetime. Use 1722 GSSCredential.DEFAULT_LIFETIME to request default credential 1723 lifetime. 1725 mech The oid of the desired mechanism. Use "(Oid) null" to 1726 request the default mechanism(s). 1728 usage The intended usage for this credential object. The 1729 value of this parameter must be one of: 1730 GSSCredential.INITIATE_AND_ACCEPT(0), 1731 GSSCredential.INITIATE_ONLY(1), GSSCredential.ACCEPT_ONLY(2) 1733 7.1.12 createCredential 1735 public abstract GSSCredential createCredential(GSSName aName, 1736 int lifetime, Oid[] mechs, int usage) 1737 throws GSSException 1739 Factory method for acquiring credentials over a set of mechanisms. 1740 Acquires credentials for each of the mechanisms specified in the 1741 array called mechs. To determine the list of mechanisms' for which 1742 the acquisition of credentials succeeded, the caller should use the 1743 GSSCredential.getMechs() method. 1745 Parameters: 1747 aName Name of the principal for whom this credential is to be 1748 acquired. Use "null" to specify the default principal. 1750 lifetime The number of seconds that credentials should remain 1751 valid. Use GSSCredential.INDEFINITE_LIFETIME to request that the 1752 credentials have the maximum permitted lifetime. Use 1753 GSSCredential.DEFAULT_LIFETIME to request default credential 1754 lifetime. 1756 mechs The array of mechanisms over which the credential is to 1757 be acquired. Use "(Oid[]) null" for requesting a system specific 1758 default set of mechanisms. 1760 usage The intended usage for this credential object. The 1761 value of this parameter must be one of: 1762 GSSCredential.INITIATE_AND_ACCEPT(0), 1763 GSSCredential.INITIATE_ONLY(1), GSSCredential.ACCEPT_ONLY(2) 1765 7.1.13 createContext 1767 public abstract GSSContext createContext(GSSName peer, Oid mech, 1768 GSSCredential myCred, int lifetime) 1769 throws GSSException 1771 Factory method for creating a context on the initiator's side. 1772 Context flags may be modified through the mutator methods prior to 1773 calling GSSContext.initSecContext(). 1775 Parameters: 1777 peer Name of the target peer. 1779 mech Oid of the desired mechanism. Use "(Oid) null" to 1780 request the default mechanism. 1782 myCred Credentials of the initiator. Use "null" to act as a 1783 default initiator principal. 1785 lifetime The request lifetime, in seconds, for the context. Use 1786 GSSContext.INDEFINITE_LIFETIME and GSSContext.DEFAULT_LIFETIME to 1787 request indefinite or default context lifetime. 1789 7.1.14 createContext 1791 public abstract GSSContext createContext(GSSCredential myCred) 1792 throws GSSException 1794 Factory method for creating a context on the acceptor' side. The 1795 context's properties will be determined from the input token supplied 1796 to the accept method. 1798 Parameters: 1800 myCred Credentials for the acceptor. Use "null" to act as a 1801 default acceptor principal. 1803 7.1.15 createContext 1805 public abstract GSSContext createContext(byte[] interProcessToken) 1806 throws GSSException 1808 Factory method for creating a previously exported context. The 1809 context properties will be determined from the input token and can't 1810 be modified through the set methods. 1812 Parameters: 1814 interProcessToken The token previously emitted from the export 1815 method. 1817 7.1.16 addProviderAtFront 1819 public abstract void addProviderAtFront(Provider p, Oid mech) 1820 throws GSSException 1822 This method is used to indicate to the GSSManager that the 1823 application would like a particular provider to be used ahead of all 1824 others when support is desired for the given mechanism. When a value 1825 of null is used instead of an Oid for the mechanism, the GSSManager 1826 must use the indicated provider ahead of all others no matter what 1827 the mechanism is. Only when the indicated provider does not support 1828 the needed mechanism should the GSSManager move on to a different 1829 provider. 1831 Calling this method repeatedly preserves the older settings but 1832 lowers them in preference thus forming an ordered list of provider 1833 and Oid pairs that grows at the top. 1835 Calling addProviderAtFront with a null Oid will remove all previous 1836 preferences that were set for this provider in the GSSManager 1837 instance. Calling addProviderAtFront with a non-null Oid will remove 1838 any previous preference that was set using this mechanism and this 1839 provider together. 1841 If the GSSManager implementation does not support an SPI with a 1842 pluggable provider architecture it should throw a GSSException with 1843 the status code GSSException.UNAVAILABLE to indicate that the 1844 operation is unavailable. 1846 Parameters: 1848 p The provider instance that should be used whenever 1849 support is needed for mech. 1851 mech The mechanism for which the provider is being set 1853 7.1.17 Example Code 1855 Suppose an application desired that the provider A always be checked 1856 first when any mechanism is needed, it would call: 1858 GSSManager mgr = GSSManager.getInstance(); 1859 // mgr may at this point have its own pre-configured list 1860 // of provider preferences. The following will prepend to 1861 // any such list: 1863 mgr.addProviderAtFront(A, null); 1865 Now if it also desired that the mechanism of Oid m1 always be 1866 obtained from the provider B before the previously set A was checked, 1867 it would call: 1869 mgr.addProviderAtFront(B, m1); 1871 The GSSManager would then first check with B if m1 was needed. In 1872 case B did not provide support for m1, the GSSManager would continue 1873 on to check with A. If any mechanism m2 is needed where m2 is 1874 different from m1 then the GSSManager would skip B and check with A 1875 directly. 1877 Suppose at a later time the following call is made to the same 1878 GSSManager instance: 1880 mgr.addProviderAtFront(B, null) 1882 then the previous setting with the pair (B, m1) is subsumed by this 1883 and should be removed. Effectively the list of preferences now 1884 becomes {(B, null), (A, null), ... //followed by the pre-configured 1885 list. 1887 Please note, however, that the following call: 1889 mgr.addProviderAtFront(A, m3) 1891 does not subsume the previous setting of (A, null) and the list will 1892 effectively become {(A, m3), (B, null), (A, null), ...} 1894 7.1.18 addProviderAtEnd 1896 public abstract void addProviderAtEnd(Provider p, Oid mech) 1897 throws GSSException 1899 This method is used to indicate to the GSSManager that the 1900 application would like a particular provider to be used if no other 1901 provider can be found that supports the given mechanism. When a 1902 value of null is used instead of an Oid for the mechanism, the 1903 GSSManager must use the indicated provider for any mechanism. 1905 Calling this method repeatedly preserves the older settings but 1906 raises them above newer ones in preference thus forming an ordered 1907 list of providers and Oid pairs that grows at the bottom. Thus the 1908 older provider settings will be utilized first before this one is. 1910 If there are any previously existing preferences that conflict with 1911 the preference being set here, then the GSSManager should ignore this 1912 request. 1914 If the GSSManager implementation does not support an SPI with a 1915 pluggable provider architecture it should throw a GSSException with 1916 the status code GSSException.UNAVAILABLE to indicate that the 1917 operation is unavailable. 1919 Parameters: 1921 p The provider instance that should be used whenever 1922 support is needed for mech. 1924 mech The mechanism for which the provider is being set 1926 7.1.19 Example Code 1928 Suppose an application desired that when a mechanism of Oid m1 is 1929 needed the system default providers always be checked first, and only 1930 when they do not support m1 should a provider A be checked. It would 1931 then make the call: 1933 GSSManager mgr = GSSManager.getInstance(); 1935 mgr.addProviderAtEnd(A, m1); 1937 Now, if it also desired that for all mechanisms the provider B be 1938 checked after all configured providers have been checked, it would 1939 then call: 1941 mgr.addProviderAtEnd(B, null); 1943 Effectively the list of preferences now becomes {..., (A, m1), (B, 1944 null)}. 1946 Suppose at a later time the following call is made to the same 1947 GSSManager instance: 1949 mgr.addProviderAtEnd(B, m2) 1951 then the previous setting with the pair (B, null) subsumes this and 1952 therefore this request should be ignored. The same would happen if a 1953 request is made for the already existing pairs of (A, m1) or (B, 1954 null). 1956 Please note, however, that the following call: 1958 mgr.addProviderAtEnd(A, null) 1960 is not subsumed by the previous setting of (A, m1) and the list will 1961 effectively become {..., (A, m1), (B, null), (A, null)} 1963 7.2 public interface GSSName 1965 This interface encapsulates a single GSS-API principal entity. 1966 Different name formats and their definitions are identified with 1967 universal Object Identifiers (Oids). The format of the names can be 1968 derived based on the unique oid of its namespace type. 1970 7.2.1 Example Code 1972 Included below are code examples utilizing the GSSName interface. 1973 The code below creates a GSSName, converts it to a mechanism name 1974 (MN), performs a comparison, obtains a printable representation of 1975 the name, exports it and then re-imports to obtain a new GSSName. 1977 GSSManager mgr = GSSManager.getInstance(); 1979 // create a host based service name 1980 GSSName name = mgr.createName("service@host", 1981 GSSName.NT_HOSTBASED_SERVICE); 1983 Oid krb5 = new Oid("1.2.840.113554.1.2.2"); 1985 GSSName mechName = name.canonicalize(krb5); 1987 // the above two steps are equivalent to the following 1988 GSSName mechName = mgr.createName("service@host", 1989 GSSName.NT_HOSTBASED_SERVICE, krb5); 1991 // perform name comparison 1992 if (name.equals(mechName)) 1993 print("Names are equals."); 1995 // obtain textual representation of name and its printable 1996 // name type 1997 print(mechName.toString() + 1998 mechName.getStringNameType().toString()); 2000 // export and re-import the name 2001 byte[] exportName = mechName.export(); 2003 // create a new name object from the exported buffer 2004 GSSName newName = mgr.createName(exportName, 2005 GSSName.NT_EXPORT_NAME); 2007 7.2.2 Static Constants 2009 public static final Oid NT_HOSTBASED_SERVICE 2011 Oid indicating a host-based service name form. It is used to 2012 represent services associated with host computers. This name form is 2013 constructed using two elements, "service" and "hostname", as follows: 2015 service@hostname 2017 Values for the "service" element are registered with the IANA. It 2018 represents the following value: { 1(iso), 3(org), 6(dod), 2019 1(internet), 5(security), 6(nametypes), 2(gss-host-based-services) } 2021 public static final Oid NT_USER_NAME 2023 Name type to indicate a named user on a local system. It represents 2024 the following value: { iso(1) member-body(2) United States(840) 2025 mit(113554) infosys(1) gssapi(2) generic(1) user_name(1) } 2027 public static final Oid NT_MACHINE_UID_NAME 2029 Name type to indicate a numeric user identifier corresponding to a 2030 user on a local system. (e.g. Uid). It represents the following 2031 value: { iso(1) member-body(2) United States(840) mit(113554) 2032 infosys(1) gssapi(2) generic(1) machine_uid_name(2) } 2034 public static final Oid NT_STRING_UID_NAME 2036 Name type to indicate a string of digits representing the numeric 2037 user identifier of a user on a local system. It represents the 2038 following value: { iso(1) member-body(2) United States(840) 2039 mit(113554) infosys(1) gssapi(2) generic(1) string_uid_name(3) } 2041 public static final Oid NT_ANONYMOUS 2043 Name type for representing an anonymous entity. It represents the 2044 following value: { 1(iso), 3(org), 6(dod), 1(internet), 5(security), 2045 6(nametypes), 3(gss-anonymous-name) } 2047 public static final Oid NT_EXPORT_NAME 2049 Name type used to indicate an exported name produced by the export 2050 method. It represents the following value: { 1(iso), 3(org), 6(dod), 2051 1(internet), 5(security), 6(nametypes), 4(gss-api-exported-name) } 2053 7.2.3 equals 2055 public boolean equals(GSSName another) throws GSSException 2057 Compares two GSSName objects to determine whether they refer to the 2058 same entity. This method may throw a GSSException when the names 2059 cannot be compared. If either of the names represents an anonymous 2060 entity, the method will return "false". 2062 Parameters: 2064 another GSSName object to compare with. 2066 7.2.4 equals 2068 public boolean equals(Object another) 2070 A variation of the equals method described in 7.2.3 that is provided 2071 to override the Object.equals() method that the implementing class 2072 will inherit. The behavior is exactly the same as that in 7.2.3 2073 except that no GSSException is thrown; instead, false will be 2074 returned in the situation where an error occurs. (Note that the Java 2075 language specification requires that two objects that are equal 2076 according to the equals(Object) method must return the same integer 2077 result when the hashCode() method is called on them.) 2079 Parameters: 2081 another GSSName object to compare with. 2083 7.2.5 canonicalize 2085 public GSSName canonicalize(Oid mech) throws GSSException 2087 Creates a mechanism name (MN) from an arbitrary internal name. This 2088 is equivalent to using the factory methods described in 7.1.8 or 2089 7.1.9 that take the mechanism name as one of their parameters. 2091 Parameters: 2093 mech The oid for the mechanism for which the canonical form 2094 of the name is requested. 2096 7.2.6 export 2098 public byte[] export() throws GSSException 2100 Returns a canonical contiguous byte representation of a mechanism 2101 name (MN), suitable for direct, byte by byte comparison by 2102 authorization functions. If the name is not an MN, implementations 2103 may throw a GSSException with the NAME_NOT_MN status code. If an 2104 implementation chooses not to throw an exception, it should use some 2105 system specific default mechanism to canonicalize the name and then 2106 export it. The format of the header of the output buffer is 2107 specified in RFC 2743. 2109 7.2.7 toString 2111 public String toString() 2113 Returns a textual representation of the GSSName object. To retrieve 2114 the printed name format, which determines the syntax of the returned 2115 string, the getStringNameType method can be used. 2117 7.2.8 getStringNameType 2119 public Oid getStringNameType() throws GSSException 2121 Returns the oid representing the type of name returned through the 2122 toString method. Using this oid, the syntax of the printable name 2123 can be determined. 2125 7.2.9 isAnonymous 2127 public boolean isAnonymous() 2129 Tests if this name object represents an anonymous entity. Returns 2130 "true" if this is an anonymous name. 2132 7.2.10 isMN 2134 public boolean isMN() 2136 Tests if this name object contains only one mechanism element and is 2137 thus a mechanism name as defined by RFC 2743. 2139 7.3 public interface GSSCredential implements Cloneable 2141 This interface encapsulates the GSS-API credentials for an entity. A 2142 credential contains all the necessary cryptographic information to 2143 enable the creation of a context on behalf of the entity that it 2144 represents. It may contain multiple, distinct, mechanism specific 2145 credential elements, each containing information for a specific 2146 security mechanism, but all referring to the same entity. 2148 A credential may be used to perform context initiation, acceptance, 2149 or both. 2151 GSS-API implementations must impose a local access-control policy on 2152 callers to prevent unauthorized callers from acquiring credentials to 2153 which they are not entitled. GSS-API credential creation is not 2154 intended to provide a "login to the network" function, as such a 2155 function would involve the creation of new credentials rather than 2156 merely acquiring a handle to existing credentials. Such functions, 2157 if required, should be defined in implementation-specific extensions 2158 to the API. 2160 If credential acquisition is time-consuming for a mechanism, the 2161 mechanism may choose to delay the actual acquisition until the 2162 credential is required (e.g. by GSSContext). Such mechanism- 2163 specific implementation decisions should be invisible to the calling 2164 application; thus the query methods immediately following the 2165 creation of a credential object must return valid credential data, 2166 and may therefore incur the overhead of a deferred credential 2167 acquisition. 2169 Applications will create a credential object passing the desired 2170 parameters. The application can then use the query methods to obtain 2171 specific information about the instantiated credential object 2172 (equivalent to the gss_inquire routines). When the credential is no 2173 longer needed, the application should call the dispose (equivalent to 2174 gss_release_cred) method to release any resources held by the 2175 credential object and to destroy any cryptographically sensitive 2176 information. 2178 Classes implementing this interface also implement the Cloneable 2179 interface. This indicates the the class will support the clone() 2180 method that will allow the creation of duplicate credentials. This 2181 is useful when called just before the add() call to retain a copy of 2182 the original credential. 2184 7.3.1 Example Code 2186 This example code demonstrates the creation of a GSSCredential 2187 implementation for a specific entity, querying of its fields, and its 2188 release when it is no longer needed. 2190 GSSManager mgr = GSSManager.getInstance(); 2192 // start by creating a name object for the entity 2193 GSSName name = mgr.createName("userName", GSSName.NT_USER_NAME); 2195 // now acquire credentials for the entity 2196 GSSCredential cred = mgr.createCredential(name, 2197 GSSCredential.ACCEPT_ONLY); 2199 // display credential information - name, remaining lifetime, 2200 // and the mechanisms it has been acquired over 2201 print(cred.getName().toString()); 2202 print(cred.getRemainingLifetime()); 2204 Oid[] mechs = cred.getMechs(); 2205 if (mechs != null) { 2206 for (int i = 0; i < mechs.length; i++) 2207 print(mechs[i].toString()); 2208 } 2210 // release system resources held by the credential 2211 cred.dispose(); 2213 7.3.2 Static Constants 2215 public static final int INITIATE_AND_ACCEPT 2217 Credential usage flag requesting that it be able to be used for both 2218 context initiation and acceptance. The value of this constant is 0. 2220 public static final int INITIATE_ONLY 2222 Credential usage flag requesting that it be able to be used for 2223 context initiation only. The value of this constant is 1. 2225 public static final int ACCEPT_ONLY 2227 Credential usage flag requesting that it be able to be used for 2228 context acceptance only. The value of this constant is 2. 2230 public static final int DEFAULT_LIFETIME 2232 A lifetime constant representing the default credential lifetime. 2233 The value of this constant is 0. 2235 public static final int INDEFINITE_LIFETIME 2237 A lifetime constant representing indefinite credential lifetime. The 2238 value of this constant is the maximum integer value in Java - 2239 Integer.MAX_VALUE. 2241 7.3.3 dispose 2243 public void dispose() throws GSSException 2245 Releases any sensitive information that the GSSCredential object may 2246 be containing. Applications should call this method as soon as the 2247 credential is no longer needed to minimize the time any sensitive 2248 information is maintained. 2250 7.3.4 getName 2252 public GSSName getName() throws GSSException 2254 Retrieves the name of the entity that the credential asserts. 2256 7.3.5 getName 2258 public GSSName getName(Oid mechOID) throws GSSException 2260 Retrieves a mechanism name of the entity that the credential asserts. 2262 Equivalent to calling canonicalize() on the name returned by 7.3.4. 2264 Parameters: 2266 mechOID The mechanism for which information should be returned. 2268 7.3.6 getRemainingLifetime 2270 public int getRemainingLifetime() throws GSSException 2272 Returns the remaining lifetime in seconds for a credential. The 2273 remaining lifetime is the minimum lifetime for any of the underlying 2274 credential mechanisms. A return value of 2275 GSSCredential.INDEFINITE_LIFETIME indicates that the credential does 2276 not expire. A return value of 0 indicates that the credential is 2277 already expired. 2279 7.3.7 getRemainingInitLifetime 2281 public int getRemainingInitLifetime(Oid mech) throws GSSException 2283 Returns the remaining lifetime is seconds for the credential to 2284 remain capable of initiating security contexts under the specified 2285 mechanism. A return value of GSSCredential.INDEFINITE_LIFETIME 2286 indicates that the credential does not expire for context initiation. 2287 A return value of 0 indicates that the credential is already expired. 2289 Parameters: 2291 mechOID The mechanism for which information should be returned. 2293 7.3.8 getRemainingAcceptLifetime 2295 public int getRemainingAcceptLifetime(Oid mech) throws GSSException 2297 Returns the remaining lifetime is seconds for the credential to 2298 remain capable of accepting security contexts under the specified 2299 mechanism. A return value of GSSCredential.INDEFINITE_LIFETIME 2300 indicates that the credential does not expire for context acceptance. 2301 A return value of 0 indicates that the credential is already expired. 2303 Parameters: 2305 mechOID The mechanism for which information should be returned. 2307 7.3.9 getUsage 2309 public int getUsage() throws GSSException 2311 Returns the credential usage flag as a union over all mechanisms. 2312 The return value will be one of GSSCredential.INITIATE_AND_ACCEPT(0), 2313 GSSCredential.INITIATE_ONLY(1), or GSSCredential.ACCEPT_ONLY(2). 2315 7.3.10 getUsage 2317 public int getUsage(Oid mechOID) throws GSSException 2319 Returns the credential usage flag for the specified mechanism only. 2320 The return value will be one of GSSCredential.INITIATE_AND_ACCEPT(0), 2321 GSSCredential.INITIATE_ONLY(1), or GSSCredential.ACCEPT_ONLY(2). 2323 Parameters: 2325 mechOID The mechanism for which information should be returned. 2327 7.3.11 getMechs 2329 public Oid[] getMechs() throws GSSException 2331 Returns an array of mechanisms supported by this credential. 2333 7.3.12 add 2335 public void add(GSSName aName, int initLifetime, int acceptLifetime, 2336 Oid mech, int usage) throws GSSException 2338 Adds a mechanism specific credential-element to an existing 2339 credential. This method allows the construction of credentials one 2340 mechanism at a time. 2342 This routine is envisioned to be used mainly by context acceptors 2343 during the creation of acceptance credentials which are to be used 2344 with a variety of clients using different security mechanisms. 2346 This routine adds the new credential element "in-place". To add the 2347 element in a new credential, first call clone() to obtain a copy of 2348 this credential, then call its add() method. 2350 Parameters: 2352 aName Name of the principal for whom this credential is to be 2353 acquired. Use "null" to specify the default principal. 2355 initLifetime The number of seconds that credentials should remain 2356 valid for initiating of security contexts. Use 2357 GSSCredential.INDEFINITE_LIFETIME to request that the credentials 2358 have the maximum permitted lifetime. Use 2359 GSSCredential.DEFAULT_LIFETIME to request default credential 2360 lifetime. 2362 acceptLifetime The number of seconds that credentials should 2363 remain valid for accepting of security contexts. Use 2364 GSSCredential.INDEFINITE_LIFETIME to request that the credentials 2365 have the maximum permitted lifetime. Use 2366 GSSCredential.DEFAULT_LIFETIME to request default credential 2367 lifetime. 2369 mech The mechanisms over which the credential is to be 2370 acquired. 2372 usage The intended usage for this credential object. The 2373 value of this parameter must be one of: 2374 GSSCredential.INITIATE_AND_ACCEPT(0), 2375 GSSCredential.INITIATE_ONLY(1), GSSCredential.ACCEPT_ONLY(2) 2377 7.3.13 equals 2379 public boolean equals(Object another) 2381 Tests if this GSSCredential refers to the same entity as the supplied 2382 object. The two credentials must be acquired over the same 2383 mechanisms and must refer to the same principal. Returns "true" if 2384 the two GSSCredentials refer to the same entity; "false" otherwise. 2385 (Note that the Java language specification requires that two objects 2386 that are equal according to the equals(Object) method must return the 2387 same integer result when the hashCode() method is called on them.) 2389 Parameters: 2391 another Another GSSCredential object for comparison. 2393 7.4 public interface GSSContext 2395 This interface encapsulates the GSS-API security context and provides 2396 the security services (wrap, unwrap, getMIC, verifyMIC) that are 2397 available over the context. Security contexts are established between 2398 peers using locally acquired credentials. Multiple contexts may 2399 exist simultaneously between a pair of peers, using the same or 2400 different set of credentials. GSS-API functions in a manner 2401 independent of the underlying transport protocol and depends on its 2402 calling application to transport its tokens between peers. 2404 Before the context establishment phase is initiated, the context 2405 initiator may request specific characteristics desired of the 2406 established context. These can be set using the set methods. After 2407 the context is established, the caller can check the actual 2408 characteristic and services offered by the context using the query 2409 methods. 2411 The context establishment phase begins with the first call to the 2412 init method by the context initiator. During this phase the 2413 initSecContext and acceptSecContext methods will produce GSS-API 2414 authentication tokens which the calling application needs to send to 2415 its peer. If an error occurs at any point, an exception will get 2416 thrown and the code will start executing in a catch block. If not, 2417 the normal flow of code continues and the application can make a call 2418 to the isEstablished() method. If this method returns false it 2419 indicates that a token is needed from its peer in order to continue 2420 the context establishment phase. A return value of true signals that 2421 the local end of the context is established. This may still require 2422 that a token be sent to the peer, if one is produced by GSS-API. 2423 During the context establishment phase, the isProtReady() method may 2424 be called to determine if the context can be used for the per-message 2425 operations. This allows applications to use per-message operations on 2426 contexts which aren't fully established. 2428 After the context has been established or the isProtReady() method 2429 returns "true", the query routines can be invoked to determine the 2430 actual characteristics and services of the established context. The 2431 application can also start using the per-message methods of wrap and 2432 getMIC to obtain cryptographic operations on application supplied 2433 data. 2435 When the context is no longer needed, the application should call 2436 dispose to release any system resources the context may be using. 2438 7.4.1 Example Code 2440 The example code presented below demonstrates the usage of the 2441 GSSContext interface for the initiating peer. Different operations 2442 on the GSSContext object are presented, including: object 2443 instantiation, setting of desired flags, context establishment, query 2444 of actual context flags, per-message operations on application data, 2445 and finally context deletion. 2447 GSSManager mgr = GSSManager.getInstance(); 2448 // start by creating the name for a service entity 2449 GSSName targetName = mgr.createName("service@host", 2450 GSSName.NT_HOSTBASED_SERVICE); 2452 // create a context using default credentials for the above entity 2453 // and the implementation specific default mechanism 2454 GSSContext context = mgr.createContext(targetName, 2455 null, /* default mechanism */ 2456 null, /* default credentials */ 2457 GSSContext.INDEFINITE_LIFETIME); 2459 // set desired context options - all others are false by default 2460 context.requestConf(true); 2461 context.requestMutualAuth(true); 2462 context.requestReplayDet(true); 2463 context.requestSequenceDet(true); 2465 // establish a context between peers - using byte arrays 2466 byte[]inTok = new byte[0]; 2468 try { 2469 do { 2470 byte[] outTok = context.initSecContext(inTok, 0, 2471 inTok.length); 2473 // send the token if present 2474 if (outTok != null) 2475 sendToken(outTok); 2477 // check if we should expect more tokens 2478 if (context.isEstablished()) 2479 break; 2481 // another token expected from peer 2482 inTok = readToken(); 2484 } while (true); 2486 } catch (GSSException e) { 2487 print("GSSAPI error: " + e.getMessage()); 2488 } 2490 // display context information 2491 print("Remaining lifetime in seconds = " + context.getLifetime()); 2492 print("Context mechanism = " + context.getMech().toString()); 2493 print("Initiator = " + context.getSrcName().toString()); 2494 print("Acceptor = " + context.getTargName().toString()); 2495 if (context.getConfState()) 2496 print("Confidentiality security service available"); 2498 if (context.getIntegState()) 2499 print("Integrity security service available"); 2501 // perform wrap on an application supplied message, appMsg, 2502 // using QOP = 0, and requesting privacy service 2503 byte[] appMsg ... 2505 MessageProp mProp = new MessageProp(0, true); 2507 byte[] tok = context.wrap(appMsg, 0, appMsg.length, mProp); 2509 if (mProp.getPrivacy()) 2510 print("Message protected with privacy."); 2512 sendToken(tok); 2514 // release the local-end of the context 2515 context.dispose(); 2517 7.4.2 Static Constants 2519 public static final int DEFAULT_LIFETIME 2521 A lifetime constant representing the default context lifetime. The 2522 value of this constant is 0. 2524 public static final int INDEFINITE_LIFETIME 2526 A lifetime constant representing indefinite context lifetime. The 2527 value of this constant is the maximum integer value in Java - 2528 Integer.MAX_VALUE. 2530 7.4.3 initSecContext 2532 public byte[] initSecContext(byte[] inputBuf, int offset, int len) 2533 throws GSSException 2535 Called by the context initiator to start the context creation 2536 process. This is equivalent to the stream based method except that 2537 the token buffers are handled as byte arrays instead of using stream 2538 objects. This method may return an output token which the 2539 application will need to send to the peer for processing by the 2540 accept call. Typically, the application would do so by calling the 2541 flush() method on an OutputStream that encapsulates the connection 2542 between the two peers. The application can call isEstablished() to 2543 determine if the context establishment phase is complete for this 2544 peer. A return value of "false" from isEstablished() indicates that 2545 more tokens are expected to be supplied to the initSecContext() 2546 method. Note that it is possible that the initSecContext() method 2547 return a token for the peer, and isEstablished() return "true" also. 2548 This indicates that the token needs to be sent to the peer, but the 2549 local end of the context is now fully established. 2551 Upon completion of the context establishment, the available context 2552 options may be queried through the get methods. 2554 Parameters: 2556 inputBuf Token generated by the peer. This parameter is ignored 2557 on the first call. 2559 offset The offset within the inputBuf where the token begins. 2561 len The length of the token within the inputBuf (starting at 2562 the offset). 2564 7.4.4 Example Code 2566 // Create a new GSSContext implementation object. 2567 // GSSContext wrapper implements interface GSSContext. 2568 GSSContext context = mgr.createContext(...); 2570 byte[] inTok = new byte[0]; 2572 try { 2573 do { 2574 byte[] outTok = context.initSecContext(inTok, 0, 2575 inTok.length); 2577 // send the token if present 2578 if (outTok != null) 2579 sendToken(outTok); 2581 // check if we should expect more tokens 2582 if (context.isEstablished()) 2583 break; 2585 // another token expected from peer 2586 inTok = readToken(); 2587 } while (true); 2589 } catch (GSSException e) { 2590 print("GSSAPI error: " + e.getMessage()); 2591 } 2593 7.4.5 initSecContext 2595 public int initSecContext(InputStream inStream, 2596 OutputStream outStream) throws GSSException 2598 Called by the context initiator to start the context creation 2599 process. This is equivalent to the byte array based method. This 2600 method may write an output token to the outStream, which the 2601 application will need to send to the peer for processing by the 2602 accept call. Typically, the application would do so by calling the 2603 flush() method on an OutputStream that encapsulates the connection 2604 between the two peers. The application can call isEstablished() to 2605 determine if the context establishment phase is complete for this 2606 peer. A return value of "false" from isEstablished indicates that 2607 more tokens are expected to be supplied to the initSecContext method. 2608 Note that it is possible that the initSecContext() method return a 2609 token for the peer, and isEstablished() return "true" also. This 2610 indicates that the token needs to be sent to the peer, but the local 2611 end of the context is now fully established. 2613 The GSS-API authentication tokens contain a definitive start and end. 2614 This method will attempt to read one of these tokens per invocation, 2615 and may block on the stream if only part of the token is available. 2617 Upon completion of the context establishment, the available context 2618 options may be queried through the get methods. 2620 Parameters: 2622 inStream Contains the token generated by the peer. This 2623 parameter is ignored on the first call. 2625 outStream Output stream where the output token will be written. 2626 During the final stage of context establishment, there may be no 2627 bytes written. 2629 7.4.6 Example Code 2631 This sample code merely demonstrates the token exchange during the 2632 context establishment phase. It is expected that most Java 2633 applications will use custom implementations of the Input and Output 2634 streams that encapsulate the communication routines. For instance, a 2635 simple read on the application InputStream, when called by the 2636 Context, might cause a token to be read from the peer, and a simple 2637 flush() on the application OutputStream might cause a previously 2638 written token to be transmitted to the peer. 2640 // Create a new GSSContext implementation object. 2641 // GSSContext wrapper implements interface GSSContext. 2642 GSSContext context = mgr.createContext(...); 2644 // use standard java.io stream objects 2645 ByteArrayOutputStream os = new ByteArrayOutputStream(); 2646 ByteArrayInputStream is = null; 2648 try { 2649 do { 2650 context.initSecContext(is, os); 2652 // send token if present 2653 if (os.size() > 0) 2654 sendToken(os); 2656 // check if we should expect more tokens 2657 if (context.isEstablished()) 2658 break; 2660 // another token expected from peer 2661 is = recvToken(); 2663 } while (true); 2665 } catch (GSSException e) { 2666 print("GSSAPI error: " + e.getMessage()); 2667 } 2669 7.4.7 acceptSecContext 2671 public byte[] acceptSecContext(byte[] inTok, int offset, int len) 2672 throws GSSException 2674 Called by the context acceptor upon receiving a token from the peer. 2675 This call is equivalent to the stream based method except that the 2676 token buffers are handled as byte arrays instead of using stream 2677 objects. 2679 This method may return an output token which the application will 2680 need to send to the peer for further processing by the init call. 2682 "null" return value indicates that no token needs to be sent to the 2683 peer. The application can call isEstablished() to determine if the 2684 context establishment phase is complete for this peer. A return 2685 value of "false" from isEstablished() indicates that more tokens are 2686 expected to be supplied to this method. 2688 Note that it is possible that acceptSecContext() return a token for 2689 the peer, and isEstablished() return "true" also. This indicates 2690 that the token needs to be sent to the peer, but the local end of the 2691 context is now fully established. 2693 Upon completion of the context establishment, the available context 2694 options may be queried through the get methods. 2696 Parameters: 2698 inTok Token generated by the peer. 2700 offset The offset within the inTok where the token begins. 2702 len The length of the token within the inTok (starting at 2703 the offset). 2705 7.4.8 Example Code 2707 // acquire server credentials 2708 GSSCredential server = mgr.createCredential(...); 2710 // create acceptor GSS-API context from the default provider 2711 GSSContext context = mgr.createContext(server, null); 2713 try { 2714 do { 2715 byte[] inTok = readToken(); 2717 byte[] outTok = context.acceptSecContext(inTok, 0, 2718 inTok.length); 2720 // possibly send token to peer 2721 if (outTok != null) 2722 sendToken(outTok); 2724 // check if local context establishment is complete 2725 if (context.isEstablished()) 2726 break; 2727 } while (true); 2729 } catch (GSSException e) { 2730 print("GSS-API error: " + e.getMessage()); 2731 } 2733 7.4.9 acceptSecContext 2735 public void acceptSecContext(InputStream inStream, 2736 OutputStream outStream) throws GSSException 2738 Called by the context acceptor upon receiving a token from the peer. 2739 This call is equivalent to the byte array method. It may write an 2740 output token to the outStream, which the application will need to 2741 send to the peer for processing by its initSecContext method. 2742 Typically, the application would do so by calling the flush() method 2743 on an OutputStream that encapsulates the connection between the two 2744 peers. The application can call isEstablished() to determine if the 2745 context establishment phase is complete for this peer. A return 2746 value of "false" from isEstablished() indicates that more tokens are 2747 expected to be supplied to this method. 2749 Note that it is possible that acceptSecContext() return a token for 2750 the peer, and isEstablished() return "true" also. This indicates 2751 that the token needs to be sent to the peer, but the local end of the 2752 context is now fully established. 2754 The GSS-API authentication tokens contain a definitive start and end. 2755 This method will attempt to read one of these tokens per invocation, 2756 and may block on the stream if only part of the token is available. 2758 Upon completion of the context establishment, the available context 2759 options may be queried through the get methods. 2761 Parameters: 2763 inStream Contains the token generated by the peer. 2765 outStream Output stream where the output token will be written. 2766 During the final stage of context establishment, there may be no 2767 bytes written. 2769 7.4.10 Example Code 2771 This sample code merely demonstrates the token exchange during the 2772 context establishment phase. It is expected that most Java 2773 applications will use custom implementations of the Input and Output 2774 streams that encapsulate the communication routines. For instance, a 2775 simple read on the application InputStream, when called by the 2776 Context, might cause a token to be read from the peer, and a simple 2777 flush() on the application OutputStream might cause a previously 2778 written token to be transmitted to the peer. 2780 // acquire server credentials 2781 GSSCredential server = mgr.createCredential(...); 2783 // create acceptor GSS-API context from the default provider 2784 GSSContext context = mgr.createContext(server, null); 2786 // use standard java.io stream objects 2787 ByteArrayOutputStream os = new ByteArrayOutputStream(); 2788 ByteArrayInputStream is = null; 2790 try { 2791 do { 2793 is = recvToken(); 2795 context.acceptSecContext(is, os); 2797 // possibly send token to peer 2798 if (os.size() > 0) 2799 sendToken(os); 2801 // check if local context establishment is complete 2802 if (context.isEstablished()) 2803 break; 2804 } while (true); 2806 } catch (GSSException e) { 2807 print("GSS-API error: " + e.getMessage()); 2808 } 2810 7.4.11 isEstablished 2812 public boolean isEstablished() 2814 Used during context establishment to determine the state of the 2815 context. Returns "true" if this is a fully established context on 2816 the caller's side and no more tokens are needed from the peer. 2817 Should be called after a call to initSecContext() or 2818 acceptSecContext() when no GSSException is thrown. 2820 7.4.12 dispose 2822 public void dispose() throws GSSException 2824 Releases any system resources and cryptographic information stored in 2825 the context object. This will invalidate the context. 2827 7.4.13 getWrapSizeLimit 2829 public int getWrapSizeLimit(int qop, boolean confReq, 2830 int maxTokenSize) throws GSSException 2832 Returns the maximum message size that, if presented to the wrap 2833 method with the same confReq and qop parameters, will result in an 2834 output token containing no more than the maxTokenSize bytes. 2836 This call is intended for use by applications that communicate over 2837 protocols that impose a maximum message size. It enables the 2838 application to fragment messages prior to applying protection. 2840 GSS-API implementations are recommended but not required to detect 2841 invalid QOP values when getWrapSizeLimit is called. This routine 2842 guarantees only a maximum message size, not the availability of 2843 specific QOP values for message protection. 2845 Successful completion of this call does not guarantee that wrap will 2846 be able to protect a message of the computed length, since this 2847 ability may depend on the availability of system resources at the 2848 time that wrap is called. However, if the implementation itself 2849 imposes an upper limit on the length of messages that may be 2850 processed by wrap, the implementation should not return a value that 2851 is greater than this length. 2853 Parameters: 2855 qop Indicates the level of protection wrap will be asked to 2856 provide. 2858 confReq Indicates if wrap will be asked to provide privacy 2859 service. 2861 maxTokenSize The desired maximum size of the token emitted by 2862 wrap. 2864 7.4.14 wrap 2866 public byte[] wrap(byte[] inBuf, int offset, int len, 2867 MessageProp msgProp) throws GSSException 2869 Applies per-message security services over the established security 2870 context. The method will return a token with a cryptographic MIC and 2871 may optionally encrypt the specified inBuf. This method is equivalent 2872 in functionality to its stream counterpart. The returned byte array 2873 will contain both the MIC and the message. 2875 The MessageProp object is instantiated by the application and used to 2876 specify a QOP value which selects cryptographic algorithms, and a 2877 privacy service to optionally encrypt the message. The underlying 2878 mechanism that is used in the call may not be able to provide the 2879 privacy service. It sets the actual privacy service that it does 2880 provide in this MessageProp object which the caller should then query 2881 upon return. If the mechanism is not able to provide the requested 2882 QOP, it throws a GSSException with the BAD_QOP code. 2884 Since some application-level protocols may wish to use tokens emitted 2885 by wrap to provide "secure framing", implementations should support 2886 the wrapping of zero-length messages. 2888 The application will be responsible for sending the token to the 2889 peer. 2891 Parameters: 2893 inBuf Application data to be protected. 2895 offset The offset within the inBuf where the data begins. 2897 len The length of the data within the inBuf (starting at the 2898 offset). 2900 msgProp Instance of MessageProp that is used by the application 2901 to set the desired QOP and privacy state. Set the desired QOP to 2902 0 to request the default QOP. Upon return from this method, this 2903 object will contain the the actual privacy state that was applied 2904 to the message by the underlying mechanism. 2906 7.4.15 wrap 2908 public void wrap(InputStream inStream, OutputStream outStream, 2909 MessageProp msgProp) throws GSSException 2911 Allows to apply per-message security services over the established 2912 security context. The method will produce a token with a 2913 cryptographic MIC and may optionally encrypt the message in inStream. 2914 The outStream will contain both the MIC and the message. 2916 The MessageProp object is instantiated by the application and used to 2917 specify a QOP value which selects cryptographic algorithms, and a 2918 privacy service to optionally encrypt the message. The underlying 2919 mechanism that is used in the call may not be able to provide the 2920 privacy service. It sets the actual privacy service that it does 2921 provide in this MessageProp object which the caller should then query 2922 upon return. If the mechanism is not able to provide the requested 2923 QOP, it throws a GSSException with the BAD_QOP code. 2925 Since some application-level protocols may wish to use tokens emitted 2926 by wrap to provide "secure framing", implementations should support 2927 the wrapping of zero-length messages. 2929 The application will be responsible for sending the token to the 2930 peer. 2932 Parameters: 2934 inStream Input stream containing the application data to be 2935 protected. 2937 outStream The output stream to write the protected message to. 2938 The application is responsible for sending this to the other peer 2939 for processing in its unwrap method. 2941 msgProp Instance of MessageProp that is used by the application 2942 to set the desired QOP and privacy state. Set the desired QOP to 2943 0 to request the default QOP. Upon return from this method, this 2944 object will contain the the actual privacy state that was applied 2945 to the message by the underlying mechanism. 2947 7.4.16 unwrap 2949 public byte[] unwrap(byte[] inBuf, int offset, int len, 2950 MessageProp msgProp) throws GSSException 2952 Used by the peer application to process tokens generated with the 2953 wrap call. This call is equal in functionality to its stream 2954 counterpart. The method will return the message supplied in the peer 2955 application to the wrap call, verifying the embedded MIC. 2957 The MessageProp object is instantiated by the application and is used 2958 by the underlying mechanism to return information to the caller such 2959 as the QOP, whether confidentiality was applied to the message, and 2960 other supplementary message state information. 2962 Since some application-level protocols may wish to use tokens emitted 2963 by wrap to provide "secure framing", implementations should support 2964 the wrapping and unwrapping of zero-length messages. 2966 Parameters: 2968 inBuf GSS-API wrap token received from peer. 2970 offset The offset within the inBuf where the token begins. 2972 len The length of the token within the inBuf (starting at 2973 the offset). 2975 msgProp Upon return from the method, this object will contain 2976 the applied QOP, the privacy state of the message, and 2977 supplementary information described in 5.12.3 stating whether the 2978 token was a duplicate, old, out of sequence or arriving after a 2979 gap. 2981 7.4.17 unwrap 2983 public void unwrap(InputStream inStream, OutputStream outStream, 2984 MessageProp msgProp) throws GSSException 2986 Used by the peer application to process tokens generated with the 2987 wrap call. This call is equal in functionality to its byte array 2988 counterpart. It will produce the message supplied in the peer 2989 application to the wrap call, verifying the embedded MIC. 2991 The MessageProp object is instantiated by the application and is used 2992 by the underlying mechanism to return information to the caller such 2993 as the QOP, whether confidentiality was applied to the message, and 2994 other supplementary message state information. 2996 Since some application-level protocols may wish to use tokens emitted 2997 by wrap to provide "secure framing", implementations should support 2998 the wrapping and unwrapping of zero-length messages. 3000 Parameters: 3002 inStream Input stream containing the GSS-API wrap token received 3003 from the peer. 3005 outStream The output stream to write the application message to. 3007 msgProp Upon return from the method, this object will contain 3008 the applied QOP, the privacy state of the message, and 3009 supplementary information described in 5.12.3 stating whether the 3010 token was a duplicate, old, out of sequence or arriving after a 3011 gap. 3013 7.4.18 getMIC 3015 public byte[] getMIC(byte[] inMsg, int offset, int len, 3016 MessageProp msgProp) throws GSSException 3018 Returns a token containing a cryptographic MIC for the supplied 3019 message, for transfer to the peer application. Unlike wrap, which 3020 encapsulates the user message in the returned token, only the message 3021 MIC is returned in the output token. This method is identical in 3022 functionality to its stream counterpart. 3024 Note that privacy can only be applied through the wrap call. 3026 Since some application-level protocols may wish to use tokens emitted 3027 by getMIC to provide "secure framing", implementations should support 3028 derivation of MICs from zero-length messages. 3030 Parameters: 3032 inMsg Message to generate MIC over. 3034 offset The offset within the inMsg where the token begins. 3036 len The length of the token within the inMsg (starting at 3037 the offset). 3039 msgProp Instance of MessageProp that is used by the application 3040 to set the desired QOP. Set the desired QOP to 0 in msgProp to 3041 request the default QOP. Alternatively pass in "null" for msgProp 3042 to request default QOP. 3044 7.4.19 getMIC 3046 public void getMIC(InputStream inStream, OutputStream outStream, 3047 MessageProp msgProp) throws GSSException 3049 Produces a token containing a cryptographic MIC for the supplied 3050 message, for transfer to the peer application. Unlike wrap, which 3051 encapsulates the user message in the returned token, only the message 3052 MIC is produced in the output token. This method is identical in 3053 functionality to its byte array counterpart. 3055 Note that privacy can only be applied through the wrap call. 3057 Since some application-level protocols may wish to use tokens emitted 3058 by getMIC to provide "secure framing", implementations should support 3059 derivation of MICs from zero-length messages. 3061 Parameters: 3063 inStream Input stream containing the message to generate MIC 3064 over. 3066 outStream Output stream to write the GSS-API output token to. 3068 msgProp Instance of MessageProp that is used by the application 3069 to set the desired QOP. Set the desired QOP to 0 in msgProp to 3070 request the default QOP. Alternatively pass in "null" for msgProp 3071 to request default QOP. 3073 7.4.20 verifyMIC 3075 public void verifyMIC(byte[] inTok, int tokOffset, int tokLen, 3076 byte[] inMsg, int msgOffset, int msgLen, 3077 MessageProp msgProp) throws GSSException 3079 Verifies the cryptographic MIC, contained in the token parameter, 3080 over the supplied message. This method is equivalent in 3081 functionality to its stream counterpart. 3083 The MessageProp object is instantiated by the application and is used 3084 by the underlying mechanism to return information to the caller such 3085 as the QOP indicating the strength of protection that was applied to 3086 the message and other supplementary message state information. 3088 Since some application-level protocols may wish to use tokens emitted 3089 by getMIC to provide "secure framing", implementations should support 3090 the calculation and verification of MICs over zero-length messages. 3092 Parameters: 3094 inTok Token generated by peer's getMIC method. 3096 tokOffset The offset within the inTok where the token begins. 3098 tokLen The length of the token within the inTok (starting at 3099 the offset). 3101 inMsg Application message to verify the cryptographic MIC 3102 over. 3104 msgOffset The offset within the inMsg where the message begins. 3106 msgLen The length of the message within the inMsg (starting at 3107 the offset). 3109 msgProp Upon return from the method, this object will contain 3110 the applied QOP and supplementary information described in 5.12.3 3111 stating whether the token was a duplicate, old, out of sequence or 3112 arriving after a gap. The confidentiality state will be set to 3113 "false". 3115 7.4.21 verifyMIC 3117 public void verifyMIC(InputStream tokStream, InputStream msgStream, 3118 MessageProp msgProp) throws GSSException 3120 Verifies the cryptographic MIC, contained in the token parameter, 3121 over the supplied message. This method is equivalent in 3122 functionality to its byte array counterpart. 3124 The MessageProp object is instantiated by the application and is used 3125 by the underlying mechanism to return information to the caller such 3126 as the QOP indicating the strength of protection that was applied to 3127 the message and other supplementary message state information. 3129 Since some application-level protocols may wish to use tokens emitted 3130 by getMIC to provide "secure framing", implementations should support 3131 the calculation and verification of MICs over zero-length messages. 3133 Parameters: 3135 tokStream Input stream containing the token generated by peer's 3136 getMIC method. 3138 msgStream Input stream containing the application message to 3139 verify the cryptographic MIC over. 3141 msgProp Upon return from the method, this object will contain 3142 the applied QOP and supplementary information described in 5.12.3 3143 stating whether the token was a duplicate, old, out of sequence or 3144 arriving after a gap. The confidentiality state will be set to 3145 "false". 3147 7.4.22 export 3149 public byte[] export() throws GSSException 3151 Provided to support the sharing of work between multiple processes. 3152 This routine will typically be used by the context-acceptor, in an 3153 application where a single process receives incoming connection 3154 requests and accepts security contexts over them, then passes the 3155 established context to one or more other processes for message 3156 exchange. 3158 This method deactivates the security context and creates an 3159 interprocess token which, when passed to the byte array constructor 3160 of the GSSContext interface in another process, will re-activate the 3161 context in the second process. Only a single instantiation of a 3162 given context may be active at any one time; a subsequent attempt by 3163 a context exporter to access the exported security context will fail. 3165 The implementation may constrain the set of processes by which the 3166 interprocess token may be imported, either as a function of local 3167 security policy, or as a result of implementation decisions. For 3168 example, some implementations may constrain contexts to be passed 3169 only between processes that run under the same account, or which are 3170 part of the same process group. 3172 The interprocess token may contain security-sensitive information 3173 (for example cryptographic keys). While mechanisms are encouraged to 3174 either avoid placing such sensitive information within interprocess 3175 tokens, or to encrypt the token before returning it to the 3176 application, in a typical GSS-API implementation this may not be 3177 possible. Thus the application must take care to protect the 3178 interprocess token, and ensure that any process to which the token is 3179 transferred is trustworthy. 3181 7.4.23 requestMutualAuth 3183 public void requestMutualAuth(boolean state) throws GSSException 3185 Sets the request state of the mutual authentication flag for the 3186 context. This method is only valid before the context creation 3187 process begins and only for the initiator. 3189 Parameters: 3191 state Boolean representing if mutual authentication should be 3192 requested during context establishment. 3194 7.4.24 requestReplayDet 3196 public void requestReplayDet(boolean state) throws GSSException 3198 Sets the request state of the replay detection service for the 3199 context. This method is only valid before the context creation 3200 process begins and only for the initiator. 3202 Parameters: 3204 state Boolean representing if replay detection is desired over 3205 the established context. 3207 7.4.25 requestSequenceDet 3209 public void requestSequenceDet(boolean state) throws GSSException 3211 Sets the request state for the sequence checking service of the 3212 context. This method is only valid before the context creation 3213 process begins and only for the initiator. 3215 Parameters: 3217 state Boolean representing if sequence detection is desired 3218 over the established context. 3220 7.4.26 requestCredDeleg 3222 public void requestCredDeleg(boolean state) throws GSSException 3224 Sets the request state for the credential delegation flag for the 3225 context. This method is only valid before the context creation 3226 process begins and only for the initiator. 3228 Parameters: 3230 state Boolean representing if credential delegation is 3231 desired. 3233 7.4.27 requestAnonymity 3235 public void requestAnonymity(boolean state) throws GSSException 3237 Requests anonymous support over the context. This method is only 3238 valid before the context creation process begins and only for the 3239 initiator. 3241 Parameters: 3243 state Boolean representing if anonymity support is requested. 3245 7.4.28 requestConf 3247 public void requestConf(boolean state) throws GSSException 3249 Requests that confidentiality service be available over the context. 3250 This method is only valid before the context creation process begins 3251 and only for the initiator. 3253 Parameters: 3255 state Boolean indicating if confidentiality services are to be 3256 requested for the context. 3258 7.4.29 requestInteg 3260 public void requestInteg(boolean state) throws GSSException 3262 Requests that integrity services be available over the context. This 3263 method is only valid before the context creation process begins and 3264 only for the initiator. 3266 Parameters: 3268 state Boolean indicating if integrity services are to be 3269 requested for the context. 3271 7.4.30 requestLifetime 3273 public void requestLifetime(int lifetime) throws GSSException 3275 Sets the desired lifetime for the context in seconds. This method is 3276 only valid before the context creation process begins and only for 3277 the initiator. Use GSSContext.INDEFINITE_LIFETIME and 3278 GSSContext.DEFAULT_LIFETIME to request indefinite or default context 3279 lifetime. 3281 Parameters: 3283 lifetime The desired context lifetime in seconds. 3285 7.4.31 setChannelBinding 3287 public void setChannelBinding(ChannelBinding cb) throws GSSException 3289 Sets the channel bindings to be used during context establishment. 3291 This method is only valid before the context creation process begins. 3293 Parameters: 3295 cb Channel bindings to be used. 3297 7.4.32 getCredDelegState 3299 public boolean getCredDelegState() 3301 Returns the state of the delegated credentials for the context. When 3302 issued before context establishment is completed or when the 3303 isProtReady method returns "false", it returns the desired state, 3304 otherwise it will indicate the actual state over the established 3305 context. 3307 7.4.33 getMutualAuthState 3309 public boolean getMutualAuthState() 3311 Returns the state of the mutual authentication option for the 3312 context. When issued before context establishment completes or when 3313 the isProtReady method returns "false", it returns the desired state, 3314 otherwise it will indicate the actual state over the established 3315 context. 3317 7.4.34 getReplayDetState 3319 public boolean getReplayDetState() 3321 Returns the state of the replay detection option for the context. 3322 When issued before context establishment completes or when the 3323 isProtReady method returns "false", it returns the desired state, 3324 otherwise it will indicate the actual state over the established 3325 context. 3327 7.4.35 getSequenceDetState 3329 public boolean getSequenceDetState() 3331 Returns the state of the sequence detection option for the context. 3332 When issued before context establishment completes or when the 3333 isProtReady method returns "false", it returns the desired state, 3334 otherwise it will indicate the actual state over the established 3335 context. 3337 7.4.36 getAnonymityState 3339 public boolean getAnonymityState() 3341 Returns "true" if this is an anonymous context. When issued before 3342 context establishment completes or when the isProtReady method 3343 returns "false", it returns the desired state, otherwise it will 3344 indicate the actual state over the established context. 3346 7.4.37 isTransferable 3348 public boolean isTransferable() throws GSSException 3350 Returns "true" if the context is transferable to other processes 3351 through the use of the export method. This call is only valid on 3352 fully established contexts. 3354 7.4.38 isProtReady 3356 public boolean isProtReady() 3358 Returns "true" if the per message operations can be applied over the 3359 context. Some mechanisms may allow the usage of per-message 3360 operations before the context is fully established. This will also 3361 indicate that the get methods will return actual context state 3362 characteristics instead of the desired ones. 3364 7.4.39 getConfState 3366 public boolean getConfState() 3368 Returns the confidentiality service state over the context. When 3369 issued before context establishment completes or when the isProtReady 3370 method returns "false", it returns the desired state, otherwise it 3371 will indicate the actual state over the established context. 3373 7.4.40 getIntegState 3375 public boolean getIntegState() 3377 Returns the integrity service state over the context. When issued 3378 before context establishment completes or when the isProtReady method 3379 returns "false", it returns the desired state, otherwise it will 3380 indicate the actual state over the established context. 3382 7.4.41 getLifetime 3384 public int getLifetime() 3385 Returns the context lifetime in seconds. When issued before context 3386 establishment completes or when the isProtReady method returns 3387 "false", it returns the desired lifetime, otherwise it will indicate 3388 the remaining lifetime for the context. 3390 7.4.42 getSrcName 3392 public GSSName getSrcName() throws GSSException 3394 Returns the name of the context initiator. This call is valid only 3395 after the context is fully established or the isProtReady method 3396 returns "true". It is guaranteed to return an MN. 3398 7.4.43 getTargName 3400 public GSSName getTargName() throws GSSException 3402 Returns the name of the context target (acceptor). This call is 3403 valid only after the context is fully established or the isProtReady 3404 method returns "true". It is guaranteed to return an MN. 3406 7.4.44 getMech 3408 public Oid getMech() throws GSSException 3410 Returns the mechanism oid for this context. This method may be 3411 called before the context is fully established, but the mechanism 3412 returned may change on successive calls in negotiated mechanism case. 3414 7.4.45 getDelegCred 3416 public GSSCredential getDelegCred() throws GSSException 3418 Returns the delegated credential object on the acceptor's side. To 3419 check for availability of delegated credentials call 3420 getDelegCredState. This call is only valid on fully established 3421 contexts. 3423 7.4.46 isInitiator 3425 public boolean isInitiator() throws GSSException 3427 Returns "true" if this is the initiator of the context. This call is 3428 only valid after the context creation process has started. 3430 7.5 public class MessageProp 3432 This is a utility class used within the per-message GSSContext 3433 methods to convey per-message properties. 3435 When used with the GSSContext interface's wrap and getMIC methods, an 3436 instance of this class is used to indicate the desired QOP and to 3437 request if confidentiality services are to be applied to caller 3438 supplied data (wrap only). To request default QOP, the value of 0 3439 should be used for QOP. 3441 When used with the unwrap and verifyMIC methods of the GSSContext 3442 interface, an instance of this class will be used to indicate the 3443 applied QOP and confidentiality services over the supplied message. 3444 In the case of verifyMIC, the confidentiality state will always be 3445 "false". Upon return from these methods, this object will also 3446 contain any supplementary status values applicable to the processed 3447 token. The supplementary status values can indicate old tokens, out 3448 of sequence tokens, gap tokens or duplicate tokens. 3450 7.5.1 Constructors 3452 public MessageProp(boolean privState) 3454 Constructor which sets QOP to 0 indicating that the default QOP is 3455 requested. 3457 Parameters: 3459 privState The desired privacy state. "true" for privacy and 3460 "false" for integrity only. 3462 public MessageProp(int qop, boolean privState) 3464 Constructor which sets the values for the qop and privacy state. 3466 Parameters: 3468 qop The desired QOP. Use 0 to request a default QOP. 3470 privState The desired privacy state. "true" for privacy and 3471 "false" for integrity only. 3473 7.5.2 getQOP 3475 public int getQOP() 3477 Retrieves the QOP value. 3479 7.5.3 getPrivacy 3481 public boolean getPrivacy() 3483 Retrieves the privacy state. 3485 7.5.4 getMinorStatus 3487 public int getMinorStatus() 3489 Retrieves the minor status that the underlying mechanism might have 3490 set. 3492 7.5.5 getMinorString 3494 public String getMinorString() 3496 Returns a string explaining the mechanism specific error code. null 3497 will be returned when no mechanism error code has been set. 3499 7.5.6 setQOP 3501 public void setQOP(int qopVal) 3503 Sets the QOP value. 3505 Parameters: 3507 qopVal The QOP value to be set. Use 0 to request a default QOP 3508 value. 3510 7.5.7 setPrivacy 3512 public void setPrivacy(boolean privState) 3514 Sets the privacy state. 3516 Parameters: 3518 privState The privacy state to set. 3520 7.5.8 isDuplicateToken 3522 public boolean isDuplicateToken() 3524 Returns "true" if this is a duplicate of an earlier token. 3526 7.5.9 isOldToken 3528 public boolean isOldToken() 3530 Returns "true" if the token's validity period has expired. 3532 7.5.10 isUnseqToken 3534 public boolean isUnseqToken() 3536 Returns "true" if a later token has already been processed. 3538 7.5.11 isGapToken 3540 public boolean isGapToken() 3542 Returns "true" if an expected per-message token was not received. 3544 7.5.12 setSupplementaryStates 3546 public void setSupplementaryStates(boolean duplicate, 3547 boolean old, boolean unseq, boolean gap, 3548 int minorStatus, String minorString) 3550 This method sets the state for the supplementary information flags 3551 and the minor status in MessageProp. It is not used by the 3552 application but by the GSS implementation to return this information 3553 to the caller of a per-message context method. 3555 Parameters: 3557 duplicate true if the token was a duplicate of an earlier token, 3558 false otherwise 3560 old true if the token's validity period has expired, false 3561 otherwise 3563 unseq true if a later token has already been processed, false 3564 otherwise 3566 gap true if one or more predecessor tokens have not yet been 3567 successfully processed, false otherwise 3569 minorStatus the integer minor status code that the underlying 3570 mechanism wants to set 3572 minorString the textual representation of the minorStatus value 3574 7.6 public class ChannelBinding 3576 The GSS-API accommodates the concept of caller-provided channel 3577 binding information. Channel bindings are used to strengthen the 3578 quality with which peer entity authentication is provided during 3579 context establishment. They enable the GSS-API callers to bind the 3580 establishment of the security context to relevant characteristics 3581 like addresses or to application specific data. 3583 The caller initiating the security context must determine the 3584 appropriate channel binding values to set in the GSSContext object. 3585 The acceptor must provide an identical binding in order to validate 3586 that received tokens possess correct channel-related characteristics. 3588 Use of channel bindings is optional in GSS-API. Since channel- 3589 binding information may be transmitted in context establishment 3590 tokens, applications should therefore not use confidential data as 3591 channel-binding components. 3593 7.6.1 Constructors 3595 public ChannelBinding(InetAddress initAddr, InetAddress acceptAddr, 3596 byte[] appData) 3598 Create a ChannelBinding object with user supplied address information 3599 and data. "null" values can be used for any fields which the 3600 application does not want to specify. 3602 Parameters: 3604 initAddr The address of the context initiator. "null" value can 3605 be supplied to indicate that the application does not want to set 3606 this value. 3608 acceptAddr The address of the context acceptor. "null" value can 3609 be supplied to indicate that the application does not want to set 3610 this value. 3612 appData Application supplied data to be used as part of the 3613 channel bindings. "null" value can be supplied to indicate that 3614 the application does not want to set this value. 3616 public ChannelBinding(byte[] appData) 3618 Creates a ChannelBinding object without any addressing information. 3620 Parameters: 3622 appData Application supplied data to be used as part of the 3623 channel bindings. 3625 7.6.2 getInitiatorAddress 3627 public InetAddress getInitiatorAddress() 3629 Returns the initiator's address for this channel binding. "null" is 3630 returned if the address has not been set. 3632 7.6.3 getAcceptorAddress 3634 public InetAddress getAcceptorAddress() 3636 Returns the acceptor's address for this channel binding. "null" is 3637 returned if the address has not been set. 3639 7.6.4 getApplicationData 3641 public byte[] getApplicationData() 3643 Returns application data being used as part of the ChannelBinding. 3644 "null" is returned if no application data has been specified for the 3645 channel binding. 3647 7.6.5 equals 3649 public boolean equals(Object obj) 3651 Returns "true" if two channel bindings match. (Note that the Java 3652 language specification requires that two objects that are equal 3653 according to the equals(Object) method must return the same integer 3654 result when the hashCode() method is called on them.) 3656 Parameters: 3658 obj Another channel binding to compare with. 3660 7.7 public class Oid 3662 This class represents Universal Object Identifiers (Oids) and their 3663 associated operations. 3665 Oids are hierarchically globally-interpretable identifiers used 3666 within the GSS-API framework to identify mechanisms and name formats. 3668 The structure and encoding of Oids is defined in ISOIEC-8824 and 3669 ISOIEC-8825. For example the Oid representation of Kerberos V5 3670 mechanism is "1.2.840.113554.1.2.2" 3672 The GSSName name class contains public static Oid objects 3673 representing the standard name types defined in GSS-API. 3675 7.7.1 Constructors 3677 public Oid(String strOid) throws GSSException 3679 Creates an Oid object from a string representation of its integer 3680 components (e.g. "1.2.840.113554.1.2.2"). 3682 Parameters: 3684 strOid The string representation for the oid. 3686 public Oid(InputStream derOid) throws GSSException 3688 Creates an Oid object from its DER encoding. This refers to the full 3689 encoding including tag and length. The structure and encoding of 3690 Oids is defined in ISOIEC-8824 and ISOIEC-8825. This method is 3691 identical in functionality to its byte array counterpart. 3693 Parameters: 3695 derOid Stream containing the DER encoded oid. 3697 public Oid(byte[] DEROid) throws GSSException 3699 Creates an Oid object from its DER encoding. This refers to the full 3700 encoding including tag and length. The structure and encoding of 3701 Oids is defined in ISOIEC-8824 and ISOIEC-8825. This method is 3702 identical in functionality to its byte array counterpart. 3704 Parameters: 3706 derOid Byte array storing a DER encoded oid. 3708 7.7.2 toString 3710 public String toString() 3712 Returns a string representation of the oid's integer components in 3713 dot separated notation (e.g. "1.2.840.113554.1.2.2"). 3715 7.7.3 equals 3717 public boolean equals(Object Obj) 3719 Returns "true" if the two Oid objects represent the same oid value. 3720 (Note that the Java language specification requires that two objects 3721 that are equal according to the equals(Object) method must return the 3722 same integer result when the hashCode() method is called on them.) 3724 Parameters: 3726 obj Another Oid object to compare with. 3728 7.7.4 getDER 3730 public byte[] getDER() 3732 Returns the full ASN.1 DER encoding for this oid object, which 3733 includes the tag and length. 3735 7.7.5 containedIn 3737 public boolean containedIn(Oid[] oids) 3739 A utility method to test if an Oid object is contained within the 3740 supplied Oid object array. 3742 Parameters: 3744 oids An array of oids to search. 3746 7.8 public class GSSException extends Exception 3748 This exception is thrown whenever a fatal GSS-API error occurs 3749 including mechanism specific errors. It may contain both, the major 3750 and minor, GSS-API status codes. The mechanism implementers are 3751 responsible for setting appropriate minor status codes when throwing 3752 this exception. Aside from delivering the numeric error code(s) to 3753 the caller, this class performs the mapping from their numeric values 3754 to textual representations. All Java GSS-API methods are declared 3755 throwing this exception. 3757 All implementations are encouraged to use the Java 3758 internationalization techniques to provide local translations of the 3759 message strings. 3761 7.8.1 Static Constants 3763 All valid major GSS-API error code values are declared as constants 3764 in this class. 3766 public static final int BAD_BINDINGS 3768 Channel bindings mismatch error. The value of this constant is 1. 3770 public static final int BAD_MECH 3772 Unsupported mechanism requested error. The value of this constant is 3773 2 3775 public static final int BAD_NAME 3777 Invalid name provided error. The value of this constant is 3. 3779 public static final int BAD_NAMETYPE 3781 Name of unsupported type provided error. The value of this constant 3782 is 4. 3784 public static final int BAD_STATUS 3786 Invalid status code error - this is the default status value. The 3787 value of this constant is 5. 3789 public static final int BAD_MIC 3791 Token had invalid integrity check error. The value of this constant 3792 is 6. 3794 public static final int CONTEXT_EXPIRED 3796 Specified security context expired error. The value of this constant 3797 is 7. 3799 public static final int CREDENTIALS_EXPIRED 3801 Expired credentials detected error. The value of this constant is 8. 3803 public static final int DEFECTIVE_CREDENTIAL 3805 Defective credential error. The value of this constant is 9. 3807 public static final int DEFECTIVE_TOKEN 3808 Defective token error. The value of this constant is 10. 3810 public static final int FAILURE 3812 General failure, unspecified at GSS-API level. The value of this 3813 constant is 11. 3815 public static final int NO_CONTEXT 3817 Invalid security context error. The value of this constant is 12. 3819 public static final int NO_CRED 3821 Invalid credentials error. The value of this constant is 13. 3823 public static final int BAD_QOP 3825 Unsupported QOP value error. The value of this constant is 14. 3827 public static final int UNAUTHORIZED 3829 Operation unauthorized error. The value of this constant is 15. 3831 public static final int UNAVAILABLE 3833 Operation unavailable error. The value of this constant is 16. 3835 public static final int DUPLICATE_ELEMENT 3837 Duplicate credential element requested error. The value of this 3838 constant is 17. 3840 public static final int NAME_NOT_MN 3842 Name contains multi-mechanism elements error. The value of this 3843 constant is 18. 3845 public static final int DUPLICATE_TOKEN 3847 The token was a duplicate of an earlier token. This is contained in 3848 an exception only when detected during context establishment, in 3849 which case it is considered a fatal error. (Non-fatal supplementary 3850 codes are indicated via the MessageProp object.) The value of this 3851 constant is 19. 3853 public static final int OLD_TOKEN 3855 The token's validity period has expired. This is contained in an 3856 exception only when detected during context establishment, in which 3857 case it is considered a fatal error. (Non-fatal supplementary codes 3858 are indicated via the MessageProp object.) The value of this 3859 constant is 20. 3861 public static final int UNSEQ_TOKEN 3863 A later token has already been processed. This is contained in an 3864 exception only when detected during context establishment, in which 3865 case it is considered a fatal error. (Non-fatal supplementary codes 3866 are indicated via the MessageProp object.) The value of this 3867 constant is 21. 3869 public static final int GAP_TOKEN 3871 An expected per-message token was not received. This is contained in 3872 an exception only when detected during context establishment, in 3873 which case it is considered a fatal error. (Non-fatal supplementary 3874 codes are indicated via the MessageProp object.) The value of this 3875 constant is 22. 3877 7.8.2 Constructors 3879 public GSSException(int majorCode) 3881 Creates a GSSException object with a specified major code. 3883 Parameters: 3885 majorCode The GSS error code causing this exception to be thrown. 3887 public GSSException(int majorCode, int minorCode, String minorString) 3889 Creates a GSSException object with the specified major code, minor 3890 code, and minor code textual explanation. This constructor is to be 3891 used when the exception is originating from the security mechanism. 3892 It allows to specify the GSS code and the mechanism code. 3894 Parameters: 3896 majorCode The GSS error code causing this exception to be thrown. 3898 minorCode The mechanism error code causing this exception to be 3899 thrown. 3901 minorString The textual explanation of the mechanism error code. 3903 7.8.3 getMajor 3905 public int getMajor() 3907 Returns the major code representing the GSS error code that caused 3908 this exception to be thrown. 3910 7.8.4 getMinor 3912 public int getMinor() 3914 Returns the mechanism error code that caused this exception. The 3915 minor code is set by the underlying mechanism. Value of 0 indicates 3916 that mechanism error code is not set. 3918 7.8.5 getMajorString 3920 public String getMajorString() 3922 Returns a string explaining the GSS major error code causing this 3923 exception to be thrown. 3925 7.8.6 getMinorString 3927 public String getMinorString() 3929 Returns a string explaining the mechanism specific error code. null 3930 will be returned when no mechanism error code has been set. 3932 7.8.7 setMinor 3934 public void setMinor(int minorCode, String message) 3936 Used internally by the GSS-API implementation and the underlying 3937 mechanisms to set the minor code and its textual representation. 3939 Parameters: 3941 minorCode The mechanism specific error code. 3943 message A textual explanation of the mechanism error code. 3945 7.8.8 toString 3947 public String toString() 3949 Returns a textual representation of both the major and minor status 3950 codes. 3952 7.8.9 getMessage 3954 public String getMessage() 3956 Returns a detailed message of this exception. Overrides 3957 Throwable.getMessage. It is customary in Java to use this method to 3958 obtain exception information. 3960 8. Sample Applications 3962 8.1 Simple GSS Context Initiator 3964 import org.ietf.jgss.*; 3966 /** 3967 * This is a partial sketch for a simple client program that acts 3968 * as a GSS context initiator. It illustrates how to use the Java 3969 * bindings for the GSS-API specified in 3970 * Generic Security Service API Version 2 : Java bindings 3971 * 3972 * 3973 * This code sketch assumes the existence of a GSS-API 3974 * implementation that supports the mechanism that it will need 3975 * and is present as a library package (org.ietf.jgss) either as 3976 * part of the standard JRE or in the CLASSPATH the application 3977 * specifies. 3978 */ 3980 public class SimpleClient { 3982 private String serviceName; // name of peer (ie. server) 3983 private GSSCredential clientCred = null; 3984 private GSSContext context = null; 3985 private Oid mech; // underlying mechanism to use 3987 private GSSManager mgr = GSSManager.getInstance(); 3989 ... 3990 ... 3992 private void clientActions() { 3993 initializeGSS(); 3994 establishContext(); 3995 doCommunication(); 3996 } 3998 /** 3999 * Acquire credentials for the client. 4000 */ 4001 private void initializeGSS() { 4003 try { 4005 clientCred = mgr.createCredential(null /*default princ*/, 4006 GSSCredential.INDEFINITE_LIFETIME /* max lifetime */, 4007 mech /* mechanism to use */, 4008 GSSCredential.INITIATE_ONLY /* init context */); 4010 print("GSSCredential created for " + 4011 cred.getName().toString()); 4012 print("Credential lifetime (sec)=" + 4013 cred.getRemainingLifetime()); 4014 } catch (GSSException e) { 4015 print("GSS-API error in credential acquisition: " 4016 + e.getMessage()); 4017 ... 4018 ... 4019 } 4021 ... 4022 ... 4023 } 4025 /** 4026 * Does the security context establishment with the 4027 * server. 4028 */ 4029 private void establishContext() { 4031 byte[] inToken = new byte[0]; 4032 byte[] outToken = null; 4034 try { 4036 GSSName peer = mgr.createName(serviceName, 4037 GSSName.NT_HOSTBASED_SERVICE); 4038 context = mgr.createContext(peer, mech, gssCred, 4039 GSSContext.INDEFINITE_LIFETIME/*lifetime*/); 4041 // Will need to support confidentiality 4042 context.requestConf(true); 4044 while (!context.isEstablished()) { 4046 outToken = context.initSecContext(inToken, 0, 4047 inToken.length); 4049 if (outToken != null) 4050 writeGSSToken(outToken); 4052 if (!context.isEstablished()) 4053 inToken = readGSSToken(); 4054 } 4055 GSSName peer = context.getSrcName(); 4056 print("Security context established with " + peer + 4057 " using underlying mechanism " + mech.toString()); 4058 } catch (GSSException e) { 4059 print("GSS-API error during context establishment: " 4060 + e.getMessage()); 4061 ... 4062 ... 4063 } 4065 ... 4066 ... 4067 } 4069 /** 4070 * Sends some data to the server and reads back the 4071 * response. 4072 */ 4073 private void doCommunication() { 4074 byte[] inToken = null; 4075 byte[] outToken = null; 4076 byte[] buffer; 4078 // Container for multiple input-output arguments to and 4079 // from the per-message routines (e.g., wrap/unwrap). 4080 MessageProp messgInfo = new MessageProp(); 4082 try { 4084 /* 4085 * Now send some bytes to the server to be 4086 * processed. They will be integrity protected but 4087 * not encrypted for privacy. 4088 */ 4090 buffer = readFromFile(); 4092 // Set privacy to false and use the default QOP 4093 messgInfo.setPrivacy(false); 4095 outToken = context.wrap(buffer, 0, buffer.length, 4096 messgInfo); 4098 writeGSSToken(outToken); 4100 /* 4101 * Now read the response from the server. 4102 */ 4104 inToken = readGSSToken(); 4105 buffer = context.unwrap(inToken, 0, 4106 inToken.length, messgInfo); 4107 // All ok if no exception was thrown! 4109 GSSName peer = context.getSrcName(); 4111 print("Message from " + peer.toString() 4112 + " arrived."); 4113 print("Was it encrypted? " + 4114 messgInfo.getPrivacy()); 4115 print("Duplicate Token? " + 4116 messgInfo.isDuplicateToken()); 4117 print("Old Token? " + 4118 messgInfo.isOldToken()); 4119 print("Unsequenced Token? " + 4120 messgInfo.isUnseqToken()); 4121 print("Gap Token? " + 4122 messgInfo.isGapToken()); 4124 ... 4125 ... 4127 } catch (GSSException e) { 4128 print("GSS-API error in per-message calls: " 4129 + e.getMessage()); 4130 ... 4131 ... 4133 } 4135 ... 4137 ... 4139 } // end of doCommunication method 4141 ... 4142 ... 4144 } // end of class SimpleClient 4146 8.2 Simple GSS Context Acceptor 4148 import org.ietf.jgss.*; 4150 /** 4151 * This is a partial sketch for a simple server program that acts 4152 * as a GSS context acceptor. It illustrates how to use the Java 4153 * bindings for the GSS-API specified in 4154 * Generic Security Service API Version 2 : Java bindings 4155 * 4156 * This code sketch assumes the existence of a GSS-API 4157 * implementation that supports the mechanisms that it will need 4158 * and is present as a library package (org.ietf.jgss) either as 4159 * part of the standard JRE or in the CLASSPATH the application 4160 * specifies. 4161 */ 4163 import org.ietf.jgss.*; 4165 public class SimpleServer { 4167 private String serviceName; 4168 private GSSName name; 4169 private GSSCredential cred; 4171 private GSSManager mgr; 4173 ... 4174 ... 4176 /** 4177 * Wait for client connections, establish security contexts 4178 * and provide service. 4179 */ 4180 private void loop() { 4182 ... 4183 ... 4185 mgr = GSSManager.getInstance(); 4187 name = mgr.createName(serviceName, 4188 GSSName.NT_HOSTBASED_SERVICE); 4190 cred = mgr.createCredential(name, 4191 GSSCredential.INDEFINITE_LIFETIME, 4192 null, 4193 GSSCredential.ACCEPT_ONLY); 4195 // Loop infinitely 4196 while (true) { 4197 Socket s = serverSock.accept(); 4199 // Start a new thread to serve this connection 4200 Thread serverThread = new ServerThread(s); 4201 serverThread.start(); 4203 } 4204 } 4206 /** 4207 * Inner class ServerThread whose run() method provides the 4208 * secure service to a connection. 4209 */ 4211 private class ServerThread extends Thread { 4213 ... 4214 ... 4216 /** 4217 * Deals with the connection from one client. It also 4218 * handles all GSSException's thrown while talking to 4219 * this client. 4220 */ 4221 public void run() { 4223 byte[] inToken = null; 4224 byte[] outToken = null; 4225 byte[] buffer; 4227 GSSName peer; 4229 // Container for multiple input-output arguments to 4230 // and from the per-message routines 4231 // (ie. wrap/unwrap). 4232 MessageProp supplInfo = new MessageProp(); 4234 GSSContext secContext = null; 4236 try { 4238 // Now do the context establishment loop 4240 GSSContext context = mgr.createContext(cred); 4242 while (!context.isEstablished()) { 4243 inToken = readGSSToken(); 4245 outToken = context.acceptSecContext(inToken, 4246 0, inToken.length); 4248 if (outToken != null) 4249 writeGSSToken(outToken); 4251 } 4253 // SimpleServer wants confidentiality to be 4254 // available. Check for it. 4255 if (!context.getConfState()){ 4256 ... 4257 ... 4258 } 4260 GSSName peer = context.getSrcName(); 4261 Oid mech = context.getMech(); 4262 print("Security context established with " + 4263 peer.toString() + 4264 " using underlying mechanism " + 4265 mech.toString() + 4266 " from Provider " + 4267 context.getProvider().getName()); 4269 // Now read the bytes sent by the client to be 4270 // processed. 4271 inToken = readGSSToken(); 4273 // Unwrap the message 4274 buffer = context.unwrap(inToken, 0, 4275 inToken.length, supplInfo); 4276 // All ok if no exception was thrown! 4278 // Print other supplementary per-message status 4279 // information 4281 print("Message from " + 4282 peer.toString() + " arrived."); 4283 print("Was it encrypted? " + 4284 supplInfo.getPrivacy()); 4285 print("Duplicate Token? " + 4286 supplInfo.isDuplicateToken()); 4287 print("Old Token? " + supplInfo.isOldToken()); 4288 print("Unsequenced Token? " + 4289 supplInfo.isUnseqToken()); 4291 print("Gap Token? " + supplInfo.isGapToken()); 4293 /* 4294 * Now process the bytes and send back an 4295 * encrypted response. 4296 */ 4298 buffer = serverProcess(buffer); 4300 // Encipher it and send it across 4302 supplInfo.setPrivacy(true); // privacy requested 4303 supplInfo.setQOP(0); // default QOP 4304 outToken = context.wrap(buffer, 0, buffer.length, 4305 supplInfo); 4306 writeGSSToken(outToken); 4308 } catch (GSSException e) { 4309 print("GSS-API Error: " + e.getMessage()); 4310 // Alternatively, could call e.getMajorMessage() 4311 // and e.getMinorMessage() 4312 print("Abandoning security context."); 4314 ... 4315 ... 4317 } 4319 ... 4320 ... 4322 } // end of run method in ServerThread 4324 } // end of inner class ServerThread 4326 ... 4327 ... 4329 } // end of class SimpleServer 4331 9. Security Considerations 4333 The Java language security model allows platform providers to have 4334 policy based fine-grained access control over any resource that an 4335 application wants. When using a Java security manager (such as, but 4336 not limited to, the case of applets running in browsers) the 4337 application code is in a sandbox by default. 4339 Administrators of the platform JRE determine what permissions, if 4340 any, are to be given to source from different codebases. Thus the 4341 administrator has to be aware of any special requirements that the 4342 GSS provider might have for system resources. For instance, a 4343 Kerberos provider might wish to make a network connection to the KDC 4344 to obtain initial credentials. This would not be allowed under the 4345 sandbox unless the administrator had granted permissions for this. 4346 Also note that this granting and checking of permissions happens 4347 transparently to the application and is outside the scope of this 4348 document. 4350 The Java language allows administrators to pre-configure a list of 4351 security service providers in the /lib/security/java.security 4352 file. At runtime, the system approaches these providers in order of 4353 preference when looking for security related services. Applications 4354 have a means to modify this list through methods in the "Security" 4355 class in the "java.security" package. However, since these 4356 modifications would be visible in the entire JVM and thus affect all 4357 code executing in it, this operation is not available in the sandbox 4358 and requires special permissions to perform. Thus when a GSS 4359 application has special needs that are met by a particular security 4360 provider, it has two choices: 4362 1) To install the provider on a JVM wide basis using the 4363 java.security.Security class and then depend on the system to find 4364 the right provider automatically when the need arises. (This would 4365 require the application to be granted a "insertProvider 4366 SecurityPermission".) 4368 2) To pass an instance of the provider to the local instance of 4369 GSSManager so that only factory calls going through that GSSManager 4370 use the desired provider. (This would not require any permissions.) 4372 10. Acknowledgments 4374 This proposed API leverages earlier work performed by the IETF's CAT 4375 WG as outlined in both RFC 2743 and RFC 2744. Many conceptual 4376 definitions, implementation directions, and explanations have been 4377 included from these documents. 4379 We would like to thank Mike Eisler, Lin Ling, Ram Marti, Michael 4380 Saltz and other members of Sun's development team for their helpful 4381 input, comments and suggestions. 4383 We would also like to thank Joe Salowey, and Michael Smith for many 4384 insightful ideas and suggestions that have contributed to this 4385 document. 4387 11. References 4389 [RFC2853] Kabat, J. and M. Upadhyay, "Generic Security Service 4390 Application Program Interface : Java Bindings", RFC 2853, 4391 June 2000. 4393 [GSSAPIv2] 4394 Linn, J., "Generic Security Service Application Program 4395 Interface, Version 2", RFC 2078, January 1997. 4397 [GSSAPIv2-UPDATE] 4398 Linn, J., "Generic Security Service Application Program 4399 Interface, Version 2, Update 1", RFC 2743, January 2000. 4401 [GSSAPI-Cbind] 4402 Wray, J., "Generic Security Service API Version 2 : 4403 C-bindings", RFC 2744, January 2000. 4405 [KERBV5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 4406 RFC 1964, June 1996. 4408 [SPKM] Adams, C., "The Simple Public-Key GSS-API Mechanism", 4409 RFC 2025, October 1996. 4411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4412 Requirement Levels", BCP 14, RFC 2119, March 1997. 4414 Authors' Addresses 4416 Mayank D. Upadhyay 4417 Google Inc. 4418 1600 Amphitheatre Parkway 4419 Mountain View, CA 94043 4420 USA 4422 Email: mayank+ietf-2853@google.com 4424 Seema Malkani 4425 Sun Microsystems, Inc. 4426 4140 Network Circle 4427 Santa Clara, CA 95054 4428 USA 4430 Email: Seema.Malkani@sun.com 4432 Intellectual Property Statement 4434 The IETF takes no position regarding the validity or scope of any 4435 Intellectual Property Rights or other rights that might be claimed to 4436 pertain to the implementation or use of the technology described in 4437 this document or the extent to which any license under such rights 4438 might or might not be available; nor does it represent that it has 4439 made any independent effort to identify any such rights. Information 4440 on the procedures with respect to rights in RFC documents can be 4441 found in BCP 78 and BCP 79. 4443 Copies of IPR disclosures made to the IETF Secretariat and any 4444 assurances of licenses to be made available, or the result of an 4445 attempt made to obtain a general license or permission for the use of 4446 such proprietary rights by implementers or users of this 4447 specification can be obtained from the IETF on-line IPR repository at 4448 http://www.ietf.org/ipr. 4450 The IETF invites any interested party to bring to its attention any 4451 copyrights, patents or patent applications, or other proprietary 4452 rights that may cover technology that may be required to implement 4453 this standard. Please address the information to the IETF at 4454 ietf-ipr@ietf.org. 4456 Disclaimer of Validity 4458 This document and the information contained herein are provided on an 4459 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4460 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4461 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4462 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4463 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4464 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4466 Copyright Statement 4468 Copyright (C) The Internet Society (2006). This document is subject 4469 to the rights, licenses and restrictions contained in BCP 78, and 4470 except as set forth therein, the authors retain all their rights. 4472 Acknowledgment 4474 Funding for the RFC Editor function is currently provided by the 4475 Internet Society.