RFC2853 日本語訳
2853 Generic Security Service API Version 2 : Java Bindings. J. Kabat,M. Upadhyay. June 2000. (Format: TXT=199512 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Kabat
Request for Comments: 2853 ValiCert, Inc.
Category: Standards Track M. Upadhyay
Sun Microsystems, Inc.
June 2000
コメントを求めるワーキンググループJ.カバットの要求をネットワークでつないでください: 2853年のValiCert Inc.カテゴリ: 標準化過程M.Upadhyayサン・マイクロシステムズ・インク2000年6月
Generic Security Service API Version 2 : Java Bindings
一般的なセキュリティー・サービスAPIバージョン2: Java結合
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document specifies the Java bindings for GSS-API which is described at a language independent conceptual level in RFC 2743 [GSSAPIv2-UPDATE].
Generic Security Services Application Program Interface(GSS-API)はさまざまな基本的な暗号のメカニズムの上でセキュリティー・サービスへの一定のアクセスをアプリケーション・プログラマーに提供します。このドキュメントはRFC2743[GSSAPIv2-UPDATE]の言語の独立している概念的なレベルで説明されるGSS-APIのためのJava結合を指定します。
The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are The Simple Public-Key GSS-API Mechanism [SPKM] and The Kerberos Version 5 GSS-API Mechanism [KERBV5].
GSS-APIで、訪問者アプリケーションは、主要なアイデンティティを認証して、同輩への権利を代表として派遣して、1メッセージあたり1個のベースに秘密性や保全などのセキュリティー・サービスを適用します。 GSS-APIのために定義されたセキュリティー対策に関する例は、Simple Public主要なGSS-API Mechanism[SPKM]とケルベロスバージョン5GSS-API Mechanism[KERBV5]です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 2. GSS-API Operational Paradigm . . . . . . . . . . . . . . . 6 3. Additional Controls . . . . . . . . . . . . . . . . . . . 8 3.1. Delegation . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Mutual Authentication . . . . . . . . . . . . . . . . . 10 3.3. Replay and Out-of-Sequence Detection . . . . . . . . . . 10 3.4. Anonymous Authentication . . . . . . . . . . . . . . . . 11 3.5. Confidentiality . . . . . . . . . . . . . . . . . . . . 12 3.6. Inter-process Context Transfer . . . . . . . . . . . . . 12 3.7. The Use of Incomplete Contexts . . . . . . . . . . . . . 13
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 5 2。 GSS-APIの操作上のパラダイム. . . . . . . . . . . . . . . 6 3。 追加コントロール. . . . . . . . . . . . . . . . . . . 8 3.1。 代表団. . . . . . . . . . . . . . . . . . . . . . . 9 3.2。 互いの認証. . . . . . . . . . . . . . . . . 10 3.3。 再生と順序が狂って検出. . . . . . . . . . 10 3.4。 匿名の認証. . . . . . . . . . . . . . . . 11 3.5。 秘密性. . . . . . . . . . . . . . . . . . . . 12 3.6。 相互文脈転送. . . . . . . . . . . . . 12 3.7を処理してください。 不完全な関係. . . . . . . . . . . . . 13の使用
Kabat & Upadhyay Standards Track [Page 1] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[1ページ]。
4. Calling Conventions . . . . . . . . . . . . . . . . . . . 13 4.1. Package Name . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Provider Framework . . . . . . . . . . . . . . . . . . . 13 4.3. Integer types . . . . . . . . . . . . . . . . . . . . . 14 4.4. Opaque Data types . . . . . . . . . . . . . . . . . . . 14 4.5. Strings . . . . . . . . . . . . . . . . . . . . . . . . 15 4.6. Object Identifiers . . . . . . . . . . . . . . . . . . . 15 4.7. Object Identifier Sets . . . . . . . . . . . . . . . . . 15 4.8. Credentials . . . . . . . . . . . . . . . . . . . . . . 16 4.9. Contexts . . . . . . . . . . . . . . . . . . . . . . . . 18 4.10. Authentication tokens . . . . . . . . . . . . . . . . . 18 4.11. Interprocess tokens . . . . . . . . . . . . . . . . . . 18 4.12. Error Reporting . . . . . . . . . . . . . . . . . . . . 19 4.12.1. GSS status codes . . . . . . . . . . . . . . . . . . 19 4.12.2. Mechanism-specific status codes . . . . . . . . . . . 21 4.12.3. Supplementary status codes . . . . . . . . . . . . . 21 4.13. Names . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.14. Channel Bindings . . . . . . . . . . . . . . . . . . . 25 4.15. Stream Objects . . . . . . . . . . . . . . . . . . . . 26 4.16. Optional Parameters . . . . . . . . . . . . . . . . . . 26 5. Introduction to GSS-API Classes and Interfaces . . . . . . 26 5.1. GSSManager class . . . . . . . . . . . . . . . . . . . . 26 5.2. GSSName interface . . . . . . . . . . . . . . . . . . . 27 5.3. GSSCredential interface . . . . . . . . . . . . . . . . 28 5.4. GSSContext interface . . . . . . . . . . . . . . . . . . 28 5.5. MessageProp class . . . . . . . . . . . . . . . . . . . 30 5.6. GSSException class . . . . . . . . . . . . . . . . . . . 30 5.7. Oid class . . . . . . . . . . . . . . . . . . . . . . . 30 5.8. ChannelBinding class . . . . . . . . . . . . . . . . . . 31 6. Detailed GSS-API Class Description . . . . . . . . . . . . 31 6.1. public abstract class GSSManager . . . . . . . . . . . . 31 6.1.1. Example Code . . . . . . . . . . . . . . . . . . . . . 32 6.1.2. getInstance . . . . . . . . . . . . . . . . . . . . . 33 6.1.3. getMechs . . . . . . . . . . . . . . . . . . . . . . . 33 6.1.4. getNamesForMech . . . . . . . . . . . . . . . . . . . 33 6.1.5. getMechsForName . . . . . . . . . . . . . . . . . . . 33 6.1.6. createName . . . . . . . . . . . . . . . . . . . . . . 33 6.1.7. createName . . . . . . . . . . . . . . . . . . . . . . 34 6.1.8. createName . . . . . . . . . . . . . . . . . . . . . . 35 6.1.9. createName . . . . . . . . . . . . . . . . . . . . . . 35 6.1.10. createCredential . . . . . . . . . . . . . . . . . . 36 6.1.11. createCredential . . . . . . . . . . . . . . . . . . 36 6.1.12. createCredential . . . . . . . . . . . . . . . . . . 37 6.1.13. createContext . . . . . . . . . . . . . . . . . . . . 37 6.1.14. createContext . . . . . . . . . . . . . . . . . . . . 38 6.1.15. createContext . . . . . . . . . . . . . . . . . . . . 38 6.1.16. addProviderAtFront . . . . . . . . . . . . . . . . . 38 6.1.16.1. Example Code . . . . . . . . . . . . . . . . . . . 39
4. コンベンション. . . . . . . . . . . . . . . . . . . 13 4.1を召集します。 名前. . . . . . . . . . . . . . . . . . . . . . 13 4.2をパッケージしてください。 プロバイダー枠組み. . . . . . . . . . . . . . . . . . . 13 4.3。 整数型. . . . . . . . . . . . . . . . . . . . . 14 4.4。 不透明なDataは.144.5をタイプします。 ストリング. . . . . . . . . . . . . . . . . . . . . . . . 15 4.6。 物の識別子. . . . . . . . . . . . . . . . . . . 15 4.7。 物の識別子セット. . . . . . . . . . . . . . . . . 15 4.8。 信任状. . . . . . . . . . . . . . . . . . . . . . 16 4.9。 文脈. . . . . . . . . . . . . . . . . . . . . . . . 18 4.10。 認証象徴. . . . . . . . . . . . . . . . . 18 4.11。 インタプロセス象徴. . . . . . . . . . . . . . . . . . 18 4.12。 誤り報告. . . . . . . . . . . . . . . . . . . . 19 4.12.1。 GSSステータスコード. . . . . . . . . . . . . . . . . . 19 4.12.2。 メカニズム特有のステータスコード. . . . . . . . . . . 21 4.12.3。 補っている状態は.21 4.13をコード化します。 名前. . . . . . . . . . . . . . . . . . . . . . . . . 22 4.14。 チャンネル結合. . . . . . . . . . . . . . . . . . . 25 4.15。 物. . . . . . . . . . . . . . . . . . . . 26 4.16を流してください。 任意のパラメタ. . . . . . . . . . . . . . . . . . 26 5。 GSS-APIのクラスとインタフェース. . . . . . 26 5.1への紹介。 GSSManagerクラス. . . . . . . . . . . . . . . . . . . . 26 5.2。 GSSNameは.275.3を連結します。 GSSCredentialは.285.4を連結します。 GSSContextは.285.5を連結します。 MessagePropクラス. . . . . . . . . . . . . . . . . . . 30 5.6。 GSSExceptionクラス. . . . . . . . . . . . . . . . . . . 30 5.7。 Oidクラス. . . . . . . . . . . . . . . . . . . . . . . 30 5.8。 ChannelBindingクラス. . . . . . . . . . . . . . . . . . 31 6。 詳細なGSS-API Class記述. . . . . . . . . . . . 31 6.1の公共の抽象クラスGSSManager. . . . . . . . . . . . 31 6.1.1。 例のコード、.326.1、.2. getInstance、.336.1、.3. getMechs、.336.1、.4. getNamesForMech、.336.1、.5. getMechsForName、.336.1、.6. createName、.336.1、.7. createName、.346.1、.8. createName. . . . . . . . . . . . . . . . . . . . . . 35 6; 1.9. createName、.356.1、.10. createCredential、.366.1、.11. createCredential、.366.1、.12. createCredential、.376.1、.13. createContext、.376.1、.14. createContext、.386.1、.15. createContext、.386.1、.16. addProviderAtFront. . . . . . . . . . . . . . . . . 38 6.1.16.1. 例のコード. . . . . . . . . . . . . . . . . . . 39
Kabat & Upadhyay Standards Track [Page 2] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[2ページ]。
6.1.17. addProviderAtEnd . . . . . . . . . . . . . . . . . . 40 6.1.17.1. Example Code . . . . . . . . . . . . . . . . . . . 41 6.2. public interface GSSName . . . . . . . . . . . . . . . . 42 6.2.1. Example Code . . . . . . . . . . . . . . . . . . . . . 42 6.2.2. Static Constants . . . . . . . . . . . . . . . . . . . 43 6.2.3. equals . . . . . . . . . . . . . . . . . . . . . . . . 44 6.2.4. equals . . . . . . . . . . . . . . . . . . . . . . . . 44 6.2.5. canonicalize . . . . . . . . . . . . . . . . . . . . . 44 6.2.6. export . . . . . . . . . . . . . . . . . . . . . . . . 45 6.2.7. toString . . . . . . . . . . . . . . . . . . . . . . . 45 6.2.8. getStringNameType . . . . . . . . . . . . . . . . . . 45 6.2.9. isAnonymous . . . . . . . . . . . . . . . . . . . . . 45 6.2.10. isMN . . . . . . . . . . . . . . . . . . . . . . . . 45 6.3. public interface GSSCredential implements Cloneable . . 45 6.3.1. Example Code . . . . . . . . . . . . . . . . . . . . . 46 6.3.2. Static Constants . . . . . . . . . . . . . . . . . . . 47 6.3.3. dispose . . . . . . . . . . . . . . . . . . . . . . . 48 6.3.4. getName . . . . . . . . . . . . . . . . . . . . . . . 48 6.3.5. getName . . . . . . . . . . . . . . . . . . . . . . . 48 6.3.6. getRemainingLifetime . . . . . . . . . . . . . . . . . 48 6.3.7. getRemainingInitLifetime . . . . . . . . . . . . . . . 49 6.3.8. getRemainingAcceptLifetime . . . . . . . . . . . . . . 49 6.3.9. getUsage . . . . . . . . . . . . . . . . . . . . . . . 49 6.3.10. getUsage . . . . . . . . . . . . . . . . . . . . . . 49 6.3.11. getMechs . . . . . . . . . . . . . . . . . . . . . . 50 6.3.12. add . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.3.13. equals . . . . . . . . . . . . . . . . . . . . . . . 51 6.4. public interface GSSContext . . . . . . . . . . . . . . 51 6.4.1. Example Code . . . . . . . . . . . . . . . . . . . . . 52 6.4.2. Static Constants . . . . . . . . . . . . . . . . . . . 54 6.4.3. initSecContext . . . . . . . . . . . . . . . . . . . . 54 6.4.3.1. Example Code . . . . . . . . . . . . . . . . . . . . 55 6.4.4. initSecContext . . . . . . . . . . . . . . . . . . . . 56 6.4.4.1. Example Code . . . . . . . . . . . . . . . . . . . . 56 6.4.5. acceptSecContext . . . . . . . . . . . . . . . . . . . 57 6.4.5.1. Example Code . . . . . . . . . . . . . . . . . . . . 58 6.4.6. acceptSecContext . . . . . . . . . . . . . . . . . . . 59 6.4.6.1. Example Code . . . . . . . . . . . . . . . . . . . . 59 6.4.7. isEstablished . . . . . . . . . . . . . . . . . . . . 60 6.4.8. dispose . . . . . . . . . . . . . . . . . . . . . . . 60 6.4.9. getWrapSizeLimit . . . . . . . . . . . . . . . . . . . 61 6.4.10. wrap . . . . . . . . . . . . . . . . . . . . . . . . 61 6.4.11. wrap . . . . . . . . . . . . . . . . . . . . . . . . 62 6.4.12. unwrap . . . . . . . . . . . . . . . . . . . . . . . 63 6.4.13. unwrap . . . . . . . . . . . . . . . . . . . . . . . 64 6.4.14. getMIC . . . . . . . . . . . . . . . . . . . . . . . 65 6.4.15. getMIC . . . . . . . . . . . . . . . . . . . . . . . 65 6.4.16. verifyMIC . . . . . . . . . . . . . . . . . . . . . . 66
6.1.17. addProviderAtEnd、.406.1 .17 .1。 例のCode.416.2公衆はGSSName. . . . . . . . . . . . . . . . 42 6.2.1を連結します。 例のコード. . . . . . . . . . . . . . . . . . . . . 42 6.2.2。 .446.2.4同輩. . . . . . . . . . . . . . . . . . . . . . . . 44 6.2.5が.446.2に.6にcanonicalizeする静的なConstants. . . . . . . . . . . . . . . . . . . 43 6.2.3人の同輩が.456.2を輸出します; 7. toString、.456.2、.8. getStringNameType、.456.2、.9. isAnonymous、.456.2、.10. isMN. . . . . . . . . . . . . . . . . . . . . . . . 45 6.3公共のインタフェースGSSCredentialがCloneableを実行する、.456.3、.1 例のコード. . . . . . . . . . . . . . . . . . . . . 46 6.3.2。 静的なConstants、.476.3、.3、配列、.486.3、.4. getName、.486.3、.5. getName、.486.3、.6. getRemainingLifetime、.486.3、.7. getRemainingInitLifetime、.496.3、.8. getRemainingAcceptLifetime…; . . . . . . . . . . . 49 6.3.9. getUsage、.496.3、.10. getUsage、.496.3、.11. getMechs、.506.3、.12、付加、.506.3、.13. 同輩.516.4公共のインタフェースGSSContext、.516.4、.1 例のコード. . . . . . . . . . . . . . . . . . . . . 52 6.4.2。 静的な定数. . . . . . . . . . . . . . . . . . . 54 6.4.3initSecContext. . . . . . . . . . . . . . . . . . . . 54 6.4.3、.1 例コード. . . . . . . . . . . . . . . . . . . . 55 6.4.4initSecContext. . . . . . . . . . . . . . . . . . . . 56 6.4.4の.1。 例コード. . . . . . . . . . . . . . . . . . . . 56 6.4.5acceptSecContext. . . . . . . . . . . . . . . . . . . 57 6.4.5の.1。 例コード. . . . . . . . . . . . . . . . . . . . 58 6.4.6acceptSecContext. . . . . . . . . . . . . . . . . . . 59 6.4.6の.1。 例のCode、.596.4、.7. isEstablished、.606.4、.8、配列、.606.4、.9. getWrapSizeLimit、.616.4、.10. 包装、.616.4、.11. 包装…………; . . . . . . . . . . . . 62 6.4.12. .13が.646.4.14getMIC. . . . . . . . . . . . . . . . . . . . . . . 65 6.4.15getMIC. . . . . . . . . . . . . . . . . . . . . . . 65 6.4.16verifyMIC.66に開ける.636.4を開けてください。
Kabat & Upadhyay Standards Track [Page 3] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[3ページ]。
6.4.17. verifyMIC . . . . . . . . . . . . . . . . . . . . . . 67 6.4.18. export . . . . . . . . . . . . . . . . . . . . . . . 68 6.4.19. requestMutualAuth . . . . . . . . . . . . . . . . . . 68 6.4.20. requestReplayDet . . . . . . . . . . . . . . . . . . 69 6.4.21. requestSequenceDet . . . . . . . . . . . . . . . . . 69 6.4.22. requestCredDeleg . . . . . . . . . . . . . . . . . . 69 6.4.23. requestAnonymity . . . . . . . . . . . . . . . . . . 69 6.4.24. requestConf . . . . . . . . . . . . . . . . . . . . . 70 6.4.25. requestInteg . . . . . . . . . . . . . . . . . . . . 70 6.4.26. requestLifetime . . . . . . . . . . . . . . . . . . . 70 6.4.27. setChannelBinding . . . . . . . . . . . . . . . . . . 71 6.4.28. getCredDelegState . . . . . . . . . . . . . . . . . . 71 6.4.29. getMutualAuthState . . . . . . . . . . . . . . . . . 71 6.4.30. getReplayDetState . . . . . . . . . . . . . . . . . . 71 6.4.31. getSequenceDetState . . . . . . . . . . . . . . . . . 71 6.4.32. getAnonymityState . . . . . . . . . . . . . . . . . . 72 6.4.33. isTransferable . . . . . . . . . . . . . . . . . . . 72 6.4.34. isProtReady . . . . . . . . . . . . . . . . . . . . . 72 6.4.35. getConfState . . . . . . . . . . . . . . . . . . . . 72 6.4.36. getIntegState . . . . . . . . . . . . . . . . . . . . 72 6.4.37. getLifetime . . . . . . . . . . . . . . . . . . . . . 73 6.4.38. getSrcName . . . . . . . . . . . . . . . . . . . . . 73 6.4.39. getTargName . . . . . . . . . . . . . . . . . . . . . 73 6.4.40. getMech . . . . . . . . . . . . . . . . . . . . . . . 73 6.4.41. getDelegCred . . . . . . . . . . . . . . . . . . . . 73 6.4.42. isInitiator . . . . . . . . . . . . . . . . . . . . . 73 6.5. public class MessageProp . . . . . . . . . . . . . . . . 74 6.5.1. Constructors . . . . . . . . . . . . . . . . . . . . . 74 6.5.2. getQOP . . . . . . . . . . . . . . . . . . . . . . . . 75 6.5.3. getPrivacy . . . . . . . . . . . . . . . . . . . . . . 75 6.5.4. getMinorStatus . . . . . . . . . . . . . . . . . . . . 75 6.5.5. getMinorString . . . . . . . . . . . . . . . . . . . . 75 6.5.6. setQOP . . . . . . . . . . . . . . . . . . . . . . . . 75 6.5.7. setPrivacy . . . . . . . . . . . . . . . . . . . . . . 75 6.5.8. isDuplicateToken . . . . . . . . . . . . . . . . . . . 76 6.5.9. isOldToken . . . . . . . . . . . . . . . . . . . . . . 76 6.5.10. isUnseqToken . . . . . . . . . . . . . . . . . . . . 76 6.5.11. isGapToken . . . . . . . . . . . . . . . . . . . . . 76 6.5.12. setSupplementaryStates . . . . . . . . . . . . . . . 76 6.6. public class ChannelBinding . . . . . . . . . . . . . . 77 6.6.1. Constructors . . . . . . . . . . . . . . . . . . . . . 77 6.6.2. getInitiatorAddress . . . . . . . . . . . . . . . . . 78 6.6.3. getAcceptorAddress . . . . . . . . . . . . . . . . . . 78 6.6.4. getApplicationData . . . . . . . . . . . . . . . . . . 78 6.6.5. equals . . . . . . . . . . . . . . . . . . . . . . . . 78 6.7. public class Oid . . . . . . . . . . . . . . . . . . . . 79 6.7.1. Constructors . . . . . . . . . . . . . . . . . . . . . 79 6.7.2. toString . . . . . . . . . . . . . . . . . . . . . . . 80
6.4.17. verifyMIC、.676.4、.18. 輸出、.686.4、.19. requestMutualAuth、.686.4、.20. requestReplayDet、.696.4、.21. requestSequenceDet、.696.4、.22. requestCredDeleg、.696.4、.23. requestAnonymity、.696.4、.24. requestConf………………; . 70 6.4.25. requestInteg、.706.4、.26. requestLifetime、.706.4、.27. setChannelBinding、.716.4、.28. getCredDelegState、.716.4、.29. getMutualAuthState、.716.4、.30. getReplayDetState、.716.4、.31. getSequenceDetState、.716.4、.32. getAnonymityState…………。. . . . . 72 6.4.33isTransferable、.726.4、.34. isProtReady、.726.4、.35. getConfState、.726.4、.36. getIntegState、.726.4、.37. getLifetime、.736.4、.38. getSrcName……; . . . . . . . . . . . . . 73 6.4.39. getTargName、.736.4、.40. getMech、.736.4、.41. getDelegCred、.736.4、.42. isInitiator. . . . . . . . . . . . . . . . . . . . . 73 6.5の公立のクラスMessageProp、.746.5、.1 建設者、.746.5、.2. getQOP、.756.5、.3. getPrivacy、.756.5、.4. getMinorStatus、.756.5、.5. getMinorString、.756.5、.6. setQOP、.756.5、.7. setPrivacy………; . . . . . . . . . . . . 75 6.5.8. isDuplicateToken、.766.5、.9. isOldToken、.766.5、.10. isUnseqToken、.766.5、.11. isGapToken、.766.5、.12. setSupplementaryStates. . . . . . . . . . . . . . . 76 6.6の公立のクラスChannelBinding、.776.6、.1 建設者、.776.6、.2. getInitiatorAddress、.786.6、.3. getAcceptorAddress、.786.6、.4. getApplicationData、.786.6、.5. 同輩.786.7公衆クラスOid、.796.7、.1 建設者. . . . . . . . . . . . . . . . . . . . . 79 6.7.2toString. . . . . . . . . . . . . . . . . . . . . . . 80
Kabat & Upadhyay Standards Track [Page 4] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[4ページ]。
6.7.3. equals . . . . . . . . . . . . . . . . . . . . . . . . 80 6.7.4. getDER . . . . . . . . . . . . . . . . . . . . . . . . 80 6.7.5. containedIn . . . . . . . . . . . . . . . . . . . . . 80 6.8. public class GSSException extends Exception . . . . . . 80 6.8.1. Static Constants . . . . . . . . . . . . . . . . . . . 81 6.8.2. Constructors . . . . . . . . . . . . . . . . . . . . . 83 6.8.3. getMajor . . . . . . . . . . . . . . . . . . . . . . . 84 6.8.4. getMinor . . . . . . . . . . . . . . . . . . . . . . . 84 6.8.5. getMajorString . . . . . . . . . . . . . . . . . . . . 84 6.8.6. getMinorString . . . . . . . . . . . . . . . . . . . . 84 6.8.7. setMinor . . . . . . . . . . . . . . . . . . . . . . . 84 6.8.8. toString . . . . . . . . . . . . . . . . . . . . . . . 85 6.8.9. getMessage . . . . . . . . . . . . . . . . . . . . . . 85 7. Sample Applications . . . . . . . . . . . . . . . . . . . 85 7.1. Simple GSS Context Initiator . . . . . . . . . . . . . . 85 7.2. Simple GSS Context Acceptor . . . . . . . . . . . . . . 89 8. Security Considerations . . . . . . . . . . . . . . . . . 93 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 94 10. Bibliography . . . . . . . . . . . . . . . . . . . . . . 94 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . 95 12. Full Copyright Statement. . . . . . . . . . . . . . . . . 96
6.7.3. 同輩.806.7.4getDER. . . . . . . . . . . . . . . . . . . . . . . . 80 6.7.5containedIn. . . . . . . . . . . . . . . . . . . . . 80 6.8の公立のクラスGSSExceptionはException. . . . . . 80 6.8.1を広げています。 静的な定数. . . . . . . . . . . . . . . . . . . 81 6.8.2。 建設者. . . . . . . . . . . . . . . . . . . . . 83 6.8.3getMajor. . . . . . . . . . . . . . . . . . . . . . . 84 6.8.4getMinor. . . . . . . . . . . . . . . . . . . . . . . 84 6.8.5getMajorString. . . . . . . . . . . . . . . . . . . . 84 6.8; 6. getMinorString. . . . . . . . . . . . . . . . . . . . 84 6.8.7setMinor. . . . . . . . . . . . . . . . . . . . . . . 84 6.8.8toString. . . . . . . . . . . . . . . . . . . . . . . 85 6.8.9getMessage. . . . . . . . . . . . . . . . . . . . . . 85 7。 アプリケーション. . . . . . . . . . . . . . . . . . . 85 7.1を抽出してください。 純真なGSS文脈創始者. . . . . . . . . . . . . . 85 7.2。 簡単なGSS文脈アクセプタ. . . . . . . . . . . . . . 89 8。 セキュリティ問題. . . . . . . . . . . . . . . . . 93 9。 承認. . . . . . . . . . . . . . . . . . . . . 94 10。 図書目録. . . . . . . . . . . . . . . . . . . . . . 94 11。 作者のアドレス. . . . . . . . . . . . . . . . . . . 95 12。 完全な著作権宣言文。 . . . . . . . . . . . . . . . . 96
1. Introduction
1. 序論
This document specifies Java language bindings for the Generic Security Services Application Programming Interface Version 2 (GSS- API). GSS-API Version 2 is described in a language independent format in RFC 2743 [GSSAPIv2-UPDATE]. The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis.
このドキュメントはGeneric Security Services Application Programming Interfaceバージョン2(GSS API)のためのジャバ言語結合を指定します。 GSS-APIバージョン2はRFC2743[GSSAPIv2-UPDATE]の言語の独立している形式で説明されます。 GSS-APIで、訪問者アプリケーションは、主要なアイデンティティを認証して、同輩への権利を代表として派遣して、1メッセージあたり1個のベースに秘密性や保全などのセキュリティー・サービスを適用します。
This document leverages the work performed by the WG in the area of RFC 2743 [GSSAPIv2-UPDATE] and the C-bindings RFC 2744 [GSSAPI-C]. Whenever appropriate, text has been used from the C-bindings RFC 2744 to explain generic concepts and provide direction to the implementors.
このドキュメントはRFC2743の領域のWG[GSSAPIv2-UPDATE]とC-結合RFC2744[GSSAPI-C]によって行われた仕事に投機します。 適切であるときはいつも、テキストは、類概念について説明して、作成者への指示を提供するのにC-結合RFC2744年から使用されました。
The design goals of this API have been to satisfy all the functionality defined in RFC 2743 and to provide these services in an object oriented method. The specification also aims to satisfy the needs of both types of Java application developers, those who would like access to a "system-wide" GSS-API implementation, as well as those who would want to provide their own "custom" implementation.
このAPIのデザイン目標は、RFC2743で定義されたすべての機能性を満たして、これらのサービスをオブジェクト指向方法に提供することです。 また、仕様は、両方のタイプのJavaのアプリケーション開発者の需要を満たすことを目指します、「システム全体」のGSS-API実行へのアクセスが欲しい人、それら自身の「カスタム」の実現を提供したがっている人と同様に。
Kabat & Upadhyay Standards Track [Page 5] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[5ページ]。
A "system-wide" implementation is one that is available to all applications in the form of a library package. It may be a standard package in the Java runtime environment (JRE) being used or it may be additionally installed and accessible to any application via the CLASSPATH.
「システム全体」の実現はライブラリパッケージの形ですべてのアプリケーションに利用可能なものです。 それは、CLASSPATHを通してどんなアプリケーションにもそれが使用されるJavaランタイム環境(JRE)において標準パッケージであるかもしれませんかさらに、インストールされていてアクセスしやすいかもしれません。
A "custom" implementation of the GSS-API, on the other hand, is one that would, in most cases, be bundled with the application during distribution. It is expected that such an implementation would be meant to provide for some particular need of the application, such as support for some specific mechanism.
他方では、GSS-APIの「カスタム」の実現は多くの場合、分配の間にアプリケーションで束ねられるものです。 そのような実現がアプリケーションの何らかの特別の必要性に備えることになっていると予想されます、何らかの特定のメカニズムのサポートなどのように。
The design of this API also aims to provide a flexible framework to add and manage GSS-API mechanisms. GSS-API leverages the Java Cryptography Architecture (JCA) provider model to support the plugability of mechanisms. Mechanisms can be added on a "system- wide" basis, where all users of the framework will have them available. The specification also allows for the addition of mechanisms per-instance of the GSS-API.
また、このAPIのデザインは、GSS-APIメカニズムを加えて、管理するためにフレキシブルな枠組みを提供することを目指します。GSS-APIは、メカニズムのplugabilityを支持するためにJava Cryptography Architecture(JCA)プロバイダーモデルに投機します。aでメカニズムは加えることができる、「システム、広さ、」 枠組みのすべてのユーザが彼らを利用可能にするところの基礎。 また、仕様はGSS-APIのメカニズム例の添加を考慮します。
Lastly, this specification presents an API that will naturally fit within the operation environment of the Java platform. Readers are assumed to be familiar with both the GSS-API and the Java platform.
最後に、この仕様はJavaプラットホームの操作環境の中で自然に合うAPIを提示します。 読者がGSS-APIとJavaプラットホームの両方によく知られさせると思われます。
2. GSS-API Operational Paradigm
2. GSS-APIの操作上のパラダイム
The Generic Security Service Application Programming Interface Version 2 [GSSAPIv2-UPDATE] defines a generic security API to calling applications. It allows a communicating application to authenticate the user associated with another application, to delegate rights to another application, and to apply security services such as confidentiality and integrity on a per-message basis.
アプリケーションと呼ぶとGeneric Security Service Application Programming Interfaceバージョン2[GSSAPIv2-UPDATE]は一般的なセキュリティAPIを定義します。 それで、交信アプリケーションは、別のアプリケーションに関連しているユーザを認証して、別のアプリケーションへの権利を代表として派遣して、1メッセージあたり1個のベースに秘密性や保全などのセキュリティー・サービスを適用します。
There are four stages to using GSS-API:
GSS-APIを使用することへの4つのステージがあります:
1) The application acquires a set of credentials with which it may
prove its identity to other processes. The application's
credentials vouch for its global identity, which may or may not
be related to any local username under which it may be running.
1) アプリケーションはそれがアイデンティティを立証するかもしれない1セットの信任状を他の過程に取得します。 アプリケーションの信任状はグローバルなアイデンティティを保証します。(それは、それが走っているかもしれないどんなローカルのユーザ名にも関連するかもしれません)。
2) A pair of communicating applications establish a joint security
context using their credentials. The security context
encapsulates shared state information, which is required in
order that per-message security services may be provided.
Examples of state information that might be shared between
applications as part of a security context are cryptographic
keys, and message sequence numbers. As part of the
establishment of a security context, the context initiator is
2) 1組の交信アプリケーションは、それらの信任状を使用することで共同セキュリティ文脈を確立します。 セキュリティ文脈は共有された州の情報を要約します。(それが、1メッセージあたりのセキュリティー・サービスを提供できるように必要です)。 セキュリティ文脈の一部としてアプリケーションの間で共有されるかもしれない州の情報に関する例は、暗号化キーと、メッセージ通番です。 セキュリティ文脈の確立の一部として、文脈創始者はそうです。
Kabat & Upadhyay Standards Track [Page 6] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[6ページ]。
authenticated to the responder, and may require that the
responder is authenticated back to the initiator. The
initiator may optionally give the responder the right to
initiate further security contexts, acting as an agent or
delegate of the initiator. This transfer of rights is termed
"delegation", and is achieved by creating a set of credentials,
similar to those used by the initiating application, but which
may be used by the responder.
応答者に認証されて、応答者が創始者に認証して戻されるのが必要であるかもしれません。 創始者は任意にさらなるセキュリティ文脈を開始する権利を応答者に与えるかもしれません、創始者のエージェントか代表として務めて。 この権利譲渡は、「代表団」と呼ばれて、1セットの信任状を作成することによって、達成されます、開始アプリケーションで使用される応答者によって使用されるかもしれないものと同様です。
A GSSContext object is used to establish and maintain the
shared information that makes up the security context. Certain
GSSContext methods will generate a token, which applications
treat as cryptographically protected, opaque data. The caller
of such GSSContext method is responsible for transferring the
token to the peer application, encapsulated if necessary in an
application-to-application protocol. On receipt of such a
token, the peer application should pass it to a corresponding
GSSContext method which will decode the token and extract the
information, updating the security context state information
accordingly.
GSSContext物は、セキュリティ文脈を作る共有された情報を確立して、保守するのに使用されます。 あるGSSContext方法は象徴を発生させるでしょう。(アプリケーションは暗号で保護されて、不明瞭なデータをそれとして扱います)。 そのようなGSSContext方法の訪問者は、同輩アプリケーションに象徴を移すのに責任があって、必要なら、アプリケーションからアプリケーション・プロトコルで要約されています。 そのような象徴を受け取り次第、同輩アプリケーションは象徴を解読して、情報を抜粋する対応するGSSContext方法にそれを通過するべきです、それに従って、セキュリティ文脈州の情報をアップデートして。
3) Per-message services are invoked on a GSSContext object to
apply either:
3) 1メッセージあたりのサービスは適用するためにGSSContext物の上に呼び出されます:
integrity and data origin authentication, or
または保全とデータ起源認証。
confidentiality, integrity and data origin authentication
秘密性、保全、およびデータ起源認証
to application data, which are treated by GSS-API as arbitrary
octet-strings. An application transmitting a message that it
wishes to protect will call the appropriate GSSContext method
(getMIC or wrap) to apply protection, and send the resulting
token to the receiving application. The receiver will pass the
received token (and, in the case of data protected by getMIC,
the accompanying message-data) to the corresponding decoding
method of the GSSContext interface (verifyMIC or unwrap) to
remove the protection and validate the data.
アプリケーションデータに。(アプリケーションデータは任意の八重奏ストリングとしてGSS-APIによって扱われます)。 保護したがっているというメッセージを送るアプリケーションは、適切なGSSContextを保護を適用する方法(getMICか包装)と呼んで、結果として起こる象徴を受信アプリケーションに送るでしょう。 受信機が容認された象徴(そしてgetMICによって保護されたデータ、付随のメッセージデータの場合で)をGSSContextインタフェースの対応する解読方法に渡す、(verifyMIC、開けてください、)、保護を取り除いて、データを有効にするために。
4) At the completion of a communications session (which may extend
across several transport connections), each application uses a
GSSContext method to invalidate the security context and
release any system or cryptographic resources held. Multiple
contexts may also be used (either successively or
simultaneously) within a single communications association, at
the discretion of the applications.
4) コミュニケーションセッション(数人の輸送の接続に達するかもしれない)の完成のときに、各アプリケーションはセキュリティ文脈を無効にするGSSContext方法とどんなシステムや暗号のリソースも保持したリリースを使用します。 また、複数の文脈が単一のコミュニケーション協会の中で使用されるかもしれません(相次ぐか同時)、アプリケーションの裁量で。
Kabat & Upadhyay Standards Track [Page 7] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[7ページ]。
3. Additional Controls
3. 追加コントロール
This section discusses the optional services that a context initiator may request of the GSS-API before the context establishment. Each of these services is requested by calling the appropriate mutator method in the GSSContext object before the first call to init is performed. Only the context initiator can request context flags.
このセクションは文脈設立の前に文脈創始者が要求するかもしれないGSS-APIの任意のサービスについて論じます。 それぞれのこれらのサービスは、イニットへの準備ラッパが実行される前にGSSContext物に適切なmutator方法を呼ぶことによって、要求されています。 文脈創始者だけが文脈旗を要求できます。
The optional services defined are:
定義された任意のサービスは以下の通りです。
Delegation
The (usually temporary) transfer of rights from initiator to
acceptor, enabling the acceptor to authenticate itself as an
agent of the initiator.
(通常一時的)が移す代表団は創始者からアクセプタまでまっすぐになります、アクセプタが創始者のエージェントとしてそれ自体を認証するのを可能にして。
Mutual Authentication
In addition to the initiator authenticating its identity to the
context acceptor, the context acceptor should also authenticate
itself to the initiator.
文脈アクセプタへのアイデンティティを認証する創始者への互いのAuthentication In添加、また、文脈アクセプタは創始者にそれ自体を認証するはずです。
Replay Detection
In addition to providing message integrity services, GSSContext
per-message operations of getMIC and wrap should include
message numbering information to enable verifyMIC and unwrap
to detect if a message has been duplicated.
メッセージの保全サービスを提供することへの再生Detection In添加、getMICと包装の1メッセージあたりのGSSContext操作はメッセージがコピーされたかどうか検出するためにverifyMICを有効にして、開けるためにメッセージ付番情報を含むべきです。
Out-of-Sequence Detection
In addition to providing message integrity services, GSSContext
per-message operations (getMIC and wrap) should include
message sequencing information to enable verifyMIC and unwrap
to detect if a message has been received out of sequence.
メッセージの保全サービスを提供することへの系列で出ているDetection In添加、1メッセージあたりのGSSContext操作(getMICと包装)はメッセージが順序が狂って受け取られたかどうか検出するためにverifyMICを有効にして、開けるためにメッセージ配列情報を含むべきです。
Anonymous Authentication
The establishment of the security context should not reveal the
initiator's identity to the context acceptor.
匿名のAuthentication、セキュリティ文脈の確立は文脈アクセプタへの創始者のアイデンティティを明らかにするべきではありません。
Some mechanisms may not support all optional services, and some mechanisms may only support some services in conjunction with others. The GSSContext interface offers query methods to allow the verification by the calling application of which services will be available from the context when the establishment phase is complete. In general, if the security mechanism is capable of providing a requested service, it should do so even if additional services must be enabled in order to provide the requested service. If the mechanism is incapable of providing a requested service, it should proceed without the service leaving the application to abort the context establishment process if it considers the requested service to be mandatory.
いくつかのメカニズムがすべての任意のサービスを支持するかもしれないというわけではありません、そして、いくつかのメカニズムが他のものに関連していくつかのサービスを支持するだけであるかもしれません。 GSSContextインタフェース申し出は確立段階が完全であるときにサービスが文脈から利用可能になる呼ぶアプリケーションで検証を許す方法を質問します。 一般に、セキュリティー対策が要求されたサービスを提供できるなら、要求されたサービスを提供するために追加サービスを可能にしなければならなくても、それはそうするべきです。 要求されたサービスが義務的であると考えて、メカニズムが要求されたサービスを提供できないなら、それはアプリケーションを残すサービスなしで文脈設立の過程を中止するべきでありかけます。
Kabat & Upadhyay Standards Track [Page 8] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[8ページ]。
Some mechanisms may specify that support for some services is optional, and that implementors of the mechanism need not provide it. This is most commonly true of the confidentiality service, often because of legal restrictions on the use of data-encryption, but may apply to any of the services. Such mechanisms are required to send at least one token from acceptor to initiator during context establishment when the initiator indicates a desire to use such a service, so that the initiating GSS-API can correctly indicate whether the service is supported by the acceptor's GSS-API.
いくつかのメカニズムが、いくつかのサービスのサポートが任意であり、メカニズムの作成者がそれを提供する必要はないと指定するかもしれません。 これは秘密性サービスに関して一般的に最も本当です、サービスのどれかに適用するかもしれなくてしばしばデータ暗号化の使用の法的規制のために。 創始者がそのようなサービスを利用する願望を示すとき、そのようなメカニズムは文脈設立の間、少なくとも1つの象徴をアクセプタから創始者に送らなければなりません、開始GSS-APIが、サービスがアクセプタのGSS-APIで後押しされているかどうかを正しく示すことができるように。
3.1. Delegation
3.1. 代表団
The GSS-API allows delegation to be controlled by the initiating application via the requestCredDeleg method before the first call to init has been issued. Some mechanisms do not support delegation, and for such mechanisms attempts by an application to enable delegation are ignored.
イニットへの準備ラッパが発行される前にGSS-APIは、代表団が開始アプリケーションでrequestCredDeleg方法で制御されるのを許容します。 いくつかのメカニズムが、代表団を支持しないで、代表団を可能にするアプリケーションによるそのようなメカニズム試みのために無視されます。
The acceptor of a security context, for which the initiator enabled delegation, can check if delegation was enabled by using the getCredDelegState method of the GSSContext interface. In cases when it is, the delegated credential object can be obtained by calling the getDelegCred method. The obtained GSSCredential object may then be used to initiate subsequent GSS-API security contexts as an agent or delegate of the initiator. If the original initiator's identity is "A" and the delegate's identity is "B", then, depending on the underlying mechanism, the identity embodied by the delegated credential may be either "A" or "B acting for A".
セキュリティ文脈のアクセプタは、委譲がGSSContextインタフェースのgetCredDelegStateメソッドを使用することによって可能にされたかどうかチェックできます。(創始者は文脈に関して委譲を可能にしました)。 それがそうであることの場合では、getDelegCredをメソッドと呼ぶことによって、代表として派遣された資格証明オブジェクトを入手できます。 そして、得られたGSSCredentialオブジェクトは、創始者のエージェントか代表としてその後のGSS-APIセキュリティ文脈を開始するのに使用されるかもしれません。 オリジナルの創始者のアイデンティティが「A」であり、代表のアイデンティティが「B」であるなら、代表として派遣された資格証明書によって具体化されたアイデンティティは、発症機序によって、「A」か「Aの代理をするB」のどちらかであるかもしれません。
For many mechanisms that support delegation, a simple boolean does not provide enough control. Examples of additional aspects of delegation control that a mechanism might provide to an application are duration of delegation, network addresses from which delegation is valid, and constraints on the tasks that may be performed by a delegate. Such controls are presently outside the scope of the GSS- API. GSS-API implementations supporting mechanisms offering additional controls should provide extension routines that allow these controls to be exercised (perhaps by modifying the initiator's GSS-API credential object prior to its use in establishing a context). However, the simple delegation control provided by GSS-API should always be able to over-ride other mechanism-specific delegation controls. If the application instructs the GSSContext object that delegation is not desired, then the implementation must not permit delegation to occur. This is an exception to the general rule that a mechanism may enable services even if they are not requested - delegation may only be provided at the explicit request of the application.
委譲をサポートする多くのメカニズムのために、簡単な論理演算子は十分なコントロールを提供しません。 メカニズムがアプリケーションに提供するかもしれない委譲コントロールの追加局面に関する例は委譲、委譲が有効であるネットワーク・アドレス、およびタスクにおける代表によって実行されるかもしれない規制の持続時間です。 GSS APIの範囲の外にそのようなコントロールが現在、あります。 追加コントロールを提供するメカニズムをサポートするGSS-API実行はこれらのコントロールが運動させられるのを(恐らく文脈を確立することにおける使用の前に創始者のGSS-APIの資格証明オブジェクトを変更することによって)許容する拡大ルーチンを提供するべきです。 しかしながら、GSS-APIによって提供された簡単な委譲コントロールはいつも他のメカニズム特有の委譲コントロールをくつがえすはずであることができます。 アプリケーションが、委譲が望まれていないようGSSContextオブジェクトに命令するなら、実装は、委譲が起こるのを許容してはいけません。 これはそれらが要求されないでもメカニズムがサービスを可能にするかもしれないという一般的な規則への例外です--アプリケーションの明白な要求によって委譲を提供するだけであるかもしれません。
Kabat & Upadhyay Standards Track [Page 9] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[9ページ]。
3.2. Mutual Authentication
3.2. 互いの認証
Usually, a context acceptor will require that a context initiator authenticate itself so that the acceptor may make an access-control decision prior to performing a service for the initiator. In some cases, the initiator may also request that the acceptor authenticate itself. GSS-API allows the initiating application to request this mutual authentication service by calling the requestMutualAuth method of the GSSContext interface with a "true" parameter before making the first call to init. The initiating application is informed as to whether or not the context acceptor has authenticated itself. Note that some mechanisms may not support mutual authentication, and other mechanisms may always perform mutual authentication, whether or not the initiating application requests it. In particular, mutual authentication may be required by some mechanisms in order to support replay or out-of-sequence message detection, and for such mechanisms a request for either of these services will automatically enable mutual authentication.
通常、文脈アクセプタは、アクセプタが創始者のために事業を行う前にアクセス制御決定をすることができるように文脈創始者がそれ自体を認証するのを必要とするでしょう。 いくつかの場合、また、創始者は、アクセプタがそれ自体を認証するよう要求するかもしれません。 GSS-APIで、requestMutualAuthを準備ラッパをイニットにする前の「本当」のパラメタとのGSSContextインタフェースのメソッドと呼ぶことによって、開始アプリケーションはこの互いの認証サービスを要求できます。 文脈アクセプタがそれ自体を認証したかどうかに関して開始アプリケーションは知識があります。 いくつかのメカニズムが互いの認証をサポートしないかもしれなくて、他のメカニズムがいつも互いの認証を実行するかもしれないことに注意してください、開始アプリケーションがそれを要求するか否かに関係なく。 特定の、そして、互いの認証では、いくつかのメカニズムが、再生か順序が狂ってメッセージ検出をサポートして、これらのサービスのどちらかを求める要求が自動的にそうするそのようなメカニズムのために互いの認証を可能にするのに必要であるかもしれません。
3.3. Replay and Out-of-Sequence Detection
3.3. 再生と順序が狂って検出
The GSS-API may provide detection of mis-ordered messages once a security context has been established. Protection may be applied to messages by either application, by calling either getMIC or wrap methods of the GSSContext interface, and verified by the peer application by calling verifyMIC or unwrap for the peer's GSSContext object.
セキュリティ文脈がいったん確立されると、GSS-APIは誤規則正しいメッセージの検出を提供するかもしれません。 保護はどちらかをgetMICと呼ぶのによるアプリケーションかGSSContextのメソッドが連結して、verifyMICと呼ぶのによる同輩アプリケーションで確かめるか、または同輩のGSSContextオブジェクトのために開ける包装のどちらかによってメッセージに適用されるかもしれません。
The getMIC method calculates a cryptographic checksum of an application message, and returns that checksum in a token. The application should pass both the token and the message to the peer application, which presents them to the verifyMIC method of the peer's GSSContext object.
getMICメソッドは、アプリケーションメッセージの暗号のチェックサムについて計算して、トークンでそのチェックサムを返します。 アプリケーションはトークンとメッセージの両方を同輩アプリケーションに通過するべきです。(それは、同輩のGSSContextオブジェクトのverifyMICメソッドにそれらを提示します)。
The wrap method calculates a cryptographic checksum of an application message, and places both the checksum and the message inside a single token. The application should pass the token to the peer application, which presents it to the unwrap method of the peer's GSSContext object to extract the message and verify the checksum.
包装メソッドは、アプリケーションメッセージの暗号のチェックサムについて計算して、ただ一つのトークンでチェックサムとメッセージの両方を置きます。 アプリケーションがそれを提示する同輩アプリケーションへのトークンを通過するべきである、同輩のGSSContextオブジェクトがメッセージを抜粋して、チェックサムについて確かめるメソッドを開けてください。
Either pair of routines may be capable of detecting out-of-sequence message delivery, or duplication of messages. Details of such mis- ordered messages are indicated through supplementary query methods of the MessageProp object that is filled in by each of these routines.
どちらかの組のルーチンは順序が狂ってメッセージ配送、またはメッセージの複製を検出できるかもしれません。 そのような誤規則正しいメッセージの詳細はそれぞれのこれらのルーチンで記入されるMessagePropオブジェクトの補っている質問メソッドで示されます。
A mechanism need not maintain a list of all tokens that have been processed in order to support these status codes. A typical mechanism might retain information about only the most recent "N"
メカニズムはこれらのステータスコードをサポートするために処理されたすべてのトークンのリストを維持する必要はありません。 典型的なメカニズムは最新の「N」だけの情報を保有するかもしれません。
Kabat & Upadhyay Standards Track [Page 10] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[10ページ]。
tokens processed, allowing it to distinguish duplicates and missing tokens within the most recent "N" messages; the receipt of a token older than the most recent "N" would result in the isOldToken method of the instance of MessageProp to return "true".
トークンは処理されて、許容は「N」最新のメッセージの中で写しとなくなったトークンを区別するそれです。 最新の「N」より古いトークンの領収書はMessagePropのインスタンスが「本当に」戻るisOldTokenメソッドをもたらすでしょう。
3.4. Anonymous Authentication
3.4. 匿名の認証
In certain situations, an application may wish to initiate the authentication process to authenticate a peer, without revealing its own identity. As an example, consider an application providing access to a database containing medical information, and offering unrestricted access to the service. A client of such a service might wish to authenticate the service (in order to establish trust in any information retrieved from it), but might not wish the service to be able to obtain the client's identity (perhaps due to privacy concerns about the specific inquiries, or perhaps simply to avoid being placed on mailing-lists).
ある状況で、アプリケーションは同輩を認証するために認証過程を開始したがっているかもしれません、それ自身のアイデンティティを明らかにしないで。 例と、医療情報を含んでいて、サービスへの無制限なアクセスを提供しながらデータベースへのアクセスを提供するアプリケーションを考えてください。 そのようなサービスのクライアントは、サービスを認証することを願っていますが(それから検索されたどんな情報にも信頼を確立するために)、サービスにクライアントのアイデンティティを得ることができて欲しくないかもしれません(特定の問い合せは恐らくプライバシーのため単にメーリングリストに置かれるのを避けるために恐らく心配です)。
In normal use of the GSS-API, the initiator's identity is made available to the acceptor as a result of the context establishment process. However, context initiators may request that their identity not be revealed to the context acceptor. Many mechanisms do not support anonymous authentication, and for such mechanisms the request will not be honored. An authentication token will still be generated, but the application is always informed if a requested service is unavailable, and has the option to abort context establishment if anonymity is valued above the other security services that would require a context to be established.
GSS-APIを通常の使用で、創始者のアイデンティティを文脈設立プロセスの結果、アクセプタに利用可能にします。 しかしながら、文脈創始者は、彼らのアイデンティティが文脈アクセプタに明らかにされないよう要求するかもしれません。 多くのメカニズムは匿名の認証をサポートしません、そして、要求はそのようなメカニズムにおいて、光栄に思うようにならないでしょう。 それでも、認証トークンが生成されますが、アプリケーションは、要求されたサービスが入手できないならいつも知識があって、匿名が文脈が確立されるのを必要とする他のセキュリティー・サービスを超えて評価されるなら、文脈設立を中止するオプションを持っています。
In addition to informing the application that a context is established anonymously (via the isAnonymous method of the GSSContext class), the getSrcName method of the acceptor's GSSContext object will, for such contexts, return a reserved internal-form name, defined by the implementation.
文脈が匿名で(GSSContextのクラスのisAnonymousメソッドで)確立されることをアプリケーションに知らせることに加えて、そのような文脈のために、アクセプタのGSSContextオブジェクトのgetSrcNameメソッドは実装によって定義された予約された内部のフォーム名を返すでしょう。
The toString method for a GSSName object representing an anonymous entity will return a printable name. The returned value will be syntactically distinguishable from any valid principal name supported by the implementation. The associated name-type object identifier will be an oid representing the value of NT_ANONYMOUS. This name- type oid will be defined as a public, static Oid object of the GSSName class. The printable form of an anonymous name should be chosen such that it implies anonymity, since this name may appear in, for example, audit logs. For example, the string "<anonymous>" might be a good choice, if no valid printable names supported by the implementation can begin with "<" and end with ">".
匿名の実体を表すGSSNameオブジェクトのためのtoStringメソッドは印刷可能な名前を返すでしょう。 戻り値は実装によってサポートされたどんな妥当な主要な名前からも区別可能にシンタクス上なるでしょう。 関連名前タイプオブジェクト識別子はNT_更生会の値を表すoidになるでしょう。 この名前タイプoidはGSSNameのクラスの公共の、そして、静的なOidオブジェクトと定義されるでしょう。 匿名の名前の印刷可能なフォームが選ばれるべきであるので、匿名を含意します、この名前が例えば、監査ログに現れるかもしれないので。 例えば、ストリング「<の匿名の>」は良い選択であるかもしれません、実装によってサポートされたどんな妥当な印刷可能な名前も"<"で始まって、">"で終わることができないなら。
Kabat & Upadhyay Standards Track [Page 11] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[11ページ]。
When using the equal method of the GSSName interface, and one of the operands is a GSSName instance representing an anonymous entity, the method must return "false".
GSSNameの等しいメソッドを使用して、連結してください。そうすれば、オペランドの1つが匿名の実体を表すGSSNameインスタンスであるときに、メソッドは「虚偽で」戻らなければなりません。
3.5. Confidentiality
3.5. 秘密性
If a GSSContext supports the confidentiality service, wrap method may be used to encrypt application messages. Messages are selectively encrypted, under the control of the setPrivacy method of the MessageProp object used in the wrap method.
GSSContextが、秘密性がサービスであるとサポートするなら、包装メソッドは、アプリケーションメッセージを暗号化するのに使用されるかもしれません。 メッセージは包装メソッドで使用されるMessagePropオブジェクトのsetPrivacyメソッドのコントロールの下で選択的に暗号化されます。
3.6. Inter-process Context Transfer
3.6. 相互プロセス文脈転送
GSS-API V2 provides functionality which allows a security context to be transferred between processes on a single machine. These are implemented using the export method of GSSContext and a byte array constructor of the same class. The most common use for such a feature is a client-server design where the server is implemented as a single process that accepts incoming security contexts, which then launches child processes to deal with the data on these contexts. In such a design, the child processes must have access to the security context object created within the parent so that they can use per- message protection services and delete the security context when the communication session ends.
GSS-API V2はセキュリティ文脈が単一マシンの上にプロセスの間に移されるのを許容する機能性を提供します。 これらはGSSContextの輸出メソッドを使用して、同じクラスのバイト配列建設者であると実装されます。 そのような特徴の最も一般の使用はこれらの文脈のサーバが入って来るセキュリティ文脈を受け入れて、次にデータに対処するために子プロセスを始める単一のプロセスとして実装されるクライアント/サーバデザインです。 そのようなaデザインでは、子プロセスがそれらが使用できるそのように親の中で作成されたセキュリティ文脈オブジェクトに近づく手段を持たなければならない、-、保護サービスを通信させてください、そして、コミュニケーションセッションが終わったら、セキュリティ文脈を削除してください。
Since the security context data structure is expected to contain sequencing information, it is impractical in general to share a context between processes. Thus GSSContext interface provides an export method that the process, which currently owns the context, can call to declare that it has no intention to use the context subsequently, and to create an inter-process token containing information needed by the adopting process to successfully re-create the context. After successful completion of export, the original security context is made inaccessible to the calling process by GSS- API and any further usage of this object will result in failures. The originating process transfers the inter-process token to the adopting process, which creates a new GSSContext object using the byte array constructor. The properties of the context are equivalent to that of the original context.
セキュリティ文脈データ構造が配列情報を含むと予想されて、一般に、プロセスの間の文脈を共有するのは非実用的です。 したがって、GSSContextインタフェースはプロセス(現在、文脈を所有している)がそれには次に、文脈を使用して、情報を含むと採用プロセスで首尾よく作り直すのが必要であった相互プロセストークンを作成するという意志が全くないと宣言するために呼ぶことができる輸出メソッドに文脈を提供します。 輸出の無事終了の後に、オリジナルのセキュリティ文脈をGSS APIで呼び出しプロセスに近づきがたくします、そして、このオブジェクトのどんなさらなる使用法も失敗に終わるでしょう。 起因するプロセスは相互プロセストークンを採用プロセスに移します。(それは、バイト配列建設者を使用することで新しいGSSContextオブジェクトを作成します)。 文脈の特性はオリジナルの文脈のものに同等です。
The inter-process token may contain sensitive data from the original security context (including cryptographic keys). Applications using inter-process tokens to transfer security contexts must take appropriate steps to protect these tokens in transit.
相互プロセストークンはオリジナルのセキュリティ文脈からの極秘データを含むかもしれません(暗号化キーを含んでいて)。 セキュリティ文脈を移すのに相互プロセストークンを使用するアプリケーションは、トランジットにおけるこれらのトークンを保護するために適切な手段を講じなければなりません。
Kabat & Upadhyay Standards Track [Page 12] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[12ページ]。
Implementations are not required to support the inter-process transfer of security contexts. Calling the isTransferable method of the GSSContext interface will indicate if the context object is transferable.
実装は、相互プロセスがセキュリティ文脈の転送であるとサポートするのに必要ではありません。 isTransferableをGSSContextインタフェースのメソッドと呼ぶのが文脈オブジェクトが移転可能であるかどうかを示すでしょう。
3.7. The Use of Incomplete Contexts
3.7. 不完全な関係の使用
Some mechanisms may allow the per-message services to be used before the context establishment process is complete. For example, a mechanism may include sufficient information in its initial context- level tokens for the context acceptor to immediately decode messages protected with wrap or getMIC. For such a mechanism, the initiating application need not wait until subsequent context-level tokens have been sent and received before invoking the per-message protection services.
文脈設立プロセスが完全になる前にいくつかのメカニズムが、1メッセージあたりのサービスが利用されるのを許容するかもしれません。 例えば、文脈アクセプタがすぐに包装かgetMICと共に保護されたメッセージを解読するように、メカニズムは文脈の初期のレベルトークンに十分な情報を含むかもしれません。 そのようなメカニズムのために、開始アプリケーションは1メッセージあたりの保護サービスを呼び出す前にその後の文脈レベルトークンを送って、受け取るまで待つ必要はありません。
An application can invoke the isProtReady method of the GSSContext class to determine if the per-message services are available in advance of complete context establishment. Applications wishing to use per-message protection services on partially-established contexts should query this method before attempting to invoke wrap or getMIC.
アプリケーションはGSSContextのクラスが1メッセージあたりのサービスが完全な文脈設立の前に利用可能であるかどうか決定するisProtReadyメソッドを呼び出すことができます。 部分的に確立した関係で1メッセージあたりの保護サービスを利用したがっているアプリケーションは包装かgetMICを呼び出すのを試みる前に、このメソッドを質問するべきです。
4. Calling Conventions
4. 呼び出し規則
Java provides the implementors with not just a syntax for the language, but also an operational environment. For example, memory is automatically managed and does not require application intervention. These language features have allowed for a simpler API and have led to the elimination of certain GSS-API functions.
Javaは言語のための構文だけではなく、運用環境も作成者に提供します。 例えば、メモリは、自動的に管理されて、アプリケーション介入を必要としません。 これらの言語機能は、より簡単なAPIを考慮して、あるGSS-API関数の除去につながりました。
Moreover, the JCA defines a provider model which allows for implementation independent access to security services. Using this model, applications can seamlessly switch between different implementations and dynamically add new services. The GSS-API specification leverages these concepts by the usage of providers for the mechanism implementations.
そのうえ、JCAはセキュリティー・サービスへの実装の独立しているアクセスを考慮するプロバイダーモデルを定義します。 このモデルを使用して、アプリケーションは、シームレスに異なった実装を切り換えて、ダイナミックに新種業務を加えることができます。 GSS-API仕様はメカニズム実装のためにプロバイダーの用法でこれらの概念を利用します。
4.1. Package Name
4.1. パッケージ名
The classes and interfaces defined in this document reside in the package called "org.ietf.jgss". Applications that wish to make use of this API should import this package name as shown in section 7.
本書では定義されたクラスとインタフェースは"org.ietf.jgss"と呼ばれるパッケージの中にあります。 このAPIを利用したがっているアプリケーションはセクション7で示されるようにこのパッケージ名を意味するべきです。
4.2. Provider Framework
4.2. プロバイダーフレームワーク
The Java security API's use a provider architecture that allows applications to be implementation independent and security API implementations to be modular and extensible. The
セキュリティAPIのJavaものはモジュールであって広げることができるようにアプリケーションが実装独立者とセキュリティAPI実行であることを許容するプロバイダーアーキテクチャを使用します。 The
Kabat & Upadhyay Standards Track [Page 13] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[13ページ]。
java.security.Provider class is an abstract class that a vendor extends. This class maps various properties that represent different security services that are available to the names of the actual vendor classes that implement those services. When requesting a service, an application simply specifies the desired provider and the API delegates the request to service classes available from that provider.
java.security.Providerのクラスはベンダーが広げる抽象クラスです。 このクラスはそれらのサービスを実装する実際のベンダーのクラスの名前に利用可能な異なったセキュリティー・サービスを表す様々な特性を写像します。 サービス、アプリケーションが単に必要なプロバイダーとAPI代表を指定するよう要求するとき、修理する要求はそのプロバイダーから利用可能な状態で属します。
Using the Java security provider model insulates applications from implementation details of the services they wish to use. Applications can switch between providers easily and new providers can be added as needed, even at runtime.
Javaセキュリティプロバイダーモデルを使用すると、アプリケーションはそれらが利用したがっているサービスの実装の詳細から隔離されます。 アプリケーションは容易にプロバイダーを切り換えることができます、そして、ランタイムのときにさえ新しいプロバイダーは加えることができます。
The GSS-API may use providers to find components for specific underlying security mechanisms. For instance, a particular provider might contain components that will allow the GSS-API to support the Kerberos v5 mechanism and another might contain components to support the SPKM mechanism. By delegating mechanism specific functionality to the components obtained from providers the GSS-API can be extended to support an arbitrary list of mechanism.
GSS-APIは、特定の基本的なセキュリティー対策に関してコンポーネントを見つけるのにプロバイダーを使用するかもしれません。例えば、特定のプロバイダーはGSS-APIがケルベロスv5メカニズムをサポートできるコンポーネントを含むかもしれません、そして、別のものはSPKMメカニズムをサポートするコンポーネントを含むかもしれません。 メカニズムの特定の機能性をプロバイダーから得られたコンポーネントへ代表として派遣することによって、メカニズムの任意のリストをサポートするためにGSS-APIを広げることができます。
How the GSS-API locates and queries these providers is beyond the scope of this document and is being deferred to a Service Provider Interface (SPI) specification. The availability of such a SPI specification is not mandatory for the adoption of this API specification nor is it mandatory to use providers in the implementation of a GSS-API framework. However, by using the provider framework together with an SPI specification one can create an extensible and implementation independent GSS-API framework.
GSS-APIがどうこれらのプロバイダーを場所を見つけて、質問するかは、このドキュメントの範囲を超えていて、Service Provider Interface(SPI)仕様に延期されています。 そのようなSPI仕様の有用性はこのAPI仕様の採用に義務的ではありません、そして、それは、GSS-APIフレームワークの実装にプロバイダーを使用するために義務的ではありません。 しかしながら、SPIと共にプロバイダーフレームワークを使用することによって、仕様1は広げることができるのと実装の独立しているGSS-APIフレームワークを作成できます。
4.3. Integer types
4.3. 整数型
All numeric values are declared as "int" primitive Java type. The Java specification guarantees that this will be a 32 bit two's complement signed number.
すべての数値が"int"原始のJavaタイプとして宣言されます。 Java仕様は、これが数であると署名される32ビットの2の補数になるのを保証します。
Throughout this API, the "boolean" primitive Java type is used wherever a boolean value is required or returned.
このAPI中では、「論理演算子」原始のJavaタイプをどこでブール値を必要としても使用するか、または返します。
4.4. Opaque Data types
4.4. 不透明なDataはタイプします。
Java byte arrays are used to represent opaque data types which are consumed and produced by the GSS-API in the forms of tokens. Java arrays contain a length field which enables the users to easily determine their size. The language has automatic garbage collection which alleviates the need by developers to release memory and simplifies buffer ownership issues.
Javaバイト配列は、トークンの形にGSS-APIによって消費されて、作り出される不明瞭なデータ型を表すのに使用されます。 Java配列はユーザが容易に彼らのサイズを決定するのを可能にする長さの分野を含んでいます。 言語には、メモリを発表する開発者による必要性を軽減して、バッファ所有権問題を簡素化する自動ガーベージコレクションがあります。
Kabat & Upadhyay Standards Track [Page 14] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[14ページ]。
4.5. Strings
4.5. ストリング
The String object will be used to represent all textual data. The Java String object, transparently treats all characters as two-byte Unicode characters which allows support for many locals. All routines returning or accepting textual data will use the String object.
Stringオブジェクトは、すべての原文のデータを表すのに使用されるでしょう。 Java Stringは反対して、透過的に御馳走は皆、多くのローカルのサポートを許す2バイトのユニコード文字としてキャラクタです。 原文のデータを返すか、または受け入れるすべてのルーチンがStringオブジェクトを使用するでしょう。
4.6. Object Identifiers
4.6. オブジェクト識別子
An Oid object will be used to represent Universal Object Identifiers (Oids). Oids are ISO-defined, hierarchically globally-interpretable identifiers used within the GSS-API framework to identify security mechanisms and name formats. The Oid object can be created from a string representation of its dot notation (e.g. "1.3.6.1.5.6.2") as well as from its ASN.1 DER encoding. Methods are also provided to test equality and provide the DER representation for the object.
Oidオブジェクトは、Universal Object Identifiers(Oids)を表すのに使用されるでしょう。 OidsがISOによって定義されている、階層的では、グローバルに解明できる識別子はセキュリティー対策と名前形式を特定するのに中でGSS-APIフレームワークを使用しました。 ドット記法のストリング表現からOidオブジェクトを作成できる、(例えば、「1.3、.6、.1、.5、.6、ASN.1DERコード化現在良い0.2インチ、」 また、平等をテストして、オブジェクトのDER表現を提供するためにメソッドを提供します。
An important feature of the Oid class is that its instances are immutable - i.e. there are no methods defined that allow one to change the contents of an Oid. This property allows one to treat these objects as "statics" without the need to perform copies.
Oidのクラスの重要な特徴はインスタンスが不変であるということです--すなわち、Oidのコンテンツを変えるために1つを許容する定義されたメソッドが全くありません。 この特性は、コピーを実行する必要性なしで「静電気帯電」としてこれらのオブジェクトを扱うために1つを許容します。
Certain routines allow the usage of a default oid. A "null" value can be used in those cases.
あるルーチンはデフォルトoidの使用法を許容します。 それらの場合に「ヌル」の値を使用できます。
4.7. Object Identifier Sets
4.7. オブジェクト識別子セット
The Java bindings represents object identifiers sets as arrays of Oid objects. All Java arrays contain a length field which allows for easy manipulation and reference.
Oidの配列が反対するようにJava結合はオブジェクト識別子セットを表します。 すべてのJava配列が簡単な操作と参照を考慮する長さの分野を含んでいます。
In order to support the full functionality of RFC 2743, the Oid class includes a method which checks for existence of an Oid object within a specified array. This is equivalent in functionality to gss_test_oid_set_member. The use of Java arrays and Java's automatic garbage collection has eliminated the need for the following routines: gss_create_empty_oid_set, gss_release_oid_set, and gss_add_oid_set_member. Java GSS-API implementations will not contain them. Java's automatic garbage collection and the immutable property of the Oid object eliminates the complicated memory management issues of the C counterpart.
RFC2743の完全な機能性をサポートするために、OidのクラスはOidオブジェクトの存在がないかどうか指定された配列の中でチェックするメソッドを含んでいます。 gss_テスト_oid_セット_メンバーにとって、これは機能性で同等です。 Java配列とJavaの自動ガーベージコレクションの使用は以下のルーチンの必要性を排除しました: gss_は_oid_が設定した空の_を作成します、そして、gss_リリース_oid_はセットしました、そして、gss_は_oid_が_メンバーを設定したと言い足します。 Java GSS-API実行はそれらを含まないでしょう。 OidオブジェクトのJavaの自動ガーベージコレクションと不変の特性はC対応者の複雑なメモリ管理問題を排除します。
When ever a default value for an Object Identifier Set is required, a "null" value can be used. Please consult the detailed method description for details.
Object Identifier Setのためのデフォルト値が今までに必要であるときに、「ヌル」の値を使用できます。 詳細のための詳細なメソッド記述に相談してください。
Kabat & Upadhyay Standards Track [Page 15] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[15ページ]。
4.8. Credentials
4.8. 資格証明書
GSS-API credentials are represented by the GSSCredential interface. The interface contains several constructs to allow for the creation of most common credential objects for the initiator and the acceptor. Comparisons are performed using the interface's "equals" method. The following general description of GSS-API credentials is included from the C-bindings specification:
GSS-API資格証明書はGSSCredentialインタフェースによって表されます。 インタフェースは創始者とアクセプタのためにほとんどの一般的な資格証明オブジェクトの創案のために許容するいくつかの構造物を含んでいます。 比較は、インタフェースの「同輩」メソッドを使用することで実行されます。 GSS-API資格証明書の以下の概説はC-結合仕様から含まれています:
GSS-API credentials can contain mechanism-specific principal authentication data for multiple mechanisms. A GSS-API credential is composed of a set of credential-elements, each of which is applicable to a single mechanism. A credential may contain at most one credential-element for each supported mechanism. A credential- element identifies the data needed by a single mechanism to authenticate a single principal, and conceptually contains two credential-references that describe the actual mechanism-specific authentication data, one to be used by GSS-API for initiating contexts, and one to be used for accepting contexts. For mechanisms that do not distinguish between acceptor and initiator credentials, both references would point to the same underlying mechanism-specific authentication data.
GSS-API資格証明書は複数のメカニズムのためのメカニズム特有の主要な認証データを含むことができます。GSS-API資格証明書は1セットの資格証明要素で構成されます。それはそれぞれただ一つのメカニズムに適切です。 資格証明書はそれぞれのサポートしているメカニズムあたり1つの資格証明要素を高々含むかもしれません。 資格証明書要素は、ただ一つの元本を認証するためにただ一つのメカニズムによって必要とされたデータを特定して、概念的に実際のメカニズム特有の認証データ(文脈を受け入れるのに使用されるために文脈、および1を開始するのにGSS-APIによって使用されるべき1)について説明する2つの資格証明参照箇所を含んでいます。 アクセプタを見分けないメカニズムと創始者資格証明書のために、両方の参照は同じ基本的なメカニズム特有の認証データを示すでしょう。
Credentials describe a set of mechanism-specific principals, and give their holder the ability to act as any of those principals. All principal identities asserted by a single GSS-API credential should belong to the same entity, although enforcement of this property is an implementation-specific matter. A single GSSCredential object represents all the credential elements that have been acquired.
資格証明書は、1セットのメカニズム特有の主体について説明して、それらの主体のどれかとして機能する能力を彼らの所有者に与えます。 ただ一つのGSS-API資格証明書によって断言されたすべての主要なアイデンティティが同じ実体に属すべきです、この特性の実施は実装特有の問題ですが。 単一のGSSCredentialオブジェクトは帯びられたすべての資格証明要素を表します。
The creation's of an GSSContext object allows the value of "null" to be specified as the GSSCredential input parameter. This will indicate a desire by the application to act as a default principal. While individual GSS-API implementations are free to determine such default behavior as appropriate to the mechanism, the following default behavior by these routines is recommended for portability:
創案のGSSContextオブジェクトのものは、「ヌル」の値がGSSCredential入力パラメタとして指定されるのを許容します。 これは、デフォルト元本として務めるためにアプリケーションで願望を示すでしょう。 個々のGSS-API実行が無料で適宜そのようなデフォルトの振舞いをメカニズムに決定できる間、これらのルーチンによる以下のデフォルトの振舞いは移植性のために推薦されます:
For the initiator side of the context:
文脈の創始者側に:
1) If there is only a single principal capable of initiating
security contexts for the chosen mechanism that the application
is authorized to act on behalf of, then that principal shall be
used, otherwise
1) アプリケーションが主体が使用されるものとすることについてその時、そうでないことを代表して行動するのが認可される選ばれたメカニズムのためのセキュリティ文脈を開始できるただ一つの元本しかなければ
Kabat & Upadhyay Standards Track [Page 16] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[16ページ]。
2) If the platform maintains a concept of a default network-
identity for the chosen mechanism, and if the application is
authorized to act on behalf of that identity for the purpose of
initiating security contexts, then the principal corresponding
to that identity shall be used, otherwise
2) プラットホームがデフォルトの概念を維持するなら、選ばれたメカニズムのためにアイデンティティをネットワークでつないでください。そうすれば、アプリケーションがセキュリティ文脈を開始する目的のためのそのアイデンティティを代表して行動するのが認可されるなら、そのアイデンティティに対応する主体は使用されるものとします、そうではありません。
3) If the platform maintains a concept of a default local
identity, and provides a means to map local identities into
network-identities for the chosen mechanism, and if the
application is authorized to act on behalf of the network-
identity image of the default local identity for the purpose of
initiating security contexts using the chosen mechanism, then
the principal corresponding to that identity shall be used,
otherwise
3) プラットホームがデフォルトの地方のアイデンティティの概念を維持して、選ばれたメカニズムとアプリケーションがデフォルトのネットワークアイデンティティイメージを代表して地方に行動するのが認可されるかどうかネットワークアイデンティティアイデンティティに地方のアイデンティティを写像する手段を選ばれたメカニズムを使用することでセキュリティ文脈を開始する目的に提供するなら、そのアイデンティティに対応する主体は使用されるものとします、そうではありません。
4) A user-configurable default identity should be used.
4) ユーザ構成可能なデフォルトのアイデンティティは使用されるべきです。
and for the acceptor side of the context
そして、文脈のアクセプタ側に
1) If there is only a single authorized principal identity capable
of accepting security contexts for the chosen mechanism, then
that principal shall be used, otherwise
1) 選ばれたメカニズムのためのセキュリティ文脈を受け入れることができるただ一つの認可された主要なアイデンティティしかなければ、その主体は使用されるものとします、そうではありません。
2) If the mechanism can determine the identity of the target
principal by examining the context-establishment token
processed during the accept method, and if the accepting
application is authorized to act as that principal for the
purpose of accepting security contexts using the chosen
mechanism, then that principal identity shall be used,
otherwise
2) メカニズムが、文脈設立トークンを調べるのによる目標主体のアイデンティティが処理したことを決定できる、メソッドを受け入れてください。そうすれば、受諾アプリケーションが選ばれたメカニズムを使用することでセキュリティ文脈を受け入れる目的のためにそんなに主要であるとして機能するのが認可されるなら、その主要なアイデンティティは使用されるものとします、そうではありません。
3) If the mechanism supports context acceptance by any principal,
and if mutual authentication was not requested, any principal
that the application is authorized to accept security contexts
under using the chosen mechanism may be used, otherwise
3) メカニズムがどんな主体でも文脈承認をサポートして、互いの認証が要求されなかったなら、アプリケーションがセキュリティ文脈を受け入れるのが認可される選ばれたメカニズムを使用するどんな校長も使用されるかもしれません、そうではありません。
4) A user-configurable default identity shall be used.
4) ユーザ構成可能なデフォルトのアイデンティティは使用されるものとします。
The purpose of the above rules is to allow security contexts to be established by both initiator and acceptor using the default behavior whenever possible. Applications requesting default behavior are likely to be more portable across mechanisms and implementations than ones that instantiate an GSSCredential object representing a specific identity.
上の規則の目的はセキュリティ文脈が創始者とアクセプタの両方によって確立されるのを可能であるときはいつも、デフォルトの振舞いを使用することで許容することです。 デフォルトの振舞いを要求するアプリケーションはメカニズムと実装の向こう側に、特定のアイデンティティを表しながらGSSCredentialオブジェクトを例示するものより携帯用である傾向があります。
Kabat & Upadhyay Standards Track [Page 17] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[17ページ]。
4.9. Contexts
4.9. 文脈
The GSSContext interface is used to represent one end of a GSS-API security context, storing state information appropriate to that end of the peer communication, including cryptographic state information. The instantiation of the context object is done differently by the initiator and the acceptor. After the context has been instantiated, the initiator may choose to set various context options which will determine the characteristics of the desired security context. When all the application desired characteristics have been set, the initiator will call the initSecContext method which will produce a token for consumption by the peer's acceptSecContext method. It is the responsibility of the application to deliver the authentication token(s) between the peer applications for processing. Upon completion of the context establishment phase, context attributes can be retrieved, by both the initiator and acceptor, using the accessor methods. These will reflect the actual attributes of the established context. At this point the context can be used by the application to apply cryptographic services to its data.
GSSContextインタフェースはGSS-APIセキュリティ文脈の片端を表すのに使用されます、そのために同輩コミュニケーションで適切な州の情報を保存して、暗号の州の情報を含んでいて。 創始者とアクセプタは異なって文脈オブジェクトの具体化をします。 文脈が例示された後に、創始者は、必要なセキュリティ文脈の特性を決定する様々な文脈オプションを設定するのを選ぶかもしれません。 すべてのアプリケーション必要な特性が設定されたとき、創始者は、initSecContextを消費で同輩のacceptSecContextメソッドでトークンを生産するメソッドと呼ぶでしょう。 処理の同輩アプリケーションの間に認証トークンを提供するのは、アプリケーションの責任です。 文脈確立段階の完成のときに、文脈属性を検索できます、創始者とアクセプタの両方で、アクセサメソッドを使用して。 これらは確立した関係の実際の属性を反映するでしょう。 ここに、暗号のサービスをデータに適用するのにアプリケーションで文脈を使用できます。
4.10. Authentication tokens
4.10. 認証トークン
A token is a caller-opaque type that GSS-API uses to maintain synchronization between each end of the GSS-API security context. The token is a cryptographically protected octet-string, generated by the underlying mechanism at one end of a GSS-API security context for use by the peer mechanism at the other end. Encapsulation (if required) within the application protocol and transfer of the token are the responsibility of the peer applications.
トークンはGSS-APIがGSS-APIセキュリティ文脈の各端の間で同期を維持するのに使用する訪問者分っているタイプです。 トークンはもう一方の端のときに同輩メカニズムによる使用のためのGSS-APIセキュリティ文脈の片端の発症機序によって生成された暗号で保護された八重奏ストリングです。 トークンのアプリケーション・プロトコルと(必要なら)転送の中のカプセル化は同輩アプリケーションの責任です。
Java GSS-API uses byte arrays to represent authentication tokens. Overloaded methods exist which allow the caller to supply input and output streams which will be used for the reading and writing of the token data.
Java GSS-APIは、認証トークンを表すのにバイト配列を使用します。 訪問者が読書とトークンデータを主題にして書くのに使用される入出力ストリームを供給できる積みすぎられたメソッドは存在しています。
4.11. Interprocess tokens
4.11. インタプロセストークン
Certain GSS-API routines are intended to transfer data between processes in multi-process programs. These routines use a caller- opaque octet-string, generated by the GSS-API in one process for use by the GSS-API in another process. The calling application is responsible for transferring such tokens between processes. Note that, while GSS-API implementors are encouraged to avoid placing sensitive information within interprocess tokens, or to cryptographically protect them, many implementations will be unable to avoid placing key material or other sensitive data within them. It is the application's responsibility to ensure that interprocess tokens are protected in transit, and transferred only to processes
あるGSS-APIルーチンはマルチプロセスプログラムにおけるプロセスの間にデータを移すつもりです。これらのルーチンは別のプロセスのGSS-APIによる使用のために1つのプロセスでGSS-APIによって生成された訪問者の不透明な八重奏ストリングを使用します。 呼ぶアプリケーションはそのようなトークンをプロセスの間に移すのに原因となります。 GSS-API作成者がインタプロセストークンの中に機密情報を置くのを避けるか、または暗号でそれらを保護するよう奨励されている間多くの実装が、それらの中に主要な材料か他の極秘データを置くのを避けることができないことに注意してください。 インタプロセストークンがトランジットで保護されて、プロセスだけに移されるのを保証するのは、アプリケーションの責任です。
Kabat & Upadhyay Standards Track [Page 18] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[18ページ]。
that are trustworthy. An interprocess token is represented using a byte array emitted from the export method of the GSSContext interface. The receiver of the interprocess token would initialize an GSSContext object with this token to create a new context. Once a context has been exported, the GSSContext object is invalidated and is no longer available.
それは信頼できます。 インタプロセストークンは、GSSContextインタフェースの輸出メソッドから放たれたバイト配列を使用することで表されます。 インタプロセストークンの受信機は、新しい関係を作成するためにこのトークンでGSSContextオブジェクトを初期化するでしょう。 文脈がいったんエクスポートされると、GSSContextオブジェクトは、無効にされて、もう利用可能ではありません。
4.12. Error Reporting
4.12. 誤り報告
RFC 2743 defined the usage of major and minor status values for signaling of GSS-API errors. The major code, also called GSS status code, is used to signal errors at the GSS-API level independent of the underlying mechanism(s). The minor status value or Mechanism status code, is a mechanism defined error value indicating a mechanism specific error code.
RFC2743はGSS-API誤りのシグナリングのために主要で小さい方の状態値の用法を定義しました。 主要なまた、GSSステータスコードと呼ばれたコードは、発症機序の如何にかかわらずGSS-APIレベルにおける誤りに合図するのに使用されます。 小さい方の状態値かMechanismステータスコードがメカニズムの特定のエラーコードを示すメカニズムの定義された誤り価値です。
Java GSS-API uses exceptions implemented by the GSSException class to signal both minor and major error values. Both mechanism specific errors and GSS-API level errors are signaled through instances of this class. The usage of exceptions replaces the need for major and minor codes to be used within the API calls. GSSException class also contains methods to obtain textual representations for both the major and minor values, which is equivalent to the functionality of gss_display_status.
Java GSS-APIは小さい方のものと同様に主要な誤り値に合図するためにGSSExceptionのクラスによって実装された例外を使用します。 メカニズムの特定の誤りとGSS-APIの平らな誤りの両方がこのクラスのインスタンスを通して合図されます。 例外の用法は主要で小さい方のコードがAPI呼び出しの中で使用される必要性を取り替えます。 また、GSSExceptionのクラスは両方の主要で小さい方の値の原文の表現を得るメソッドを含みます(gss_ディスプレイ_状態の機能性に同等です)。
4.12.1. GSS status codes
4.12.1. GSSステータスコード
GSS status codes indicate errors that are independent of the underlying mechanism(s) used to provide the security service. The errors that can be indicated via a GSS status code are generic API routine errors (errors that are defined in the GSS-API specification). These bindings take advantage of the Java exceptions mechanism, thus eliminating the need for calling errors.
GSSステータスコードは、発症機序から独立している誤りが以前はよくセキュリティー・サービスを提供していたのを示します。 GSSステータスコードで示すことができる誤りはジェネリックAPIルーチン誤り(GSS-API仕様に基づき定義される誤り)です。 これらの結合はJava例外メカニズムを利用して、その結果、誤りと呼ぶ必要性を排除します。
A GSS status code indicates a single fatal generic API error from the routine that has thrown the GSSException. Using exceptions announces that a fatal error has occurred during the execution of the method. The GSS-API operational model also allows for the signaling of supplementary status information from the per-message calls. These need to be handled as return values since using exceptions is not appropriate for informatory or warning-like information. The methods that are capable of producing supplementary information are the two per-message methods GSSContext.verifyMIC() and GSSContext.unwrap(). These methods fill the supplementary status codes in the MessageProp object that was passed in.
GSSステータスコードはGSSExceptionを投げたルーチンからただ一つの致命的なジェネリックAPI誤りを示します。 例外を使用するのは、致命的な誤りがメソッドの実行の間発生していると発表します。 またオペレーショナル・モデルがメッセージからの補っている状態情報のシグナリングのために許すGSS-APIは呼びます。 informatoryか警告のような情報には、これらの例外を使用して以来リターンが評価するように扱われるべき必要性は適切ではありません。 補助情報を作り出すできるメソッドは、2メッセージのメソッドのGSSContext.verifyMIC()とGSSContext.unwrap()です。 これらのメソッドはそれが通過されたMessagePropオブジェクトに補っているステータスコードをいっぱいにしています。
Kabat & Upadhyay Standards Track [Page 19] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[19ページ]。
GSSException object, along with providing the functionality for setting of the various error codes and translating them into textual representation, also contains the definitions of all the numeric error values. The following table lists the definitions of error codes:
また、GSSExceptionオブジェクトは様々なエラーコードの設定に機能性を提供して、原文の表現にそれらを翻訳すると共にすべての数値誤り値の定義を含んでいます。 以下のテーブルはエラーコードの定義を記載します:
Table: GSS Status Codes
以下をテーブルの上に置いてください。 GSSステータスコード
Name Value Meaning
名前値の意味
BAD_MECH 1 An unsupported mechanism
was requested.
BAD_MECH1のAnのサポートされないメカニズムは要求されました。
BAD_NAME 2 An invalid name was supplied.
BAD_NAME2のAnの無効の名前を提供しました。
BAD_NAMETYPE 3 A supplied name was of an
unsupported type.
サポートされないタイプにはBAD_NAMETYPE3のA供給された名がありました。
BAD_BINDINGS 4 Incorrect channel bindings were
supplied.
BAD_BINDINGS4Incorrectチャンネル結合を供給しました。
BAD_STATUS 5 An invalid status code was
supplied.
BAD_STATUS5のAnの無効のステータスコードを供給しました。
BAD_MIC 6 A token had an invalid MIC.
BAD_MIC6Aトークンには、無効のMICがありました。
NO_CRED 7 No credentials were supplied, or
the credentials were unavailable
or inaccessible.
資格証明書は、いいえ_CRED7いいえ資格証明書を供給したか、入手できないか、または近づきがたかったです。
NO_CONTEXT 8 Invalid context has been
supplied.
いいえ_CONTEXT8Invalid文脈を提供しました。
DEFECTIVE_TOKEN 9 A supplied token was invalid.
DEFECTIVE_TOKEN9のA供給されたトークンは無効でした。
DEFECTIVE_CREDENTIAL 10 A supplied credential was
invalid.
DEFECTIVE_CREDENTIAL10のA供給された資格証明書は無効でした。
CREDENTIALS_EXPIRED 11 The referenced credentials
have expired.
参照をつけられた資格証明書が吐き出したCREDENTIALS_EXPIRED11。
CONTEXT_EXPIRED 12 The context has expired.
文脈が吐き出したCONTEXT_EXPIRED12。
FAILURE 13 Miscellaneous failure,
unspecified at the GSS-API level.
GSS-APIレベルで不特定のFAILURE13Miscellaneousの故障。
BAD_QOP 14 The quality-of-protection
requested could not be provided.
BAD_QOP14を提供できません保護の品質が、要求した。
Kabat & Upadhyay Standards Track [Page 20] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[20ページ]。
UNAUTHORIZED 15 The operation is forbidden by
local security policy.
操作がローカルの安全保障政策によって禁じられるUNAUTHORIZED15。
UNAVAILABLE 16 The operation or option is
unavailable.
UNAVAILABLE、16 操作かオプションが入手できません。
DUPLICATE_ELEMENT 17 The requested credential
element already exists.
要求された資格証明要素のDUPLICATE_ELEMENT17は既に存在しています。
NAME_NOT_MN 18 The provided name was not a
mechanism name.
_提供が命名するミネソタ18ではなくNAME_がメカニズム名ではありませんでした。
OLD_TOKEN 19 The token's validity period has
expired.
トークンの有効期間が吐き出したOLD_TOKEN19。
DUPLICATE_TOKEN 20 The token was a duplicate of an
earlier version.
DUPLICATE_TOKEN、20 トークンは以前のバージョンの写しでした。
The GSS major status code of FAILURE is used to indicate that the underlying mechanism detected an error for which no specific GSS status code is defined. The mechanism-specific status code can provide more details about the error.
FAILUREのGSSの主要なステータスコードは、発症機序がどんな特定のGSSステータスコードも定義されない誤りを検出したのを示すのに使用されます。 メカニズム特有のステータスコードは誤りに関するその他の詳細を提供できます。
The different major status codes that can be contained in the GSSException object thrown by the methods in this specification are the same as the major status codes returned by the corresponding calls in RFC 2743 [GSSAPIv2-UPDATE].
この仕様でメソッドで投げられたGSSExceptionオブジェクトに含むことができる異なった主要なステータスコードは対応する呼び出しで主要なステータスコードがRFC2743[GSSAPIv2-UPDATE]で戻ったのと同じです。
4.12.2. Mechanism-specific status codes
4.12.2. メカニズム特有のステータスコード
Mechanism-specific status codes are communicated in two ways, they are part of any GSSException thrown from the mechanism specific layer to signal a fatal error, or they are part of the MessageProp object that the per-message calls use to signal non-fatal errors.
メカニズム特有のステータスコードは2つの方法で伝えられるか、それらが致命的な誤りに合図するためにメカニズムの特定の層から投げられたどんなGSSExceptionの一部であるかそれらが1メッセージあたりの呼び出しが非致命的な誤りに合図するのに使用するMessagePropオブジェクトの一部です。
A default value of 0 in either the GSSException object or the MessageProp object will be used to represent the absence of any mechanism specific status code.
GSSExceptionオブジェクトかMessagePropオブジェクトのどちらかの0のデフォルト値は、どんなメカニズムの特定のステータスコードの欠如も表すのに使用されるでしょう。
4.12.3. Supplementary status codes
4.12.3. 補っているステータスコード
Supplementary status codes are confined to the per-message methods of the GSSContext interface. Because of the informative nature of these errors it is not appropriate to use exceptions to signal them. Instead, the per-message operations of the GSSContext interface return these values in a MessageProp object.
補っているステータスコードはGSSContextインタフェースの1メッセージあたりのメソッドに閉じ込められます。 これらの誤りの有益な本質のために、それらに合図するのに例外を使用するのは適切ではありません。 代わりに、GSSContextインタフェースの1メッセージあたりの操作はMessagePropオブジェクトでこれらの値を返します。
Kabat & Upadhyay Standards Track [Page 21] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[21ページ]。
The MessageProp class defines query methods which return boolean values indicating the following supplementary states:
MessagePropのクラスは以下の補っている州を示すブール値を返す質問メソッドを定義します:
Table: Supplementary Status Methods
以下をテーブルの上に置いてください。 補っている状態メソッド
Method Name Meaning when "true" is returned
「本当である」ときに、メソッドName Meaningを返します。
isDuplicateToken The token was a duplicate of an
earlier token.
isDuplicateToken、トークンは以前のトークンの写しでした。
isOldToken The token's validity period has
expired.
isOldToken、トークンの有効期間は期限が切れました。
isUnseqToken A later token has already been
processed.
既にisUnseqTokenのA後のトークンを処理してあります。
isGapToken An expected per-message token was
not received.
isGapToken Anは、1メッセージあたりのトークンが受け取られなかったと予想しました。
"true" return value for any of the above methods indicates that the token exhibited the specified property. The application must determine the appropriate course of action for these supplementary values. They are not treated as errors by the GSS-API.
上のメソッドのどれかの「本当」のリターン値は、トークンが指定された特性を示したのを示します。 アプリケーションはこれらの補っている値のための適切な行動を決定しなければなりません。 それらはGSS-APIによって誤りとして扱われません。
4.13. Names
4.13. 名前
A name is used to identify a person or entity. GSS-API authenticates the relationship between a name and the entity claiming the name.
名前は、人か実体を特定するのに使用されます。 GSS-APIは名前を要求する名前と実体との関係を認証します。
Since different authentication mechanisms may employ different namespaces for identifying their principals, GSS-API's naming support is necessarily complex in multi-mechanism environments (or even in some single-mechanism environments where the underlying mechanism supports multiple namespaces).
異なった認証機構がそれらの主体を特定するのに異なった名前空間を使うかもしれないので、GSS-API命名サポートは必ずマルチメカニズム環境(または発症機序が複数の名前空間をサポートするいくつかのただ一つのメカニズム環境でさえ)で複雑です。
Two distinct conceptual representations are defined for names:
2つの異なった概念的な表現が名前のために定義されます:
1) A GSS-API form represented by implementations of the GSSName
interface: A single GSSName object may contain multiple names from
different namespaces, but all names should refer to the same
entity. An example of such an internal name would be the name
returned from a call to the getName method of the GSSCredential
interface, when applied to a credential containing credential
elements for multiple authentication mechanisms employing
different namespaces. This GSSName object will contain a distinct
name for the entity for each authentication mechanism.
1) GSSNameインタフェースの実装によって表されたGSS-API書式: 単一のGSSNameオブジェクトは異なった名前空間からの複数の名前を含むかもしれませんが、すべての名前が同じ実体について言及するべきです。 そのような内部名に関する例は呼び出しからGSSCredentialインタフェースのgetNameメソッドまで返された名前でしょう、複数の認証機構のための異なった名前空間を使う資格証明要素を含む資格証明書に適用されると。 このGSSNameオブジェクトは各認証機構のための実体のための別個の名前を含むでしょう。
Kabat & Upadhyay Standards Track [Page 22] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[22ページ]。
For GSS-API implementations supporting multiple namespaces,
GSSName implementations must contain sufficient information to
determine the namespace to which each primitive name belongs.
複数の名前空間をサポートするGSS-API実行のために、GSSName実装はそれぞれの原始の名前が属する名前空間を決定できるくらいの情報を含まなければなりません。
2) Mechanism-specific contiguous byte array and string forms:
Different GSSName initialization methods are provided to handle
both byte array and string formats and to accommodate various
calling applications and name types. These formats are capable of
containing only a single name (from a single namespace).
Contiguous string names are always accompanied by an object
identifier specifying the namespace to which the name belongs, and
their format is dependent on the authentication mechanism that
employs that name. The string name forms are assumed to be
printable, and may therefore be used by GSS-API applications for
communication with their users. The byte array name formats are
assumed to be in non-printable formats (e.g. the byte array
returned from the export method of the GSSName interface).
2) メカニズム特有の隣接のバイト配列とストリングフォーム: バイト配列と記号列の書式の両方を扱って、様々な呼ぶアプリケーションと名前タイプに対応するために異なったGSSName初期化メソッドを提供します。 これらの形式はただ一つの名前(ただ一つの名前空間からの)しか含むことができません。 隣接のストリング名はいつも名前が属する名前空間を指定するオブジェクト識別子によって伴われます、そして、それらの形式はその名前を使う認証機構に依存しています。 ストリング名前フォームは、印刷可能であると思われて、したがって、彼らのユーザとのコミュニケーションのGSS-APIアプリケーションで使用されるかもしれません。 非印刷可能な形式にはバイト配列名形式があると思われます(例えば、バイト配列はGSSNameインタフェースの輸出メソッドから戻りました)。
A GSSName object can be converted to a contiguous representation by using the toString method. This will guarantee that the name will be converted to a printable format. Different initialization methods in the GSSName interface are defined allowing support for multiple syntaxes for each supported namespace, and allowing users the freedom to choose a preferred name representation. The toString method should use an implementation-chosen printable syntax for each supported name-type. To obtain the printable name type, getStringNameType method can be used.
toStringメソッドを使用することによって、GSSNameオブジェクトを隣接の表現に変換できます。 これは、名前が印刷可能な形式に変換されるのを保証するでしょう。 GSSNameインタフェースの異なった初期化メソッドは、それぞれのサポートしている名前空間のための複数の構文のサポートを許して、都合のよい名前表現を選ぶ自由をユーザに許容しながら、定義されます。 toStringメソッドは名前タイプであるとサポートされたそれぞれに実装に選ばれた印刷可能な構文を使用するべきです。 タイプという印刷可能な名前を得るために、getStringNameTypeメソッドを使用できます。
There is no guarantee that calling the toString method on the GSSName interface will produce the same string form as the original imported string name. Furthermore, it is possible that the name was not even constructed from a string representation. The same applies to name- space identifiers which may not necessarily survive unchanged after a journey through the internal name-form. An example of this might be a mechanism that authenticates X.500 names, but provides an algorithmic mapping of Internet DNS names into X.500. That mechanism's implementation of GSSName might, when presented with a DNS name, generate an internal name that contained both the original DNS name and the equivalent X.500 name. Alternatively, it might only store the X.500 name. In the latter case, the toString method of GSSName would most likely generate a printable X.500 name, rather than the original DNS name.
GSSNameインタフェースにtoStringメソッドを呼ぶとオリジナルがストリング名を意味したので同じストリングフォームが製作されるという保証が全くありません。 その上、名前がストリング表現から構成さえされなかった、可能です。 同じくらいは、内部名フォームを通した旅行の後に必ず変わりがない状態で存続するかもしれないというわけではない識別子とスペースを命名するのに申し込みます。 この例はX.500名を認証しますが、インターネットDNS名のアルゴリズムのマッピングをX.500に供給するメカニズムであるかもしれません。 DNS名を与えるとき、そのメカニズムのGSSNameの実装はオリジナルのDNS名と同等なX.500名の両方を含んだ内部名を生成するかもしれません。 あるいはまた、それはX.500名を保存するだけであるかもしれません。 後者の場合では、GSSNameのtoStringメソッドはたぶんオリジナルのDNS名よりむしろ印刷可能なX.500名を生成するでしょう。
The context acceptor can obtain a GSSName object representing the entity performing the context initiation (through the usage of getSrcName method). Since this name has been authenticated by a single mechanism, it contains only a single name (even if the internal name presented by the context initiator to the GSSContext
文脈アクセプタは文脈開始(getSrcNameメソッドの用法による)を実行する実体を表すGSSNameオブジェクトを入手できます。 この名前がただ一つのメカニズムによって認証されたので、ただ一つの名前だけを含んでいる、(内部名は文脈創始者をGSSContextに紹介しました。
Kabat & Upadhyay Standards Track [Page 23] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[23ページ]。
object had multiple components). Such names are termed internal mechanism names, or "MN"s and the names emitted by GSSContext interface in the getSrcName and getTargName are always of this type. Since some applications may require MNs without wanting to incur the overhead of an authentication operation, creation methods are provided that take not only the name buffer and name type, but also the mechanism oid for which this name should be created. When dealing with an existing GSSName object, the canonicalize method may be invoked to convert a general internal name into an MN.
オブジェクトには複数のコンポーネントがあった、) 「ミネソタ」sとGSSContextによって放たれた名前はgetSrcNameで連結します、そして、そのような名前が内部のメカニズム名と呼ばれるか、またはいつもこのタイプにはgetTargNameがあります。 いくつかのアプリケーションが認証操作のオーバーヘッドを被りたくなくてMNsを必要とするかもしれないので、タイプという名前バッファと名前だけではなく、撮影であれば、作成メソッドが必要ですが、メカニズムもこの名前が作成されるべきであるoidです。 既存のGSSNameオブジェクトに対処するときcanonicalizeする、メソッドは、一般的な内部名をミネソタに変換するために呼び出されるかもしれません。
GSSName objects can be compared using their equal method, which returns "true" if the two names being compared refer to the same entity. This is the preferred way to perform name comparisons instead of using the printable names that a given GSS-API implementation may support. Since GSS-API assumes that all primitive names contained within a given internal name refer to the same entity, equal can return "true" if the two names have at least one primitive name in common. If the implementation embodies knowledge of equivalence relationships between names taken from different namespaces, this knowledge may also allow successful comparisons of internal names containing no overlapping primitive elements.
それらの等しいメソッド(比較される2つの名前が同じ実体について言及するなら、「本当に」戻る)を使用することでGSSNameオブジェクトを比較できます。 これは与えられたGSS-API実行がサポートするかもしれない印刷可能な名前を使用することの代わりに名前比較を実行する都合のよい方法です。 GSS-APIが、与えられた内部名の中に含まれたすべての原始の名前が同じ実体について言及すると仮定するので、2つの名前が少なくとも1つの原始の名前が共通であるなら、同輩は「本当に」戻ることができます。 また、実装が異なった名前空間から取られた名前の間の等価性関係に関する知識を具体化するなら、この知識は重なっていない原始の要素を含む内部名のうまくいっている比較を許すかもしれません。
When used in large access control lists, the overhead of creating an GSSName object on each name and invoking the equal method on each name from the ACL may be prohibitive. As an alternative way of supporting this case, GSS-API defines a special form of the contiguous byte array name which may be compared directly (byte by byte). Contiguous names suitable for comparison are generated by the export method. Exported names may be re-imported by using the byte array constructor and specifying the NT_EXPORT_NAME as the name type object identifier. The resulting GSSName name will also be a MN. The GSSName interface defines public static Oid objects representing the standard name types. Structurally, an exported name object consists of a header containing an OID identifying the mechanism that authenticated the name, and a trailer containing the name itself, where the syntax of the trailer is defined by the individual mechanism specification. Detailed description of the format is specified in the language-independent GSS-API specification [GSSAPIv2-UPDATE].
大きいアクセスコントロールリストに使用されると、GSSNameオブジェクトを各名前に作成して、各名前にACLから等しいメソッドを呼び出すオーバーヘッドはひどく高いかもしれません。 本件を支える代替の方法と、GSS-APIは直接比較されるかもしれない隣接のバイト配列名(バイトごとの)の特別な書式を定義します。 比較に適した隣接の名前は輸出メソッドで生成されます。 エクスポートしている名前は、名前タイプオブジェクト識別子としてバイト配列建設者を使用して、NT_EXPORT_NAMEを指定することによって、逆輸入されるかもしれません。 また、結果として起こるGSSName名はミネソタになるでしょう。 GSSNameインタフェースはタイプという標準の名前を表す公共の静的なOidオブジェクトを定義します。 構造的に、エクスポートしている名前オブジェクトは名前を認証したメカニズムを特定するOIDを含むヘッダー、および名前自体を含むトレーラから成ります。そこでは、トレーラの構文が独特のメカニズム仕様で定義されます。 形式の詳述は言語から独立しているGSS-API仕様[GSSAPIv2-UPDATE]で指定されます。
Note that the results obtained by using the equals method will in general be different from those obtained by invoking canonicalize and export, and then comparing the byte array output. The first series of operation determines whether two (unauthenticated) names identify the same principal; the second whether a particular mechanism would authenticate them as the same principal. These two operations will in general give the same results only for MNs.
同輩を使用することによって得て、一般に、メソッドが呼び出すことによって得られたものと異なるという結果が出力をcanonicalizeして、エクスポートして、そしてバイトを突き合わせて整列させることに注意してください。 最初のシリーズの操作は、2つ(非認証した)の名前が同じ主体を特定するかどうか決定します。 特定のメカニズムがそうするだろうかどうかが同じ主体としてそれらを認証する秒。 一般に、これらの2つの操作がMNsのためだけに同じ結果を与えるでしょう。
Kabat & Upadhyay Standards Track [Page 24] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[24ページ]。
It is important to note that the above are guidelines as how GSSName implementations should behave, and are not intended to be specific requirements of how names objects must be implemented. The mechanism designers are free to decide on the details of their implementations of the GSSName interface as long as the behavior satisfies the above guidelines.
GSSName実装がどう振る舞うべきであり、具体的に言うと、意図しないかとして上記がガイドラインであることに注意するために、名前がどう反対するかに関する要件を実装しなければならないのは重要です。 振舞いが上記のガイドラインを満たす限り、メカニズムデザイナーは自由にそれらのGSSNameインタフェースの実装の詳細を決めることができます。
4.14. Channel Bindings
4.14. チャンネル結合
GSS-API supports the use of user-specified tags to identify a given context to the peer application. These tags are intended to be used to identify the particular communications channel that carries the context. Channel bindings are communicated to the GSS-API using the ChannelBinding object. The application may use byte arrays to specify the application data to be used in the channel binding as well as using instances of the InetAddress. The InetAddress for the initiator and/or acceptor can be used within an instance of a ChannelBinding. ChannelBinding can be set for the GSSContext object using the setChannelBinding method before the first call to init or accept has been performed. Unless the setChannelBinding method has been used to set the ChannelBinding for a GSSContext object, "null" ChannelBinding will be assumed. InetAddress is currently the only address type defined within the Java platform and as such, it is the only one supported within the ChannelBinding class. Applications that use other types of addresses can include them as part of the application specific data.
GSS-APIは、同輩アプリケーションへの与えられた文脈を特定するためにユーザによって指定されたタグの使用をサポートします。 文脈を運ぶ特定のコミュニケーションチャンネルを特定するのにこれらのタグが使用されることを意図します。 チャンネル結合は、ChannelBindingオブジェクトを使用することでGSS-APIに伝えられます。 アプリケーションは、InetAddressのインスタンスを縛って、使用しながらチャンネルで使用されるためにアプリケーションデータを指定するのにバイト配列を使用するかもしれません。 ChannelBindingのインスタンスの中で創始者、そして/または、アクセプタのためのInetAddressを使用できます。 ChannelBindingによるGSSContextが準備ラッパの前にsetChannelBindingメソッドをイニットに使用することで反対するか、または受け入れるのでセットが実行されたということであることができます。 setChannelBindingメソッドがGSSContextオブジェクトにChannelBindingを設定するのに使用されていないと、「ヌル」のChannelBindingは想定されるでしょう。 現在InetAddressはJavaプラットホームの中で定義された唯一のアドレスタイプです、そして、そういうものとして、それはChannelBindingのクラスの中でサポートされた唯一無二です。 他のタイプのアドレスを使用するアプリケーションはアプリケーションの特定のデータの一部としてそれらを含むことができます。
Conceptually, the GSS-API concatenates the initiator and acceptor address information, and the application supplied byte array to form an octet string. The mechanism calculates a MIC over this octet string and binds the MIC to the context establishment token emitted by init method of the GSSContext interface. The same bindings are set by the context acceptor for its GSSContext object and during processing of the accept method a MIC is calculated in the same way. The calculated MIC is compared with that found in the token, and if the MICs differ, accept will throw a GSSException with the major code set to BAD_BINDINGS, and the context will not be established. Some mechanisms may include the actual channel binding data in the token (rather than just a MIC); applications should therefore not use confidential data as channel-binding components.
概念的に、GSS-APIは八重奏ストリングを形成する創始者、アクセプタアドレス情報、およびアプリケーションの供給されたバイト配列を連結します。 メカニズムは、この八重奏ストリングに関してMICについて計算して、GSSContextインタフェースのイニットメソッドで放たれた文脈設立トークンにMICを縛ります。 メソッドを受け入れてください。同じ結合がGSSContextオブジェクトと処理の間の文脈アクセプタによって設定される、同様に、MICは計算されます。 計算されたMICはトークンで見つけられるそれと比較されます、そして、MICsが異なって、受け入れるなら主要なコードセットでBAD_BINDINGSにGSSExceptionを投げて、文脈は確立されないでしょう。 いくつかのメカニズムがトークン(まさしくMICよりむしろ)にデータを縛る実際のチャンネルを含むかもしれません。 したがって、アプリケーションはチャンネルを拘束力があるコンポーネントとして秘密のデータを使用するべきではありません。
Individual mechanisms may impose additional constraints on addresses that may appear in channel bindings. For example, a mechanism may verify that the initiator address field of the channel binding contains the correct network address of the host system. Portable applications should therefore ensure that they either provide correct information for the address fields, or omit setting of the addressing information.
個々のメカニズムはチャンネル結合に現れるかもしれないアドレスに追加規制を課すかもしれません。 例えば、メカニズムは、チャンネル結合の創始者アドレス・フィールドがホストシステムの正しいネットワーク・アドレスを含むことを確かめるかもしれません。 したがって、携帯用のアプリケーションは、アドレス・フィールドに正確な情報を前提とするか、またはセットするのをアドレス指定情報を忘れるのを確実にするべきです。
Kabat & Upadhyay Standards Track [Page 25] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[25ページ]。
4.15. Stream Objects
4.15. ストリームオブジェクト
The context object provides overloaded methods which use input and output streams as the means to convey authentication and per-message GSS-API tokens. It is important to note that the streams are expected to contain the usual GSS-API tokens which would otherwise be handled through the usage of byte arrays. The tokens are expected to have a definite start and an end. The callers are responsible for ensuring that the supplied streams will not block, or expect to block until a full token is processed by the GSS-API method. Only a single GSS-API token will be processed per invocation of the stream based method.
文脈オブジェクトは認証を伝える手段として入出力ストリームを使用する積みすぎられたメソッドと1メッセージあたりのGSS-APIトークンを提供します。 ストリームがそうでなければバイト配列の用法で扱われる普通のGSS-APIトークンを含むと予想されることに注意するのは重要です。 トークンには明確な始めと端があると予想されます。 完全なトークンがGSS-APIメソッドで処理されるまで、訪問者は供給されたストリームが妨げると妨げるか、または予想しない確実にするのに責任があります。 ただ一つのGSS-APIトークンだけがストリームのベースのメソッドの実施単位で処理されるでしょう。
The usage of streams allows the callers to have control and management of the supplied buffers. Because streams are non- primitive objects, the callers can make the streams as complicated or as simple as desired simply by using the streams defined in the java.io package or creating their own through the use of inheritance. This will allow for the application's greatest flexibility.
ストリームの用法で、訪問者は供給されたバッファのコントロールと管理を持つことができます。 ストリームが非原始のオブジェクトであるので、訪問者はjava.ioパッケージかそれら自身のを作成する際に継承の使用で単にストリームを使用することによって望まれているのと同じくらい複雑であるか同じくらい簡単であるとしてのストリームを定義させることができます。 これはアプリケーションの最も優れた柔軟性を考慮するでしょう。
4.16. Optional Parameters
4.16. 任意のパラメタ
Whenever the application wishes to omit an optional parameter the "null" value shall be used. The detailed method descriptions indicate which parameters are optional. Methods overloading has also been used as a technique to indicate default parameters.
アプリケーションが任意のパラメタを省略したがっているときはいつも、「ヌル」の値は使用されるものとします。 詳細なメソッド記述は、どのパラメタが任意であるかを示します。 また、メソッド積みすぎは、デフォルトパラメタを示すのにテクニックとして使用されました。
5. Introduction to GSS-API Classes and Interfaces
5. GSS-APIのクラスとインタフェースへの紹介
This section presents a brief description of the classes and interfaces that constitute the GSS-API. The implementations of these are obtained from the CLASSPATH defined by the application. If Java GSS becomes part of the standard Java API's then these classes will be available by default on all systems as part of the JRE's system classes.
このセクションはGSS-APIを構成するクラスとインタフェースの簡単な説明を提示します。 アプリケーションで定義されたCLASSPATHからこれらの実装を得ます。 Java GSSが標準のAPIのJavaものの一部になると、JREのシステムの一部が属するようにこれらのクラスはデフォルトですべてのシステムの上で利用可能になるでしょう。
This section also shows the corresponding RFC 2743 functionality implemented by each of the classes. Detailed description of these classes and their methods is presented in section 6.
また、このセクションはそれぞれのクラスによって実装された対応するRFC2743の機能性を示しています。 これらのクラスとそれらのメソッドの詳述はセクション6に示されます。
5.1. GSSManager class
5.1. GSSManagerのクラス
This abstract class serves as a factory to instantiate implementations of the GSS-API interfaces and also provides methods to make queries about underlying security mechanisms.
GSS-APIの実装を例示する工場が基本的なセキュリティに関する質問をメカニズムにするメソッドを連結して、また、提供するとき、この抽象クラスは役立ちます。
Kabat & Upadhyay Standards Track [Page 26] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[26ページ]。
A default implementation can be obtained using the static method getInstance(). Applications that desire to provide their own implementation of the GSSManager class can simply extend the abstract class themselves.
静的なメソッドgetInstance()を使用することでデフォルト実装を得ることができます。 それら自身のGSSManagerのクラスの実装を提供することを望んでいるアプリケーションは単に自分たちで抽象クラスを広げることができます。
This class contains equivalents of the following RFC 2743 routines:
このクラスは以下のRFC2743ルーチンの同等物を含みます:
gss_import_name Create an internal name from 6.1.9-
the supplied information. 6.1.12
gss_輸入_が6.1からCreateを内部名と命名する、.9、-、供給された情報。 6.1.12
gss_acquire_cred Acquire credential 6.1.13-
for use. 6.1.15
gss_が_信用Acquireの資格証明6.1.13を取得する、-、使用のために。 6.1.15
gss_import_sec_context Create a previously exported 6.1.18
context.
gss_は、_秒_文脈Createが以前にエクスポートしている6.1.18文脈であるとインポートします。
gss_indicate_mechs List the mechanisms 6.1.6
supported by this GSS-API
implementation.
gss_は_メカニズム6.1.6がこのGSS-API実行でサポートしたmechs Listを示します。
gss_inquire_mechs_for_name List the mechanisms 6.1.8
supporting the
specified name type.
__がタイプという指定された名前をサポートするメカニズム6.1.8とListを命名するので、gss_は_mechsについて問い合わせます。
gss_inquire_names_for_mech List the name types 6.1.7
supported by the
specified mechanism.
gss_は__名前タイプ6.1のmech List.7のための_が指定されたメカニズムでサポートした名前について問い合わせます。
5.2. GSSName interface
5.2. GSSNameインタフェース
GSS-API names are represented in the Java bindings through the GSSName interface. Different name formats and their definitions are identified with universal Object Identifiers (oids). The format of the names can be derived based on the unique oid of each name type. The following GSS-API routines are provided by the GSSName interface:
GSS-API名はGSSNameインタフェースを通したJava結合で表されます。 異なった名前形式と彼らの定義は普遍的なObject Identifiers(oids)と同一視されています。 それぞれの名前タイプのユニークなoidに基づいて名前の形式を引き出すことができます。 GSSNameインタフェースは以下のGSS-APIルーチンを提供します:
RFC 2743 Routine Function Section(s)
RFC2743の通常の機能部(s)
gss_display_name Covert internal name 6.2.7
representation to text format.
テキスト形式へのgss_ディスプレイ_名前Covert内部名6.2.7表現。
gss_compare_name Compare two internal names. 6.2.3, 6.2.4
gss_は_名前Compare two内部名を比較します。 6.2.3, 6.2.4
gss_release_name Release resources associated N/A
with the internal name.
gss_リリース_名前ReleaseリソースはN/Aを内部名に関連づけました。
Kabat & Upadhyay Standards Track [Page 27] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[27ページ]。
gss_canonicalize_name Convert an internal name to a 6.1.11,
mechanism name.
gss_は_名前Convertをcanonicalizeします。a6.1.11、メカニズム名への内部名。
gss_export_name Convert a mechanism name to 6.2.6
export format.
gss_は、_名前Convertがメカニズム名であると6.2.6輸出形式にエクスポートします。
gss_duplicate_name Create a copy of the internal N/A
name.
内部のN/A名のgss_写し_名前Create aコピー。
The gss_release_name call is not provided as Java does its own garbage collection. The gss_duplicate_name call is also redundant; the GSSName interface has no mutator methods that can change the state of the object so it is safe for sharing.
Javaがそれ自身のガーベージコレクションをするとき、呼ぶというgss_リリース_名は提供されません。 また、呼ぶというgss_写し_名も余分です。 GSSNameインタフェースにはオブジェクトの状態を変えることができるmutatorメソッドが全くないので、共有するのに、それは安全です。
5.3. GSSCredential interface
5.3. GSSCredentialインタフェース
The GSSCredential interface is responsible for the encapsulation of GSS-API credentials. Credentials identify a single entity and provide the necessary cryptographic information to enable the creation of a context on behalf of that entity. A single credential may contain multiple mechanism specific credentials, each referred to as a credential element. The GSSCredential interface provides the functionality of the following GSS-API routines:
GSSCredentialインタフェースはGSS-API資格証明書のカプセル化に責任があります。 資格証明書は、その実体を代表して文脈の作成を可能にするために単一体を特定して、必要な暗号の情報を提供します。 ただ一つの資格証明書は複数のメカニズムの特定の資格証明書、資格証明要素と呼ばれたそれぞれを含むかもしれません。 GSSCredentialインタフェースは以下のGSS-APIルーチンの機能性を提供します:
RFC 2743 Routine Function Section(s)
RFC2743の通常の機能部(s)
gss_add_cred Constructs credentials 6.3.12
incrementally.
gss_は_信用Constructs資格証明書6.3.12を増加して加えます。
gss_inquire_cred Obtain information about 6.3.4,6.3.5
credential.
gss_は_信用Obtain情報およそ6.3.4、6.3.5資格証明書について問い合わせます。
gss_inquire_cred_by_mech Obtain per-mechanism 6.3.5-6.3.10
information about
a credential.
gss_は_資格証明書の1メカニズムあたりmech Obtain6.3.5-6.3.10情報で_信用_について問い合わせます。
gss_release_cred Disposes of credentials 6.3.3
after use.
使用の後の資格証明書6.3.3のgss_リリース_信用Disposes。
5.4. GSSContext interface
5.4. GSSContextインタフェース
This interface encapsulates the functionality of context-level calls required for security context establishment and management between peers as well as the per-message services offered to applications. A context is established between a pair of peers and allows the usage of security services on a per-message basis on application data. It
このインタフェースはアプリケーションに提供された1メッセージあたりのサービスと同様に同輩の間のセキュリティ文脈設立と管理に必要である文脈レベル呼び出しの機能性をカプセル化します。 文脈は、アプリケーションデータに1組の同輩の間で確立されて、1メッセージあたり1個のベースにセキュリティー・サービスの用法を許容します。 それ
Kabat & Upadhyay Standards Track [Page 28] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[28ページ]。
is created over a single security mechanism. The GSSContext interface provides the functionality of the following GSS-API routines:
ただ一つのセキュリティー対策の上に作成されます。 GSSContextインタフェースは以下のGSS-APIルーチンの機能性を提供します:
RFC 2743 Routine Function Section(s)
RFC2743の通常の機能部(s)
gss_init_sec_context Initiate the creation of a 6.4.3,
security context with a peer. 6.4.4
gss_イニット_、a6.4.3の作成、aがあるセキュリティ文脈がじっと見る秒の_文脈Initiate。 6.4.4
gss_accept_sec_context Accept a security context 6.4.5,
initiated by a peer. 6.4.6
gss_は_同輩によって開始された秒_文脈Accept aセキュリティ文脈6.4.5を受け入れます。 6.4.6
gss_delete_sec_context Destroy a security context. 6.4.8
gss_は_秒_文脈Destroy aセキュリティ文脈を削除します。 6.4.8
gss_context_time Obtain remaining context 6.4.37
time.
gss_文脈の_の時間のObtainの残っている文脈6.4.37時間。
gss_inquire_context Obtain context 6.4.29 to
characteristics. 6.3.42
gss_は_文脈Obtain文脈6.4.29について特性に問い合わせます。 6.3.42
gss_wrap_size_limit Determine token-size limit 6.4.9
for gss_wrap.
gss_包装_サイズ_限界Determineトークンサイズ限界、6.4、.9、gss_包装のために。
gss_export_sec_context Transfer security context 6.4.18
to another process.
別のものへのgss_輸出_秒_文脈Transferセキュリティ文脈6.4.18は処理されます。
gss_get_mic Calculate a cryptographic 6.4.14,
Message Integrity Code (MIC) 6.4.15
for a message.
aのためのMessage Integrity Code(MIC)6.4.15は、gss_が_mic Calculate a暗号の6.4.14を得るのを通信します。
gss_verify_mic Verify integrity on a received 6.4.16,
message. 6.4.17
gss_はa容認された6.4.16で_mic Verify保全について確かめて、通信してください。 6.4.17
gss_wrap Attach a MIC to a message and 6.4.10,
optionally encrypt the message 6.4.11
content.
gss_はaメッセージと6.4.10にAttach a MICを包装して、任意にメッセージを暗号化してください。6.4.11内容。
gss_unwrap Obtain a previously wrapped 6.4.12,
application message verifying 6.4.13
its integrity and optionally
decrypting it.
gss_が開けられる、Obtain aが以前に6.4に.12、アプリケーションメッセージ検証を包装した、6.4、.13、保全と任意にそれを解読すること。
The functionality offered by the gss_process_context_token routine has not been included in the Java bindings specification. The corresponding functionality of gss_delete_sec_context has also been modified to not return any peer tokens. This has been proposed in
gss_プロセス_文脈_トークンルーチンで提供された機能性はJava結合仕様に含まれていません。 gss_の対応する機能性は_また文脈がどんな同輩トークンも返さないように変更された_秒を削除します。 これでは、提案されました。
Kabat & Upadhyay Standards Track [Page 29] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[29ページ]。
accordance to the recommendations stated in RFC 2743. GSSContext does offer the functionality of destroying the locally-stored context information.
RFC2743に述べられた推薦との一致。 GSSContextは局所的に保存された文脈情報を無効にする機能性を提供します。
5.5. MessageProp class
5.5. MessagePropのクラス
This helper class is used in the per-message operations on the context. An instance of this class is created by the application and then passed into the per-message calls. In some cases, the application conveys information to the GSS-API implementation through this object and in other cases the GSS-API returns information to the application by setting it in this object. See the description of the per-message operations wrap, unwrap, getMIC, and verifyMIC in the GSSContext interfaces for details.
このアシスタントのクラスは文脈で1メッセージあたりの操作に使用されます。 このクラスのインスタンスは、1メッセージあたりの呼び出しにアプリケーションで作成されて、次に、通過されます。 いくつかの場合、アプリケーションはこのオブジェクトを通してGSS-API実行に情報を伝達します、そして、他の場合では、GSS-APIは情報をアプリケーションにこのオブジェクトにそれをはめ込むことによって、返します。 getMIC、操作が包装するメッセージの記述を見て、開けてください。そうすれば、GSSContextのverifyMICは詳細のために連結します。
5.6. GSSException class
5.6. GSSExceptionのクラス
Exceptions are used in the Java bindings to signal fatal errors to the calling applications. This replaces the major and minor codes used in the C-bindings specification as a method of signaling failures. The GSSException class handles both minor and major codes, as well as their translation into textual representation. All GSS- API methods are declared as throwing this exception.
例外は、呼ぶアプリケーションに致命的な誤りに合図するのにJava結合に使用されます。 これは失敗に合図するメソッドとしてC-結合仕様で使用される主要で小さい方のコードを置き換えます。 GSSExceptionのクラスは小さい方の、そして、主要なコードと原文の表現への彼らの翻訳の両方を扱います。 すべてのGSS APIメソッドがこの例外を投げるとして宣言されます。
RFC 2743 Routine Function Section
RFC2743の通常の機能部
gss_display_status Retrieve textual 6.8.5, 6.8.6,
representation of error 6.8.8, 6.8.9
codes.
gss_ディスプレイ_状態Retrieve原文の6.8.5、6.8.6、誤りの表現、6.8、.8、6.8 .9 コード化します。
5.7. Oid class
5.7. Oidのクラス
This utility class is used to represent Universal Object Identifiers and their associated operations. GSS-API uses object identifiers to distinguish between security mechanisms and name types. This class, aside from being used whenever an object identifier is needed, implements the following GSS-API functionality:
このユーティリティのクラスは、Universal Object Identifiersと彼らの関連操作を表すのに使用されます。 GSS-APIは、セキュリティー対策と名前タイプを見分けるのにオブジェクト識別子を使用します。 オブジェクト識別子が必要であるときはいつも、使用されることは別として、このクラスは以下のGSS-APIの機能性を実装します:
RFC 2743 Routine Function Section
RFC2743の通常の機能部
gss_test_oid_set_member Determine if the specified oid 6.7.5
is part of a set of oids.
gss_テスト_oid_が指定されたoidであるなら_メンバーDetermineを設定した、6.7、.5、oidsの1セットの一部がそうです。
Kabat & Upadhyay Standards Track [Page 30] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[30ページ]。
5.8. ChannelBinding class
5.8. ChannelBindingのクラス
An instance of this class is used to specify channel binding information to the GSSContext object before the start of a security context establishment. The application may use a byte array to specify application data to be used in the channel binding as well as use instances of the InetAddress. InetAddress is currently the only address type defined within the Java platform and as such, it is the only one supported within the ChannelBinding class. Applications that use other types of addresses can include them as part of the application data.
このクラスのインスタンスは、セキュリティ文脈設立の始まりの前にGSSContextオブジェクトに情報を縛るチャンネルを指定するのに使用されます。 アプリケーションは、チャンネル結合に使用されて、InetAddressのインスタンスを使用するためにアプリケーションデータを指定するのにバイト配列を使用するかもしれません。 現在InetAddressはJavaプラットホームの中で定義された唯一のアドレスタイプです、そして、そういうものとして、それはChannelBindingのクラスの中でサポートされた唯一無二です。 他のタイプのアドレスを使用するアプリケーションはアプリケーションデータの一部としてそれらを含むことができます。
6. Detailed GSS-API Class Description
6. 詳細なGSS-APIクラス記述
This section lists a detailed description of all the public methods that each of the GSS-API classes and interfaces must provide.
このセクションはそれぞれのGSS-APIのクラスとインタフェースが提供しなければならないすべての公共のメソッドの詳述を記載します。
6.1. public abstract class GSSManager
6.1. 公共の抽象クラスGSSManager
The GSSManager class is an abstract class that serves as a factory for three GSS interfaces: GSSName, GSSCredential, and GSSContext. It also provides methods for applications to determine what mechanisms are available from the GSS implementation and what nametypes these mechanisms support. An instance of the default GSSManager subclass may be obtained through the static method getInstance(), but applications are free to instantiate other subclasses of GSSManager.
GSSManagerのクラスは3GSSのための工場が連結するとき役立つ抽象クラスです: GSSName、GSSCredential、およびGSSContext。 また、それはアプリケーションが、どんなメカニズムがGSS実装から利用可能であるか、そして、これらのメカニズムがどんなnametypesをサポートするかを決定するメソッドを提供します。 静的なメソッドgetInstance()でデフォルトGSSManagerサブクラスのインスタンスを得るかもしれませんが、アプリケーションは無料でGSSManagerの他のサブクラスを例示できます。
All but one method in this class are declared abstract. This means that subclasses have to provide the complete implementation for those methods. The only exception to this is the static method getInstance() which will have platform specific code to return an instance of the default subclass.
このクラスにおける1つのメソッド以外のすべてが抽象的であると宣言されます。 これは、サブクラスが完全な実装をそれらのメソッドに提供しなければならないことを意味します。 これへの唯一の例外がデフォルトサブクラスのインスタンスを返すプラットホームの特定のコードがある静的なメソッドgetInstance()です。
Platform providers of GSS are required not to add any constructors to this class, private, public, or protected. This will ensure that all subclasses invoke only the default constructor provided to the base class by the compiler.
GSSのプラットホームプロバイダーは、この私設の、そして、公立のクラスにどんな建設者も追加しないのが必要である、または保護されます。 これは、すべてのサブクラスがコンパイラによって基底クラスに提供されたデフォルト建設者だけを呼び出すのを確実にするでしょう。
A subclass extending the GSSManager abstract class may be implemented as a modular provider based layer that utilizes some well known service provider specification. The GSSManager API provides the application with methods to set provider preferences on such an implementation. These methods also allow the implementation to throw a well-defined exception in case provider based configuration is not supported. Applications that expect to be portable should be aware of this and recover cleanly by catching the exception.
モジュールのプロバイダーが何らかのよく知られているサービスプロバイダー仕様を利用する層を基礎づけたので、GSSManager抽象クラスを広げるサブクラスは実装されるかもしれません。 GSSManager APIはそのような実装におけるプロバイダー好みを設定するメソッドをアプリケーションに提供します。 また、これらのメソッドで、実装はベースの構成がサポートされないケースプロバイダーにおける明確な例外を投げることができます。 携帯用であると予想するアプリケーションは、例外を捕らえることによって、清潔にこれを意識していて、回復するべきです。
Kabat & Upadhyay Standards Track [Page 31] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[31ページ]。
It is envisioned that there will be three most common ways in which providers will be used:
思い描かれて、プロバイダーが使用されるそれが3つの最も一般的な方法がいるということです:
1) The application does not care about what provider is used (the
default case).
1) アプリケーションはどんなプロバイダーが使用されているか(不履行格)気にかけません。
2) The application wants a particular provider to be used
preferentially, either for a particular mechanism or all the
time, irrespective of mechanism.
2) アプリケーションは優先的に特定のプロバイダーを使用するのを必要があります、特定のメカニズムか時間中に、メカニズムの如何にかかわらず。
3) The application wants to use the locally configured providers
as far as possible but if support is missing for one or more
mechanisms then it wants to fall back on its own provider.
3) アプリケーションは局所的に構成されたプロバイダーをできるだけ使用したがっていますが、1つ以上のメカニズムにおいて、サポートがなくなるなら、それはそれ自身のプロバイダーに後ろへ下がりたがっています。
The GSSManager class has two methods that enable these modes of usage: addProviderAtFront() and addProviderAtEnd(). These methods have the effect of creating an ordered list of <provider, oid> pairs where each pair indicates a preference of provider for a given oid.
GSSManagerのクラスには、用法のこれらのモードを可能にする2つのメソッドがあります: addProviderAtFront()とaddProviderAtEnd()。 これらのメソッドには、<プロバイダー(各組が与えられたoidのためにプロバイダーの優先を示すoid>組)の規則正しいリストを作成するという効果があります。
The use of these methods does not require any knowledge of whatever service provider specification the GSSManager subclass follows. It is hoped that these methods will serve the needs of most applications. Additional methods may be added to an extended GSSManager that could be part of a service provider specification that is standardized later.
これらのメソッドの使用はGSSManagerサブクラスが従うどんなサービスプロバイダー仕様に関する少しの知識も必要としません。 これらのメソッドがほとんどのアプリケーションの必要性に役立つことが望まれています。 追加メソッドは後で標準化されるサービスプロバイダー仕様の一部であるかもしれない拡張GSSManagerに加えられるかもしれません。
6.1.1. Example Code
6.1.1. 例のコード
GSSManager mgr = GSSManager.getInstance();
GSSManager mgrはGSSManager.getInstance()と等しいです。
// What mechs are available to us? Oid[] supportedMechs = mgr.getMechs();
//、私たちにとって、mechsされることは利用可能ですか? Oid[] supportedMechsはmgr.getMechs()と等しいです。
// Set a preference for the provider to be used when support is needed // for the mechanisms "1.2.840.113554.1.2.2" and "1.3.6.1.5.5.1.1".
そして、サポートがメカニズムのための必要な//であるときにプロバイダーが使用される//セットa好み、「1.2、.840、.113554、.1、.2、0.2インチ、「1.3 .6 .1 .5 .5 .1 0.1インチ、」
Oid krb = new Oid("1.2.840.113554.1.2.2");
Oid spkm1 = new Oid("1.3.6.1.5.5.1.1");
Oid krbが新しいOidと等しい、(「1.2 .840 .113554 .1 .2 0.2インチ)、」、。 Oid spkm1が新しいOidと等しい、(「1.3 .6 .1 .5 .5 .1 0.1インチ)、」、。
Provider p = (Provider) (new com.foo.security.Provider());
プロバイダーpが等しい、(プロバイダー) (新しいcom.foo.security.Provider())。
mgr.addProviderAtFront(p, krb); mgr.addProviderAtFront(p, spkm1);
mgr.addProviderAtFront(p、krb)。 mgr.addProviderAtFront(p、spkm1)。
// What name types does this spkm implementation support? Oid[] nameTypes = mgr.getNamesForMech(spkm1);
//はこのspkm実装サポートをしますか?どんな名前が、タイプする Oid[] nameTypesはmgr.getNamesForMech(spkm1)と等しいです。
Kabat & Upadhyay Standards Track [Page 32] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[32ページ]。
6.1.2. getInstance
6.1.2. getInstance
public static GSSManager getInstance()
公共の静的なGSSManager getInstance()
Returns the default GSSManager implementation.
デフォルトGSSManager実装を返します。
6.1.3. getMechs
6.1.3. getMechs
public abstract Oid[] getMechs()
公共の抽象的なOid[] getMechs()
Returns an array of Oid objects indicating mechanisms available to GSS-API callers. A "null" value is returned when no mechanism are available (an example of this would be when mechanism are dynamically configured, and currently no mechanisms are installed).
GSS-API訪問者にとって、利用可能なメカニズムを示すOidオブジェクトの配列を返します。 どんなメカニズムも利用可能でないときに(この例はメカニズムがダイナミックに構成されて、現在のメカニズムが全くインストールされない時でしょう)、「ヌル」の値を返します。
6.1.4. getNamesForMech
6.1.4. getNamesForMech
public abstract Oid[] getNamesForMech(Oid mech)
throws GSSException
公共の抽象的なOid[] getNamesForMech(Oid mech)はGSSExceptionを投げます。
Returns name type Oid's supported by the specified mechanism.
リターンはOidが指定されたメカニズムでサポートしたタイプを命名します。
Parameters:
パラメタ:
mech The Oid object for the mechanism to query.
Oidが質問するメカニズムのために反対させるmech。
6.1.5. getMechsForName
6.1.5. getMechsForName
public abstract Oid[] getMechsForName(Oid nameType)
公共の抽象的なOid[] getMechsForName(Oid nameType)
Returns an array of Oid objects corresponding to the mechanisms that support the specific name type. "null" is returned when no mechanisms are found to support the specified name type.
タイプという特定の名前をサポートするメカニズムに対応するOidオブジェクトの配列を返します。 メカニズムが全くタイプという指定された名前をサポートするのがわかっていないとき、「ヌル」を返します。
Parameters:
パラメタ:
nameType The Oid object for the name type.
nameType Oidはタイプという名前のために反対します。
6.1.6. createName
6.1.6. createName
public abstract GSSName createName(String nameStr, Oid nameType)
throws GSSException
公共の抽象的なGSSName createName(ストリングnameStr、Oid nameType)はGSSExceptionを投げます。
Factory method to convert a contiguous string name from the specified namespace to a GSSName object. In general, the GSSName object created will not be an MN; two examples that are exceptions to this are when the namespace type parameter indicates NT_EXPORT_NAME or when the GSS-API implementation is not multi-mechanism.
指定された名前空間からGSSNameオブジェクトまで隣接のストリング名を変換する工場のメソッド。 一般に、作成されたGSSNameオブジェクトはミネソタにならないでしょう。 これへの例外である2つの例は名前空間型引数がいつNT_EXPORT_NAMEを示すか、そして、またはいつGSS-API実行がマルチメカニズムでないということであるか。
Kabat & Upadhyay Standards Track [Page 33] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[33ページ]。
Parameters:
パラメタ:
nameStr The string representing a printable form of the name
to create.
a印刷可能なストリングの表すのが形成する作成する名前のnameStr。
nameType The Oid specifying the namespace of the printable name
supplied. Note that nameType serves to describe and
qualify the interpretation of the input nameStr, it
does not necessarily imply a type for the output
GSSName implementation. "null" value can be used to
specify that a mechanism specific default printable
syntax should be assumed by each mechanism that
examines nameStr.
供給という印刷可能な名前の名前空間を指定するnameType Oid。 nameTypeが入力nameStrの解釈を説明して、資格を与えるのに役立つというメモ、それは出力GSSName実装のために必ずタイプを含意するというわけではありません。 印刷可能な構文がそうするべきであるメカニズムの特定のデフォルトがnameStrを調べる各メカニズムによって想定されると指定するのに「ヌル」の値を使用できます。
6.1.7. createName
6.1.7. createName
public abstract GSSName createName(byte name[], Oid nameType)
throws GSSException
公共の抽象的なGSSName createName(バイト名[]、Oid nameType)はGSSExceptionを投げます。
Factory method to convert a contiguous byte array containing a name from the specified namespace to a GSSName object. In general, the GSSName object created will not be an MN; two examples that are exceptions to this are when the namespace type parameter indicates NT_EXPORT_NAME or when the GSS-API implementation is not multi- mechanism.
指定された名前空間からGSSNameオブジェクトまで名前を含む隣接のバイト配列を変換する工場のメソッド。 一般に、作成されたGSSNameオブジェクトはミネソタにならないでしょう。 これへの例外である2つの例は名前空間型引数がいつNT_EXPORT_NAMEを示すか、そして、またはいつGSS-API実行がマルチメカニズムでないということであるか。
Parameters:
パラメタ:
name The byte array containing the name to create.
作成する名前を含むとバイト配列を命名してください。
nameType The Oid specifying the namespace of the name supplied
in the byte array. Note that nameType serves to
describe and qualify the interpretation of the input
name byte array, it does not necessarily imply a type
for the output GSSName implementation. "null" value
can be used to specify that a mechanism specific
default syntax should be assumed by each mechanism
that examines the byte array.
バイト配列で提供された名前の名前空間を指定するnameType Oid。 nameTypeが入力名前バイト配列の解釈を説明して、資格を与えるのに役立つというメモ、それは出力GSSName実装のために必ずタイプを含意するというわけではありません。 メカニズムの特定のデフォルト構文がバイト配列を調べる各メカニズムによって想定されるはずであると指定するのに「ヌル」の値を使用できます。
Kabat & Upadhyay Standards Track [Page 34] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[34ページ]。
6.1.8. createName
6.1.8. createName
public abstract GSSName createName(String nameStr, Oid nameType,
Oid mech) throws GSSException
公共の抽象的なGSSName createName(ストリングnameStr、Oid nameType、Oid mech)はGSSExceptionを投げます。
Factory method to convert a contiguous string name from the specified namespace to an GSSName object that is a mechanism name (MN). In other words, this method is a utility that does the equivalent of two steps: the createName described in 6.1.7 and then also the GSSName.canonicalize() described in 6.2.5.
指定された名前空間からメカニズム名(ミネソタ)であるGSSNameオブジェクトまで隣接のストリング名を変換する工場のメソッド。 言い換えれば、このメソッドは以下の2ステップの同等物をするユーティリティです: .7と次に、GSSName.canonicalize()も6.2で.5に説明した6.1で説明されたcreateName
Parameters:
パラメタ:
nameStr The string representing a printable form of the name
to create.
a印刷可能なストリングの表すのが形成する作成する名前のnameStr。
nameType The Oid specifying the namespace of the printable name
supplied. Note that nameType serves to describe and
qualify the interpretation of the input nameStr, it
does not necessarily imply a type for the output
GSSName implementation. "null" value can be used to
specify that a mechanism specific default printable
syntax should be assumed when the mechanism examines
nameStr.
供給という印刷可能な名前の名前空間を指定するnameType Oid。 nameTypeが入力nameStrの解釈を説明して、資格を与えるのに役立つというメモ、それは出力GSSName実装のために必ずタイプを含意するというわけではありません。 メカニズムがnameStrを調べると印刷可能な構文がそうするべきであるメカニズムの特定のデフォルトが想定されると指定するのに「ヌル」の値を使用できます。
mech Oid specifying the mechanism for which this name
should be created.
この名前が作成されるべきであるメカニズムを指定するmech Oid。
6.1.9. createName
6.1.9. createName
public abstract createName(byte name[], Oid nameType, Oid mech)
throws GSSException
公共の抽象的なcreateName(バイト名[]、Oid nameType、Oid mech)はGSSExceptionを投げます。
Factory method to convert a contiguous byte array containing a name from the specified namespace to a GSSName object that is an MN. In other words, this method is a utility that does the equivalent of two steps: the createName described in 6.1.8 and then also the GSSName.canonicalize() described in 6.2.5.
指定された名前空間からミネソタであるGSSNameオブジェクトまで名前を含む隣接のバイト配列を変換する工場のメソッド。 言い換えれば、このメソッドは以下の2ステップの同等物をするユーティリティです: .8と次に、GSSName.canonicalize()も6.2で.5に説明した6.1で説明されたcreateName
Parameters:
パラメタ:
name The byte array representing the name to create.
作成する名前を表すとバイト配列を命名してください。
nameType The Oid specifying the namespace of the name supplied
in the byte array. Note that nameType serves to
describe and qualify the interpretation of the input
name byte array, it does not necessarily imply a type
for the output GSSName implementation. "null" value
バイト配列で提供された名前の名前空間を指定するnameType Oid。 nameTypeが入力名前バイト配列の解釈を説明して、資格を与えるのに役立つというメモ、それは出力GSSName実装のために必ずタイプを含意するというわけではありません。 「ヌル」の値
Kabat & Upadhyay Standards Track [Page 35] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[35ページ]。
can be used to specify that a mechanism specific
default syntax should be assumed by each mechanism
that examines the byte array.
メカニズムの特定のデフォルト構文がバイト配列を調べる各メカニズムによって想定されるはずであると指定するのに使用できます。
mech Oid specifying the mechanism for which this name
should be created.
この名前が作成されるべきであるメカニズムを指定するmech Oid。
6.1.10. createCredential
6.1.10. createCredential
public abstract GSSCredential createCredential (int usage)
throws GSSException
公共の抽象的なGSSCredential createCredential(int用法)はGSSExceptionを投げます。
Factory method for acquiring default credentials. This will cause the GSS-API to use system specific defaults for the set of mechanisms, name, and a DEFAULT lifetime.
デフォルト資格証明書を取得するための工場のメソッド。 これで、GSS-APIはメカニズム、名前、およびDEFAULT生涯のセットにシステムの特定のデフォルトを使用するでしょう。
Parameters:
パラメタ:
usage The intended usage for this credential object. The
value of this parameter must be one of:
GSSCredential.ACCEPT_AND_INITIATE,
GSSCredential.ACCEPT_ONLY, GSSCredential.INITIATE_ONLY
用法、この資格証明オブジェクトのための意図している用法。 このパラメタの値が1でなければならない、: GSSCredential.ACCEPT_AND_開始、GSSCredential.ACCEPT_だけ、GSSCredential.INITIATEだけ
6.1.11. createCredential
6.1.11. createCredential
public abstract GSSCredential createCredential (GSSName aName,
int lifetime, Oid mech, int usage)
throws GSSException
公共の抽象的なGSSCredential createCredential(GSSName aName、int生涯、Oid mech、int用法)はGSSExceptionを投げます。
Factory method for acquiring a single mechanism credential.
ただ一つのメカニズム資格証明書を取得するための工場のメソッド。
Parameters:
パラメタ:
aName Name of the principal for whom this credential is to
be acquired. Use "null" to specify the default
principal.
後天的であるこの資格証明書がことである主体のaName Name。 「ヌル」を使用して、デフォルト主体を指定してください。
lifetime The number of seconds that credentials should remain
valid. Use GSSCredential.INDEFINITE_LIFETIME to
request that the credentials have the maximum
permitted lifetime. Use
GSSCredential.DEFAULT_LIFETIME to request default
credential lifetime.
生涯、資格証明書が有効なままで残るべきである秒の数。 GSSCredential.INDEFINITE_LIFETIMEを使用して、資格証明書には最大の受入れられた寿命があるよう要求してください。 GSSCredential.DEFAULT_LIFETIMEを使用して、デフォルト資格証明の生涯を要求してください。
mech The oid of the desired mechanism. Use "(Oid) null" to
request the default mechanism(s).
mech、必要なメカニズムのoid。 「(Oid)ヌル」を使用して、デフォルトメカニズムを要求してください。
Kabat & Upadhyay Standards Track [Page 36] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[36ページ]。
usage The intended usage for this credential object. The
value of this parameter must be one of:
GSSCredential.ACCEPT_AND_INITIATE,
GSSCredential.ACCEPT_ONLY, GSSCredential.INITIATE_ONLY
用法、この資格証明オブジェクトのための意図している用法。 このパラメタの値が1でなければならない、: GSSCredential.ACCEPT_AND_開始、GSSCredential.ACCEPT_だけ、GSSCredential.INITIATEだけ
6.1.12. createCredential
6.1.12. createCredential
public abstract GSSCredential createCredential(GSSName aName,
int lifetime, Oid mechs[], int usage)
throws GSSException
公共の抽象的なGSSCredential createCredential(GSSName aName、int生涯、Oid mechs[]、int用法)はGSSExceptionを投げます。
Factory method for acquiring credentials over a set of mechanisms. Acquires credentials for each of the mechanisms specified in the array called mechs. To determine the list of mechanisms' for which the acquisition of credentials succeeded, the caller should use the GSSCredential.getMechs() method.
取得資格証明書のための工場のメソッドはaの上にメカニズムをセットしました。. mechsと呼ばれる配列で指定されたそれぞれのメカニズムのために資格証明書を取得します。 資格証明書の獲得が成功したメカニズムのリストを決定するために、訪問者はGSSCredential.getMechs()メソッドを使用するべきです。
Parameters:
パラメタ:
aName Name of the principal for whom this credential is to
be acquired. Use "null" to specify the default
principal.
後天的であるこの資格証明書がことである主体のaName Name。 「ヌル」を使用して、デフォルト主体を指定してください。
lifetime The number of seconds that credentials should remain
valid. Use GSSCredential.INDEFINITE_LIFETIME to
request that the credentials have the maximum
permitted lifetime. Use
GSSCredential.DEFAULT_LIFETIME to request default
credential lifetime.
生涯、資格証明書が有効なままで残るべきである秒の数。 GSSCredential.INDEFINITE_LIFETIMEを使用して、資格証明書には最大の受入れられた寿命があるよう要求してください。 GSSCredential.DEFAULT_LIFETIMEを使用して、デフォルト資格証明の生涯を要求してください。
mechs The array of mechanisms over which the credential is
to be acquired. Use "(Oid[]) null" for requesting a
system specific default set of mechanisms.
後天的である資格証明書がことであるメカニズムの配列をmechsします。 使用、「(Oid[])ヌル、」 システムの特定のデフォルトセットのメカニズムを要求するために。
usage The intended usage for this credential object. The
value of this parameter must be one of:
GSSCredential.ACCEPT_AND_INITIATE,
GSSCredential.ACCEPT_ONLY, GSSCredential.INITIATE_ONLY
用法、この資格証明オブジェクトのための意図している用法。 このパラメタの値が1でなければならない、: GSSCredential.ACCEPT_AND_開始、GSSCredential.ACCEPT_だけ、GSSCredential.INITIATEだけ
6.1.13. createContext
6.1.13. createContext
public abstract GSSContext createContext(GSSName peer, Oid mech,
GSSCredential myCred, int lifetime)
throws GSSException
公共の抽象的なGSSContext createContext(GSSName同輩、Oid mech、GSSCredential myCred、int生涯)はGSSExceptionを投げます。
Factory method for creating a context on the initiator's side. Context flags may be modified through the mutator methods prior to calling GSSContext.initSecContext().
創始者の側で文脈を作成するための工場のメソッド。 文脈旗はGSSContext.initSecContext()と呼ぶ前に、mutatorメソッドで変更されるかもしれません。
Kabat & Upadhyay Standards Track [Page 37] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[37ページ]。
Parameters:
パラメタ:
peer Name of the target peer.
目標同輩の同輩Name。
mech Oid of the desired mechanism. Use "(Oid) null" to
request default mechanism.
必要なメカニズムのmech Oid。 「(Oid)ヌル」を使用して、デフォルトメカニズムを要求してください。
myCred Credentials of the initiator. Use "null" to act as a
default initiator principal.
創始者のmyCred Credentials。 デフォルト創始者元本として務めるのに「ヌル」を使用してください。
lifetime The request lifetime, in seconds, for the context.
Use GSSContext.INDEFINITE_LIFETIME and
GSSContext.DEFAULT_LIFETIME to request indefinite or
default context lifetime.
生涯、秒に文脈のために生涯を要求してください。 GSSContext.INDEFINITE_LIFETIMEとGSSContext.DEFAULT_LIFETIMEを使用して、無期かデフォルト文脈生涯を要求してください。
6.1.14. createContext
6.1.14. createContext
public abstract GSSContext createContext(GSSCredential myCred)
throws GSSException
公共の抽象的なGSSContext createContext(GSSCredential myCred)はGSSExceptionを投げます。
Factory method for creating a context on the acceptor' side. The context's properties will be determined from the input token supplied to the accept method.
'文脈をアクセプタに作成するための工場のメソッド'側。 文脈の特性が供給された入力トークンから決定する、メソッドを受け入れてください。
Parameters:
パラメタ:
myCred Credentials for the acceptor. Use "null" to act as a
default acceptor principal.
アクセプタのためのmyCred Credentials。 デフォルトアクセプタ元本として務めるのに「ヌル」を使用してください。
6.1.15. createContext
6.1.15. createContext
public abstract GSSContext createContext(byte [] interProcessToken)
throws GSSException
公共の抽象的なGSSContext createContext(バイト[]interProcessToken)はGSSExceptionを投げます。
Factory method for creating a previously exported context. The context properties will be determined from the input token and can't be modified through the set methods.
以前にエクスポートしている文脈を作成するための工場のメソッド。 文脈の特性は、入力トークンから断固として、セットメソッドで変更できません。
Parameters:
パラメタ:
interProcessToken
The token previously emitted from the export method.
interProcessToken、以前に輸出メソッドから放たれたトークン。
6.1.16. addProviderAtFront
6.1.16. addProviderAtFront
public abstract void addProviderAtFront(Provider p, Oid mech)
throws GSSException
公共の抽象的な空のaddProviderAtFront(プロバイダーp、Oid mech)はGSSExceptionを投げます。
Kabat & Upadhyay Standards Track [Page 38] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[38ページ]。
This method is used to indicate to the GSSManager that the application would like a particular provider to be used ahead of all others when support is desired for the given mechanism. When a value of null is used instead of an Oid for the mechanism, the GSSManager must use the indicated provider ahead of all others no matter what the mechanism is. Only when the indicated provider does not support the needed mechanism should the GSSManager move on to a different provider.
このメソッドは、サポートが与えられたメカニズムのために望まれているとき、特定のプロバイダーをすべての他のものの前でアプリケーションが使用されたがっているのをGSSManagerに示すのに使用されます。 ヌルの値がメカニズムのためのOidの代わりに使用されるとき、GSSManagerはメカニズムが何であってもすべての他のものの前で示されたプロバイダーを使用しなければなりません。 示されたプロバイダーが必要なメカニズムをサポートしない場合にだけ、GSSManagerは異なったプロバイダーに移行するはずです。
Calling this method repeatedly preserves the older settings but lowers them in preference thus forming an ordered list of provider and Oid pairs that grows at the top.
呼んで、このメソッドは、繰り返して、より古い設定を保存しますが、その結果プロバイダーの規則正しいリストを形成する好みと先端で成長するOid組でそれらを下ろします。
Calling addProviderAtFront with a null Oid will remove all previous preferences that were set for this provider in the GSSManager instance. Calling addProviderAtFront with a non-null Oid will remove any previous preference that was set using this mechanism and this provider together.
ヌルOidと共にaddProviderAtFrontと呼ぶのがGSSManagerインスタンスにおけるこのプロバイダーに設定された前のすべての好みを取り除くでしょう。 非ヌルがあるaddProviderAtFrontをOidと呼ぶと、このメカニズムとこのプロバイダーを一緒に使用するように設定されたどんな前の好みも取り除かれるでしょう。
If the GSSManager implementation does not support an SPI with a pluggable provider architecture it should throw a GSSException with the status code GSSException.UNAVAILABLE to indicate that the operation is unavailable.
GSSManager実装がpluggableプロバイダーアーキテクチャでSPIをサポートしないなら、それは、操作が入手できないのを示すためにステータスコードGSSException.UNAVAILABLEと共にGSSExceptionを投げるべきです。
Parameters:
パラメタ:
p The provider instance that should be used whenever
support is needed for mech.
p、サポートがmechに必要であるときはいつも、使用されるべきであるプロバイダーインスタンス。
mech The mechanism for which the provider is being set
mechはプロバイダーが設定されているメカニズムです。
6.1.16.1. Example Code
6.1.16.1. 例のコード
Suppose an application desired that the provider A always be checked first when any mechanism is needed, it would call:
アプリケーションが、どんなメカニズムも必要であるときに、プロバイダーAが最初にいつもチェックされることを望んでいるなら、呼ぶでしょうに:
GSSManager mgr = GSSManager.getInstance();
// mgr may at this point have its own pre-configured list
// of provider preferences. The following will prepend to
// any such list:
GSSManager mgrはGSSManager.getInstance()と等しいです。 mgrがここにそれ自身にするかもしれない//はプロバイダー好みのリスト//をあらかじめ設定しました。 以下はどんなそのようなリストも//にprependするでしょう:
mgr.addProviderAtFront(A, null);
mgr.addProviderAtFront(A、ヌル)。
Now if it also desired that the mechanism of Oid m1 always be obtained from the provider B before the previously set A was checked, it would call:
また、Oid m1のメカニズムが以前に設定されている前にプロバイダーBからいつも入手されることを望んでいたなら現在Aがチェックされたと呼ぶでしょう:
mgr.addProviderAtFront(B, m1);
mgr.addProviderAtFront(B、m1)。
Kabat & Upadhyay Standards Track [Page 39] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[39ページ]。
The GSSManager would then first check with B if m1 was needed. In case B did not provide support for m1, the GSSManager would continue on to check with A. If any mechanism m2 is needed where m2 is different from m1 then the GSSManager would skip B and check with A directly.
GSSManagerが必要であるだろう、次に、Bとの最初のチェックがm1であるなら必要でした。 m1、GSSManagerはA.Ifと共にどんなメカニズムm2もチェックに続けているでしょう、Bが提供されないで、したがって、サポートがm2がm1と異なっているところで必要であり、次に、GSSManagerはBをスキップして、直接Aに問い合わせるでしょう。
Suppose at a later time the following call is made to the same GSSManager instance:
後で、同じGSSManagerインスタンスに以下の電話をかけると仮定してください:
mgr.addProviderAtFront(B, null)
mgr.addProviderAtFront(B、ヌル)
then the previous setting with the pair (B, m1) is subsumed by this
and should be removed. Effectively the list of preferences now
becomes {(B, null), (A, null),
... //followed by the pre-configured list.
次に、組(B、m1)がある前回の設定をこれで包括して、取り除くべきです。 現在事実上、好みのリストがなる、(B、ヌル)、(A、ヌル)… //はあらかじめ設定されたリストで続きました。
Please note, however, that the following call:
しかしながら、以下は呼びます:
mgr.addProviderAtFront(A, m3)
mgr.addProviderAtFront(A、m3)
does not subsume the previous setting of (A, null) and the list will
effectively become {(A, m3), (B, null), (A, null), ...}
有効に(A、ヌル)の前回の設定とリスト意志を包括しない、なる。(A、m3)、(B、ヌル)、(A、ヌル)…
6.1.17. addProviderAtEnd
6.1.17. addProviderAtEnd
public abstract addProviderAtEnd(Provider p, Oid mech)
throws GSSException
公共の抽象的なaddProviderAtEnd(プロバイダーp、Oid mech)はGSSExceptionを投げます。
This method is used to indicate to the GSSManager that the application would like a particular provider to be used if no other provider can be found that supports the given mechanism. When a value of null is used instead of an Oid for the mechanism, the GSSManager must use the indicated provider for any mechanism.
このメソッドは、与えられたメカニズムをサポートする他のプロバイダーを全く見つけることができないなら特定のプロバイダーをアプリケーションが使用されたがっているのをGSSManagerに示すのに使用されます。 ヌルの値がメカニズムのためのOidの代わりに使用されるとき、GSSManagerはどんなメカニズムにも示されたプロバイダーを使用しなければなりません。
Calling this method repeatedly preserves the older settings but raises them above newer ones in preference thus forming an ordered list of providers and Oid pairs that grows at the bottom. Thus the older provider settings will be utilized first before this one is.
呼んで、このメソッドは、その結果、下部で成長するプロバイダーとOid組の規則正しいリストを形成しながら、繰り返して、より古い設定を保存しますが、好みにおける、より新しいものを超えてそれらを上げます。 したがって、これが最初に、利用される前により古いプロバイダー設定は利用されるでしょう。
If there are any previously existing preferences that conflict with the preference being set here, then the GSSManager should ignore this request.
何かここに設定される好みと闘争する以前に既存の好みがあれば、GSSManagerはこの要求を無視するはずです。
If the GSSManager implementation does not support an SPI with a pluggable provider architecture it should throw a GSSException with the status code GSSException.UNAVAILABLE to indicate that the operation is unavailable.
GSSManager実装がpluggableプロバイダーアーキテクチャでSPIをサポートしないなら、それは、操作が入手できないのを示すためにステータスコードGSSException.UNAVAILABLEと共にGSSExceptionを投げるべきです。
Kabat & Upadhyay Standards Track [Page 40] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[40ページ]。
Parameters:
パラメタ:
p The provider instance that should be used whenever
support is needed for mech.
p、サポートがmechに必要であるときはいつも、使用されるべきであるプロバイダーインスタンス。
mech The mechanism for which the provider is being set
mechはプロバイダーが設定されているメカニズムです。
6.1.17.1. Example Code
6.1.17.1. 例のコード
Suppose an application desired that when a mechanism of Oid m1 is needed the system default providers always be checked first, and only when they do not support m1 should a provider A be checked. It would then make the call:
アプリケーションが、Oid m1のメカニズムが必要であるときに、システムがデフォルトとすることを望んでいたと仮定してください、プロバイダー、最初にいつもチェックされてください、そして、m1をサポートしないときだけ、プロバイダーAはチェックされるべきです。 次に、それは電話をかけるでしょう:
GSSManager mgr = GSSManager.getInstance();
GSSManager mgrはGSSManager.getInstance()と等しいです。
mgr.addProviderAtEnd(A, m1);
mgr.addProviderAtEnd(A、m1)。
Now, if it also desired that for all mechanisms the provider B be checked after all configured providers have been checked, it would then call:
今度は、また、すべての構成されたプロバイダーをチェックしてある後にプロバイダーBがチェックされて、すべてのメカニズムのために、そうすることを望んでいたなら、電話をしてください:
mgr.addProviderAtEnd(B, null);
mgr.addProviderAtEnd(B、ヌル)。
Effectively the list of preferences now becomes {..., (A, m1), (B,
null)}.
事実上、現在、好みのリストは…、(A、m1)(B、ヌル)になります。
Suppose at a later time the following call is made to the same GSSManager instance:
後で、同じGSSManagerインスタンスに以下の電話をかけると仮定してください:
mgr.addProviderAtEnd(B, m2)
mgr.addProviderAtEnd(B、m2)
then the previous setting with the pair (B, null) subsumes this and therefore this request should be ignored. The same would happen if a request is made for the already existing pairs of (A, m1) or (B, null).
次に、組(B、ヌル)がある前回の設定はこれを包括します、そして、したがって、この要求は無視されるべきです。 既に既存の組の(A、m1)か(B、ヌル)のために要求をするなら、同じくらいは起こるでしょう。
Please note, however, that the following call:
しかしながら、以下は呼びます:
mgr.addProviderAtEnd(A, null)
mgr.addProviderAtEnd(A、ヌル)
is not subsumed by the previous setting of (A, m1) and the list will
effectively become {..., (A, m1), (B, null), (A, null)}
(A、m1)の前回の設定とリスト意志によって有効に包括されていない、なる。…、(A、m1)(B、ヌル)、(A、ヌル)
Kabat & Upadhyay Standards Track [Page 41] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[41ページ]。
6.2. public interface GSSName
6.2. 公共のインタフェースGSSName
This interface encapsulates a single GSS-API principal entity. Different name formats and their definitions are identified with universal Object Identifiers (Oids). The format of the names can be derived based on the unique oid of its namespace type.
このインタフェースはただ一つのGSS-API主要な実体をカプセル化します。 異なった名前形式と彼らの定義は普遍的なObject Identifiers(Oids)と同一視されています。 名前空間タイプのユニークなoidに基づいて名前の形式を引き出すことができます。
6.2.1. Example Code
6.2.1. 例のコード
Included below are code examples utilizing the GSSName interface. The code below creates a GSSName, converts it to a mechanism name (MN), performs a comparison, obtains a printable representation of the name, exports it and then re-imports to obtain a new GSSName.
以下に含まれているのは、GSSNameインタフェースを利用するコードの例です。 以下のコードは、新しいGSSNameを入手するためにGSSNameを作成して、メカニズム名(ミネソタ)にそれを変換して、比較を実行して、名前の印刷可能な表現を得て、それをエクスポートして、次に、逆輸入をエクスポートします。
GSSManager mgr = GSSManager.getInstance();
GSSManager mgrはGSSManager.getInstance()と等しいです。
// create a host based service name
GSSName name = mgr.createName("service@host",
GSSName.NT_HOSTBASED_SERVICE);
//はベースのホストサービス名前GSSName名前=mgr.createName(" service@host "、GSSName.NT_HOSTBASED_サービス)を作成します。
Oid krb5 = new Oid("1.2.840.113554.1.2.2");
Oid krb5が新しいOidと等しい、(「1.2 .840 .113554 .1 .2 0.2インチ)、」、。
GSSName mechName = name.canonicalize(krb5);
GSSName mechNameはname.canonicalize(krb5)と等しいです。
// the above two steps are equivalent to the following
GSSName mechName = mgr.createName("service@host",
GSSName.NT_HOSTBASED_SERVICE, krb5);
上の2が踏む//は以下のGSSName mechName=mgr.createName(" service@host "、GSSName.NT_HOSTBASED_サービス、krb5)に同等です。
// perform name comparison
if (name.equals(mechName))
print("Names are equals.");
(name.equals(mechName))が印刷するなら(「名前は同輩です」。)、//は名前比較を実行します。
// obtain textual representation of name and its printable
// name type
print(mechName.toString() +
mechName.getStringNameType().toString());
//が名前の原文の表現を得て、印刷可能な//名義のタイプが印刷する、(mechName.toString()+mechName.getStringNameType().toString())。
// export and re-import the name byte [] exportName = mechName.export();
//輸出と逆輸入バイト[]exportNameという名前=mechName.export()。
// create a new name object from the exported buffer
GSSName newName = mgr.createName(exportName,
GSSName.NT_EXPORT_NAME);
//はエクスポートしているバッファGSSName newName=mgr.createName(exportName、GSSName.NT_EXPORT_NAME)から新しい名前オブジェクトを作成します。
Kabat & Upadhyay Standards Track [Page 42] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[42ページ]。
6.2.2. Static Constants
6.2.2. 静的な定数
public static final Oid NT_HOSTBASED_SERVICE
公共の静的な最終的な_Oid NT_HOSTBASED SERVICE
Oid indicating a host-based service name form. It is used to represent services associated with host computers. This name form is constructed using two elements, "service" and "hostname", as follows:
ホストベースのサービス名を示すOidが形成します。 それは、ホストコンピュータに関連しているサービスを表すのに使用されます。 この名前フォームは以下の通り2つの要素、「サービス」、および「ホスト名」を使用することで構成されます:
service@hostname
service@hostname
Values for the "service" element are registered with the IANA. It
represents the following value: { 1(iso), 3(org), 6(dod),
1(internet), 5(security), 6(nametypes), 2(gss-host-based-services) }
「サービス」要素のための値はIANAに示されます。 それは以下の値を表します: 1(iso)、3(org)、6(dod)、1(インターネット)、5(セキュリティ)、6(nametypes)、2(gssのホストベースのサービス)
public static final Oid NT_USER_NAME
公共の静的な最終的な_Oid NT_USER NAME
Name type to indicate a named user on a local system. It represents
the following value: { iso(1) member-body(2) United States(840)
mit(113554) infosys(1) gssapi(2) generic(1) user_name(1) }
タイプを命名して、ローカルシステムで命名されたユーザを示してください。 それは以下の値を表します: iso(1)メンバーボディー(2)合衆国(840)mit(113554) infosys(1) gssapi(2)ジェネリック(1)ユーザ_は(1)を命名します。
public static final Oid NT_MACHINE_UID_NAME
公共の静的な最終的な_Oid NT_MACHINE UID_NAME
Name type to indicate a numeric user identifier corresponding to a
user on a local system. (e.g. Uid). It represents the following
value: { iso(1) member-body(2) United States(840) mit(113554)
infosys(1) gssapi(2) generic(1) machine_uid_name(2) }
タイプを命名して、ユーザにとって、ローカルシステムで対応する数値ユーザ識別子を示してください。 (例えば、Uid。) それは以下の値を表します: iso(1)メンバーボディー(2)合衆国(840)mit(113554) infosys(1) gssapi(2)ジェネリック(1)マシン_uid_は(2)を命名します。
public static final Oid NT_STRING_UID_NAME
公共の静的な最終的な_Oid NT_STRING UID_NAME
Name type to indicate a string of digits representing the numeric
user identifier of a user on a local system. It represents the
following value: { iso(1) member-body(2) United States(840)
mit(113554) infosys(1) gssapi(2) generic(1) string_uid_name(3) }
タイプを命名して、ローカルシステムにユーザの数値ユーザ識別子を表す一連のケタを示してください。 それは以下の値を表します: iso(1)メンバーボディー(2)合衆国(840)mit(113554) infosys(1) gssapi(2)ジェネリック(1)ストリング_uid_は(3)を命名します。
public static final Oid NT_ANONYMOUS
公立の静的な最終的なOid NT_更生会
Name type for representing an anonymous entity. It represents the
following value: { 1(iso), 3(org), 6(dod), 1(internet), 5(security),
6(nametypes), 3(gss-anonymous-name) }
匿名の実体を表すためのタイプを命名してください。 それは以下の値を表します: 1(iso)、3(org)、6(dod)、1(インターネット)、5(セキュリティ)、6(nametypes)、3(gssの匿名の名)
public static final Oid NT_EXPORT_NAME
公共の静的な最終的な_Oid NT_EXPORT NAME
Name type used to indicate an exported name produced by the export
method. It represents the following value: { 1(iso), 3(org), 6(dod),
1(internet), 5(security), 6(nametypes), 4(gss-api-exported-name) }
名前タイプは、以前はよくエクスポートしている名前が輸出メソッドで作成されたのを示していました。 それは以下の値を表します: 1(iso)、3(org)、6(dod)、1(インターネット)、5(セキュリティ)、6(nametypes)、4(名前であるとエクスポートされたgss-api)
Kabat & Upadhyay Standards Track [Page 43] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[43ページ]。
6.2.3. equals
6.2.3. 同輩
public boolean equals(GSSName another) throws GSSException
公共の論理演算子同輩(GSSName別)はGSSExceptionを投げます。
Compares two GSSName objects to determine whether they refer to the same entity. This method may throw a GSSException when the names cannot be compared. If either of the names represents an anonymous entity, the method will return "false".
彼らが同じ実体について言及するかどうか決定するために2個のGSSNameオブジェクトを比較します。 名前が比べることができないとき、このメソッドはGSSExceptionを投げるかもしれません。 名前のどちらかが匿名の実体を表すと、メソッドは「虚偽で」戻るでしょう。
Parameters:
パラメタ:
another GSSName object to compare with.
比較する別のGSSNameオブジェクト。
6.2.4. equals
6.2.4. 同輩
public boolean equals(Object another)
公共の論理演算子同輩(別のオブジェクトもの)です。
A variation of the equals method described in 6.2.3 that is provided to override the Object.equals() method that the implementing class will inherit. The behavior is exactly the same as that in 6.2.3 except that no GSSException is thrown; instead, false will be returned in the situation where an error occurs. (Note that the Java language specification requires that two objects that are equal according to the equals(Object) method must return the same integer result when the hashCode() method is called on them.)
同輩メソッドの変化は6.2でそれが実装することのクラスが引き継ぐObject.equals()メソッドをくつがえすために提供される.3について説明しました。 振舞いはまさに.3が除く6.2におけるGSSExceptionが全く投げられないそれと同じです。 代わりに、そして、虚偽で、状況で誤りが発生するところに返すでしょう。 (ジャバ言語仕様が、hashCode()メソッドが彼らの上に呼ばれるとき、2個のメソッドが同じ整数に返さなければならない同輩(オブジェクト)によると、等しいオブジェクトが結果として生じるのを必要とすることに注意してください。)
Parameters:
パラメタ:
another GSSName object to compare with.
比較する別のGSSNameオブジェクト。
6.2.5. canonicalize
6.2.5.、canonicalize
public GSSName canonicalize(Oid mech) throws GSSException
公共のGSSName canonicalize(Oid mech)はGSSExceptionを投げます。
Creates a mechanism name (MN) from an arbitrary internal name. This is equivalent to using the factory methods described in 6.1.9 or 6.1.10 that take the mechanism name as one of their parameters.
任意の内部名からメカニズム名(ミネソタ)を作成します。 これはそれらのパラメタの1つとしてメカニズム名をみなす工場メソッド説明されたコネ6.1.9か6.1の.10を使用するのに同等です。
Parameters:
パラメタ:
mech The oid for the mechanism for which the canonical form
of the name is requested.
mech、名前の標準形が要求されているメカニズムのためのoid。
Kabat & Upadhyay Standards Track [Page 44] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[44ページ]。
6.2.6. export
6.2.6. 輸出
public byte[] export() throws GSSException
公共のバイト[]輸出()はGSSExceptionを投げます。
Returns a canonical contiguous byte representation of a mechanism name (MN), suitable for direct, byte by byte comparison by authorization functions. If the name is not an MN, implementations may throw a GSSException with the NAME_NOT_MN status code. If an implementation chooses not to throw an exception, it should use some system specific default mechanism to canonicalize the name and then export it. The format of the header of the output buffer is specified in RFC 2743.
承認によるバイト比較によるバイトがダイレクトに機能するので、適当なメカニズム名(ミネソタ)について正準な隣接のバイト表現を返します。 名前がミネソタでないなら、実装は_ミネソタステータスコードではなく、NAME_とGSSExceptionを投げるかもしれません。 実装が、例外を投げないのを選ぶなら、それは、名義の、そして、当時の輸出をcanonicalizeするのに何らかのシステムの特定のデフォルトメカニズムを使用するべきです。それ。 出力バッファのヘッダーの形式はRFC2743で指定されます。
6.2.7. toString
6.2.7. toString
public String toString()
公共のString toString()
Returns a textual representation of the GSSName object. To retrieve the printed name format, which determines the syntax of the returned string, the getStringNameType method can be used.
GSSNameオブジェクトの原文の表現を返します。 形式という印刷された名前を検索するのに、getStringNameTypeメソッドを使用できます。(名前は返されたストリングの構文を決定します)。
6.2.8. getStringNameType
6.2.8. getStringNameType
public Oid getStringNameType() throws GSSException
公共のOid getStringNameType()はGSSExceptionを投げます。
Returns the oid representing the type of name returned through the toString method. Using this oid, the syntax of the printable name can be determined.
toStringメソッドで返された名前のタイプの代理をするoidを返します。 このoidを使用して、印刷可能な名前の構文は決定できます。
6.2.9. isAnonymous
6.2.9. isAnonymous
public boolean isAnonymous()
公共の論理演算子isAnonymous()
Tests if this name object represents an anonymous entity. Returns "true" if this is an anonymous name.
この名前オブジェクトが匿名の実体を表すなら、テストします。 「本当に、」これが匿名の名前であるなら、戻ります。
6.2.10. isMN
6.2.10. isMN
public boolean isMN()
公共の論理演算子isMN()
Tests if this name object contains only one mechanism element and is thus a mechanism name as defined by RFC 2743.
この名前目的が1つのメカニズム要素だけを含んでいて、その結果、RFC2743によって定義されるようにメカニズム名であるなら、テストします。
6.3. public interface GSSCredential implements Cloneable
6.3. 公共のインタフェースGSSCredentialはCloneableを実装します。
This interface encapsulates the GSS-API credentials for an entity. A credential contains all the necessary cryptographic information to enable the creation of a context on behalf of the entity that it
このインタフェースは実体のためにGSS-API資格証明書をカプセル化します。 資格証明書が実体を代表して文脈の作成を可能にするすべての必要な暗号の情報を含んでいる、それ、それ
Kabat & Upadhyay Standards Track [Page 45] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[45ページ]。
represents. It may contain multiple, distinct, mechanism specific credential elements, each containing information for a specific security mechanism, but all referring to the same entity.
表します。 それは倍数を含むかもしれません、異なります、メカニズムの特定の資格証明要素、それぞれ特定のセキュリティー対策のための情報を含んでいますが、同じ実体についてすべて言及して。
A credential may be used to perform context initiation, acceptance, or both.
資格証明書は、文脈開始、承認、または両方を実行するのに使用されるかもしれません。
GSS-API implementations must impose a local access-control policy on callers to prevent unauthorized callers from acquiring credentials to which they are not entitled. GSS-API credential creation is not intended to provide a "login to the network" function, as such a function would involve the creation of new credentials rather than merely acquiring a handle to existing credentials. Such functions, if required, should be defined in implementation-specific extensions to the API.
GSS-API実行は、権限のない訪問者がそれらが権利を与えられない資格証明書を取得するのを防ぐためにローカルのアクセス制御方針を訪問者に課さなければなりません。 GSS-APIの資格証明作成が「ネットワークへのログイン」機能を提供することを意図しません、そのような機能が単に既存の資格証明書にハンドルを入手するよりむしろ新しい資格証明書の作成にかかわるだろうというとき。 必要なら、そのような機能は実装特有の拡大でAPIと定義されるべきです。
If credential acquisition is time-consuming for a mechanism, the mechanism may choose to delay the actual acquisition until the credential is required (e.g. by GSSContext). Such mechanism- specific implementation decisions should be invisible to the calling application; thus the query methods immediately following the creation of a credential object must return valid credential data, and may therefore incur the overhead of a deferred credential acquisition.
メカニズムにおいて、資格証明獲得が手間がかかっているなら、メカニズムは、資格証明書が必要になるまで(例えば、GSSContext)実際の獲得を遅らせるのを選ぶかもしれません。 そのようなメカニズムの特定の実装決定は呼ぶアプリケーションに目に見えないはずです。 したがって、すぐに資格証明オブジェクトの創案に続く質問メソッドは、有効な資格証明データを返さなければならなくて、したがって、延期された資格証明獲得のオーバーヘッドを被るかもしれません。
Applications will create a credential object passing the desired parameters. The application can then use the query methods to obtain specific information about the instantiated credential object (equivalent to the gss_inquire routines). When the credential is no longer needed, the application should call the dispose (equivalent to gss_release_cred) method to release any resources held by the credential object and to destroy any cryptographically sensitive information.
アプリケーションは必要なパラメタを通過する資格証明オブジェクトを作成するでしょう。 そして、アプリケーションは例示された資格証明オブジェクトに関する特殊情報を得る質問メソッドを使用できます(gss_と同等物はルーチンについて問い合わせます)。 資格証明書はもう必要でないときに、アプリケーションが呼ぶべきである、配列、(同等である、_リリース_信用) 資格証明オブジェクトで保持されたどんなリソースも発表するメソッドをgssして、破壊する、少しも暗号で、機密情報
Classes implementing this interface also implement the Cloneable interface. This indicates the the class will support the clone() method that will allow the creation of duplicate credentials. This is useful when called just before the add() call to retain a copy of the original credential.
また、このインタフェースを実装するクラスがCloneableインタフェースを実装します。 これは、クラスが、クローン()が写し資格証明書の作成を許容するメソッドであるとサポートするのを示します。 ちょうど以前呼ばれるとこれが役に立つ、() 電話をして、謄本資格証明書を保有するように言い足してください。
6.3.1. Example Code
6.3.1. 例のコード
This example code demonstrates the creation of a GSSCredential implementation for a specific entity, querying of its fields, and its release when it is no longer needed.
それはもう必要でないときに、この例のコードが特定の実体、分野の質問、およびそのリリースのためにGSSCredential実装の作成を示します。
Kabat & Upadhyay Standards Track [Page 46] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[46ページ]。
GSSManager mgr = GSSManager.getInstance();
GSSManager mgrはGSSManager.getInstance()と等しいです。
// start by creating a name object for the entity
GSSName name = mgr.createName("userName", GSSName.NT_USER_NAME);
実体GSSName名のために名前オブジェクトを作成するのによる//始めはmgr.createName(「ユーザ名」、GSSName.NT_USER_NAME)と等しいです。
// now acquire credentials for the entity
GSSCredential cred = mgr.createCredential(name,
GSSCredential.ACCEPT_ONLY);
//は現在、実体GSSCredential信用=mgr.createCredential(名前、GSSCredential.ACCEPTだけ)のために資格証明書を取得します。
// display credential information - name, remaining lifetime, // and the mechanisms it has been acquired over print(cred.getName().toString()); print(cred.getRemainingLifetime());
//ディスプレイ資格証明書情報--/を/と命名して、生涯残っていて、それが取得されたメカニズムを印刷と命名してください、(cred.getName().toString())。 印刷、(cred.getRemainingLifetime())。
Oid [] mechs = cred.getMechs();
if (mechs != null) {
for (int i = 0; i < mechs.length; i++)
print(mechs[i].toString());
}
Oid[]mechsはcred.getMechs()と等しいです。 (mechs=!ヌル)(int i=0; i<mechs.length; i++)に関しては印刷してください、(mechs[i].toString())。
// release system resources held by the credential cred.dispose();
//リリースシステム資源は資格証明cred.dispose()を固守しました。
6.3.2. Static Constants
6.3.2. 静的な定数
public static final int INITIATE_AND_ACCEPT
公共の静的な最終的な_int INITIATE AND_ACCEPT
Credential usage flag requesting that it be able to be used for both context initiation and acceptance.
文脈開始と承認の両方に使用できるよう要求する資格証明用法旗。
public static final int INITIATE_ONLY
公共の静的な最終的なint INITIATEだけ
Credential usage flag requesting that it be able to be used for context initiation only.
文脈開始だけに使用できるよう要求する資格証明用法旗。
public static final int ACCEPT_ONLY
公共の静的な最終的なint ACCEPTだけ
Credential usage flag requesting that it be able to be used for context acceptance only.
文脈承認だけに使用できるよう要求する資格証明用法旗。
public static final int DEFAULT_LIFETIME
公共の静的な最終的なint DEFAULT_LIFETIME
A lifetime constant representing the default credential lifetime.
デフォルト資格証明の生涯を表す生涯定数。
This value must be set to 0.
この値を0に設定しなければなりません。
public static final int INDEFINITE_LIFETIME
公共の静的な最終的なint INDEFINITE_LIFETIME
Kabat & Upadhyay Standards Track [Page 47] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[47ページ]。
A lifetime constant representing indefinite credential lifetime. This value must be set to the maximum integer value in Java - Integer.MAX_VALUE.
無期資格証明生涯を表す生涯定数。 Javaで最大の整数値にこの値を設定しなければなりません--Integer.MAX_VALUE。
6.3.3. dispose
6.3.3.、配列
public void dispose() throws GSSException
公共の空間は() 一投GSSExceptionを配列します。
Releases any sensitive information that the GSSCredential object may be containing. Applications should call this method as soon as the credential is no longer needed to minimize the time any sensitive information is maintained.
GSSCredentialオブジェクトが含んでいるどんな機密情報も発表します。 資格証明書はどんな機密情報も維持される時を最小にするのにもう必要でないとすぐに、アプリケーションは、これをメソッドと呼ぶべきです。
6.3.4. getName
6.3.4. getName
public GSSName getName() throws GSSException
公共のGSSName getName()はGSSExceptionを投げます。
Retrieves the name of the entity that the credential asserts.
資格証明書が断言する実体の名前を検索します。
6.3.5. getName
6.3.5. getName
public GSSName getName(Oid mechOID) throws GSSException
公共のGSSName getName(Oid mechOID)はGSSExceptionを投げます。
Retrieves a mechanism name of the entity that the credential asserts. Equivalent to calling canonicalize() on the name returned by 7.3.3.
資格証明書が断言する実体のメカニズム名を検索します。 帰りという7.3の名前のcanonicalize()を.3と呼ぶのに、同等です。
Parameters:
パラメタ:
mechOID The mechanism for which information should be
returned.
mechOID、情報が返されるべきであるメカニズム。
6.3.6. getRemainingLifetime
6.3.6. getRemainingLifetime
public int getRemainingLifetime() throws GSSException
公共のint getRemainingLifetime()はGSSExceptionを投げます。
Returns the remaining lifetime in seconds for a credential. The remaining lifetime is the minimum lifetime for any of the underlying credential mechanisms. A return value of GSSCredential.INDEFINITE_LIFETIME indicates that the credential does not expire. A return value of 0 indicates that the credential is already expired.
秒に資格証明書のために残っている生涯を返します。 残っている寿命は基本的な資格証明メカニズムのどれかの最小の生涯です。GSSCredential.INDEFINITE_LIFETIMEのリターン値は、資格証明書が期限が切れないのを示します。 0のリターン値は、資格証明書が既に吐き出されるのを示します。
Kabat & Upadhyay Standards Track [Page 48] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[48ページ]。
6.3.7. getRemainingInitLifetime
6.3.7. getRemainingInitLifetime
public int getRemainingInitLifetime(Oid mech) throws GSSException
公共のint getRemainingInitLifetime(Oid mech)はGSSExceptionを投げます。
Returns the remaining lifetime is seconds for the credential to remain capable of initiating security contexts under the specified mechanism. A return value of GSSCredential.INDEFINITE_LIFETIME indicates that the credential does not expire for context initiation. A return value of 0 indicates that the credential is already expired.
リターン、残っている寿命は資格証明書が指定されたメカニズムの下でセキュリティ文脈を開始だったことできるままで残る秒です。 資格証明書が文脈開始のために吐き出さないLIFETIMEが示すGSSCredential.INDEFINITE_のリターン値。 0のリターン値は、資格証明書が既に吐き出されるのを示します。
Parameters:
パラメタ:
mechOID The mechanism for which information should be
returned.
mechOID、情報が返されるべきであるメカニズム。
6.3.8. getRemainingAcceptLifetime
6.3.8. getRemainingAcceptLifetime
public int getRemainingAcceptLifetime(Oid mech) throws GSSException
公共のint getRemainingAcceptLifetime(Oid mech)はGSSExceptionを投げます。
Returns the remaining lifetime is seconds for the credential to remain capable of accepting security contexts under the specified mechanism. A return value of GSSCredential.INDEFINITE_LIFETIME indicates that the credential does not expire for context acceptance. A return value of 0 indicates that the credential is already expired.
リターン、残っている寿命は資格証明書が指定されたメカニズムの下にセキュリティ文脈を受け入れたことができるままで残る秒です。 資格証明書が文脈承認のために吐き出さないLIFETIMEが示すGSSCredential.INDEFINITE_のリターン値。 0のリターン値は、資格証明書が既に吐き出されるのを示します。
Parameters:
パラメタ:
mechOID The mechanism for which information should be
returned.
mechOID、情報が返されるべきであるメカニズム。
6.3.9. getUsage
6.3.9. getUsage
public int getUsage() throws GSSException
公共のint getUsage()はGSSExceptionを投げます。
Returns the credential usage flag. The return value will be one of GSSCredential.INITIATE_ONLY, GSSCredential.ACCEPT_ONLY, or GSSCredential.INITIATE_AND_ACCEPT.
資格証明用法旗を返します。 リターン値は、GSSCredential.INITIATEの1つだけか、GSSCredential.ACCEPT_だけか、GSSCredential.INITIATE_になって、_はACCEPTです。
6.3.10. getUsage
6.3.10. getUsage
public int getUsage(Oid mechOID) throws GSSException
公共のint getUsage(Oid mechOID)はGSSExceptionを投げます。
Returns the credential usage flag for the specified credential mechanism. The return value will be one of GSSCredential.INITIATE_ONLY, GSSCredential.ACCEPT_ONLY, or GSSCredential.INITIATE_AND_ACCEPT.
指定された資格証明メカニズムのために資格証明用法旗を返します。 リターン値は、GSSCredential.INITIATEの1つだけか、GSSCredential.ACCEPT_だけか、GSSCredential.INITIATE_になって、_はACCEPTです。
Kabat & Upadhyay Standards Track [Page 49] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[49ページ]。
Parameters:
パラメタ:
mechOID The mechanism for which information should be
returned.
mechOID、情報が返されるべきであるメカニズム。
6.3.11. getMechs
6.3.11. getMechs
public Oid[] getMechs() throws GSSException
公共のOid[] getMechs()はGSSExceptionを投げます。
Returns an array of mechanisms supported by this credential.
メカニズムの配列がこの資格証明書でサポートしたリターン。
6.3.12. add
6.3.12. 加えてください。
public void add(GSSName aName, int initLifetime, int acceptLifetime,
Oid mech, int usage) throws GSSException
公共の空間は、(GSSName aName、int initLifetime、int acceptLifetime、Oid mech、int用法)がGSSExceptionを投げると言い足します。
Adds a mechanism specific credential-element to an existing credential. This method allows the construction of credentials one mechanism at a time.
メカニズムの特定の資格証明要素に、既存の資格証明書に加えます。 このメソッドは一度に1つのメカニズムに資格証明書の工事を許します。
This routine is envisioned to be used mainly by context acceptors during the creation of acceptance credentials which are to be used with a variety of clients using different security mechanisms.
このルーチンは、異なったセキュリティー対策を使用するさまざまなクライアントと共に使用されることである承認資格証明書の作成の間、主に文脈アクセプタによって使用されるために思い描かれます。
This routine adds the new credential element "in-place". To add the element in a new credential, first call clone() to obtain a copy of this credential, then call its add() method.
このルーチンは「適所で」新しい資格証明要素を加えます。 新しい資格証明書で要素を加えて、最初に、この資格証明書のコピーを入手するためにクローン()と呼んで、次に、電話をする、それ、() メソッドを加えてください。
Parameters:
パラメタ:
aName Name of the principal for whom this credential is to
be acquired. Use "null" to specify the default
principal.
後天的であるこの資格証明書がことである主体のaName Name。 「ヌル」を使用して、デフォルト主体を指定してください。
initLifetime
The number of seconds that credentials should remain
valid for initiating of security contexts. Use
GSSCredential.INDEFINITE_LIFETIME to request that the
credentials have the maximum permitted lifetime. Use
GSSCredential.DEFAULT_LIFETIME to request default
credential lifetime.
initLifetime、資格証明書がセキュリティ文脈で開始に有効なままで残るべきである秒の数。 GSSCredential.INDEFINITE_LIFETIMEを使用して、資格証明書には最大の受入れられた寿命があるよう要求してください。 GSSCredential.DEFAULT_LIFETIMEを使用して、デフォルト資格証明の生涯を要求してください。
acceptLifetime
The number of seconds that credentials should remain
valid for accepting of security contexts. Use
GSSCredential.INDEFINITE_LIFETIME to request that the
acceptLifetime、資格証明書がセキュリティ文脈を受け入れるのに有効なままで残るべきである秒の数。 GSSCredential.INDEFINITE_LIFETIMEを使用して、それを要求してください。
Kabat & Upadhyay Standards Track [Page 50] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[50ページ]。
credentials have the maximum permitted lifetime. Use
GSSCredential.DEFAULT_LIFETIME to request default
credential lifetime.
資格証明書には、最大の受入れられた寿命があります。 GSSCredential.DEFAULT_LIFETIMEを使用して、デフォルト資格証明の生涯を要求してください。
mech The mechanisms over which the credential is to be
acquired.
mech、後天的である資格証明書がことであるメカニズム。
usage The intended usage for this credential object. The
value of this parameter must be one of:
GSSCredential.ACCEPT_AND_INITIATE,
GSSCredential.ACCEPT_ONLY, GSSCredential.INITIATE_ONLY
用法、この資格証明オブジェクトのための意図している用法。 このパラメタの値が1でなければならない、: GSSCredential.ACCEPT_AND_開始、GSSCredential.ACCEPT_だけ、GSSCredential.INITIATEだけ
6.3.13. equals
6.3.13. 同輩
public boolean equals(Object another)
公共の論理演算子同輩(別のオブジェクトもの)です。
Tests if this GSSCredential refers to the same entity as the supplied object. The two credentials must be acquired over the same mechanisms and must refer to the same principal. Returns "true" if the two GSSCredentials refer to the same entity; "false" otherwise. (Note that the Java language specification requires that two objects that are equal according to the equals(Object) method must return the same integer result when the hashCode() method is called on them.)
このGSSCredentialが供給されたオブジェクトと同じ実体について言及するなら、テストします。 2つの資格証明書が、同じメカニズムの上に取得しなければならなくて、同じ主体を呼ばなければなりません。 「本当に、」2GSSCredentialsが同じ実体について言及するなら、戻ります。 そうでなければ、「虚偽。」 (ジャバ言語仕様が、hashCode()メソッドが彼らの上に呼ばれるとき、2個のメソッドが同じ整数に返さなければならない同輩(オブジェクト)によると、等しいオブジェクトが結果として生じるのを必要とすることに注意してください。)
Parameters:
パラメタ:
another Another GSSCredential object for comparison.
別のAnother GSSCredentialは比較のために反対します。
6.4. public interface GSSContext
6.4. 公共のインタフェースGSSContext
This interface encapsulates the GSS-API security context and provides the security services (wrap, unwrap, getMIC, verifyMIC) that are available over the context. Security contexts are established between peers using locally acquired credentials. Multiple contexts may exist simultaneously between a pair of peers, using the same or different set of credentials. GSS-API functions in a manner independent of the underlying transport protocol and depends on its calling application to transport its tokens between peers.
包装、getMIC、開けてください、そして、verifyMIC) それはそうです。このインタフェースがGSS-APIセキュリティ文脈をカプセル化して、セキュリティー・サービスを提供する、(文脈の上で利用可能です。 セキュリティ文脈は、同輩の間で局所的に取得された資格証明書を使用することで確立されます。 同じであるか異なったセットの資格証明書を使用して、複数の文脈が同時に、1組の同輩の間に存在するかもしれません。 そして、基本的なトランスポート・プロトコルの如何にかかわらず方法によるGSS-API関数、同輩の間のトークンを輸送するためにアプリケーションと呼ぶのによります。
Before the context establishment phase is initiated, the context initiator may request specific characteristics desired of the established context. These can be set using the set methods. After the context is established, the caller can check the actual characteristic and services offered by the context using the query methods.
文脈確立段階が開始される前に、文脈創始者は確立した関係で必要な特定の特性を要求するかもしれません。 セットメソッドを使用するようにこれらを設定できます。 文脈が確立された後に、訪問者は文脈によって質問メソッドを使用することで提供された実際の特性とサービスをチェックできます。
Kabat & Upadhyay Standards Track [Page 51] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[51ページ]。
The context establishment phase begins with the first call to the init method by the context initiator. During this phase the initSecContext and acceptSecContext methods will produce GSS-API authentication tokens which the calling application needs to send to its peer. If an error occurs at any point, an exception will get thrown and the code will start executing in a catch block. If not, the normal flow of code continues and the application can make a call to the isEstablished() method. If this method returns false it indicates that a token is needed from its peer in order to continue the context establishment phase. A return value of true signals that the local end of the context is established. This may still require that a token be sent to the peer, if one is produced by GSS-API. During the context establishment phase, the isProtReady() method may be called to determine if the context can be used for the per-message operations. This allows applications to use per-message operations on contexts which aren't fully established.
文脈確立段階は準備ラッパで文脈創始者によるイニットメソッドに始まります。 このフェーズのinitSecContextとacceptSecContextの間、メソッドは呼ぶアプリケーションが同輩に送る必要があるGSS-API認証トークンを生産するでしょう。 誤りが任意な点に発生すると、例外は投げられるでしょう、そして、コードはキャッチブロックで実行し始めるでしょう。 そうでなければ、コードの正常な流れは続きます、そして、アプリケーションはisEstablished()メソッドに電話をかけることができます。 このメソッドが虚偽で戻るなら、それは、トークンが文脈確立段階を続けるのに同輩から必要であることを示します。 文脈の地方の終わりが確立されるという本当の信号のリターン値。 1つがGSS-APIによって生産されるなら、これは、トークンが同輩に送られるのをまだ必要としているかもしれません。 文脈確立段階の間、isProtReady()メソッドは、1メッセージあたりの操作に文脈を使用できるかどうか決定するために呼ばれるかもしれません。 これで、アプリケーションは完全に確立されるというわけではない文脈で1メッセージあたりの操作を使用できます。
After the context has been established or the isProtReady() method returns "true", the query routines can be invoked to determine the actual characteristics and services of the established context. The application can also start using the per-message methods of wrap and getMIC to obtain cryptographic operations on application supplied data.
文脈が確立されたか、またはisProtReady()メソッドが「本当に」戻った後に、確立した関係の実際の特性とサービスを決定するために質問ルーチンを呼び出すことができます。 また、アプリケーションは、包装の1メッセージあたりのメソッドを使用し始めることができます、そして、暗号の操作を得るgetMICは申込み次第資料を提供しました。
When the context is no longer needed, the application should call dispose to release any system resources the context may be using.
必要であることで、文脈がもうそうときに、アプリケーションは呼ぶべきです。文脈が使用しているどんなシステム資源もリリースするために、配列します。
6.4.1. Example Code
6.4.1. 例のコード
The example code presented below demonstrates the usage of the GSSContext interface for the initiating peer. Different operations on the GSSContext object are presented, including: object instantiation, setting of desired flags, context establishment, query of actual context flags, per-message operations on application data, and finally context deletion.
以下に提示された例のコードは開始している同輩のためにGSSContextインタフェースの用法を示します。 以下を含んでいて、GSSContextオブジェクトにおける異なった操作は提示されます。 オブジェクト具体化、必要な旗の設定、文脈設立、実際の文脈旗の質問、アプリケーションデータにおける1メッセージあたりの操作、および最終的に文脈削除。
GSSManager mgr = GSSManager.getInstance();
GSSManager mgrはGSSManager.getInstance()と等しいです。
// start by creating the name for a service entity
GSSName targetName = mgr.createName("service@host",
GSSName.NT_HOSTBASED_SERVICE);
サービス実体GSSName targetNameのために名前を作成するのによる//始めはmgr.createName(" service@host "、GSSName.NT_HOSTBASED_サービス)と等しいです。
// create a context using default credentials for the above entity
// and the implementation specific default mechanism
GSSContext context = mgr.createContext(targetName,
null, /* default mechanism */
null, /* default credentials */
GSSContext.INDEFINITE_LIFETIME);
//は上の実体//にデフォルト資格証明書を使用することで文脈を作成します、そして、実装の特定のデフォルトメカニズムGSSContext文脈はmgr.createContext(targetName、ヌルの、そして、/*デフォルトメカニズム*/ヌルの/*デフォルト資格証明書*/GSSContext.INDEFINITE_LIFETIME)と等しいです。
Kabat & Upadhyay Standards Track [Page 52] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[52ページ]。
// set desired context options - all others are false by default context.requestConf(true); context.requestMutualAuth(true); context.requestReplayDet(true); context.requestSequenceDet(true);
//セットは文脈オプションを望んでいました--すべての他のものがデフォルトで偽である、context.requestConf(本当の)。 context.requestMutualAuth(本当の)。 context.requestReplayDet(本当の)。 context.requestSequenceDet(本当の)。
// establish a context between peers - using byte arrays byte []inTok = new byte[0];
//は同輩の間の文脈を確立します--バイトを使用すると、新しいバイト[]inTok=バイト[0]は整列させられます。
try {
do {
byte[] outTok = context.initSecContext(inTok, 0,
inTok.length);
トライ、バイト[]outTokはcontext.initSecContext(inTok、0、inTok.length)と等しいです。
// send the token if present
if (outTok != null)
sendToken(outTok);
存在しているなら、//は(outTok!=ヌル)sendToken(outTok)であるならトークンを送ります。
// check if we should expect more tokens
if (context.isEstablished())
break;
//チェックが私たちであるなら、より多くのトークンを予想するべきである、(context.isEstablished())は壊れます。
// another token expected from peer
inTok = readToken();
別のトークンが同輩inTokから予想した//はreadToken()と等しいです。
} while (true);
(本当)ですが。
} catch (GSSException e) {
print("GSSAPI error: " + e.getMessage());
}
(GSSException e)を捕らえてください。印刷、(「GSSAPI誤り:」 + e.getMessage())。 }
// display context information
print("Remaining lifetime in seconds = " + context.getLifetime());
print("Context mechanism = " + context.getMech().toString());
print("Initiator = " + context.getSrcName().toString());
print("Acceptor = " + context.getTargName().toString());
//ディスプレイ文脈情報印刷、(+ 「残っている寿命は中で=を後援する」context.getLifetime())。 印刷、(+ 「文脈メカニズム=」context.getMech().toString())。 印刷、(+ 「創始者=」context.getSrcName().toString())。 印刷、(+ 「アクセプタ=」context.getTargName().toString())。
if (context.getConfState())
print("Confidentiality security service available");
(context.getConfState())は(「利用可能な秘密性セキュリティー・サービス」)を印刷します。
if (context.getIntegState())
print("Integrity security service available");
(context.getIntegState())は(「利用可能な保全セキュリティー・サービス」)を印刷します。
// perform wrap on an application supplied message, appMsg, // using QOP = 0, and requesting privacy service byte [] appMsg ...
//はアプリケーションの供給されたメッセージと、appMsgと、//使用QOP=0と、プライバシーサービスバイト[]appMsgを要求するのに包装を実行します…
Kabat & Upadhyay Standards Track [Page 53] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[53ページ]。
MessageProp mProp = new MessageProp(0, true);
MessageProp mPropは新しいMessageProp(本当に0)と等しいです。
byte []tok = context.wrap(appMsg, 0, appMsg.length, mProp);
バイト[]tokはcontext.wrap(appMsg、0、appMsg.length、mProp)と等しいです。
if (mProp.getPrivacy())
print("Message protected with privacy.");
(mProp.getPrivacy())は印刷します(「メッセージはプライバシーで保護しました」。)。
sendToken(tok);
sendToken(tok)。
// release the local-end of the context context.dispose();
//リリース文脈の地方の終わりのcontext.dispose()。
6.4.2. Static Constants
6.4.2. 静的な定数
public static final int DEFAULT_LIFETIME
公共の静的な最終的なint DEFAULT_LIFETIME
A lifetime constant representing the default context lifetime. This value must be set to 0.
デフォルト文脈を表す生涯定数、生涯。 この値を0に設定しなければなりません。
public static final int INDEFINITE_LIFETIME
公共の静的な最終的なint INDEFINITE_LIFETIME
A lifetime constant representing indefinite context lifetime. This value must be set to the maximum integer value in Java - Integer.MAX_VALUE.
無期文脈生涯を表す生涯定数。 Javaで最大の整数値にこの値を設定しなければなりません--Integer.MAX_VALUE。
6.4.3. initSecContext
6.4.3. initSecContext
public byte[] initSecContext(byte inputBuf[], int offset, int len)
throws GSSException
公共のバイト[]initSecContext(バイトinputBuf[]、intオフセット、int len)はGSSExceptionを投げます。
Called by the context initiator to start the context creation process. This is equivalent to the stream based method except that the token buffers are handled as byte arrays instead of using stream objects. This method may return an output token which the application will need to send to the peer for processing by the accept call. Typically, the application would do so by calling the flush() method on an OutputStream that encapsulates the connection between the two peers. The application can call isEstablished() to determine if the context establishment phase is complete for this peer. A return value of "false" from isEstablished() indicates that more tokens are expected to be supplied to the initSecContext() method. Note that it is possible that the initSecContext() method return a token for the peer, and isEstablished() return "true" also. This indicates that the token needs to be sent to the peer, but the local end of the context is now fully established.
文脈作成プロセスを始めるために文脈創始者によって電話をされます。 ストリームを使用することの代わりにバイトがオブジェクトを整列させるときトークンバッファが扱われるのを除いて、これはストリームのベースのメソッドに同等です。 このメソッドが処理のために同輩に発信するアプリケーションが、必要がある出力トークンを返すかもしれない、呼び出しを受け入れてください。 通常、同輩にOutputStreamの上の2つの間の関係をカプセル化する水洗()メソッドに電話をすることによって、アプリケーションはそうするでしょう。 アプリケーションは、この同輩にとって、文脈確立段階が完全であるかどうか決定するためにisEstablished()と呼ぶことができます。 isEstablished()から「誤ること」のリターン値は、より多くのトークンによってinitSecContext()メソッドに供給されると予想されるのを示します。 initSecContext()メソッドが同輩のためにトークンを返すのが、可能であることに注意してください。そうすれば、また、isEstablished()は「本当に」戻ります。 これは、トークンが、同輩に送られる必要であるのを示しますが、文脈の地方の終わりは現在、完全に確立されます。
Kabat & Upadhyay Standards Track [Page 54] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[54ページ]。
Upon completion of the context establishment, the available context options may be queried through the get methods.
文脈設立、オプションが質問されるかもしれない利用可能な文脈の完成、メソッドを得てください。
Parameters:
パラメタ:
inputBuf Token generated by the peer. This parameter is ignored
on the first call.
同輩によって生成されたinputBuf Token。 このパラメタは準備ラッパのときに無視されます。
offset The offset within the inputBuf where the token begins.
トークンが始まるinputBufの中でオフセットを相殺してください。
len The length of the token within the inputBuf (starting
at the offset).
inputBuf(オフセットのときに、始める)の中のトークンの長さのlen。
6.4.3.1. Example Code
6.4.3.1. 例のコード
// Create a new GSSContext implementation object. // GSSContext wrapper implements interface GSSContext. GSSContext context = mgr.createContext(...);
//は新しいGSSContext実装オブジェクトを作成します。 //GSSContextラッパー道具はGSSContextを連結します。 GSSContext文脈はmgr.createContext(…)と等しいです。
byte []inTok = new byte[0];
バイト[]inTokは新しいバイト[0]と等しいです。
try {
トライ
do {
byte[] outTok = context.initSecContext(inTok, 0,
inTok.length);
バイト[]outTokはcontext.initSecContext(inTok、0、inTok.length)と等しいです。
// send the token if present
if (outTok != null)
sendToken(outTok);
存在しているなら、//は(outTok!=ヌル)sendToken(outTok)であるならトークンを送ります。
// check if we should expect more tokens
if (context.isEstablished())
break;
//チェックが私たちであるなら、より多くのトークンを予想するべきである、(context.isEstablished())は壊れます。
// another token expected from peer
inTok = readToken();
} while (true);
別のトークンが同輩inTokから予想した//はreadToken()と等しいです。 (本当)ですが。
} catch (GSSException e) {
print("GSSAPI error: " + e.getMessage());
}
(GSSException e)を捕らえてください。印刷、(「GSSAPI誤り:」 + e.getMessage())。 }
Kabat & Upadhyay Standards Track [Page 55] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[55ページ]。
6.4.4. initSecContext
6.4.4. initSecContext
public int initSecContext(InputStream inStream,
OutputStream outStream) throws GSSException
公共のint initSecContext(InputStream inStream、OutputStream outStream)はGSSExceptionを投げます。
Called by the context initiator to start the context creation process. This is equivalent to the byte array based method. This method may write an output token to the outStream, which the application will need to send to the peer for processing by the accept call. Typically, the application would do so by calling the flush() method on an OutputStream that encapsulates the connection between the two peers. The application can call isEstablished() to determine if the context establishment phase is complete for this peer. A return value of "false" from isEstablished indicates that more tokens are expected to be supplied to the initSecContext method. Note that it is possible that the initSecContext() method return a token for the peer, and isEstablished() return "true" also. This indicates that the token needs to be sent to the peer, but the local end of the context is now fully established.
文脈作成プロセスを始めるために文脈創始者によって電話をされます。 これはバイトの配列のベースのメソッドに同等です。 このメソッドが出力トークンをoutStreamに書くかもしれない、呼び出しを受け入れてください。(outStreamで、処理のために同輩に発信しますアプリケーションが、必要がある)。 通常、同輩にOutputStreamの上の2つの間の関係をカプセル化する水洗()メソッドに電話をすることによって、アプリケーションはそうするでしょう。 アプリケーションは、この同輩にとって、文脈確立段階が完全であるかどうか決定するためにisEstablished()と呼ぶことができます。 isEstablishedから「誤ること」のリターン値は、より多くのトークンによってinitSecContextメソッドに供給されると予想されるのを示します。 initSecContext()メソッドが同輩のためにトークンを返すのが、可能であることに注意してください。そうすれば、また、isEstablished()は「本当に」戻ります。 これは、トークンが、同輩に送られる必要であるのを示しますが、文脈の地方の終わりは現在、完全に確立されます。
The GSS-API authentication tokens contain a definitive start and end. This method will attempt to read one of these tokens per invocation, and may block on the stream if only part of the token is available.
GSS-API認証トークンは決定的な始めと終わりを含んでいます。 このメソッドは、これらの1実施あたりのトークンの1つを読むのを試みて、トークンの部分だけが有効であるなら、ストリームに立ち塞がるかもしれません。
Upon completion of the context establishment, the available context options may be queried through the get methods.
文脈設立、オプションが質問されるかもしれない利用可能な文脈の完成、メソッドを得てください。
Parameters:
パラメタ:
inStream Contains the token generated by the peer. This
parameter is ignored on the first call.
トークンが同輩で生成したinStream Contains。 このパラメタは準備ラッパのときに無視されます。
outStream Output stream where the output token will be written.
During the final stage of context establishment, there
may be no bytes written.
outStream Outputは出力トークンが書かれているところに流れます。 文脈設立の最終段階の間、書かれたバイトが全くないかもしれません。
6.4.4.1. Example Code
6.4.4.1. 例のコード
This sample code merely demonstrates the token exchange during the context establishment phase. It is expected that most Java applications will use custom implementations of the Input and Output streams that encapsulate the communication routines. For instance, a simple read on the application InputStream, when called by the Context, might cause a token to be read from the peer, and a simple flush() on the application OutputStream might cause a previously written token to be transmitted to the peer.
このサンプルコードは文脈確立段階の間、単にトークン交換を示します。 ほとんどのJavaアプリケーションがコミュニケーションルーチンをカプセル化するInputとOutputストリームのカスタム実装を使用すると予想されます。 例えば、Contextによって呼ばれると、アプリケーションInputStreamの簡単な読書で同輩からトークンを読むかもしれません、そして、アプリケーションOutputStreamの簡単な水洗()で、以前に書かれたトークンを同輩に伝えるかもしれません。
// Create a new GSSContext implementation object.
//は新しいGSSContext実装オブジェクトを作成します。
Kabat & Upadhyay Standards Track [Page 56] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[56ページ]。
// GSSContext wrapper implements interface GSSContext. GSSContext context = mgr.createContext(...);
//GSSContextラッパー道具はGSSContextを連結します。 GSSContext文脈はmgr.createContext(…)と等しいです。
// use standard java.io stream objects ByteArrayOutputStream os = new ByteArrayOutputStream(); ByteArrayInputStream is = null;
//使用標準のjava.ioストリームオブジェクトByteArrayOutputStream OSは新しいByteArrayOutputStream()と等しいです。 ByteArrayInputStreamは=ヌルです。
try {
トライ
do {
context.initSecContext(is, os);
context.initSecContext、(ある、OS)、。
// send token if present
if (os.size() > 0)
sendToken(os);
存在しているなら、//は(os.size()>0)sendToken(OS)であるならトークンを送ります。
// check if we should expect more tokens
if (context.isEstablished())
break;
//チェックが私たちであるなら、より多くのトークンを予想するべきである、(context.isEstablished())は壊れます。
// another token expected from peer
is = recvToken();
別のトークンが同輩から予想した//は=recvToken()です。
} while (true);
(本当)ですが。
} catch (GSSException e) {
print("GSSAPI error: " + e.getMessage());
}
(GSSException e)を捕らえてください。印刷、(「GSSAPI誤り:」 + e.getMessage())。 }
6.4.5. acceptSecContext
6.4.5. acceptSecContext
public byte[] acceptSecContext(byte inTok[], int offset, int len)
throws GSSException
公共のバイト[]acceptSecContext(バイトinTok[]、intオフセット、int len)はGSSExceptionを投げます。
Called by the context acceptor upon receiving a token from the peer. This call is equivalent to the stream based method except that the token buffers are handled as byte arrays instead of using stream objects.
文脈アクセプタで、同輩からトークンを受けるとき、呼ばれます。 この呼び出しはストリームを使用することの代わりにバイトがオブジェクトを整列させるときトークンバッファが扱われるのを除いて、ストリームと同等物がメソッドを基礎づけたということです。
This method may return an output token which the application will need to send to the peer for further processing by the init call.
このメソッドはアプリケーションがさらなる処理のためにイニット呼び出しで同輩に送る必要がある出力トークンを返すかもしれません。
"null" return value indicates that no token needs to be sent to the peer. The application can call isEstablished() to determine if the context establishment phase is complete for this peer. A return value of "false" from isEstablished() indicates that more tokens are expected to be supplied to this method.
「ヌル」のリターン値は、どんなトークンも、同輩に送られる必要でないのを示します。 アプリケーションは、この同輩にとって、文脈確立段階が完全であるかどうか決定するためにisEstablished()と呼ぶことができます。 isEstablished()から「誤ること」のリターン値は、より多くのトークンによってこのメソッドに供給されると予想されるのを示します。
Kabat & Upadhyay Standards Track [Page 57] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[57ページ]。
Note that it is possible that acceptSecContext() return a token for the peer, and isEstablished() return "true" also. This indicates that the token needs to be sent to the peer, but the local end of the context is now fully established.
acceptSecContext()が同輩のためにトークンを返すのが、可能であることに注意してください。そうすれば、また、isEstablished()は「本当に」戻ります。 これは、トークンが、同輩に送られる必要であるのを示しますが、文脈の地方の終わりは現在、完全に確立されます。
Upon completion of the context establishment, the available context options may be queried through the get methods.
文脈設立、オプションが質問されるかもしれない利用可能な文脈の完成、メソッドを得てください。
Parameters:
パラメタ:
inTok Token generated by the peer.
同輩によって生成されたinTok Token。
offset The offset within the inTok where the token begins.
トークンが始まるinTokの中でオフセットを相殺してください。
len The length of the token within the inTok (starting at
the offset).
inTok(オフセットのときに、始める)の中のトークンの長さのlen。
6.4.5.1. Example Code
6.4.5.1. 例のコード
// acquire server credentials GSSCredential server = mgr.createCredential(...);
//はサーバ資格証明書GSSCredentialサーバ=mgr.createCredential(…)を獲得します。
// create acceptor GSS-API context from the default provider GSSContext context = mgr.createContext(server, null);
//はデフォルトプロバイダーGSSContext文脈=mgr.createContext(サーバ、ヌル)からアクセプタGSS-API文脈を作成します。
try {
do {
byte [] inTok = readToken();
トライ、バイト[]inTokはreadToken()と等しいです。
byte []outTok = context.acceptSecContext(inTok, 0,
inTok.length);
バイト[]outTokはcontext.acceptSecContext(inTok、0、inTok.length)と等しいです。
// possibly send token to peer
if (outTok != null)
sendToken(outTok);
//は(outTok!=ヌル)sendToken(outTok)であるならことによるとトークンを同輩に送ります。
// check if local context establishment is complete
if (context.isEstablished())
break;
} while (true);
//チェックが地方の文脈設立であるなら完全である、(context.isEstablished())は壊れます。 (本当)ですが。
} catch (GSSException e) {
print("GSS-API error: " + e.getMessage());
}
(GSSException e)を捕らえてください。印刷、(「GSS-API誤り:」 + e.getMessage())。 }
Kabat & Upadhyay Standards Track [Page 58] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[58ページ]。
6.4.6. acceptSecContext
6.4.6. acceptSecContext
public void acceptSecContext(InputStream inStream,
OutputStream outStream) throws GSSException
公共の空のacceptSecContext(InputStream inStream、OutputStream outStream)はGSSExceptionを投げます。
Called by the context acceptor upon receiving a token from the peer. This call is equivalent to the byte array method. It may write an output token to the outStream, which the application will need to send to the peer for processing by its initSecContext method. Typically, the application would do so by calling the flush() method on an OutputStream that encapsulates the connection between the two peers. The application can call isEstablished() to determine if the context establishment phase is complete for this peer. A return value of "false" from isEstablished() indicates that more tokens are expected to be supplied to this method.
文脈アクセプタで、同輩からトークンを受けるとき、呼ばれます。 この呼び出しはバイト配列メソッドに同等です。 それは出力トークンをoutStreamに書くかもしれません。(処理のためにinitSecContextメソッドでoutStreamを同輩に送りますアプリケーションが、必要がある)。 通常、同輩にOutputStreamの上の2つの間の関係をカプセル化する水洗()メソッドに電話をすることによって、アプリケーションはそうするでしょう。 アプリケーションは、この同輩にとって、文脈確立段階が完全であるかどうか決定するためにisEstablished()と呼ぶことができます。 isEstablished()から「誤ること」のリターン値は、より多くのトークンによってこのメソッドに供給されると予想されるのを示します。
Note that it is possible that acceptSecContext() return a token for the peer, and isEstablished() return "true" also. This indicates that the token needs to be sent to the peer, but the local end of the context is now fully established.
acceptSecContext()が同輩のためにトークンを返すのが、可能であることに注意してください。そうすれば、また、isEstablished()は「本当に」戻ります。 これは、トークンが、同輩に送られる必要であるのを示しますが、文脈の地方の終わりは現在、完全に確立されます。
The GSS-API authentication tokens contain a definitive start and end. This method will attempt to read one of these tokens per invocation, and may block on the stream if only part of the token is available.
GSS-API認証トークンは決定的な始めと終わりを含んでいます。 このメソッドは、これらの1実施あたりのトークンの1つを読むのを試みて、トークンの部分だけが有効であるなら、ストリームに立ち塞がるかもしれません。
Upon completion of the context establishment, the available context options may be queried through the get methods.
文脈設立、オプションが質問されるかもしれない利用可能な文脈の完成、メソッドを得てください。
Parameters:
パラメタ:
inStream Contains the token generated by the peer.
トークンが同輩で生成したinStream Contains。
outStream Output stream where the output token will be written.
During the final stage of context establishment, there
may be no bytes written.
outStream Outputは出力トークンが書かれているところに流れます。 文脈設立の最終段階の間、書かれたバイトが全くないかもしれません。
6.4.6.1. Example Code
6.4.6.1. 例のコード
This sample code merely demonstrates the token exchange during the context establishment phase. It is expected that most Java applications will use custom implementations of the Input and Output streams that encapsulate the communication routines. For instance, a simple read on the application InputStream, when called by the Context, might cause a token to be read from the peer, and a simple flush() on the application OutputStream might cause a previously written token to be transmitted to the peer.
このサンプルコードは文脈確立段階の間、単にトークン交換を示します。 ほとんどのJavaアプリケーションがコミュニケーションルーチンをカプセル化するInputとOutputストリームのカスタム実装を使用すると予想されます。 例えば、Contextによって呼ばれると、アプリケーションInputStreamの簡単な読書で同輩からトークンを読むかもしれません、そして、アプリケーションOutputStreamの簡単な水洗()で、以前に書かれたトークンを同輩に伝えるかもしれません。
// acquire server credentials
//はサーバ資格証明書を取得します。
Kabat & Upadhyay Standards Track [Page 59] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[59ページ]。
GSSCredential server = mgr.createCredential(...);
GSSCredentialサーバはmgr.createCredential(…)と等しいです。
// create acceptor GSS-API context from the default provider GSSContext context = mgr.createContext(server, null);
//はデフォルトプロバイダーGSSContext文脈=mgr.createContext(サーバ、ヌル)からアクセプタGSS-API文脈を作成します。
// use standard java.io stream objects ByteArrayOutputStream os = new ByteArrayOutputStream(); ByteArrayInputStream is = null;
//使用標準のjava.ioストリームオブジェクトByteArrayOutputStream OSは新しいByteArrayOutputStream()と等しいです。 ByteArrayInputStreamは=ヌルです。
try {
do {
トライ
is = recvToken();
=recvToken()です。
context.acceptSecContext(is, os);
context.acceptSecContext、(ある、OS)、。
// possibly send token to peer
if (os.size() > 0)
sendToken(os);
//は(os.size()>0)sendToken(OS)であるならことによるとトークンを同輩に送ります。
// check if local context establishment is complete
if (context.isEstablished())
break;
} while (true);
//チェックが地方の文脈設立であるなら完全である、(context.isEstablished())は壊れます。 (本当)ですが。
} catch (GSSException e) {
print("GSS-API error: " + e.getMessage());
}
(GSSException e)を捕らえてください。印刷、(「GSS-API誤り:」 + e.getMessage())。 }
6.4.7. isEstablished
6.4.7. isEstablishedされています。
public boolean isEstablished()
公共の論理演算子isEstablished()
Used during context establishment to determine the state of the context. Returns "true" if this is a fully established context on the caller's side and no more tokens are needed from the peer. Should be called after a call to initSecContext() or acceptSecContext() when no GSSException is thrown.
文脈設立の間、文脈の状態を決定するために、使用されます。 「本当に、」これが訪問者の側の完全に確立した関係であり、それ以上のトークンは全く同輩から必要でないなら、戻ります。 GSSExceptionが全く投げられないとき、呼び出しの後にinitSecContext()かacceptSecContext()に呼ばれるべきです。
6.4.8. dispose
6.4.8.、配列
public void dispose() throws GSSException
公共の空間は() 一投GSSExceptionを配列します。
Releases any system resources and cryptographic information stored in the context object. This will invalidate the context.
どんなシステム資源と暗号の情報も文脈オブジェクトに保存したリリース。 これは文脈を無効にするでしょう。
Kabat & Upadhyay Standards Track [Page 60] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[60ページ]。
6.4.9. getWrapSizeLimit
6.4.9. getWrapSizeLimit
public int getWrapSizeLimit(int qop, boolean confReq,
int maxTokenSize) throws GSSException
公共のint getWrapSizeLimit(int qop、論理演算子confReq、int maxTokenSize)はGSSExceptionを投げます。
Returns the maximum message size that, if presented to the wrap method with the same confReq and qop parameters, will result in an output token containing no more than the maxTokenSize bytes.
同じconfReqとqopパラメタで包装メソッドに提示されるならmaxTokenSizeバイトだけを含む出力トークンをもたらす最大のメッセージサイズを返します。
This call is intended for use by applications that communicate over protocols that impose a maximum message size. It enables the application to fragment messages prior to applying protection.
この呼び出しは使用のために最大のメッセージサイズを課すプロトコルの上で伝えるアプリケーションで意図します。 それは、保護を適用する前にアプリケーションがメッセージを断片化するのを可能にします。
GSS-API implementations are recommended but not required to detect invalid QOP values when getWrapSizeLimit is called. This routine guarantees only a maximum message size, not the availability of specific QOP values for message protection.
GSS-API実行は、推薦されますが、getWrapSizeLimitが呼ばれるとき、無効のQOP値を検出するのに必要ではありません。 このルーチンはメッセージ保護のために特定のQOP値の有用性ではなく、最大のメッセージサイズだけを保証します。
Successful completion of this call does not guarantee that wrap will be able to protect a message of the computed length, since this ability may depend on the availability of system resources at the time that wrap is called. However, if the implementation itself imposes an upper limit on the length of messages that may be processed by wrap, the implementation should not return a value that is greater than this length.
この呼び出しの無事終了は、包装が計算された長さに関するメッセージを保護できるのを保証しません、この能力が包装が呼ばれる時にシステム資源の有用性によるかもしれないので。 しかしながら、実装自体が包装によって処理されるかもしれないメッセージの長さに上限を課すなら、実装はこの長さより大きい値を返すべきではありません。
Parameters:
パラメタ:
qop Indicates the level of protection wrap will be asked
to provide.
保護包装のレベルが提供するように頼まれるqop Indicates。
confReq Indicates if wrap will be asked to provide privacy
service.
包装が尋ねられるなら、confReq Indicatesはプライバシーサービスを提供します。
maxTokenSize
The desired maximum size of the token emitted by wrap.
包装によって放たれたトークンの必要な最大サイズのmaxTokenSize。
6.4.10. wrap
6.4.10. 包装
public byte[] wrap(byte inBuf[], int offset, int len,
MessageProp msgProp) throws GSSException
公共のバイト[]包装(バイトinBuf[]、intオフセット、int len、MessageProp msgProp)はGSSExceptionを投げます。
Applies per-message security services over the established security context. The method will return a token with a cryptographic MIC and may optionally encrypt the specified inBuf. This method is equivalent in functionality to its stream counterpart. The returned byte array will contain both the MIC and the message.
確立したセキュリティ関係の上の1メッセージあたりのセキュリティー・サービスを適用します。 メソッドは、暗号のMICがあるトークンを返して、任意に指定されたinBufを暗号化するかもしれません。 ストリーム対応者にとって、このメソッドは機能性で同等です。 返されたバイト配列はMICとメッセージの両方を含むでしょう。
Kabat & Upadhyay Standards Track [Page 61] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[61ページ]。
The MessageProp object is instantiated by the application and used to specify a QOP value which selects cryptographic algorithms, and a privacy service to optionally encrypt the message. The underlying mechanism that is used in the call may not be able to provide the privacy service. It sets the actual privacy service that it does provide in this MessageProp object which the caller should then query upon return. If the mechanism is not able to provide the requested QOP, it throws a GSSException with the BAD_QOP code.
MessagePropオブジェクトは、アプリケーションで例示されて、任意にメッセージを暗号化するために暗号アルゴリズム、およびプライバシーサービスを選択するQOP値を指定するのに使用されます。 呼び出しに使用される発症機序はプライバシーサービスを提供できないかもしれません。 それは次に訪問者がリターンのときに質問するべきであるこのMessagePropオブジェクトに供給する実際のプライバシーサービスを設定します。 メカニズムが要求されたQOPを提供できないなら、それはBAD_QOPコードでGSSExceptionを投げます。
Since some application-level protocols may wish to use tokens emitted by wrap to provide "secure framing", implementations should support the wrapping of zero-length messages.
いくつかのアプリケーションレベルプロトコルが包装によって放たれた、「安全な縁どり」を提供したトークンを使用したがっているかもしれないので、実装はゼロ・レングスメッセージのラッピングを支えるべきです。
The application will be responsible for sending the token to the peer.
アプリケーションはトークンを同輩に送るのに原因となるようになるでしょう。
Parameters:
パラメタ:
inBuf Application data to be protected.
保護されるべきinBuf Applicationデータ。
offset The offset within the inBuf where the data begins.
データが始まるinBufの中でオフセットを相殺してください。
len The length of the data within the inBuf (starting at
the offset).
inBuf(オフセットのときに、始める)の中のデータの長さのlen。
msgProp Instance of MessageProp that is used by the
application to set the desired QOP and privacy state.
Set the desired QOP to 0 to request the default QOP.
Upon return from this method, this object will contain
the the actual privacy state that was applied to the
message by the underlying mechanism.
必要なQOPとプライバシー状態を設定するのにアプリケーションで使用されるMessagePropのmsgProp Instance。 デフォルトQOPを要求する0に必要なQOPを設定してください。 このメソッドからのリターンでは、このオブジェクトは発症機序によってメッセージに適用された実際のプライバシー状態を含むでしょう。
6.4.11. wrap
6.4.11. 包装
public void wrap(InputStream inStream, OutputStream outStream,
MessageProp msgProp) throws GSSException
公共の空の包装(InputStream inStream、OutputStream outStream、MessageProp msgProp)はGSSExceptionを投げます。
Allows to apply per-message security services over the established security context. The method will produce a token with a cryptographic MIC and may optionally encrypt the message in inStream. The outStream will contain both the MIC and the message.
確立したセキュリティ関係の上の1メッセージあたりのセキュリティー・サービスを適用するのを許容します。 メソッドは、暗号のMICと共にトークンを生産して、inStreamで任意にメッセージを暗号化するかもしれません。 outStreamはMICとメッセージの両方を含むでしょう。
The MessageProp object is instantiated by the application and used to specify a QOP value which selects cryptographic algorithms, and a privacy service to optionally encrypt the message. The underlying mechanism that is used in the call may not be able to provide the privacy service. It sets the actual privacy service that it does
MessagePropオブジェクトは、アプリケーションで例示されて、任意にメッセージを暗号化するために暗号アルゴリズム、およびプライバシーサービスを選択するQOP値を指定するのに使用されます。 呼び出しに使用される発症機序はプライバシーサービスを提供できないかもしれません。 それはする実際のプライバシーサービスを設定します。
Kabat & Upadhyay Standards Track [Page 62] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[62ページ]。
provide in this MessageProp object which the caller should then query upon return. If the mechanism is not able to provide the requested QOP, it throws a GSSException with the BAD_QOP code.
次に訪問者がリターンのときに質問するべきであるこのMessagePropオブジェクトに供給してください。 メカニズムが要求されたQOPを提供できないなら、それはBAD_QOPコードでGSSExceptionを投げます。
Since some application-level protocols may wish to use tokens emitted by wrap to provide "secure framing", implementations should support the wrapping of zero-length messages.
いくつかのアプリケーションレベルプロトコルが包装によって放たれた、「安全な縁どり」を提供したトークンを使用したがっているかもしれないので、実装はゼロ・レングスメッセージのラッピングを支えるべきです。
The application will be responsible for sending the token to the peer.
アプリケーションはトークンを同輩に送るのに原因となるようになるでしょう。
Parameters:
パラメタ:
inStream Input stream containing the application data to be
protected.
保護されるべきアプリケーションデータを含んでいて、inStream Inputは流れます。
outStream The output stream to write the protected message to.
The application is responsible for sending this to the
other peer for processing in its unwrap method.
outStream、保護されたメッセージを書く出力ストリーム。 アプリケーションが処理のために中でもう片方の同輩にこれを送るのに原因となる、それ、メソッドを開けてください。
msgProp Instance of MessageProp that is used by the
application to set the desired QOP and privacy state.
Set the desired QOP to 0 to request the default QOP.
Upon return from this method, this object will contain
the the actual privacy state that was applied to the
message by the underlying mechanism.
必要なQOPとプライバシー状態を設定するのにアプリケーションで使用されるMessagePropのmsgProp Instance。 デフォルトQOPを要求する0に必要なQOPを設定してください。 このメソッドからのリターンでは、このオブジェクトは発症機序によってメッセージに適用された実際のプライバシー状態を含むでしょう。
6.4.12. unwrap
6.4.12. 開けてください。
public byte [] unwrap(byte[] inBuf, int offset, int len,
MessageProp msgProp) throws GSSException
[]が開ける公共のバイト(バイト[]inBuf、intオフセット、int len、MessageProp msgProp)はGSSExceptionを投げます。
Used by the peer application to process tokens generated with the wrap call. This call is equal in functionality to its stream counterpart. The method will return the message supplied in the peer application to the wrap call, verifying the embedded MIC.
同輩アプリケーションで、包装呼び出しで生成されたトークンを処理するのに使用されます。 この呼び出しは機能性においてストリーム対応者と等しいです。 メソッドは埋め込まれたMICについて確かめて、同輩アプリケーションで包装呼び出しに提供されたメッセージを返すでしょう。
The MessageProp object is instantiated by the application and is used by the underlying mechanism to return information to the caller such as the QOP, whether confidentiality was applied to the message, and other supplementary message state information.
MessagePropオブジェクトはアプリケーションで例示されて、発症機序によって使用されて、QOPや、秘密性がメッセージに適用されたか、そして、他の補っているメッセージ州の情報などの訪問者に情報を返します。
Since some application-level protocols may wish to use tokens emitted by wrap to provide "secure framing", implementations should support the wrapping and unwrapping of zero-length messages.
いくつかのアプリケーションレベルプロトコルが包装によって放たれた、「安全な縁どり」を提供したトークンを使用したがっているかもしれないので、実装はゼロ・レングスメッセージをラッピングと開けることを支えるべきです。
Kabat & Upadhyay Standards Track [Page 63] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[63ページ]。
Parameters:
パラメタ:
inBuf GSS-API wrap token received from peer.
inBuf GSS-API包装トークンは同輩から受信されました。
offset The offset within the inBuf where the token begins.
トークンが始まるinBufの中でオフセットを相殺してください。
len The length of the token within the inBuf (starting at
the offset).
inBuf(オフセットのときに、始める)の中のトークンの長さのlen。
msgProp Upon return from the method, this object will contain
the applied QOP, the privacy state of the message, and
supplementary information described in 4.12.3 stating
whether the token was a duplicate, old, out of
sequence or arriving after a gap.
メソッドからのmsgProp Uponリターン、このオブジェクトが適用されたQOP、メッセージ、および中で説明された補助情報のプライバシー状態を含む、4.12、.3論述、トークンは系列かギャップの後に到着するのからの古い写しであったかどうか
6.4.13. unwrap
6.4.13. 開けてください。
public void unwrap(InputStream inStream, OutputStream outStream,
MessageProp msgProp) throws GSSException
公共の空間は一投GSSExceptionを開けます(InputStream inStream、OutputStream outStream、MessageProp msgProp)。
Used by the peer application to process tokens generated with the wrap call. This call is equal in functionality to its byte array counterpart. It will produce the message supplied in the peer application to the wrap call, verifying the embedded MIC.
同輩アプリケーションで、包装呼び出しで生成されたトークンを処理するのに使用されます。 この呼び出しは機能性においてバイト配列対応者と等しいです。 それは埋め込まれたMICについて確かめて、同輩アプリケーションで包装呼び出しに提供されたメッセージを出すでしょう。
The MessageProp object is instantiated by the application and is used by the underlying mechanism to return information to the caller such as the QOP, whether confidentiality was applied to the message, and other supplementary message state information.
MessagePropオブジェクトはアプリケーションで例示されて、発症機序によって使用されて、QOPや、秘密性がメッセージに適用されたか、そして、他の補っているメッセージ州の情報などの訪問者に情報を返します。
Since some application-level protocols may wish to use tokens emitted by wrap to provide "secure framing", implementations should support the wrapping and unwrapping of zero-length messages.
いくつかのアプリケーションレベルプロトコルが包装によって放たれた、「安全な縁どり」を提供したトークンを使用したがっているかもしれないので、実装はゼロ・レングスメッセージをラッピングと開けることを支えるべきです。
Parameters:
パラメタ:
inStream Input stream containing the GSS-API wrap token
received from the peer.
同輩から受け取られたGSS-API包装トークンを含んでいて、inStream Inputは流れます。
outStream The output stream to write the application message to.
outStream、アプリケーションメッセージを書く出力ストリーム。
msgProp Upon return from the method, this object will contain
the applied QOP, the privacy state of the message, and
supplementary information described in 4.12.3 stating
whether the token was a duplicate, old, out of
sequence or arriving after a gap.
メソッドからのmsgProp Uponリターン、このオブジェクトが適用されたQOP、メッセージ、および中で説明された補助情報のプライバシー状態を含む、4.12、.3論述、トークンは系列かギャップの後に到着するのからの古い写しであったかどうか
Kabat & Upadhyay Standards Track [Page 64] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[64ページ]。
6.4.14. getMIC
6.4.14. getMIC
public byte[] getMIC(byte []inMsg, int offset, int len,
MessageProp msgProp) throws GSSException
公共のバイト[]getMIC(バイト[]inMsg、intオフセット、int len、MessageProp msgProp)はGSSExceptionを投げます。
Returns a token containing a cryptographic MIC for the supplied message, for transfer to the peer application. Unlike wrap, which encapsulates the user message in the returned token, only the message MIC is returned in the output token. This method is identical in functionality to its stream counterpart.
供給されたメッセージ、転送のために暗号のMICを含むトークンを同輩アプリケーションに返します。 包装と異なって、出力トークンでメッセージだけMICを返します。包装は返されたトークンにおけるユーザメッセージをカプセル化します。 ストリーム対応者にとって、このメソッドは機能性が同じです。
Note that privacy can only be applied through the wrap call.
包装呼び出しでプライバシーを適用できるだけであることに注意してください。
Since some application-level protocols may wish to use tokens emitted by getMIC to provide "secure framing", implementations should support derivation of MICs from zero-length messages.
いくつかのアプリケーションレベルプロトコルが「安全な縁どり」を提供するためにgetMICによって放たれたトークンを使用したがっているかもしれないので、実装はゼロ・レングスメッセージからMICsの派生をサポートするべきです。
Parameters:
パラメタ:
inMsg Message to generate MIC over.
inMsg Message、MICを生成するために。
offset The offset within the inMsg where the token begins.
トークンが始まるinMsgの中でオフセットを相殺してください。
len The length of the token within the inMsg (starting at
the offset).
inMsg(オフセットのときに、始める)の中のトークンの長さのlen。
msgProp Instance of MessageProp that is used by the
application to set the desired QOP. Set the desired
QOP to 0 in msgProp to request the default QOP.
Alternatively pass in "null" for msgProp to request
default QOP.
必要なQOPを設定するのにアプリケーションで使用されるMessagePropのmsgProp Instance。 0への必要なQOPをmsgPropにはめ込んで、デフォルトQOPを要求してください。 あるいはまた、「ヌル」で通って、msgPropはデフォルトQOPを要求してください。
6.4.15. getMIC
6.4.15. getMIC
public void getMIC(InputStream inStream, OutputStream outStream,
MessageProp msgProp) throws GSSException
公共の空のgetMIC(InputStream inStream、OutputStream outStream、MessageProp msgProp)はGSSExceptionを投げます。
Produces a token containing a cryptographic MIC for the supplied message, for transfer to the peer application. Unlike wrap, which encapsulates the user message in the returned token, only the message MIC is produced in the output token. This method is identical in functionality to its byte array counterpart.
供給されたメッセージ、同輩アプリケーションへの転送のために暗号のMICを含むトークンを生産します。 包装と異なって、メッセージだけMICは出力トークンで生産されます。包装は返されたトークンにおけるユーザメッセージをカプセル化します。 バイト配列対応者にとって、このメソッドは機能性が同じです。
Note that privacy can only be applied through the wrap call.
包装呼び出しでプライバシーを適用できるだけであることに注意してください。
Since some application-level protocols may wish to use tokens emitted by getMIC to provide "secure framing", implementations should support derivation of MICs from zero-length messages.
いくつかのアプリケーションレベルプロトコルが「安全な縁どり」を提供するためにgetMICによって放たれたトークンを使用したがっているかもしれないので、実装はゼロ・レングスメッセージからMICsの派生をサポートするべきです。
Kabat & Upadhyay Standards Track [Page 65] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[65ページ]。
Parameters:
パラメタ:
inStream inStream Input stream containing the message to
generate MIC over.
MICを生成するメッセージを含んでいて、inStream inStream Inputは流れます。
outStream outStream Output stream to write the GSS-API output
token to.
GSS-API出力トークンを書くoutStream outStream Outputストリーム。
msgProp Instance of MessageProp that is used by the
application to set the desired QOP. Set the desired
QOP to 0 in msgProp to request the default QOP.
Alternatively pass in "null" for msgProp to request
default QOP.
必要なQOPを設定するのにアプリケーションで使用されるMessagePropのmsgProp Instance。 0への必要なQOPをmsgPropにはめ込んで、デフォルトQOPを要求してください。 あるいはまた、「ヌル」で通って、msgPropはデフォルトQOPを要求してください。
6.4.16. verifyMIC
6.4.16. verifyMIC
public void verifyMIC(byte []inTok, int tokOffset, int tokLen,
byte[] inMsg, int msgOffset, int msgLen,
MessageProp msgProp) throws GSSException
公共の空のverifyMIC(バイト[]inTok、int tokOffset、int tokLen、バイト[]inMsg、int msgOffset、int msgLen、MessageProp msgProp)はGSSExceptionを投げます。
Verifies the cryptographic MIC, contained in the token parameter, over the supplied message. This method is equivalent in functionality to its stream counterpart.
供給されたメッセージに関してトークンパラメタに含まれた暗号のMICについて確かめます。 ストリーム対応者にとって、このメソッドは機能性で同等です。
The MessageProp object is instantiated by the application and is used by the underlying mechanism to return information to the caller such as the QOP indicating the strength of protection that was applied to the message and other supplementary message state information.
MessagePropオブジェクトはアプリケーションで例示されて、発症機序によって使用されて、メッセージに適用された保護と他の補っているメッセージ州の情報の強さを示すQOPなどの訪問者に情報を返します。
Since some application-level protocols may wish to use tokens emitted by getMIC to provide "secure framing", implementations should support the calculation and verification of MICs over zero-length messages.
いくつかのアプリケーションレベルプロトコルが「安全な縁どり」を提供するためにgetMICによって放たれたトークンを使用したがっているかもしれないので、実装はゼロ・レングスメッセージの上でMICsの計算と検証をサポートするべきです。
Parameters:
パラメタ:
inTok Token generated by peer's getMIC method.
inTok Tokenは、同輩のものでgetMICがメソッドであると生成しました。
tokOffset The offset within the inTok where the token begins.
tokOffset、トークンが始まるinTokの中のオフセット。
tokLen The length of the token within the inTok (starting at
the offset).
inTok(オフセットのときに、始める)の中のトークンの長さのtokLen。
inMsg Application message to verify the cryptographic MIC
over.
暗号のMICについて確かめるinMsg Applicationメッセージ。
msgOffset The offset within the inMsg where the message begins.
msgOffset、メッセージが始まるinMsgの中のオフセット。
Kabat & Upadhyay Standards Track [Page 66] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[66ページ]。
msgLen The length of the message within the inMsg (starting
at the offset).
inMsg(オフセットのときに、始める)の中のメッセージの長さのmsgLen。
msgProp Upon return from the method, this object will contain
the applied QOP and supplementary information
described in 4.12.3 stating whether the token was a
duplicate, old, out of sequence or arriving after a
gap. The confidentiality state will be set to
"false".
メソッドからのmsgProp Uponリターン、このオブジェクトが中で説明された適用されたQOPと補助情報を含む、4.12、.3論述、トークンは系列かギャップの後に到着するのからの古い写しであったかどうか 秘密性状態は「誤っていること」に設定されるでしょう。
6.4.17. verifyMIC
6.4.17. verifyMIC
public void verifyMIC(InputStream tokStream, InputStream msgStream,
MessageProp msgProp) throws GSSException
公共の空のverifyMIC(InputStream tokStream、InputStream msgStream、MessageProp msgProp)はGSSExceptionを投げます。
Verifies the cryptographic MIC, contained in the token parameter, over the supplied message. This method is equivalent in functionality to its byte array counterpart.
供給されたメッセージに関してトークンパラメタに含まれた暗号のMICについて確かめます。 バイト配列対応者にとって、このメソッドは機能性で同等です。
The MessageProp object is instantiated by the application and is used by the underlying mechanism to return information to the caller such as the QOP indicating the strength of protection that was applied to the message and other supplementary message state information.
MessagePropオブジェクトはアプリケーションで例示されて、発症機序によって使用されて、メッセージに適用された保護と他の補っているメッセージ州の情報の強さを示すQOPなどの訪問者に情報を返します。
Since some application-level protocols may wish to use tokens emitted by getMIC to provide "secure framing", implementations should support the calculation and verification of MICs over zero-length messages.
いくつかのアプリケーションレベルプロトコルが「安全な縁どり」を提供するためにgetMICによって放たれたトークンを使用したがっているかもしれないので、実装はゼロ・レングスメッセージの上でMICsの計算と検証をサポートするべきです。
Parameters:
パラメタ:
tokStream Input stream containing the token generated by peer's
getMIC method.
同輩のgetMICメソッドで生成されたトークンを含んでいて、tokStream Inputは流れます。
msgStream Input stream containing the application message to
verify the cryptographic MIC over.
暗号のMICについて確かめるアプリケーションメッセージを含んでいて、msgStream Inputは流れます。
msgProp Upon return from the method, this object will contain
the applied QOP and supplementary information
described in 4.12.3 stating whether the token was a
duplicate, old, out of sequence or arriving after a
gap. The confidentiality state will be set to
"false".
メソッドからのmsgProp Uponリターン、このオブジェクトが中で説明された適用されたQOPと補助情報を含む、4.12、.3論述、トークンは系列かギャップの後に到着するのからの古い写しであったかどうか 秘密性状態は「誤っていること」に設定されるでしょう。
Kabat & Upadhyay Standards Track [Page 67] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[67ページ]。
6.4.18. export
6.4.18. 輸出
public byte [] export() throws GSSException
公共のバイト[]輸出()はGSSExceptionを投げます。
Provided to support the sharing of work between multiple processes. This routine will typically be used by the context-acceptor, in an application where a single process receives incoming connection requests and accepts security contexts over them, then passes the established context to one or more other processes for message exchange.
複数のプロセスの間の仕事の共有をサポートするために、提供します。 このルーチンは文脈アクセプタによって通常使用されるでしょう、単一のプロセスが接続要求要求を受け取って、セキュリティ文脈をそれらの上に受け入れて、次に交換処理のために他の1つ以上のプロセスに確立した関係を通過するアプリケーションで。
This method deactivates the security context and creates an interprocess token which, when passed to the byte array constructor of the GSSContext interface in another process, will re-activate the context in the second process. Only a single instantiation of a given context may be active at any one time; a subsequent attempt by a context exporter to access the exported security context will fail.
このメソッドは、セキュリティ文脈を非活性化して、別のプロセスでGSSContextインタフェースのバイト配列建設者に渡されると2番目のプロセスで文脈を現役に戻すインタプロセストークンを作成します。 与えられた文脈のただ一つの具体化だけがいかなる時も、アクティブであるかもしれません。 エクスポートしているセキュリティ文脈にアクセスする文脈輸出業者によるその後の試みは失敗するでしょう。
The implementation may constrain the set of processes by which the interprocess token may be imported, either as a function of local security policy, or as a result of implementation decisions. For example, some implementations may constrain contexts to be passed only between processes that run under the same account, or which are part of the same process group.
実装はインタプロセストークンがローカルの安全保障政策の機能、または実装決定の結果、インポートされるかもしれないプロセスのセットを抑制するかもしれません。 例えば、いくつかの実装が、文脈が同じアカウントで実行されるか、同じプロセスグループの一部である唯一のプロセスの間で通過されるのを抑制するかもしれません。
The interprocess token may contain security-sensitive information (for example cryptographic keys). While mechanisms are encouraged to either avoid placing such sensitive information within interprocess tokens, or to encrypt the token before returning it to the application, in a typical GSS-API implementation this may not be possible. Thus the application must take care to protect the interprocess token, and ensure that any process to which the token is transferred is trustworthy.
インタプロセストークンはセキュリティ機密情報(例えば、暗号のキー)を含むかもしれません。 メカニズムがインタプロセストークンの中にそのような機密情報を置くのを避けるか、またはそれをアプリケーションに返す前にトークンを暗号化するよう奨励される間、典型的なGSS-API実行では、これは可能でないかもしれません。 したがって、アプリケーションは、インタプロセストークンを保護するために注意して、トークンがわたっているどんなプロセスも信頼できるのを確実にしなければなりません。
6.4.19. requestMutualAuth
6.4.19. requestMutualAuth
public void requestMutualAuth(boolean state) throws GSSException
公共の空のrequestMutualAuth(論理演算子状態)はGSSExceptionを投げます。
Sets the request state of the mutual authentication flag for the context. This method is only valid before the context creation process begins and only for the initiator.
互いの認証旗の要求状態を文脈に設定します。 文脈作成プロセスが始まる前に有効であるだけであり、創始者のためだけにこのメソッド。
Parameters:
パラメタ:
state Boolean representing if mutual authentication should
be requested during context establishment.
ブール表していますが、互いの認証が文脈設立の間要求されているべきであると述べてください。
Kabat & Upadhyay Standards Track [Page 68] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[68ページ]。
6.4.20. requestReplayDet
6.4.20. requestReplayDet
public void requestReplayDet(boolean state) throws GSSException
公共の空のrequestReplayDet(論理演算子状態)はGSSExceptionを投げます。
Sets the request state of the replay detection service for the context. This method is only valid before the context creation process begins and only for the initiator.
文脈のための再生検出サービスの要求状態を設定します。 文脈作成プロセスが始まる前に有効であるだけであり、創始者のためだけにこのメソッド。
Parameters:
パラメタ:
state Boolean representing if replay detection is desired
over the established context.
再生検出が確立した関係の上で望まれているなら、ブール表すことを述べてください。
6.4.21. requestSequenceDet
6.4.21. requestSequenceDet
public void requestSequenceDet(boolean state) throws GSSException
公共の空のrequestSequenceDet(論理演算子状態)はGSSExceptionを投げます。
Sets the request state for the sequence checking service of the context. This method is only valid before the context creation process begins and only for the initiator.
文脈のサービスをチェックする系列に要求状態を設定します。 文脈作成プロセスが始まる前に有効であるだけであり、創始者のためだけにこのメソッド。
Parameters:
パラメタ:
state Boolean representing if sequence detection is desired
over the established context.
系列検出が確立した関係の上で望まれているなら、ブール表すことを述べてください。
6.4.22. requestCredDeleg
6.4.22. requestCredDeleg
public void requestCredDeleg(boolean state) throws GSSException
公共の空のrequestCredDeleg(論理演算子状態)はGSSExceptionを投げます。
Sets the request state for the credential delegation flag for the context. This method is only valid before the context creation process begins and only for the initiator.
文脈のために資格証明委譲旗に要求状態を設定します。 文脈作成プロセスが始まる前に有効であるだけであり、創始者のためだけにこのメソッド。
Parameters:
パラメタ:
state Boolean representing if credential delegation is
desired.
資格証明委譲が望まれているなら、ブール表すことを述べてください。
6.4.23. requestAnonymity
6.4.23. requestAnonymity
public void requestAnonymity(boolean state) throws GSSException
公共の空のrequestAnonymity(論理演算子状態)はGSSExceptionを投げます。
Requests anonymous support over the context. This method is only valid before the context creation process begins and only for the initiator.
文脈の上の匿名のサポートを要求します。 文脈作成プロセスが始まる前に有効であるだけであり、創始者のためだけにこのメソッド。
Kabat & Upadhyay Standards Track [Page 69] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[69ページ]。
Parameters:
パラメタ:
state Boolean representing if anonymity support is
requested.
匿名サポートが要求されるなら、ブール表すことを述べてください。
6.4.24. requestConf
6.4.24. requestConf
public void requestConf(boolean state) throws GSSException
公共の空のrequestConf(論理演算子状態)はGSSExceptionを投げます。
Requests that confidentiality service be available over the context. This method is only valid before the context creation process begins and only for the initiator.
秘密性サービスが文脈の上で利用可能であるという要求。 文脈作成プロセスが始まる前に有効であるだけであり、創始者のためだけにこのメソッド。
Parameters:
パラメタ:
state Boolean indicating if confidentiality services are to
be requested for the context.
秘密性サービスが文脈のために要求されていることであるならブール表示を述べてください。
6.4.25. requestInteg
6.4.25. requestInteg
public void requestInteg(boolean state) throws GSSException
公共の空のrequestInteg(論理演算子状態)はGSSExceptionを投げます。
Requests that integrity services be available over the context. This method is only valid before the context creation process begins and only for the initiator.
保全サービスが文脈の上で利用可能であるという要求。 文脈作成プロセスが始まる前に有効であるだけであり、創始者のためだけにこのメソッド。
Parameters:
パラメタ:
state Boolean indicating if integrity services are to be
requested for the context.
保全サービスが文脈のために要求されていることであるならブール表示を述べてください。
6.4.26. requestLifetime
6.4.26. requestLifetime
public void requestLifetime(int lifetime) throws GSSException
公共の空のrequestLifetime(int生涯)はGSSExceptionを投げます。
Sets the desired lifetime for the context in seconds. This method is only valid before the context creation process begins and only for the initiator. Use GSSContext.INDEFINITE_LIFETIME and GSSContext.DEFAULT_LIFETIME to request indefinite or default context lifetime.
秒に必要な生涯を文脈に決めます。 文脈作成プロセスが始まる前に有効であるだけであり、創始者のためだけにこのメソッド。 GSSContext.INDEFINITE_LIFETIMEとGSSContext.DEFAULT_LIFETIMEを使用して、無期かデフォルト文脈生涯を要求してください。
Parameters:
パラメタ:
lifetime The desired context lifetime in seconds.
秒の必要な文脈生涯生涯。
Kabat & Upadhyay Standards Track [Page 70] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[70ページ]。
6.4.27. setChannelBinding
6.4.27. setChannelBinding
public void setChannelBinding(ChannelBinding cb) throws GSSException
公共の空のsetChannelBinding(ChannelBinding cb)はGSSExceptionを投げます。
Sets the channel bindings to be used during context establishment. This method is only valid before the context creation process begins.
チャンネル結合に文脈設立の間、使用されるように設定します。 文脈作成プロセスが始まる前にこのメソッドは有効であるだけです。
Parameters:
パラメタ:
cb Channel bindings to be used.
使用されるべきcb Channel結合。
6.4.28. getCredDelegState
6.4.28. getCredDelegState
public boolean getCredDelegState()
公共の論理演算子getCredDelegState()
Returns the state of the delegated credentials for the context. When issued before context establishment is completed or when the isProtReady method returns "false", it returns the desired state, otherwise it will indicate the actual state over the established context.
文脈のために代表として派遣された資格証明書の状態を返します。 isProtReadyメソッドが「虚偽で」戻るとき、文脈設立が終了しているか、または必要な状態を返す前に発行されると、さもなければ、それは確立した関係の上に実際の状態を示すでしょう。
6.4.29. getMutualAuthState
6.4.29. getMutualAuthState
public boolean getMutualAuthState()
公共の論理演算子getMutualAuthState()
Returns the state of the mutual authentication option for the context. When issued before context establishment completes or when the isProtReady method returns "false", it returns the desired state, otherwise it will indicate the actual state over the established context.
文脈のための互いの認証オプションの事情を返します。 以前発行された文脈設立が完成するか、isProtReadyメソッドが「虚偽で」戻って、または必要な状態を返す時、さもなければ、それは確立した関係の上に実際の状態を示すでしょう。
6.4.30. getReplayDetState
6.4.30. getReplayDetState
public boolean getReplayDetState()
公共の論理演算子getReplayDetState()
Returns the state of the replay detection option for the context. When issued before context establishment completes or when the isProtReady method returns "false", it returns the desired state, otherwise it will indicate the actual state over the established context.
文脈のための再生検出オプションの事情を返します。 以前発行された文脈設立が完成するか、isProtReadyメソッドが「虚偽で」戻って、または必要な状態を返す時、さもなければ、それは確立した関係の上に実際の状態を示すでしょう。
6.4.31. getSequenceDetState
6.4.31. getSequenceDetState
public boolean getSequenceDetState()
公共の論理演算子getSequenceDetState()
Returns the state of the sequence detection option for the context. When issued before context establishment completes or when the isProtReady method returns "false", it returns the desired state,
文脈のための系列検出オプションの事情を返します。 以前発行された文脈設立が完成するか、isProtReadyメソッドが「虚偽で」戻って、またはそれが必要な状態を返す時
Kabat & Upadhyay Standards Track [Page 71] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[71ページ]。
otherwise it will indicate the actual state over the established context.
さもなければ、それは確立した関係の上に実際の状態を示すでしょう。
6.4.32. getAnonymityState
6.4.32. getAnonymityState
public boolean getAnonymityState()
公共の論理演算子getAnonymityState()
Returns "true" if this is an anonymous context. When issued before context establishment completes or when the isProtReady method returns "false", it returns the desired state, otherwise it will indicate the actual state over the established context.
「本当に、」これが匿名の文脈であるなら、戻ります。 以前発行された文脈設立が完成するか、isProtReadyメソッドが「虚偽で」戻って、または必要な状態を返す時、さもなければ、それは確立した関係の上に実際の状態を示すでしょう。
6.4.33. isTransferable
6.4.33. isTransferable
public boolean isTransferable() throws GSSException
公共の論理演算子isTransferable()はGSSExceptionを投げます。
Returns "true" if the context is transferable to other processes through the use of the export method. This call is only valid on fully established contexts.
「本当に、」文脈が輸出メソッドの使用で他のプロセスに移転可能であるなら、戻ります。 この呼び出しは単に完全に確立した関係で有効です。
6.4.34. isProtReady
6.4.34. isProtReady
public boolean isProtReady()
公共の論理演算子isProtReady()
Returns "true" if the per message operations can be applied over the context. Some mechanisms may allow the usage of per-message operations before the context is fully established. This will also indicate that the get methods will return actual context state characteristics instead of the desired ones.
「本当に」戻る、メッセージに従って、文脈の上に操作を適用できます。 文脈が完全に確立される前にいくつかのメカニズムが1メッセージあたりの操作の用法を許容するかもしれません。 また、これがそれを示す、意志が必要なものの代わりに実際の文脈州の特性を返すメソッドを得てください。
6.4.35. getConfState
6.4.35. getConfState
public boolean getConfState()
公共の論理演算子getConfState()
Returns the confidentiality service state over the context. When issued before context establishment completes or when the isProtReady method returns "false", it returns the desired state, otherwise it will indicate the actual state over the established context.
秘密性サービス状態を文脈の上に返します。 以前発行された文脈設立が完成するか、isProtReadyメソッドが「虚偽で」戻って、または必要な状態を返す時、さもなければ、それは確立した関係の上に実際の状態を示すでしょう。
6.4.36. getIntegState
6.4.36. getIntegState
public boolean getIntegState()
公共の論理演算子getIntegState()
Returns the integrity service state over the context. When issued before context establishment completes or when the isProtReady method returns "false", it returns the desired state, otherwise it will indicate the actual state over the established context.
保全サービス状態を文脈の上に返します。 以前発行された文脈設立が完成するか、isProtReadyメソッドが「虚偽で」戻って、または必要な状態を返す時、さもなければ、それは確立した関係の上に実際の状態を示すでしょう。
Kabat & Upadhyay Standards Track [Page 72] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[72ページ]。
6.4.37. getLifetime
6.4.37. getLifetime
public int getLifetime()
公共のint getLifetime()
Returns the context lifetime in seconds. When issued before context establishment completes or when the isProtReady method returns "false", it returns the desired lifetime, otherwise it will indicate the remaining lifetime for the context.
秒に文脈生涯を返します。 以前発行された文脈設立が完成するか、isProtReadyメソッドが「虚偽で」戻って、または必要な生涯を返す時、さもなければ、それは文脈のために残っている生涯を示すでしょう。
6.4.38. getSrcName
6.4.38. getSrcName
public GSSName getSrcName() throws GSSException
公共のGSSName getSrcName()はGSSExceptionを投げます。
Returns the name of the context initiator. This call is valid only after the context is fully established or the isProtReady method returns "true". It is guaranteed to return an MN.
文脈創始者の名前を返します。 文脈が完全に確立された後にだけこの呼び出しが有効であるか、またはisProtReadyメソッドは「本当に」戻ります。 ミネソタを返すのは保証されています。
6.4.39. getTargName
6.4.39. getTargName
public GSSName getTargName() throws GSSException
公共のGSSName getTargName()はGSSExceptionを投げます。
Returns the name of the context target (acceptor). This call is valid only after the context is fully established or the isProtReady method returns "true". It is guaranteed to return an MN.
文脈目標(アクセプタ)の名前を返します。 文脈が完全に確立された後にだけこの呼び出しが有効であるか、またはisProtReadyメソッドは「本当に」戻ります。 ミネソタを返すのは保証されています。
6.4.40. getMech
6.4.40. getMech
public Oid getMech() throws GSSException
公共のOid getMech()はGSSExceptionを投げます。
Returns the mechanism oid for this context. This method may be called before the context is fully established, but the mechanism returned may change on successive calls in negotiated mechanism case.
この文脈のためにメカニズムoidを返します。 文脈が完全に確立される前にこのメソッドは呼ばれるかもしれませんが、返されたメカニズムは交渉されたメカニズム場合における連続した呼び出しのときに変化するかもしれません。
6.4.41. getDelegCred
6.4.41. getDelegCred
public GSSCredential getDelegCred() throws GSSException
公共のGSSCredential getDelegCred()はGSSExceptionを投げます。
Returns the delegated credential object on the acceptor's side. To check for availability of delegated credentials call getDelegCredState. This call is only valid on fully established contexts.
アクセプタの側の上の代表として派遣された資格証明オブジェクトを返します。 代表として派遣された資格証明書の有用性がないかどうかチェックするには、getDelegCredStateに電話をしてください。 この呼び出しは単に完全に確立した関係で有効です。
6.4.42. isInitiator
6.4.42. isInitiator
public boolean isInitiator() throws GSSException
公共の論理演算子isInitiator()はGSSExceptionを投げます。
Returns "true" if this is the initiator of the context. This call is only valid after the context creation process has started.
「本当に、」これが文脈の創始者であるなら、戻ります。 文脈作成プロセスが始まった後にこの呼び出しは有効であるだけです。
Kabat & Upadhyay Standards Track [Page 73] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[73ページ]。
6.5. public class MessageProp
6.5. 公立のクラスMessageProp
This is a utility class used within the per-message GSSContext methods to convey per-message properties.
これは1メッセージあたりの特性を伝える1メッセージあたりのGSSContextメソッドの中で使用されたユーティリティのクラスです。
When used with the GSSContext interface's wrap and getMIC methods, an instance of this class is used to indicate the desired QOP and to request if confidentiality services are to be applied to caller supplied data (wrap only). To request default QOP, the value of 0 should be used for QOP.
GSSContextインタフェースの包装とgetMICメソッドで使用されると、このクラスのインスタンスは、必要なQOPを示して、訪問者に、(包装専用)が秘密性サービスが適用されていることであるなら資料を提供していたよう要求するのに使用されます。 デフォルトQOPを要求するために、0の値はQOPに使用されるべきです。
When used with the unwrap and verifyMIC methods of the GSSContext interface, an instance of this class will be used to indicate the applied QOP and confidentiality services over the supplied message. In the case of verifyMIC, the confidentiality state will always be "false". Upon return from these methods, this object will also contain any supplementary status values applicable to the processed token. The supplementary status values can indicate old tokens, out of sequence tokens, gap tokens or duplicate tokens.
開けてください。そうすれば、GSSContextインタフェースのverifyMICメソッド、このクラスのインスタンスは開けるでしょう。使用されている、使用されて、供給されたメッセージの上の適用されたQOPと秘密性サービスを示してください。 verifyMICの場合では、秘密性状態はいつも「誤っているでしょう」。 また、これらのメソッドからのリターンでは、このオブジェクトは処理トークンに適切などんな補っている状態値も含むでしょう。 補っている状態値は古いトークン、順序が狂ってトークン、ギャップトークンまたは写しトークンを示すことができます。
6.5.1. Constructors
6.5.1. 建設者
public MessageProp(boolean privState)
公共のMessageProp(論理演算子privState)
Constructor which sets QOP to 0 indicating that the default QOP is requested.
デフォルトQOPが要求されているのを示す0にQOPを設定する建設者。
Parameters:
パラメタ:
privState The desired privacy state. "true" for privacy and
"false" for integrity only.
プライバシーが述べる必要なprivState。 プライバシーに「本当で」保全だけにおいて「誤っています」。
public MessageProp(int qop, boolean privState)
公共のMessageProp(int qop、論理演算子privState)
Constructor which sets the values for the qop and privacy state.
どれがqopに値を設定するか、そして、プライバシーが述べる建設者。
Parameters:
パラメタ:
qop The desired QOP. Use 0 to request a default QOP.
必要QOPのqop。 0を使用して、デフォルトQOPを要求してください。
privState The desired privacy state. "true" for privacy and
"false" for integrity only.
プライバシーが述べる必要なprivState。 プライバシーに「本当で」保全だけにおいて「誤っています」。
Kabat & Upadhyay Standards Track [Page 74] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[74ページ]。
6.5.2. getQOP
6.5.2. getQOP
public int getQOP()
公共のint getQOP()
Retrieves the QOP value.
QOP値を検索します。
6.5.3. getPrivacy
6.5.3. getPrivacy
public boolean getPrivacy()
公共の論理演算子getPrivacy()
Retrieves the privacy state.
プライバシー状態を検索します。
6.5.4. getMinorStatus
6.5.4. getMinorStatus
public int getMinorStatus()
公共のint getMinorStatus()
Retrieves the minor status that the underlying mechanism might have set.
発症機序が設定したかもしれない小さい方の状態を検索します。
6.5.5. getMinorString
6.5.5. getMinorString
public String getMinorString()
公共のString getMinorString()
Returns a string explaining the mechanism specific error code. null will be returned when no mechanism error code has been set.
メカニズムエラーコードが全く設定されていないとき. ヌルが返されるメカニズムの特定のエラーコードがわかるストリングを返します。
6.5.6. setQOP
6.5.6. setQOP
public void setQOP(int qopVal)
公共の空のsetQOP(int qopVal)
Sets the QOP value.
QOPが評価するセット。
Parameters:
パラメタ:
qopVal The QOP value to be set. Use 0 to request a default
QOP value.
qopVal QOPは、設定されるのを評価します。 0を使用して、デフォルトQOP価値を要求してください。
6.5.7. setPrivacy
6.5.7. setPrivacy
public void setPrivacy(boolean privState)
公共の空のsetPrivacy(論理演算子privState)
Sets the privacy state.
プライバシー状態を設定します。
Parameters:
パラメタ:
privState The privacy state to set.
privState、設定するプライバシー状態。
Kabat & Upadhyay Standards Track [Page 75] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[75ページ]。
6.5.8. isDuplicateToken
6.5.8. isDuplicateToken
public boolean isDuplicateToken()
公共の論理演算子isDuplicateToken()
Returns "true" if this is a duplicate of an earlier token.
「本当に、」これが以前のトークンの写しであるなら、戻ります。
6.5.9. isOldToken
6.5.9. isOldToken
public boolean isOldToken()
公共の論理演算子isOldToken()
Returns "true" if the token's validity period has expired.
「本当に、」トークンの有効期間が期限が切れたなら、戻ります。
6.5.10. isUnseqToken
6.5.10. isUnseqToken
public boolean isUnseqToken()
公共の論理演算子isUnseqToken()
Returns "true" if a later token has already been processed.
「本当に、」既に後のトークンを処理してあるなら、戻ります。
6.5.11. isGapToken
6.5.11. isGapToken
public boolean isGapToken()
公共の論理演算子isGapToken()
Returns "true" if an expected per-message token was not received.
「本当に、」1メッセージあたり1つの予想されたトークンが受け取られなかったなら、戻ります。
6.5.12. setSupplementaryStates
6.5.12. setSupplementaryStates
public void setSupplementaryStates(boolean duplicate,
boolean old, boolean unseq, boolean gap,
int minorStatus, String minorString)
公共の空のsetSupplementaryStates(論理演算子写し、論理演算子の古くて、論理演算子unseqな論理演算子ギャップ、int minorStatus、String minorString)
This method sets the state for the supplementary information flags and the minor status in MessageProp. It is not used by the application but by the GSS implementation to return this information to the caller of a per-message context method.
このメソッドは補っている情報フラグとMessagePropの小さい方の状態に状態を設定します。 それはアプリケーションで使用されるのではなく、1メッセージの文脈あたり1つのメソッドの訪問者にこの情報を返すGSS実装によって使用されます。
Parameters:
パラメタ:
duplicate true if the token was a duplicate of an earlier token,
false otherwise
そうでなければ、本当に、トークンが虚偽以前のトークンの写しであったなら、コピーします。
old true if the token's validity period has expired, false
otherwise
旧、そうでなければ、本当に、トークンであるなら、有効期間は虚偽で期限が切れました。
unseq true if a later token has already been processed,
false otherwise
本当に、後のトークンが既にあったなら、別の方法で虚偽で処理されて、unseqします。
gap true if one or more predecessor tokens have not yet
been successfully processed, false otherwise
ギャップ、本当に、そうでなければ、より多くの前任者トークンは、1であるなら、まだ首尾よく処理されていて、誤っていません。
Kabat & Upadhyay Standards Track [Page 76] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[76ページ]。
minorStatus the integer minor status code that the underlying
mechanism wants to set
minorStatusは発症機序がセットしたがっているさ細な整数ステータスコードです。
minorString the textual representation of the minorStatus
value
minorStatus価値の原文の表現をminorStringします。
6.6. public class ChannelBinding
6.6. 公立のクラスChannelBinding
The GSS-API accommodates the concept of caller-provided channel binding information. Channel bindings are used to strengthen the quality with which peer entity authentication is provided during context establishment. They enable the GSS-API callers to bind the establishment of the security context to relevant characteristics like addresses or to application specific data.
GSS-APIは情報を縛る訪問者によって提供されたチャンネルの概念に対応します。 チャンネル結合は、同輩実体認証が文脈設立の間に提供される品質を強化するのに使用されます。 彼らは、GSS-API訪問者がアドレスのような関連特性、または、アプリケーションの特定のデータにセキュリティ文脈の確立を縛るのを可能にします。
The caller initiating the security context must determine the appropriate channel binding values to set in the GSSContext object. The acceptor must provide an identical binding in order to validate that received tokens possess correct channel-related characteristics.
セキュリティ文脈を開始する訪問者は、値を縛る適切なチャンネルがGSSContextオブジェクトにセットすると決心しなければなりません。 必須がその容認されたトークンを有効にするために同じ結合を提供するアクセプタは正しいチャンネル関連の特性を持っています。
Use of channel bindings is optional in GSS-API. Since channel- binding information may be transmitted in context establishment tokens, applications should therefore not use confidential data as channel-binding components.
チャンネル結合の使用はGSS-APIで任意です。 チャンネルの拘束力がある情報が文脈設立トークンで伝えられるかもしれないので、したがって、アプリケーションはチャンネルを拘束力があるコンポーネントとして秘密のデータを使用するべきではありません。
6.6.1. Constructors
6.6.1. 建設者
public ChannelBinding(InetAddress initAddr, InetAddress acceptAddr,
byte[] appData)
公共のChannelBinding(InetAddress initAddr、InetAddress acceptAddr、バイト[]appData)
Create a ChannelBinding object with user supplied address information and data. "null" values can be used for any fields which the application does not want to specify.
アドレス情報とデータを提供するユーザでChannelBindingオブジェクトを作成してください。 アプリケーションが指定したがっていないどんな分野にも「ヌル」の値を使用できます。
Parameters:
パラメタ:
initAddr The address of the context initiator. "null" value
can be supplied to indicate that the application does
not want to set this value.
initAddr、文脈創始者のアドレス。 アプリケーションがこの値を設定したがっていないのを示すために「ヌル」の値を供給できます。
acceptAddrThe address of the context acceptor. "null" value can
be supplied to indicate that the application does not
want to set this value.
文脈アクセプタのacceptAddrTheアドレス。 アプリケーションがこの値を設定したがっていないのを示すために「ヌル」の値を供給できます。
appData Application supplied data to be used as part of the
channel bindings. "null" value can be supplied to
indicate that the application does not want to set
this value.
appData Applicationは、チャンネル結合の一部として使用されるために資料を提供しました。 アプリケーションがこの値を設定したがっていないのを示すために「ヌル」の値を供給できます。
Kabat & Upadhyay Standards Track [Page 77] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[77ページ]。
public ChannelBinding(byte[] appData)
公共のChannelBinding(バイト[]appData)
Creates a ChannelBinding object without any addressing information.
少しもアドレス指定情報なしでChannelBindingオブジェクトを作成します。
Parameters:
パラメタ:
appData Application supplied data to be used as part of the
channel bindings.
appData Applicationは、チャンネル結合の一部として使用されるために資料を提供しました。
6.6.2. getInitiatorAddress
6.6.2. getInitiatorAddress
public InetAddress getInitiatorAddress()
公共のInetAddress getInitiatorAddress()
Returns the initiator's address for this channel binding. "null" is returned if the address has not been set.
このチャンネル結合のための創始者のアドレスを返します。 アドレスを設定していないなら、「ヌル」を返します。
6.6.3. getAcceptorAddress
6.6.3. getAcceptorAddress
public InetAddress getAcceptorAddress()
公共のInetAddress getAcceptorAddress()
Returns the acceptor's address for this channel binding. "null" is returned if the address has not been set.
このチャンネル結合のためのアクセプタのアドレスを返します。 アドレスを設定していないなら、「ヌル」を返します。
6.6.4. getApplicationData
6.6.4. getApplicationData
public byte[] getApplicationData()
公共のバイト[]getApplicationData()
Returns application data being used as part of the ChannelBinding. "null" is returned if no application data has been specified for the channel binding.
ChannelBindingの一部として使用されるアプリケーションデータを返します。 チャンネル結合にアプリケーションデータを全く指定していないなら、「ヌル」を返します。
6.6.5. equals
6.6.5. 同輩
public boolean equals(Object obj)
公共の論理演算子同輩(オブジェクトobj)
Returns "true" if two channel bindings match. (Note that the Java language specification requires that two objects that are equal according to the equals(Object) method must return the same integer result when the hashCode() method is called on them.)
「本当に、」2つのチャンネル結合が合っているなら、戻ります。 (ジャバ言語仕様が、hashCode()メソッドが彼らの上に呼ばれるとき、2個のメソッドが同じ整数に返さなければならない同輩(オブジェクト)によると、等しいオブジェクトが結果として生じるのを必要とすることに注意してください。)
Parameters:
パラメタ:
obj Another channel binding to compare with.
obj Anotherは比較する結合を向けます。
Kabat & Upadhyay Standards Track [Page 78] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[78ページ]。
6.7. public class Oid
6.7. 公立のクラスOid
This class represents Universal Object Identifiers (Oids) and their associated operations.
このクラスはUniversal Object Identifiers(Oids)と彼らの関連操作を表します。
Oids are hierarchically globally-interpretable identifiers used within the GSS-API framework to identify mechanisms and name formats.
Oidsによるグローバルに解明できる識別子がメカニズムと名前形式を特定するのに中で階層的では、GSS-APIフレームワークを使用したということです。
The structure and encoding of Oids is defined in ISOIEC-8824 and ISOIEC-8825. For example the Oid representation of Kerberos V5 mechanism is "1.2.840.113554.1.2.2"
Oidsの構造とコード化はISOIEC-8824とISOIEC-8825で定義されます。 例えば、ケルベロスV5メカニズムのOid表現がそうである、「1.2 .840 .113554 .1 .2 0.2インチ」
The GSSName name class contains public static Oid objects representing the standard name types defined in GSS-API.
クラスというGSSName名はタイプというGSS-APIで定義された標準の名前を表す公共の静的なOidオブジェクトを含んでいます。
6.7.1. Constructors
6.7.1. 建設者
public Oid(String strOid) throws GSSException
公共のOid(ストリングstrOid)はGSSExceptionを投げます。
Creates an Oid object from a string representation of its integer components (e.g. "1.2.840.113554.1.2.2").
整数成分のストリング表現からOidオブジェクトを作成する、(例えば、「1.2 .840 .113554 .1 .2 0.2インチ)、」
Parameters:
パラメタ:
strOid The string representation for the oid.
strOid、oidのストリング表現。
public Oid(InputStream derOid) throws GSSException
公共のOid(InputStream derOid)はGSSExceptionを投げます。
Creates an Oid object from its DER encoding. This refers to the full encoding including tag and length. The structure and encoding of Oids is defined in ISOIEC-8824 and ISOIEC-8825. This method is identical in functionality to its byte array counterpart.
DERコード化からOidオブジェクトを作成します。 タグと長さを含んでいて、これは完全なコード化を示します。 Oidsの構造とコード化はISOIEC-8824とISOIEC-8825で定義されます。 バイト配列対応者にとって、このメソッドは機能性が同じです。
Parameters:
パラメタ:
derOid Stream containing the DER encoded oid.
DERを含むderOid Streamがoidをコード化しました。
public Oid(byte[] DEROid) throws GSSException
公共のOid(バイト[]DEROid)はGSSExceptionを投げます。
Creates an Oid object from its DER encoding. This refers to the full encoding including tag and length. The structure and encoding of Oids is defined in ISOIEC-8824 and ISOIEC-8825. This method is identical in functionality to its byte array counterpart.
DERコード化からOidオブジェクトを作成します。 タグと長さを含んでいて、これは完全なコード化を示します。 Oidsの構造とコード化はISOIEC-8824とISOIEC-8825で定義されます。 バイト配列対応者にとって、このメソッドは機能性が同じです。
Parameters:
パラメタ:
derOid Byte array storing a DER encoded oid.
DERを保存するderOid Byte配列がoidをコード化しました。
Kabat & Upadhyay Standards Track [Page 79] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[79ページ]。
6.7.2. toString
6.7.2. toString
public String toString()
公共のString toString()
Returns a string representation of the oid's integer components in dot separated notation (e.g. "1.2.840.113554.1.2.2").
oidの整数成分のストリング表現が中に点を打たせるリターンが記法を切り離した、(例えば、「1.2 .840 .113554 .1 .2 0.2インチ)、」
6.7.3. equals
6.7.3. 同輩
public boolean equals(Object Obj)
公共の論理演算子同輩(オブジェクトObj)
Returns "true" if the two Oid objects represent the same oid value. (Note that the Java language specification requires that two objects that are equal according to the equals(Object) method must return the same integer result when the hashCode() method is called on them.)
「本当に、」2個のOidオブジェクトが同じoid値を表すなら、戻ります。 (ジャバ言語仕様が、hashCode()メソッドが彼らの上に呼ばれるとき、2個のメソッドが同じ整数に返さなければならない同輩(オブジェクト)によると、等しいオブジェクトが結果として生じるのを必要とすることに注意してください。)
Parameters:
パラメタ:
obj Another Oid object to compare with.
比較するobj Another Oidオブジェクト。
6.7.4. getDER
6.7.4. getDER
public byte[] getDER()
公共のバイト[]getDER()
Returns the full ASN.1 DER encoding for this oid object, which includes the tag and length.
このoidオブジェクトのための完全なASN.1DERコード化を返します。(オブジェクトはタグと長さを含んでいます)。
6.7.5. containedIn
6.7.5. containedIn
public boolean containedIn(Oid[] oids)
公共の論理演算子containedIn(Oid[] oids)
A utility method to test if an Oid object is contained within the supplied Oid object array.
Oidが反対するなら、テストするユーティリティメソッドは供給されたOidオブジェクト配列の中に含まれています。
Parameters:
パラメタ:
oids An array of oids to search.
捜すoidsのoids An配列。
6.8. public class GSSException extends Exception
6.8. 公立のクラスGSSExceptionはExceptionを広げています。
This exception is thrown whenever a fatal GSS-API error occurs including mechanism specific errors. It may contain both, the major and minor, GSS-API status codes. The mechanism implementers are responsible for setting appropriate minor status codes when throwing this exception. Aside from delivering the numeric error code(s) to the caller, this class performs the mapping from their numeric values to textual representations. All Java GSS-API methods are declared throwing this exception.
メカニズムの特定の誤りを含んでいて、致命的なGSS-API誤りが発生するときはいつも、この例外は投げられます。 それは両方、少佐、および小さい方のGSS-APIステータスコードを含むかもしれません。 メカニズムimplementersはこの例外を投げるとき適切な小さい方のステータスコードを設定するのに責任があります。 数値エラーコードを訪問者に提供することは別として、このクラスはそれらの数値から原文の表現までマッピングを実行します。 すべてのJava GSS-APIメソッドが、この例外を投げながら、宣言されます。
Kabat & Upadhyay Standards Track [Page 80] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[80ページ]。
All implementations are encouraged to use the Java internationalization techniques to provide local translations of the message strings.
すべての実装がメッセージストリングのローカルの翻訳を提供するのにJava国際化のテクニックを使用するよう奨励されます。
6.8.1. Static Constants
6.8.1. 静的な定数
All valid major GSS-API error code values are declared as constants in this class.
すべての有効な主要なGSS-API誤りコード値が定数としてこのクラスで宣言されます。
public static final int BAD_BINDINGS
公共の静的な最終的なint BAD_BINDINGS
Channel bindings mismatch error.
チャンネル結合は誤りにミスマッチします。
public static final int BAD_MECH
公共の静的な最終的なint BAD_MECH
Unsupported mechanism requested error.
サポートされないメカニズムは誤りを要求しました。
public static final int BAD_NAME
公共の静的な最終的なint BAD_NAME
Invalid name provided error.
無効の名前は誤りを提供しました。
public static final int BAD_NAMETYPE
公共の静的な最終的なint BAD_NAMETYPE
Name of unsupported type provided error.
サポートされないタイプの名前は誤りを提供しました。
public static final int BAD_STATUS
公共の静的な最終的なint BAD_STATUS
Invalid status code error - this is the default status value.
無効のステータスコード誤り--これはデフォルト状態値です。
public static final int BAD_MIC
公共の静的な最終的なint BAD_MIC
Token had invalid integrity check error.
トークンで、無効の保全は誤りをチェックしました。
public static final int CONTEXT_EXPIRED
公共の静的な最終的なint CONTEXT_EXPIRED
Specified security context expired error.
指定されたセキュリティ文脈は誤りを吐き出しました。
public static final int CREDENTIALS_EXPIRED
公共の静的な最終的なint CREDENTIALS_EXPIRED
Expired credentials detected error.
満期の資格証明書は誤りを検出しました。
Kabat & Upadhyay Standards Track [Page 81] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[81ページ]。
public static final int DEFECTIVE_CREDENTIAL
公共の静的な最終的なint DEFECTIVE_CREDENTIAL
Defective credential error.
欠陥がある資格証明誤り。
public static final int DEFECTIVE_TOKEN
公共の静的な最終的なint DEFECTIVE_TOKEN
Defective token error.
欠陥があるトークン誤り。
public static final int FAILURE
公共の静的な最終的なint FAILURE
General failure, unspecified at GSS-API level.
GSS-APIレベルで不特定の一般失敗。
public static final int NO_CONTEXT
公共の静的な最終的なintいいえ_CONTEXT
Invalid security context error.
無効のセキュリティ文脈誤り。
public static final int NO_CRED
公共の静的な最終的なintいいえ_CRED
Invalid credentials error.
無効の資格証明書誤り。
public static final int BAD_QOP
公共の静的な最終的なint BAD_QOP
Unsupported QOP value error.
サポートされないQOPは誤りを評価します。
public static final int UNAUTHORIZED
公共の静的な最終的なint UNAUTHORIZED
Operation unauthorized error.
操作の権限のない誤り。
public static final int UNAVAILABLE
公共の静的な最終的なint UNAVAILABLE
Operation unavailable error.
操作の入手できない誤り。
public static final int DUPLICATE_ELEMENT
公共の静的な最終的なint DUPLICATE_ELEMENT
Duplicate credential element requested error.
資格証明要素要求された誤りをコピーしてください。
public static final int NAME_NOT_MN
_公共の静的な最終的なint NAME_ミネソタでない
Name contains multi-mechanism elements error.
名前はマルチメカニズム要素誤りを含んでいます。
Kabat & Upadhyay Standards Track [Page 82] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[82ページ]。
public static final int DUPLICATE_TOKEN
公共の静的な最終的なint DUPLICATE_TOKEN
The token was a duplicate of an earlier token. This is a fatal error code that may occur during context establishment. It is not used to indicate supplementary status values. The MessageProp object is used for that purpose.
トークンは以前のトークンの写しでした。 これは文脈設立の間に起こるかもしれない致命的なエラーコードです。 それは、補っている状態値を示すのに使用されません。 MessagePropオブジェクトはそのために使用されます。
public static final int OLD_TOKEN
公共の静的な最終的なint OLD_TOKEN
The token's validity period has expired. This is a fatal error code that may occur during context establishment. It is not used to indicate supplementary status values. The MessageProp object is used for that purpose.
トークンの有効期間は期限が切れました。 これは文脈設立の間に起こるかもしれない致命的なエラーコードです。 それは、補っている状態値を示すのに使用されません。 MessagePropオブジェクトはそのために使用されます。
public static final int UNSEQ_TOKEN
公共の静的な最終的なint UNSEQ_TOKEN
A later token has already been processed. This is a fatal error code that may occur during context establishment. It is not used to indicate supplementary status values. The MessageProp object is used for that purpose.
既に後のトークンを処理してあります。 これは文脈設立の間に起こるかもしれない致命的なエラーコードです。 それは、補っている状態値を示すのに使用されません。 MessagePropオブジェクトはそのために使用されます。
public static final int GAP_TOKEN
公共の静的な最終的なint GAP_TOKEN
An expected per-message token was not received. This is a fatal error code that may occur during context establishment. It is not used to indicate supplementary status values. The MessageProp object is used for that purpose.
1メッセージあたり1つの予想されたトークンは受け取られませんでした。 これは文脈設立の間に起こるかもしれない致命的なエラーコードです。 それは、補っている状態値を示すのに使用されません。 MessagePropオブジェクトはそのために使用されます。
6.8.2. Constructors
6.8.2. 建設者
public GSSException(int majorCode)
公共のGSSException(int majorCode)
Creates a GSSException object with a specified major code.
指定された主要なコードでGSSExceptionオブジェクトを作成します。
Parameters:
パラメタ:
majorCode The GSS error code causing this exception to be
thrown.
誤りがコード化するこの例外を投げさせるmajorCode GSS。
public GSSException(int majorCode, int minorCode, String minorString)
公共のGSSException(int majorCode、int minorCode、String minorString)
Creates a GSSException object with the specified major code, minor code, and minor code textual explanation. This constructor is to be used when the exception is originating from the security mechanism. It allows to specify the GSS code and the mechanism code.
指定された主要なコード、小さい方のコード、および小さい方のコード原文の説明でGSSExceptionオブジェクトを作成します。 例外がセキュリティー対策から発しているとき、この建設者は使用されていることになっています。 それで、GSSコードとメカニズムコードを指定します。
Kabat & Upadhyay Standards Track [Page 83] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[83ページ]。
Parameters:
パラメタ:
majorCode The GSS error code causing this exception to be
thrown.
誤りがコード化するこの例外を投げさせるmajorCode GSS。
minorCode The mechanism error code causing this exception
to be thrown.
minorCode、この例外を投げるメカニズムエラーコード。
minorString The textual explanation of the mechanism error
code.
メカニズムエラーコードの原文の説明をminorStringします。
6.8.3. getMajor
6.8.3. getMajor
public int getMajor()
公共のint getMajor()
Returns the major code representing the GSS error code that caused this exception to be thrown.
この例外を投げたGSSエラーコードを表す主要なコードを返します。
6.8.4. getMinor
6.8.4. getMinor
public int getMinor()
公共のint getMinor()
Returns the mechanism error code that caused this exception. The minor code is set by the underlying mechanism. Value of 0 indicates that mechanism error code is not set.
この例外を引き起こしたメカニズムエラーコードを返します。 小さい方のコードは発症機序によって設定されます。 0の値は、メカニズムエラーコードが設定されないのを示します。
6.8.5. getMajorString
6.8.5. getMajorString
public String getMajorString()
公共のString getMajorString()
Returns a string explaining the GSS major error code causing this exception to be thrown.
この例外を投げるGSSの主要なエラーコードがわかるストリングを返します。
6.8.6. getMinorString
6.8.6. getMinorString
public String getMinorString()
公共のString getMinorString()
Returns a string explaining the mechanism specific error code. null will be returned when no mechanism error code has been set.
メカニズムエラーコードが全く設定されていないとき. ヌルが返されるメカニズムの特定のエラーコードがわかるストリングを返します。
6.8.7. setMinor
6.8.7. setMinor
public void setMinor(int minorCode, String message)
公共の空のsetMinor(int minorCode、Stringメッセージ)
Used internally by the GSS-API implementation and the underlying mechanisms to set the minor code and its textual representation.
GSS-API実行と発症機序で、小さい方のコードとその原文の表現を設定するために内用しました。
Kabat & Upadhyay Standards Track [Page 84] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[84ページ]。
Parameters:
パラメタ:
minorCode The mechanism specific error code.
minorCode、メカニズムの特定のエラーコード。
message A textual explanation of the mechanism error code.
メカニズムエラーコードのメッセージのA原文の説明。
6.8.8. toString
6.8.8. toString
public String toString()
公共のString toString()
Returns a textual representation of both the major and minor status codes.
両方の主要で小さい方のステータスコードの原文の表現を返します。
6.8.9. getMessage
6.8.9. getMessage
public String getMessage()
公共のString getMessage()
Returns a detailed message of this exception. Overrides Throwable.getMessage. It is customary in Java to use this method to obtain exception information.
この例外の詳細なメッセージを返します。 Throwable.getMessageをくつがえします。 Javaでは、例外情報を得るこのメソッドを使用するのは通例です。
7. Sample Applications
7. サンプルアプリケーション
7.1. Simple GSS Context Initiator
7.1. 純真なGSS文脈創始者
import org.ietf.jgss.*;
輸入org.ietf.jgss*。
/**
* This is a partial sketch for a simple client program that acts
* as a GSS context initiator. It illustrates how to use the Java
* bindings for the GSS-API specified in
* Generic Security Service API Version 2 : Java bindings
*
*
* This code sketch assumes the existence of a GSS-API
* implementation that supports the mechanism that it will need and
* is present as a library package (org.ietf.jgss) either as part of
* the standard JRE or in the CLASSPATH the application specifies.
*/
/、***これはGSS文脈創始者として*を機能させる簡単なクライアントプログラムのための部分的なスケッチです。 それは*ジェネリックSecurity Service APIバージョン2で指定されたGSS-APIにJava*結合を使用する方法を例証します: サポートそれが必要とするメカニズムと*がGSS-API*実装の存在ですが、このコードスケッチが仮定するJava結合***はライブラリパッケージとして標準のJREかアプリケーションが指定するCLASSPATHにどちらか*の一部としての(org.ietf.jgss)を提示します。 */
public class SimpleClient {
公立のクラスSimpleClient
private String serviceName; // name of peer (ie. server)
private GSSCredential clientCred = null;
private GSSContext context = null;
private Oid mech; // underlying mechanism to use
個人的なString serviceName。 (ieサーバ)同輩の個人的なGSSCredential clientCredという//名前はヌルと等しいです。 個人的なGSSContext関係はヌルと等しいです。 個人的なOid mech。 使用する//発症機序
private GSSManager mgr = GSSManager.getInstance();
個人的なGSSManager mgrはGSSManager.getInstance()と等しいです。
Kabat & Upadhyay Standards Track [Page 85] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[85ページ]。
...
...
... ...
private void clientActions() {
initializeGSS();
establishContext();
doCommunication();
}
個人的な空のclientActions()initializeGSS(); establishContext();doCommunication()。
/**
* Acquire credentials for the client.
*/
private void initializeGSS() {
/***はクライアントのために資格証明書を取得します。 */個人的な空のinitializeGSS()
try {
トライ
clientCred = mgr.createCredential(null /*default princ*/,
GSSCredential.INDEFINITE_LIFETIME /* max lifetime */,
mech /* mechanism to use */,
GSSCredential.INITIATE_ONLY /* init context */);
=mgr.createCredentialをclientCredした、(ヌル/*デフォルトprinc*/、GSSCredential.INDEFINITE_LIFETIME/*は生涯*/に最大限にします、*/を使用するmech/*メカニズム、GSSCredential.INITIATEだけ、/*イニット文脈*/)、。
print("GSSCredential created for " +
cred.getName().toString());
print("Credential lifetime (sec)=" +
cred.getRemainingLifetime());
} catch (GSSException e) {
print("GSS-API error in credential acquisition: "
+ e.getMessage());
...
...
}
印刷、(「」 + cred.getName().toString())のために作成されたGSSCredential。 印刷、(+ 「資格証明生涯(秒)=」cred.getRemainingLifetime())。 (GSSException e)を捕らえてください。印刷、(「資格証明獲得におけるGSS-API誤り:」 + e.getMessage())。 ... ... }
...
...
}
... ... }
/**
* Does the security context establishment with the
* server.
*/
private void establishContext() {
/***はサーバ**/個人的な空のestablishContext()とのセキュリティ文脈設立をします。
byte[] inToken = new byte[0];
byte[] outToken = null;
バイト[]inTokenは新しいバイト[0]と等しいです。 バイト[]outTokenはヌルと等しいです。
try {
トライ
GSSName peer = mgr.createName(serviceName,
GSSName同輩=mgr.createName、(serviceName
Kabat & Upadhyay Standards Track [Page 86] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[86ページ]。
GSSName.NT_HOSTBASED_SERVICE);
GSSName.NT_HOSTBASED_サービス)、。
context = mgr.createContext(peer, mech, gssCred,
GSSContext.INDEFINITE_LIFETIME/*lifetime*/);
文脈はmgr.createContext(同輩、mech、gssCred、GSSContext.INDEFINITE_LIFETIME/*生涯*/)と等しいです。
// Will need to support confidentiality
context.requestConf(true);
秘密性がcontext.requestConf(本当の)であるとサポートする//ウィルの必要性。
while (!context.isEstablished()) {
(context.isEstablished())
outToken = context.initSecContext(inToken, 0,
inToken.length);
outTokenはcontext.initSecContext(inToken、0、inToken.length)と等しいです。
if (outToken != null)
writeGSSToken(outToken);
(outToken!=ヌル)writeGSSToken(outToken)であるなら。
if (!context.isEstablished())
inToken = readGSSToken();
}
(context.isEstablished()) inTokenはreadGSSToken()と等しいです。 }
GSSName peer = context.getSrcName();
print("Security context established with " + peer +
" using underlying mechanism " + mech.toString());
} catch (GSSException e) {
print("GSS-API error during context establishment: "
+ e.getMessage());
...
...
}
GSSName同輩はcontext.getSrcName()と等しいです。 印刷、(「セキュリティ文脈は」 + 同輩+「使用発症機序」で+ mech.toString())を設立しました。 (GSSException e)を捕らえてください。印刷、(「文脈設立の間のGSS-API誤り:」 + e.getMessage())。 ... ... }
...
...
}
... ... }
/**
* Sends some data to the server and reads back the
* response.
*/
private void doCommunication() {
byte[] inToken = null;
byte[] outToken = null;
byte[] buffer;
/***は、いくつかのデータをサーバに送って、*応答を読み返します。 */個人的な空のdoCommunication()、バイト[]inTokenはヌルと等しいです; バイト[]outTokenはヌルと等しいです; バイト[]バッファ
// Container for multiple input-output arguments to and
// from the per-message routines (e.g., wrap/unwrap).
MessageProp messgInfo = new MessageProp();
1メッセージあたりのルーチン(例えば、包装するか、または開ける)からの複数の入出力議論と//のための//コンテナ。 MessageProp messgInfoは新しいMessageProp()と等しいです。
try {
トライ
Kabat & Upadhyay Standards Track [Page 87] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[87ページ]。
/*
* Now send some bytes to the server to be
* processed. They will be integrity protected but
* not encrypted for privacy.
*/
*が現在*になるようにサーバに数バイト送る/*は処理されました。 それらは、保護された保全にもかかわらず、プライバシーのために暗号化されなかった*になるでしょう。 */
buffer = readFromFile();
=readFromFile()をバッファリングしてください。
// Set privacy to false and use the default QOP
messgInfo.setPrivacy(false);
//は、誤っているのにプライバシーを設定して、デフォルトQOP messgInfo.setPrivacy(誤った)を使用します。
outToken = context.wrap(buffer, 0, buffer.length,
messgInfo);
outTokenはcontext.wrap(バッファ、0、buffer.length、messgInfo)と等しいです。
writeGSSToken(outToken);
writeGSSToken(outToken)。
/*
* Now read the response from the server.
*/
/**は現在. */をサーバからの応答に読み込みました。
inToken = readGSSToken();
buffer = context.unwrap(inToken, 0, inToken.length,
messgInfo);
// All ok if no exception was thrown!
inTokenはreadGSSToken()と等しいです。 =context.unwrap(inToken、0、inToken.length、messgInfo)をバッファリングしてください。 //、すべてのOKが例外でないなら投げられました!
GSSName peer = context.getSrcName();
GSSName同輩はcontext.getSrcName()と等しいです。
print("Message from " + peer.toString()
+ " arrived.");
print("Was it encrypted? " +
messgInfo.getPrivacy());
print("Duplicate Token? " +
messgInfo.isDuplicateToken());
print("Old Token? " +
messgInfo.isOldToken());
print("Unsequenced Token? " +
messgInfo.isUnseqToken());
print("Gap Token? " +
messgInfo.isGapToken());
印刷してください(+ peer.toString()+「到着」は「通信します」)。 印刷(「それは暗号化されましたか?」 「+ messgInfo.getPrivacy()」); 印刷(「写しトークン?」 「+ messgInfo.isDuplicateToken()」); 印刷(「古いトークン?」 「+ messgInfo.isOldToken()」); 印刷(「Unsequencedトークン?」 「+ messgInfo.isUnseqToken()」); 印刷(「ギャップトークン?」 「+ messgInfo.isGapToken()」);
...
...
... ...
} catch (GSSException e) {
print("GSS-API error in per-message calls: "
+ e.getMessage());
...
...
(GSSException e)を捕らえてください、印刷、(「GSS-API誤りは中にメッセージ単位で呼ぶ」という+e.getMessage())。 ... ...
Kabat & Upadhyay Standards Track [Page 88] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[88ページ]。
}
}
...
...
...
...
} // end of doCommunication method
} doCommunicationメソッドの//終わり
...
...
... ...
} // end of class SimpleClient
} クラスSimpleClientの//端
7.2. Simple GSS Context Acceptor
7.2. 簡単なGSS文脈アクセプタ
import org.ietf.jgss.*;
輸入org.ietf.jgss*。
/**
* This is a partial sketch for a simple server program that acts
* as a GSS context acceptor. It illustrates how to use the Java
* bindings for the GSS-API specified in
* Generic Security Service API Version 2 : Java bindings
*
* This code sketch assumes the existence of a GSS-API
* implementation that supports the mechanisms that it will need and
* is present as a library package (org.ietf.jgss) either as part of
* the standard JRE or in the CLASSPATH the application specifies.
*/
/、***これはGSS文脈アクセプタとして*を機能させる簡単なサーバプログラムのための部分的なスケッチです。 それは*ジェネリックSecurity Service APIバージョン2で指定されたGSS-APIにJava*結合を使用する方法を例証します: サポートそれが必要とするメカニズムと*がGSS-API*実装の存在ですが、このコードスケッチが仮定するJava結合**はライブラリパッケージとして標準のJREかアプリケーションが指定するCLASSPATHにどちらか*の一部としての(org.ietf.jgss)を提示します。 */
import org.ietf.jgss.*;
輸入org.ietf.jgss*。
public class SimpleServer {
公立のクラスSimpleServer
private String serviceName;
private GSSName name;
private GSSCredential cred;
個人的なString serviceName。 個人的なGSSName名。 個人的なGSSCredential信用。
private GSSManager mgr;
個人的なGSSManager mgr。
...
...
... ...
/**
* Wait for client connections, establish security contexts and
* provide service.
*/
private void loop() {
*/***はクライアント接続を待っています、そして、セキュリティ文脈を確立してください、そして、サービスを提供してください。 */兵卒空の輪()
Kabat & Upadhyay Standards Track [Page 89] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[89ページ]。
...
...
... ...
mgr = GSSManager.getInstance();
mgrはGSSManager.getInstance()と等しいです。
name = mgr.createName(serviceName,
GSSName.NT_HOSTBASED_SERVICE);
mgr.createName(serviceName、GSSName.NT_HOSTBASED_SERVICE)と=を命名してください。
cred = mgr.createCredential(name,
GSSCredential.INDEFINITE_LIFETIME,
null,
GSSCredential.ACCEPT_ONLY);
信用はmgr.createCredential(名前、GSSCredential.INDEFINITE_LIFETIME、ヌル、GSSCredential.ACCEPTだけ)と等しいです。
// Loop infinitely
while (true) {
//輪は無限にゆったり過ごします(本当の)。
Socket s = serverSock.accept();
ソケットsはserverSock.accept()と等しいです。
// Start a new thread to serve this connection
Thread serverThread = new ServerThread(s);
serverThread.start();
//スタートの新しいこの接続Thread serverThreadに役立つ新しいスレッド=ServerThread(s)。 serverThread.start()。
}
}
} }
/**
* Inner class ServerThread whose run() method provides the
* secure service to a connection.
*/
走行()メソッドが*を提供する/***内側のクラスServerThreadは接続に対するサービスを保証します。 */
private class ServerThread extends Thread {
私設のクラスServerThreadはThreadを広げています。
...
...
... ...
/**
* Deals with the connection from one client. It also
* handles all GSSException's thrown while talking to
* this client.
*/
public void run() {
/***は1人のクライアントから接続に対処します。 それ、また、*はGSSExceptionがこのクライアントについて*と話している間に投げているすべてを扱います。 */公共の空の走行()
byte[] inToken = null;
byte[] outToken = null;
byte[] buffer;
バイト[]inTokenはヌルと等しいです。 バイト[]outTokenはヌルと等しいです。 バイト[]バッファ。
GSSName peer;
GSSNameはじっと見ます。
Kabat & Upadhyay Standards Track [Page 90] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[90ページ]。
// Container for multiple input-output arguments to and
// from the per-message routines (ie. wrap/unwrap).
MessageProp supplInfo = new MessageProp();
1メッセージあたりのルーチン(ie包装/は開けられる)からの複数の入出力議論と//のための//コンテナ。 MessageProp supplInfoは新しいMessageProp()と等しいです。
GSSContext secContext = null;
GSSContext secContextはヌルと等しいです。
try {
トライ
// Now do the context establishment loop
//は現在、文脈設立輪をします。
GSSContext context = mgr.createContext(cred);
GSSContext文脈はmgr.createContext(信用)と等しいです。
while (!context.isEstablished()) {
(context.isEstablished())
inToken = readGSSToken();
inTokenはreadGSSToken()と等しいです。
outToken = context.acceptSecContext(inToken, 0,
inToken.length);
outTokenはcontext.acceptSecContext(inToken、0、inToken.length)と等しいです。
if (outToken != null)
writeGSSToken(outToken);
(outToken!=ヌル)writeGSSToken(outToken)であるなら。
}
}
// SimpleServer wants confidentiality to be
// available. Check for it.
if (!context.getConfState()){
...
...
}
//SimpleServerは、秘密性に//利用可能であって欲しいです。 それがないかどうかチェックしてください、(context.getConfState()){ ... ... }
GSSName peer = context.getSrcName();
Oid mech = context.getMech();
print("Security context established with " +
peer.toString() +
" using underlying mechanism " +
mech.toString() +
" from Provider " +
context.getProvider().getName());
GSSName同輩はcontext.getSrcName()と等しいです。 Oid mechはcontext.getMech()と等しいです。 印刷、(「セキュリティ文脈は」 + peer.toString()+「使用発症機序」+mech.toString()と共に+ + 「プロバイダー」context.getProvider().getName())を設立しました。
// Now read the bytes sent by the client to be
// processed.
inToken = readGSSToken();
//になるようにクライアントによって送られたバイトが現在読まれている//は処理されました。inTokenはreadGSSToken()と等しいです。
// Unwrap the message
//はメッセージを開けます。
Kabat & Upadhyay Standards Track [Page 91] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[91ページ]。
buffer = context.unwrap(inToken, 0, inToken.length,
supplInfo);
// All ok if no exception was thrown!
=context.unwrap(inToken、0、inToken.length、supplInfo)をバッファリングしてください。 //、すべてのOKが例外でないなら投げられました!
// Print other supplementary per-message status
// information
//印刷他の1メッセージあたりの補っている状態//情報
print("Message from " +
peer.toString() + " arrived.");
print("Was it encrypted? " +
supplInfo.getPrivacy());
print("Duplicate Token? " +
supplInfo.isDuplicateToken());
print("Old Token? " + supplInfo.isOldToken());
print("Unsequenced Token? " +
supplInfo.isUnseqToken());
print("Gap Token? " + supplInfo.isGapToken());
印刷してください(+ peer.toString()+「到着」は「通信します」)。 印刷(「それは暗号化されましたか?」 「+ supplInfo.getPrivacy()」); 印刷(「写しトークン?」 「+ supplInfo.isDuplicateToken()」); 印刷(「古いトークン?」 「+ supplInfo.isOldToken()」); 印刷(「Unsequencedトークン?」 「+ supplInfo.isUnseqToken()」); 印刷(「ギャップトークン?」 「+ supplInfo.isGapToken()」);
/*
* Now process the bytes and send back an encrypted
* response.
*/
/**は、もう、バイトを処理して、暗号化された*応答を返送します。 */
buffer = serverProcess(buffer);
=serverProcess(バッファ)をバッファリングしてください。
// Encipher it and send it across
//は、それを暗号化して、それを使いにやります。
supplInfo.setPrivacy(true); // privacy requested
supplInfo.setQOP(0); // default QOP
outToken = context.wrap(buffer, 0, buffer.length,
supplInfo);
writeGSSToken(outToken);
supplInfo.setPrivacy(本当の)。 //プライバシーはsupplInfo.setQOP(0)を要求しました。 //デフォルトQOP outTokenはcontext.wrap(バッファ、0、buffer.length、supplInfo)と等しいです。 writeGSSToken(outToken)。
} catch (GSSException e) {
print("GSS-API Error: " + e.getMessage());
// Alternatively, could call e.getMajorMessage()
// and e.getMinorMessage()
print("Abandoning security context.");
(GSSException e)を捕らえてください、印刷、(「GSS-API誤り:」 + e.getMessage())。 あるいはまた、e.をgetMajorMessage()//とe.と呼ぶことができました。//、getMinorMessage()は印刷します(「セキュリティ文脈を捨てます」。)。
...
...
... ...
}
}
...
...
... ...
} // end of run method in ServerThread
} ServerThreadの走行メソッドの//終わり
Kabat & Upadhyay Standards Track [Page 92] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[92ページ]。
} // end of inner class ServerThread
} 内側のクラスServerThreadの//端
...
...
... ...
} // end of class SimpleServer
} クラスSimpleServerの//端
8. Security Considerations
8. セキュリティ問題
The Java language security model allows platform providers to have policy based fine-grained access control over any resource that an application wants. When using a Java security manager (such as, but not limited to, the case of applets running in browsers) the application code is in a sandbox by default.
機密保護モデルがプラットホームプロバイダーを方針を持たせるジャバ言語はアプリケーションが必要とするどんなリソースのきめ細かに粒状のアクセスコントロールも基礎づけました。 Javaのセキュリティマネージャを使用する、(あれほどです、他、サンドボックスにはブラウザ) 応用コードへ駆け込むアプレットに関するケースがデフォルトであります。
Administrators of the platform JRE determine what permissions, if any, are to be given to source from different codebases. Thus the administrator has to be aware of any special requirements that the GSS provider might have for system resources. For instance, a Kerberos provider might wish to make a network connection to the KDC to obtain initial credentials. This would not be allowed under the sandbox unless the administrator had granted permissions for this. Also note that this granting and checking of permissions happens transparently to the application and is outside the scope of this document.
JREプラットホームの管理者は、もしあればどんな許容が異なったcodebasesからソースに与えられるかことであるかと決心しています。 したがって、管理者はGSSプロバイダーがシステム資源のために持っているどんな特別な要件も意識していなければなりません。 例えば、ケルベロスプロバイダーは、初期の資格証明書を得るためにKDCにネットワーク接続を作りたがっているかもしれません。 管理者がこれのために許可を与えていない場合、これはサンドボックスの下で許容されていないでしょうに。 これが許容を承諾して、チェックして、透過的にアプリケーションに起こって、このドキュメントの範囲の外にある注意も。
The Java language allows administrators to pre-configure a list of security service providers in the <JRE>/lib/security/java.security file. At runtime, the system approaches these providers in order of preference when looking for security related services. Applications have a means to modify this list through methods in the "Security" class in the "java.security" package. However, since these modifications would be visible in the entire JVM and thus affect all code executing in it, this operation is not available in the sandbox and requires special permissions to perform. Thus when a GSS application has special needs that are met by a particular security provider, it has two choices:
ジャバ言語で、管理者は<JRE>/lib/security/java.securityファイルでセキュリティサービスプロバイダーのリストをあらかじめ設定できます。 ランタイムのときにセキュリティ関連するサービスを探すとき、システムは好みの順にこれらのプロバイダーにアプローチします。 アプリケーションは"java.security"パッケージの中に「セキュリティ」のクラスにおけるメソッドでこのリストを変更する手段を持っています。 これらの変更は、全体のJVMで目に見えて、しかしながら、この操作はサンドボックスで利用可能でなく、働くために特別な許容を必要として、その結果、それですべてのコード実行に影響するでしょう。 したがって、GSSアプリケーションに特定のセキュリティプロバイダーによって満たされる特別な需要があるとき、それには、2つの選択があります:
1) To install the provider on a JVM wide basis using the
java.security.Security class and then depend on the system to
find the right provider automatically when the need arises.
(This would require the application to be granted a
"insertProvider SecurityPermission".)
1) java.security.Securityのクラスを使用することでJVMの広いベースにプロバイダーをインストールして、次に、必要性が起こるとき自動的に正しいプロバイダーを見つけるためにシステムによるために。 (これは、"insertProvider SecurityPermission"がアプリケーションに与えられるのを必要とするでしょう。)
2) To pass an instance of the provider to the local instance of
GSSManager so that only factory calls going through that
GSSManager use the desired provider. (This would not require
any permissions.)
2) そのGSSManagerを通る工場の呼び出しだけが必要なプロバイダーを使用するようにGSSManagerの地方のインスタンスにプロバイダーのインスタンスを通過するために。 (これは少しの許容も必要としないでしょう。)
Kabat & Upadhyay Standards Track [Page 93] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[93ページ]。
9. Acknowledgments
9. 承認
This proposed API leverages earlier work performed by the IETF's CAT WG as outlined in both RFC 2743 and RFC 2744. Many conceptual definitions, implementation directions, and explanations have been included from these documents.
この提案されたAPIはRFC2743とRFC2744の両方に概説されているようにIETFのCAT WGによって行われた以前の仕事を利用します。 多くの概念的な定義、実装方向、および説明はこれらのドキュメントから含まれています。
We would like to thank Mike Eisler, Lin Ling, Ram Marti, Michael Saltz and other members of Sun's development team for their helpful input, comments and suggestions.
彼らの有用な入力、コメント、および提案についてマイク・アイスラー、リンLing、RamマルティマイケルSaltz、およびSunの開発チームの他のメンバーに感謝申し上げます。
We would also like to thank Joe Salowey, and Michael Smith for many insightful ideas and suggestions that have contributed to this document.
また、多くの洞察に満ちた考えとこのドキュメントに貢献した提案についてジョーSalowey、およびマイケル・スミスに感謝申し上げます。
10. Bibliography
10. 図書目録
[GSSAPIv2] Linn, J., "Generic Security Service Application
Program Interface, Version 2", RFC 2078, January
1997.
[GSSAPIv2] リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェース、バージョン2インチ、RFC2078、1997年1月。」
[GSSAPIv2-UPDATE] Linn, J., "Generic Security Service Application
Program Interface, Version 2, Update 1", RFC 2743,
January 2000.
[GSSAPIv2-アップデート] リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェース、バージョン2は2000年1月に1インチ、RFC2743をアップデートします」。
[GSSAPI-Cbind] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
[GSSAPI-Cbind] レイ、J.、「ジェネリックセキュリティはAPIバージョン2を供給します」。 「C-結合」、RFC2744、2000年1月。
[KERBV5] Linn, J., "The Kerberos Version 5 GSS-API
Mechanism", RFC 1964, June 1996.
[KERBV5] リン、J.、「ケルベロスバージョン5GSS-APIメカニズム」、RFC1964、1996年6月。
[SPKM] Adams, C., "The Simple Public-Key GSS-API
Mechanism", RFC 2025, October 1996.
[SPKM]アダムス、C.、「簡単な公開カギGSS-APIメカニズム」、RFC2025、1996年10月。
Kabat & Upadhyay Standards Track [Page 94] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[94ページ]。
11. Authors' Addresses
11. 作者のアドレス
Address comments related to this memorandum to:
アドレスコメントは以下のことのためにこのメモに関連しました。
<cat-ietf@mit.edu>
<の猫ietfな@mit.edu>。
Jack Kabat ValiCert, Inc. 339 N. Bernardo Avenue Mountain View, CA 94043, USA
ジャックカバットValiCert Inc.339N.ベルナルド・Avenueマウンテンビュー、カリフォルニア 94043、米国
Phone: +1-650-567-5496 EMail: jackk@valicert.com
以下に電話をしてください。 +1-650-567-5496 メールしてください: jackk@valicert.com
Mayank Upadhyay Sun Microsystems, Inc. 901 San Antonio Road, MS CUP02-102 Palo Alto, CA 94303
Mayank Upadhyayサン・マイクロシステムズ・インク901サンアントニオ道路、MS CUP02-102パロアルト、カリフォルニア 94303
Phone: +1-408-517-5956 EMail: mdu@eng.sun.com
以下に電話をしてください。 +1-408-517-5956 メールしてください: mdu@eng.sun.com
Kabat & Upadhyay Standards Track [Page 95] RFC 2853 GSS-API Java Bindings June 2000
カバットとUpadhyay規格はGSS-API Java結合2000年6月にRFC2853を追跡します[95ページ]。
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Kabat & Upadhyay Standards Track [Page 96]
カバットとUpadhyay標準化過程[96ページ]
一覧
スポンサーリンク
