RFC1964 日本語訳
1964 The Kerberos Version 5 GSS-API Mechanism. J. Linn. June 1996. (Format: TXT=47413 bytes) (Updated by RFC4121) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Linn Request for Comments: 1964 OpenVision Technologies Category: Standards Track June 1996
コメントを求めるワーキンググループJ.リンの要求をネットワークでつないでください: 1964年のOpenVision技術カテゴリ: 標準化過程1996年6月
The Kerberos Version 5 GSS-API Mechanism
ケルベロスバージョン5GSS-APIメカニズム
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)の現行版を参照してください。 このメモの分配は無制限です。
ABSTRACT
要約
This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using Kerberos Version 5 technology (as specified in RFC 1510).
ケルベロスバージョン5技術を使用するとき(RFC1510で指定されるように)Generic Security Service Application Program Interface(RFCs1508と1509年に指定されるように)を実装する同輩によって使われるように、この仕様はプロトコル、手順、およびコンベンションを定義します。
ACKNOWLEDGMENTS
承認
Much of the material in this memo is based on working documents drafted by John Wray of Digital Equipment Corporation and on discussions, implementation activities, and interoperability testing involving Marc Horowitz, Ted Ts'o, and John Wray. Particular thanks are due to each of these individuals for their contributions towards development and availability of GSS-API support within the Kerberos Version 5 code base.
マーク・ホロビッツ、テッドTs'o、およびジョン・レイにかかわる議論、実装活動、およびDECのジョン・レイによって作成されたドキュメントを扱うことに基づいた相互運用性テストにはこのメモによる材料の多くがあります。 特定の感謝は開発に向かった彼らの貢献のためのこれらの個人各人とケルベロスバージョン5コードベースの中のGSS-APIサポートの有用性のためです。
1. Token Formats
1. トークン形式
This section discusses protocol-visible characteristics of the GSS- API mechanism to be implemented atop Kerberos V5 security technology per RFC-1508 and RFC-1510; it defines elements of protocol for interoperability and is independent of language bindings per RFC- 1509.
このセクションは1RFC-1508あたりのケルベロスV5セキュリティー技術の上で実装されるGSS APIメカニズムとRFC-1510のプロトコル目に見える特性について論じます。 それは、相互運用性のためにプロトコルの原理を定義して、RFC1509あたりの言語結合から独立しています。
Tokens transferred between GSS-API peers (for security context management and per-message protection purposes) are defined. The data elements exchanged between a GSS-API endpoint implementation and the Kerberos KDC are not specific to GSS-API usage and are therefore defined within RFC-1510 rather than within this specification.
GSS-API同輩(セキュリティ文脈管理とメッセージあたりの保護目的)の間に移されたトークンは定義されます。 GSS-API終点実装とケルベロスKDCの間で交換されたデータ要素は、GSS-API用法に特定でなく、したがって、この仕様の中でというよりむしろRFC-1510の中で定義されます。
Linn Standards Track [Page 1] RFC 1964 Kerberos Version 5 GSS-API June 1996
リンStandardsはGSS-API1996年6月にRFC1964ケルベロスバージョン5を追跡します[1ページ]。
To support ongoing experimentation, testing, and evolution of the specification, the Kerberos V5 GSS-API mechanism as defined in this and any successor memos will be identified with the following Object Identifier, as defined in RFC-1510, until the specification is advanced to the level of Proposed Standard RFC:
仕様の進行中の実験、テスト、および発展をサポートするために、これとどんな後継者メモでも定義されるケルベロスV5 GSS-APIメカニズムは以下のObject Identifierと同一視されるでしょう、RFC-1510で定義されるように、仕様がProposed Standard RFCのレベルに進められるまで:
{iso(1), org(3), dod(5), internet(1), security(5), kerberosv5(2)}
iso(1)、org(3)、dod(5)、インターネット(1)、セキュリティ(5)、kerberosv5(2)
Upon advancement to the level of Proposed Standard RFC, the Kerberos V5 GSS-API mechanism will be identified by an Object Identifier having the value:
Proposed Standard RFCのレベルへの前進のときに、ケルベロスV5 GSS-APIメカニズムは値を持っているObject Identifierによって特定されるでしょう:
{iso(1) member-body(2) United States(840) mit(113554) infosys(1)
gssapi(2) krb5(2)}
iso(1)メンバーボディー(2)合衆国(840)mit(113554) infosys(1) gssapi(2) krb5(2)
1.1. Context Establishment Tokens
1.1. 文脈設立トークン
Per RFC-1508, Appendix B, the initial context establishment token will be enclosed within framing as follows:
Appendix B、RFC-1508に従って、以下の通り以下を縁どる中に初期の文脈設立トークンは同封されるでしょう。
InitialContextToken ::=
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType
-- MechType is OBJECT IDENTIFIER
-- representing "Kerberos V5"
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific;
-- ASN.1 usage within innerContextToken
-- is not required
}
InitialContextToken:、:= [アプリケーション0] 暗黙の系列MechTypeがOBJECT IDENTIFIERであるというthisMech MechTypeが表す、「thisMech(コンテンツメカニズム詳細)によって少しも定義されたケルベロスV5" innerContextToken(innerContextTokenの中のASN.1用法)は必要でない、」
The innerContextToken of the initial context token will consist of a Kerberos V5 KRB_AP_REQ message, preceded by a two-byte token-id (TOK_ID) field, which shall contain the value 01 00.
初期の文脈トークンのinnerContextTokenは値01 00を含むものとする2バイトのトークンイド(TOK_ID)分野が先行したケルベロスV5 KRB_AP_REQメッセージから成るでしょう。
The above GSS-API framing shall be applied to all tokens emitted by the Kerberos V5 GSS-API mechanism, including KRB_AP_REP, KRB_ERROR, context-deletion, and per-message tokens, not just to the initial token in a context establishment sequence. While not required by RFC-1508, this enables implementations to perform enhanced error- checking. The innerContextToken field of context establishment tokens for the Kerberos V5 GSS-API mechanism will contain a Kerberos message (KRB_AP_REQ, KRB_AP_REP or KRB_ERROR), preceded by a 2-byte TOK_ID field containing 01 00 for KRB_AP_REQ messages, 02 00 for KRB_AP_REP messages and 03 00 for KRB_ERROR messages.
上のGSS-API縁どりは文脈設立系列の初期のトークンだけではなく、KRB_AP_REPを含んでいて、トークンがケルベロスV5 GSS-APIメカニズムで放ったすべて、KRB_ERROR、文脈削除、および1メッセージあたりのトークンに適用されるものとします。 RFC-1508は必要でない間、これが、実装が高められた誤りの照合を実行するのを可能にします。 ケルベロスV5 GSS-APIメカニズムのための文脈設立トークンのinnerContextToken分野はケルベロスメッセージ(KRB_AP_REQ、KRB_AP_REPまたはKRB_ERROR)を含むでしょう、KRB_AP_REQメッセージのための01 00、KRB_AP_REPメッセージのための02 00、およびKRB_ERRORメッセージのための03 00を含む2バイトのTOK_ID分野が先行して。
Linn Standards Track [Page 2] RFC 1964 Kerberos Version 5 GSS-API June 1996
リンStandardsはGSS-API1996年6月にRFC1964ケルベロスバージョン5を追跡します[2ページ]。
1.1.1. Initial Token
1.1.1. 初期のトークン
Relevant KRB_AP_REQ syntax (from RFC-1510) is as follows:
関連KRB_AP_REQ構文(RFC-1510からの)は以下の通りです:
AP-REQ ::= [APPLICATION 14] SEQUENCE {
pvno [0] INTEGER, -- indicates Version 5
msg-type [1] INTEGER, -- indicates KRB_AP_REQ
ap-options[2] APOptions,
ticket[3] Ticket,
authenticator[4] EncryptedData
}
AP-REQ:、:= [アプリケーション14] 系列pvno[0]INTEGER--、表示、バージョン5は[1] INTEGERをmsgタイプします--[2] KRB_AP_REQ ap-オプションAPOptionsを示します、チケット[3]チケット、固有識別文字[4]EncryptedData
APOptions ::= BIT STRING {
reserved (0),
use-session-key (1),
mutual-required (2)
}
APOptions:、:= ビット列予約された(0)、セッションキーを使用している(1)、互いに必要な(2)
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno [0] INTEGER, -- indicates Version 5
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData
}
以下にレッテルをはってください:= [アプリケーション1] 系列tkt-vno[0]INTEGER--、バージョン5分野[1]分野、sname[2]PrincipalName、enc-部分[3]EncryptedDataは示します。
-- Encrypted part of ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags[0] TicketFlags,
key[1] EncryptionKey,
crealm[2] Realm,
cname[3] PrincipalName,
transited[4] TransitedEncoding,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
caddr[9] HostAddresses OPTIONAL,
authorization-data[10] AuthorizationData OPTIONAL
}
-- チケットEncTicketPartの暗号化された部分:、:= [アプリケーション3] 系列旗[0]TicketFlags、キー[1]EncryptionKey、crealm[2]分野(cname[3] PrincipalName)は[4] TransitedEncodingを通過しました、authtime[5] KerberosTime、starttime[6] KerberosTime OPTIONAL、endtime[7] KerberosTime、現金箱[8]KerberosTime OPTIONALを取り替えます、caddr[9] HostAddresses OPTIONAL、承認データ[10]AuthorizationData OPTIONAL
-- Unencrypted authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno[0] INTEGER,
crealm[1] Realm,
cname[2] PrincipalName,
cksum[3] Checksum OPTIONAL,
cusec[4] INTEGER,
ctime[5] KerberosTime,
-- Unencrypted固有識別文字Authenticator:、:= [APPLICATION2]SEQUENCE、固有識別文字-vno[0] INTEGER、crealm[1]分野、cname[2] PrincipalName、cksum[3]チェックサムOPTIONAL、キューセック[4]INTEGER、ctime[5] KerberosTime
Linn Standards Track [Page 3] RFC 1964 Kerberos Version 5 GSS-API June 1996
リンStandardsはGSS-API1996年6月にRFC1964ケルベロスバージョン5を追跡します[3ページ]。
subkey[6] EncryptionKey OPTIONAL,
seq-number[7] INTEGER OPTIONAL,
authorization-data[8] AuthorizationData OPTIONAL
}
サブキー[6]EncryptionKey OPTIONAL、seq-数の[7]INTEGER OPTIONAL、承認データ[8]AuthorizationData OPTIONAL
For purposes of this specification, the authenticator shall include the optional sequence number, and the checksum field shall be used to convey channel binding, service flags, and optional delegation information. The checksum will have a type of 0x8003 (a value being registered within the Kerberos protocol specification), and a value field of at least 24 bytes in length. The length of the value field is extended beyond 24 bytes if and only if an optional facility to carry a Kerberos-defined KRB_CRED message for delegation purposes is supported by an implementation and active on a context. When delegation is active, a TGT with its FORWARDABLE flag set will be transferred within the KRB_CRED message.
この仕様の目的のために、固有識別文字は任意の一連番号を含んでいるものとします、そして、チェックサム分野は、チャンネル結合、サービス旗、および任意の委譲情報を伝えるのに使用されるものとします。 チェックサムには、一種の0×8003(ケルベロスプロトコル仕様の中に示される値)、および長さ少なくとも24バイトの値の分野があるでしょう。 そして、値の分野の長さが24バイトを超えたところまで広げられる、任意の施設である場合にだけ、委譲目的へのケルベロスで定義されたKRB_CREDメッセージを伝えるのは、実装によってサポートされて、文脈でアクティブです。 委譲がアクティブであるときに、KRB_CREDメッセージの中でFORWARDABLE旗のセットがあるTGTを移すでしょう。
The checksum value field's format is as follows:
チェックサム値のフィールドの形式は以下の通りです:
Byte Name Description
0..3 Lgth Number of bytes in Bnd field;
Currently contains hex 10 00 00 00
(16, represented in little-endian form)
4..19 Bnd MD5 hash of channel bindings, taken over all non-null
components of bindings, in order of declaration.
Integer fields within channel bindings are represented
in little-endian order for the purposes of the MD5
calculation.
20..23 Flags Bit vector of context-establishment flags,
with values consistent with RFC-1509, p. 41:
GSS_C_DELEG_FLAG: 1
GSS_C_MUTUAL_FLAG: 2
GSS_C_REPLAY_FLAG: 4
GSS_C_SEQUENCE_FLAG: 8
GSS_C_CONF_FLAG: 16
GSS_C_INTEG_FLAG: 32
The resulting bit vector is encoded into bytes 20..23
in little-endian form.
24..25 DlgOpt The Delegation Option identifier (=1) [optional]
26..27 Dlgth The length of the Deleg field. [optional]
28..n Deleg A KRB_CRED message (n = Dlgth + 29) [optional]
バイト名前記述03 Bnd分野のバイトのLgth Number。 現在、十六進法10 00 00 00(リトルエンディアンフォームに表された16)4を含みます。宣言の順に結合のすべての非ヌルコンポーネントの上に取られたチャンネル結合の19Bnd MD5ハッシュ。 チャンネル結合の中の整数分野はMD5計算の目的のリトルエンディアン注文に表されます。 20..文脈設立のBitベクトルがRFC-1509、pと一致した値で旗を揚げさせる23個の旗。 41: GSS_C_DELEG_旗: 1個のGSS_Cの_の互いの_旗: 2GSS_C_再生_は弛みます: _4GSS_C、系列_は弛みます: 8GSS_C_CONF_旗: 16GSS_C_INTEG_旗: 32 結果として起こる噛み付いているベクトルはバイト20にコード化されます。リトルエンディアンによる23は形成されます。 24..25 DlgOpt Delegation Option識別子(=1)[任意の]26。27 Deleg分野の長さのDlgth。 [任意]の28。n Deleg A KRB_CREDメッセージ(n=Dlgth+29)[任意]です。
In computing the contents of the "Bnd" field, the following detailed points apply:
"Bnd"分野のコンテンツを計算する際に、以下の詳細なポイントは適用されます:
(1) Each integer field shall be formatted into four bytes, using
little-endian byte ordering, for purposes of MD5 hash
computation.
(1) MD5ハッシュ計算の目的にリトルエンディアンバイト順を使用して、それぞれの整数分野は4バイトにフォーマットされるものとします。
Linn Standards Track [Page 4] RFC 1964 Kerberos Version 5 GSS-API June 1996
リンStandardsはGSS-API1996年6月にRFC1964ケルベロスバージョン5を追跡します[4ページ]。
(2) All input length fields within gss_buffer_desc elements of a
gss_channel_bindings_struct, even those which are zero-valued,
shall be included in the hash calculation; the value elements of
gss_buffer_desc elements shall be dereferenced, and the
resulting data shall be included within the hash computation,
only for the case of gss_buffer_desc elements having non-zero
length specifiers.
(2) gss_チャンネル_結合_structのgss_バッファ_desc要素の中のすべての入力長さの分野(無評価されたものさえ)がハッシュ計算に含まれているものとします。 gss_バッファ_desc要素の価値要素は「反-参照をつけ」られるものとします、そして、結果として起こるデータはハッシュ計算の中に含まれているものとします、非ゼロ・レングス特許説明書の作成書があるgss_バッファ_desc要素のケースのためだけに。
(3) If the caller passes the value GSS_C_NO_BINDINGS instead of
a valid channel bindings structure, the Bnd field shall be set
to 16 zero-valued bytes.
(3) 訪問者が_有効なチャンネル結合構造の代わりに値GSS_Cのいいえ_BINDINGSを渡すなら、Bnd分野は無評価された16バイトに設定されるものとします。
In the initial Kerberos V5 GSS-API mechanism token (KRB_AP_REQ token) from initiator to target, the GSS_C_DELEG_FLAG, GSS_C_MUTUAL_FLAG, GSS_C_REPLAY_FLAG, and GSS_C_SEQUENCE_FLAG values shall each be set as the logical AND of the initiator's corresponding request flag to GSS_Init_sec_context() and a Boolean indicator of whether that optional service is available to GSS_Init_sec_context()'s caller. GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG, for which no corresponding context-level input indicator flags to GSS_Init_sec_context() exist, shall each be set to indicate whether their respective per-message protection services are available for use on the context being established.
初期のケルベロスV5 GSS-APIメカニズムトークンでは、創始者から目標までの(KRB_AP_REQトークン)(GSS_C_DELEG_FLAG)はそれぞれGSS_Init_秒_文脈()への創始者の対応する要求旗の論理的なANDとその任意のサービスがそうであるかどうかに関するブールインディケータとして設定されて、GSS_Init_秒_文脈()に利用可能であるのが、訪問者であるという_GSS_C MUTUAL_FLAG、_GSS_C REPLAY_FLAG、および_GSS_C SEQUENCE_FLAGが、評価することでしょう。 _GSS_C CONF_FLAGと_GSS_C INTEG_FLAG、GSS_Init_秒_文脈()へのどの対応する文脈レベルがない入力インディケータ旗が存在するか、それぞれが、確立される文脈のにおける使用について、彼らの1メッセージあたりのそれぞれの保護サービスがあるかどうかを示すように設定されるでしょうか?
When input source address channel binding values are provided by a caller (i.e., unless the input argument is GSS_C_NO_BINDINGS or the source address specifier value within the input structure is GSS_C_NULL_ADDRTYPE), and the corresponding token received from the context's peer bears address restrictions, it is recommended that an implementation of the Kerberos V5 GSS-API mechanism should check that the source address as provided by the caller matches that in the received token, and should return the GSS_S_BAD_BINDINGS major_status value if a mismatch is detected. Note: discussion is ongoing about the strength of recommendation to be made in this area, and on the circumstances under which such a recommendation should be applicable; implementors are therefore advised that changes on this matter may be included in subsequent versions of this specification.
いつが拘束力がある値が訪問者(すなわち、入力議論がGSS_C_いいえ_BINDINGSであるか投入構造の中のソースアドレス特許説明書の作成書価値がGSS_C_NULL_ADDRTYPEでないなら)によって提供されるソースアドレスチャンネル、および文脈の同輩弱気筋アドレス制限から受け取られた対応するトークンを入力したか; ミスマッチが検出されるなら、ケルベロスV5 GSS-APIメカニズムの実装が訪問者によって提供されるソースアドレスが容認されたトークンでそれに合っているのをチェックするべきであり、GSS_S_のBAD_BINDINGSの主要な_状態値を返すのは、お勧めです。 以下に注意してください。 議論はこの領域で作られているという推薦の強さと、そして、そのような推薦が適切であるべき事情の上で進行中です。 したがって、作成者はこの件の変化がこの仕様のその後のバージョンに含まれるかもしれないと忠告されます。
1.1.2. Response Tokens
1.1.2. 応答トークン
A context establishment sequence based on the Kerberos V5 mechanism will perform one-way authentication (without confirmation or any return token from target to initiator in response to the initiator's KRB_AP_REQ) if the mutual_req bit is not set in the application's call to GSS_Init_sec_context(). Applications requiring confirmation that their authentication was successful should request mutual authentication, resulting in a "mutual-required" indication within KRB_AP_REQ APoptions and the setting of the mutual_req bit in the
互いの_reqビットがGSS_Init_秒_文脈()へのアプリケーションの呼び出しで設定されないと、ケルベロスV5メカニズムに基づく文脈設立系列は一方向認証(確認か創始者のKRB_AP_REQに対応した少しも目標から創始者までのリターントークンのない)を実行するでしょう。 互いの_のREQ APoptionsと設定がreqするKRB_AP_の中の確認を必要として、彼らの認証がうまくいったのが互いの認証を要求するべきであり、aへの結果になるのが「互いに必要」であるというアプリケーション指示に中で噛み付きました。
Linn Standards Track [Page 5] RFC 1964 Kerberos Version 5 GSS-API June 1996
リンStandardsはGSS-API1996年6月にRFC1964ケルベロスバージョン5を追跡します[5ページ]。
flags field of the authenticator checksum. In response to such a request, the context target will reply to the initiator with a token containing either a KRB_AP_REP or KRB_ERROR, completing the mutual context establishment exchange.
固有識別文字チェックサムの分野に旗を揚げさせます。 そのような要求に対応して、文脈目標はKRB_AP_REPを含むトークンかKRB_ERRORと共に創始者に答えるでしょう、互いの文脈設立交換を終了して。
Relevant KRB_AP_REP syntax is as follows:
関連KRB_AP_REP構文は以下の通りです:
AP-REP ::= [APPLICATION 15] SEQUENCE {
pvno [0] INTEGER, -- represents Kerberos V5
msg-type [1] INTEGER, -- represents KRB_AP_REP
enc-part [2] EncryptedData
}
AP-レップ:、:= [アプリケーション15] 系列pvno[0]INTEGER--、表す、ケルベロスは[1] INTEGERをV5 msgタイプします--[2] KRB_AP_REP enc-パートEncryptedDataを表します。
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime,
cusec [1] INTEGER,
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] INTEGER OPTIONAL
}
EncAPRepPart:、:= [アプリケーション27] 系列ctime[0]KerberosTime、キューセック[1]INTEGER、サブキー[2]EncryptionKey OPTIONAL、seq-数の[3]INTEGER OPTIONAL
The optional seq-number element within the AP-REP's EncAPRepPart shall be included.
AP-REPのEncAPRepPartの中の任意のseq-数の要素は含まれているものとします。
The syntax of KRB_ERROR is as follows:
KRB_ERRORの構文は以下の通りです:
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
ctime[2] KerberosTime OPTIONAL,
cusec[3] INTEGER OPTIONAL,
stime[4] KerberosTime,
susec[5] INTEGER,
error-code[6] INTEGER,
crealm[7] Realm OPTIONAL,
cname[8] PrincipalName OPTIONAL,
realm[9] Realm, -- Correct realm
sname[10] PrincipalName, -- Correct name
e-text[11] GeneralString OPTIONAL,
e-data[12] OCTET STRING OPTIONAL
}
KRB-誤り:、:= [アプリケーション30] 系列pvno[0] INTEGER、[1] msg-タイプINTEGER、ctime[2] KerberosTime OPTIONAL、キューセック[3]INTEGER OPTIONAL、stime[4] KerberosTime、susec[5] INTEGER、エラーコード[6]INTEGER、crealm[7]分野OPTIONAL、cname[8] PrincipalName OPTIONAL、分野[9]分野--正しい分野sname[10] PrincipalName--Correctは電子テキストを[11]GeneralString OPTIONALと命名します、電子データ[12]OCTET STRING OPTIONALです。
Values to be transferred in the error-code field of a KRB-ERROR message are defined in [RFC-1510], not in this specification.
KRB-ERRORメッセージのエラーコード分野で移されるべき値はこの仕様に基づき定義されるのではなく、[RFC-1510]で定義されます。
Linn Standards Track [Page 6] RFC 1964 Kerberos Version 5 GSS-API June 1996
リンStandardsはGSS-API1996年6月にRFC1964ケルベロスバージョン5を追跡します[6ページ]。
1.2. Per-Message and Context Deletion Tokens
1.2. メッセージと文脈削除トークン
Three classes of tokens are defined in this section: "MIC" tokens, emitted by calls to GSS_GetMIC() (formerly GSS_Sign()) and consumed by calls to GSS_VerifyMIC() (formerly GSS_Verify()), "Wrap" tokens, emitted by calls to GSS_Wrap() (formerly GSS_Seal()) and consumed by calls to GSS_Unwrap() (formerly GSS_Unseal()), and context deletion tokens, emitted by calls to GSS_Delete_sec_context() and consumed by calls to GSS_Process_context_token(). Note: References to GSS-API per-message routines in the remainder of this specification will be based on those routines' newer recommended names rather than those names' predecessors.
3つのクラスのトークンはこのセクションで定義されます: GSS_GetMIC()への呼び出しで放たれた"MIC"トークン、(以前GSS_Sign())であってGSS_VerifyMIC()への呼び出しで消費される、(以前GSS_Verify())(「包装」トークン)がGSS_Wrap()への呼び出しで放った、(以前GSS_Seal())であってGSS_Unwrap()への呼び出しで消費される、(以前Unseal())、および文脈削除トークンがGSS_Process_文脈_トークン()にGSS_Delete_秒_文脈()への呼び出しで放って、呼び出しで消費したGSS_。 以下に注意してください。 この仕様の残りにおける1メッセージあたりのGSS-APIルーチンの参照はそれらの名前の前任者よりむしろそれらのルーチンのさらに新しいお勧めの名前に基づくでしょう。
Several variants of cryptographic keys are used in generation and processing of per-message tokens:
暗号化キーのいくつかの異形が1メッセージあたりのトークンの世代と処理に使用されます:
(1) context key: uses Kerberos session key (or subkey, if
present in authenticator emitted by context initiator) directly
(1) 文脈キー: または、ケルベロスセッションキーを使用する、(サブキー、文脈創始者によって放たれた固有識別文字で存在しているなら直接
(2) confidentiality key: forms variant of context key by
exclusive-OR with the hexadecimal constant f0f0f0f0f0f0f0f0.
(2) 秘密性キー: 16進定数f0f0f0f0f0f0f0f0によって排他的論理和で主要な文脈の異形を形成します。
(3) MD2.5 seed key: forms variant of context key by reversing
the bytes of the context key (i.e. if the original key is the
8-byte sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the seed key
will be {hh, gg, ff, ee, dd, cc, bb, aa}).
(3) MD2.5はキーに種を蒔きます: 文脈キー(オリジナルのキーがすなわち、aaに、bbに、cc(ddであって、eeなff、gg)がhhする8バイトの系列であるなら、種子キーはhh、gg、ff、ee、dd、cc、bb、aaになる)のバイトを逆にすることによって主要な文脈の異形を形成します。
1.2.1. Per-message Tokens - MIC
1.2.1. 1メッセージあたりのトークン--MIC
Use of the GSS_GetMIC() call yields a token, separate from the user data being protected, which can be used to verify the integrity of that data as received. The token has the following format:
GSS_GetMIC()呼び出しの使用はトークンをもたらします、保護される利用者データから、別々です。(受け取るようにそのデータの保全について確かめるのに利用者データを使用できます)。 トークンには、以下の形式があります:
Byte no Name Description
0..1 TOK_ID Identification field.
Tokens emitted by GSS_GetMIC() contain
the hex value 01 01 in this field.
2..3 SGN_ALG Integrity algorithm indicator.
00 00 - DES MAC MD5
01 00 - MD2.5
02 00 - DES MAC
4..7 Filler Contains ff ff ff ff
8..15 SND_SEQ Sequence number field.
16..23 SGN_CKSUM Checksum of "to-be-signed data",
calculated according to algorithm
specified in SGN_ALG field.
バイトはName記述ではありません0。1 ID IdentificationがさばくTOK_。 GSS_GetMIC()によって放たれたトークンはこの分野に十六進法値01 01を保管しています。 2..3SGN_ALG Integrityアルゴリズムインディケータ。 00 00--デスMac MD5 01 00--MD2.5 02 00--デスMAC4。7 フィラーContains ff ff ff ff8。15 SND_SEQ Sequenceナンバーフィールド。 16..23 ALGがさばくSGN_で指定されたアルゴリズムによると、計算された「署名しているデータ」のSGN_CKSUM Checksum。
Linn Standards Track [Page 7] RFC 1964 Kerberos Version 5 GSS-API June 1996
リンStandardsはGSS-API1996年6月にRFC1964ケルベロスバージョン5を追跡します[7ページ]。
GSS-API tokens must be encapsulated within the higher-level protocol by the application; no embedded length field is necessary.
上位レベル・プロトコルの中でアプリケーションでGSS-APIトークンをカプセル化しなければなりません。 どんな埋め込まれた長さの分野も必要ではありません。
1.2.1.1. Checksum
1.2.1.1. チェックサム
Checksum calculation procedure (common to all algorithms): Checksums are calculated over the data field, logically prepended by the first 8 bytes of the plaintext packet header. The resulting value binds the data to the packet type and signature algorithm identifier fields.
チェックサム計算手順(すべてのアルゴリズムに共通の): チェックサムは、データ・フィールドに関して計算されて、平文パケットのヘッダーの最初の8バイトによって論理的にprependedされています。 結果として起こる値はパケットタイプと署名アルゴリズム識別子分野にデータを縛ります。
DES MAC MD5 algorithm: The checksum is formed by computing an MD5 [RFC-1321] hash over the plaintext data, and then computing a DES-CBC MAC on the 16-byte MD5 result. A standard 64-bit DES-CBC MAC is computed per [FIPS-PUB-113], employing the context key and a zero IV. The 8-byte result is stored in the SGN_CKSUM field.
DES MAC MD5アルゴリズム: チェックサムは、平文データに関してMD5[RFC-1321]ハッシュを計算して、次に、16バイトのMD5結果でDES-CBC MACを計算することによって、形成されます。 標準の64ビットのDES-CBC MACは[FIPS-PUB-113]単位で計算されて、文脈キーを使って、aはIVのゼロに合っています。 8バイトの結果はSGN_CKSUM分野に保存されます。
MD2.5 algorithm: The checksum is formed by first DES-CBC encrypting a
16-byte zero-block, using a zero IV and a key formed by reversing the
bytes of the context key (i.e. if the original key is the 8-byte
sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will be
{hh, gg, ff, ee, dd, cc, bb, aa}). The resulting 16-byte value is
logically prepended to the to-be-signed data. A standard MD5
checksum is calculated over the combined data, and the first 8 bytes
of the result are stored in the SGN_CKSUM field. Note 1: we refer to
this algorithm informally as "MD2.5" to connote the fact that it uses
half of the 128 bits generated by MD5; use of only a subset of the
MD5 bits is intended to protect against the prospect that data could
be postfixed to an existing message with corresponding modifications
being made to the checksum. Note 2: This algorithm is fairly novel
and has received more limited evaluation than that to which other
integrity algorithms have been subjected. An initial, limited
evaluation indicates that it may be significantly weaker than DES MAC
MD5.
MD2.5アルゴリズム: チェックサムは16バイトの無ブロックを暗号化しながら、最初に、DES-CBCによって形成されて、aをIVとaがないのが合わせる使用するのは文脈キーのバイトを逆にすることによって、形成されました(オリジナルのキーがすなわち、aaに、bbに、cc(ddであって、eeなff、gg)がhhする8バイトの系列であるなら、チェックサムキーはhh、gg、ff、ee、dd、cc、bb、aaになるでしょう)。 結果として起こる16バイトの値は署名しているデータに論理的にprependedされます。 標準のMD5チェックサムは結合したデータに関して計算されます、そして、結果の最初の8バイトはSGN_CKSUM分野に保存されます。 注意1: 私たちは「MD5によって生成された半分の128ビットを使用するという事実を内包するMD2.5"」とこのアルゴリズムを非公式に呼びます。 MD5ビットの部分集合だけの使用が対応する変更をチェックサムにしていて既存のメッセージをデータを語尾に添えることができたという見通しから守ることを意図します。 注意2: このアルゴリズムは、かなり目新しく、他の保全アルゴリズムをかけてあるそれより限られた評価を受け取りました。 初期の、そして、限られた評価は、それがDES MAC MD5よりかなり弱いかもしれないのを示します。
DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on the plaintext data per [FIPS-PUB-113], employing the context key and a zero IV. Padding procedures to accomodate plaintext data lengths which may not be integral multiples of 8 bytes are defined in [FIPS- PUB-113]. The result is an 8-byte value, which is stored in the SGN_CKSUM field. Support for this algorithm may not be present in all implementations.
DES-MACアルゴリズム: 標準の64ビットのDES-CBC MACは[FIPS-PUB-113]あたりの平文データで計算されて、文脈キーを使って、aはIVのゼロに合っています。 accomodate平文データの長さに手順を水増しして、どれが8バイトの整数倍でないかもしれないかは[FIPS- PUB-113]で定義されます。 結果は8バイトの値です。(その値はSGN_CKSUM分野に保存されます)。 このアルゴリズムのサポートはすべての実装で存在していないかもしれません。
1.2.1.2. Sequence Number
1.2.1.2. 一連番号
Sequence number field: The 8 byte plaintext sequence number field is formed from the sender's four-byte sequence number as follows. If the four bytes of the sender's sequence number are named s0, s1, s2
一連番号分野: 8バイトの平文一連番号分野は以下の送付者の4バイトの系列番号から形成されます。 送付者の4バイトの一連番号がs0、s1、s2と命名されるなら
Linn Standards Track [Page 8] RFC 1964 Kerberos Version 5 GSS-API June 1996
リンStandardsはGSS-API1996年6月にRFC1964ケルベロスバージョン5を追跡します[8ページ]。
and s3 (from least to most significant), the plaintext sequence number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di, di), where 'di' is the direction-indicator (Hex 0 - sender is the context initiator, Hex FF - sender is the context acceptor). The field is then DES-CBC encrypted using the context key and an IV formed from the first 8 bytes of the previously calculated SGN_CKSUM field. After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence number is incremented by one.
s3(最少から最も重要になるまでの)、そして、平文一連番号分野は8バイト列です: (s0、s1、s2、s3、ディ、ディ、ディ、ディ), 'ディ'が方向インディケータ(0人に魔法をかけてください--送付者は文脈創始者です、Hex FF--送付者は文脈アクセプタである)であるところ。 そして、分野は以前に計算されたSGN_CKSUM分野の最初の8バイトから形成された文脈キーとIVを使用することで暗号化されたDES-CBCです。 GSS_GetMIC()かGSS_Wrap()トークンを送った後に、送付者の一連番号は1つ増加されます。
The receiver of the token will first verify the SGN_CKSUM field. If valid, the sequence number field may be decrypted and compared to the expected sequence number. The repetition of the (effectively 1-bit) direction indicator within the sequence number field provides redundancy so that the receiver may verify that the decryption succeeded.
トークンの受信機は最初に、SGN_CKSUM分野について確かめるでしょう。 有効であるなら、一連番号分野は、予想された一連番号に解読されて、たとえられるかもしれません。 一連番号分野の中の(事実上1ビット)の方向インディケータの反復は、受信機が、復号化が成功したことを確かめることができるように、冗長を提供します。
Since the checksum computation is used as an IV to the sequence number decryption, attempts to splice a checksum and sequence number from different messages will be detected. The direction indicator will detect packets that have been maliciously reflected.
チェックサム計算がIVとして一連番号復号化に使用されるので、異なったメッセージからチェックサムと一連番号を継ぐ試みは検出されるでしょう。 方向インディケータは陰湿に反映されたパケットを検出するでしょう。
The sequence number provides a basis for detection of replayed tokens. Replay detection can be performed using state information retained on received sequence numbers, interpreted in conjunction with the security context on which they arrive.
一連番号は再演されたトークンの検出の基礎を提供します。 それらが到着するセキュリティ文脈に関連して解釈された容認された一連番号で保有された州の情報を使用することで再生検出を実行できます。
Provision of per-message replay and out-of-sequence detection services is optional for implementations of the Kerberos V5 GSS-API mechanism. Further, it is recommended that implementations of the Kerberos V5 GSS-API mechanism which offer these services should honor a caller's request that the services be disabled on a context. Specifically, if replay_det_req_flag is input FALSE, replay_det_state should be returned FALSE and the GSS_DUPLICATE_TOKEN and GSS_OLD_TOKEN stati should not be indicated as a result of duplicate detection when tokens are processed; if sequence_req_flag is input FALSE, sequence_state should be returned FALSE and GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_TOKEN stati should not be indicated as a result of out-of-sequence detection when tokens are processed.
ケルベロスV5 GSS-APIメカニズムの実装に、1メッセージあたりの再生の、そして、順序が狂って検出サービスの支給は任意です。 さらに、これらのサービスを提供するケルベロスV5 GSS-APIメカニズムの実装がサービスが文脈で無効にされるという訪問者の要求を光栄に思うのは、お勧めです。 明確に、再生_det_req_旗が入力FALSEであるなら、再生_det_状態にFALSEを返すべきです、そして、トークンを処理するとき、写し検出の結果、GSS_DUPLICATE_TOKENとGSS_OLD_TOKEN statiを示すべきではありません。 系列_req_旗が入力FALSEであるなら、系列_状態にFALSEを返すべきです、そして、トークンを処理するとき、順序が狂って検出の結果、GSS_DUPLICATE_TOKEN、GSS_OLD_TOKEN、およびGSS_UNSEQ_TOKEN statiを示すべきではありません。
1.2.2. Per-message Tokens - Wrap
1.2.2. 1メッセージあたりのトークン--包装
Use of the GSS_Wrap() call yields a token which encapsulates the input user data (optionally encrypted) along with associated integrity check quantities. The token emitted by GSS_Wrap() consists of an integrity header whose format is identical to that emitted by GSS_GetMIC() (except that the TOK_ID field contains the value 02 01), followed by a body portion that contains either the plaintext data
GSS_Wrap()呼び出しの使用は関連保全チェック量と共に入力が利用者データであるとカプセル化する(任意に暗号化されます)トークンをもたらします。 GSS_Wrap()によって放たれたトークンは形式が平文データを含むボディー部分があとに続いたGSS_GetMIC()(TOK_ID分野が値02 01を含んでいるのを除いて)によって放たれたそれと同じである保全ヘッダーから成ります。
Linn Standards Track [Page 9] RFC 1964 Kerberos Version 5 GSS-API June 1996
リンStandardsはGSS-API1996年6月にRFC1964ケルベロスバージョン5を追跡します[9ページ]。
(if SEAL_ALG = ff ff) or encrypted data for any other supported value of SEAL_ALG. Currently, only SEAL_ALG = 00 00 is supported, and means that DES-CBC encryption is being used to protect the data.
(SEAL_ALGがff ffと等しいなら) または、SEAL_ALGの値であるとサポートされたいかなる他の暗号化されたデータ。 現在、SEAL_ALG=00 00だけ、が、サポートされて、DES-CBC暗号化がデータを保護するのに使用されていることを意味します。
The GSS_Wrap() token has the following format:
GSS_Wrap()トークンには、以下の形式があります:
Byte no Name Description
0..1 TOK_ID Identification field.
Tokens emitted by GSS_Wrap() contain
the hex value 02 01 in this field.
2..3 SGN_ALG Checksum algorithm indicator.
00 00 - DES MAC MD5
01 00 - MD2.5
02 00 - DES MAC
4..5 SEAL_ALG ff ff - none
00 00 - DES
6..7 Filler Contains ff ff
8..15 SND_SEQ Encrypted sequence number field.
16..23 SGN_CKSUM Checksum of plaintext padded data,
calculated according to algorithm
specified in SGN_ALG field.
24..last Data encrypted or plaintext padded data
バイトはName記述ではありません0。1 ID IdentificationがさばくTOK_。 GSS_Wrap()によって放たれたトークンはこの分野に十六進法値02 01を保管しています。 2..3SGN_ALG Checksumアルゴリズムインディケータ。 00 00--デスMac MD5 01 00--MD2.5 02 00--デスMAC4。5 SEAL_ALG ff ff--なにも、00 00--DES6。7 フィラーContains ff ff8。15SND_SEQ Encrypted一連番号分野。 16..23 平文のSGN_CKSUM ChecksumはALGがさばくSGN_で指定されたアルゴリズムによると、計算されたデータを水増ししました。 24..暗号化された最後のDataか平文がデータを水増ししました。
GSS-API tokens must be encapsulated within the higher-level protocol by the application; no embedded length field is necessary.
上位レベル・プロトコルの中でアプリケーションでGSS-APIトークンをカプセル化しなければなりません。 どんな埋め込まれた長さの分野も必要ではありません。
1.2.2.1. Checksum
1.2.2.1. チェックサム
Checksum calculation procedure (common to all algorithms): Checksums are calculated over the plaintext padded data field, logically prepended by the first 8 bytes of the plaintext packet header. The resulting signature binds the data to the packet type, protocol version, and signature algorithm identifier fields.
チェックサム計算手順(すべてのアルゴリズムに共通の): チェックサムは、平文そっと歩いているデータ・フィールドに関して計算されて、平文パケットのヘッダーの最初の8バイトによって論理的にprependedされています。 結果として起こる署名はパケットタイプ、プロトコルバージョン、および署名アルゴリズム識別子分野にデータを縛ります。
DES MAC MD5 algorithm: The checksum is formed by computing an MD5 hash over the plaintext padded data, and then computing a DES-CBC MAC on the 16-byte MD5 result. A standard 64-bit DES-CBC MAC is computed per [FIPS-PUB-113], employing the context key and a zero IV. The 8- byte result is stored in the SGN_CKSUM field.
DES MAC MD5アルゴリズム: チェックサムは、平文そっと歩いているデータに関してMD5ハッシュを計算して、次に、16バイトのMD5結果でDES-CBC MACを計算することによって、形成されます。 標準の64ビットのDES-CBC MACは[FIPS-PUB-113]単位で計算されて、文脈キーを使って、aはIVのゼロに合っています。 8バイト結果はSGN_CKSUM分野に保存されます。
MD2.5 algorithm: The checksum is formed by first DES-CBC encrypting a
16-byte zero-block, using a zero IV and a key formed by reversing the
bytes of the context key (i.e., if the original key is the 8-byte
sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will be
{hh, gg, ff, ee, dd, cc, bb, aa}). The resulting 16-byte value is
logically pre-pended to the "to-be-signed data". A standard MD5
checksum is calculated over the combined data, and the first 8 bytes
of the result are stored in the SGN_CKSUM field.
MD2.5アルゴリズム: チェックサムは16バイトの無ブロックを暗号化しながら、最初に、DES-CBCによって形成されて、aをIVとaがないのが合わせる使用するのは文脈キーのバイトを逆にすることによって、形成されました(オリジナルのキーがすなわち、aaに、bbに、cc(ddであって、eeなff、gg)がhhする8バイトの系列であるなら、チェックサムキーはhh、gg、ff、ee、dd、cc、bb、aaになるでしょう)。 結果として起こる16バイトの値は「署名しているデータ」に論理的にあらかじめpendedされます。 標準のMD5チェックサムは結合したデータに関して計算されます、そして、結果の最初の8バイトはSGN_CKSUM分野に保存されます。
Linn Standards Track [Page 10] RFC 1964 Kerberos Version 5 GSS-API June 1996
リンStandardsはGSS-API1996年6月にRFC1964ケルベロスバージョン5を追跡します[10ページ]。
DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on the plaintext padded data per [FIPS-PUB-113], employing the context key and a zero IV. The plaintext padded data is already assured to be an integral multiple of 8 bytes; no additional padding is required or applied in order to accomplish MAC calculation. The result is an 8- byte value, which is stored in the SGN_CKSUM field. Support for this lgorithm may not be present in all implementations.
DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on the plaintext padded data per [FIPS-PUB-113], employing the context key and a zero IV. The plaintext padded data is already assured to be an integral multiple of 8 bytes; no additional padding is required or applied in order to accomplish MAC calculation. The result is an 8- byte value, which is stored in the SGN_CKSUM field. Support for this lgorithm may not be present in all implementations.
1.2.2.2. Sequence Number
1.2.2.2. Sequence Number
Sequence number field: The 8 byte plaintext sequence number field is formed from the sender's four-byte sequence number as follows. If the four bytes of the sender's sequence number are named s0, s1, s2 and s3 (from least to most significant), the plaintext sequence number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di, di), where 'di' is the direction-indicator (Hex 0 - sender is the context initiator, Hex FF - sender is the context acceptor).
Sequence number field: The 8 byte plaintext sequence number field is formed from the sender's four-byte sequence number as follows. If the four bytes of the sender's sequence number are named s0, s1, s2 and s3 (from least to most significant), the plaintext sequence number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di, di), where 'di' is the direction-indicator (Hex 0 - sender is the context initiator, Hex FF - sender is the context acceptor).
The field is then DES-CBC encrypted using the context key and an IV formed from the first 8 bytes of the SEAL_CKSUM field.
The field is then DES-CBC encrypted using the context key and an IV formed from the first 8 bytes of the SEAL_CKSUM field.
After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence numbers are incremented by one.
After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence numbers are incremented by one.
1.2.2.3. Padding
1.2.2.3. Padding
Data padding: Before encryption and/or signature calculation, plaintext data is padded to the next highest multiple of 8 bytes, by appending between 1 and 8 bytes, the value of each such byte being the total number of pad bytes. For example, given data of length 20 bytes, four pad bytes will be appended, and each byte will contain the hex value 04. An 8-byte random confounder is prepended to the data, and signatures are calculated over the resulting padded plaintext.
Data padding: Before encryption and/or signature calculation, plaintext data is padded to the next highest multiple of 8 bytes, by appending between 1 and 8 bytes, the value of each such byte being the total number of pad bytes. For example, given data of length 20 bytes, four pad bytes will be appended, and each byte will contain the hex value 04. An 8-byte random confounder is prepended to the data, and signatures are calculated over the resulting padded plaintext.
After padding, the data is encrypted according to the algorithm specified in the SEAL_ALG field. For SEAL_ALG=DES (the only non-null algorithm currently supported), the data is encrypted using DES-CBC, with an IV of zero. The key used is derived from the established context key by XOR-ing the context key with the hexadecimal constant f0f0f0f0f0f0f0f0.
After padding, the data is encrypted according to the algorithm specified in the SEAL_ALG field. For SEAL_ALG=DES (the only non-null algorithm currently supported), the data is encrypted using DES-CBC, with an IV of zero. The key used is derived from the established context key by XOR-ing the context key with the hexadecimal constant f0f0f0f0f0f0f0f0.
1.2.3. Context deletion token
1.2.3. Context deletion token
The token emitted by GSS_Delete_sec_context() is based on the packet format for tokens emitted by GSS_GetMIC(). The context-deletion token has the following format:
The token emitted by GSS_Delete_sec_context() is based on the packet format for tokens emitted by GSS_GetMIC(). The context-deletion token has the following format:
Linn Standards Track [Page 11] RFC 1964 Kerberos Version 5 GSS-API June 1996
Linn Standards Track [Page 11] RFC 1964 Kerberos Version 5 GSS-API June 1996
Byte no Name Description
0..1 TOK_ID Identification field.
Tokens emitted by
GSS_Delete_sec_context() contain
the hex value 01 02 in this field.
2..3 SGN_ALG Integrity algorithm indicator.
00 00 - DES MAC MD5
01 00 - MD2.5
02 00 - DES MAC
4..7 Filler Contains ff ff ff ff
8..15 SND_SEQ Sequence number field.
16..23 SGN_CKSUM Checksum of "to-be-signed data",
calculated according to algorithm
specified in SGN_ALG field.
Byte no Name Description 0..1 TOK_ID Identification field. Tokens emitted by GSS_Delete_sec_context() contain the hex value 01 02 in this field. 2..3 SGN_ALG Integrity algorithm indicator. 00 00 - DES MAC MD5 01 00 - MD2.5 02 00 - DES MAC 4..7 Filler Contains ff ff ff ff 8..15 SND_SEQ Sequence number field. 16..23 SGN_CKSUM Checksum of "to-be-signed data", calculated according to algorithm specified in SGN_ALG field.
SGN_ALG and SND_SEQ will be calculated as for tokens emitted by GSS_GetMIC(). The SGN_CKSUM will be calculated as for tokens emitted by GSS_GetMIC(), except that the user-data component of the "to-be- signed" data will be a zero-length string.
SGN_ALG and SND_SEQ will be calculated as for tokens emitted by GSS_GetMIC(). The SGN_CKSUM will be calculated as for tokens emitted by GSS_GetMIC(), except that the user-data component of the "to-be- signed" data will be a zero-length string.
2. Name Types and Object Identifiers
2. Name Types and Object Identifiers
This section discusses the name types which may be passed as input to the Kerberos V5 GSS-API mechanism's GSS_Import_name() call, and their associated identifier values. It defines interface elements in support of portability, and assumes use of C language bindings per RFC-1509. In addition to specifying OID values for name type identifiers, symbolic names are included and recommended to GSS-API implementors in the interests of convenience to callers. It is understood that not all implementations of the Kerberos V5 GSS-API mechanism need support all name types in this list, and that additional name forms will likely be added to this list over time. Further, the definitions of some or all name types may later migrate to other, mechanism-independent, specifications. The occurrence of a name type in this specification is specifically not intended to suggest that the type may be supported only by an implementation of the Kerberos V5 mechanism. In particular, the occurrence of the string "_KRB5_" in the symbolic name strings constitutes a means to unambiguously register the name strings, avoiding collision with other documents; it is not meant to limit the name types' usage or applicability.
This section discusses the name types which may be passed as input to the Kerberos V5 GSS-API mechanism's GSS_Import_name() call, and their associated identifier values. It defines interface elements in support of portability, and assumes use of C language bindings per RFC-1509. In addition to specifying OID values for name type identifiers, symbolic names are included and recommended to GSS-API implementors in the interests of convenience to callers. It is understood that not all implementations of the Kerberos V5 GSS-API mechanism need support all name types in this list, and that additional name forms will likely be added to this list over time. Further, the definitions of some or all name types may later migrate to other, mechanism-independent, specifications. The occurrence of a name type in this specification is specifically not intended to suggest that the type may be supported only by an implementation of the Kerberos V5 mechanism. In particular, the occurrence of the string "_KRB5_" in the symbolic name strings constitutes a means to unambiguously register the name strings, avoiding collision with other documents; it is not meant to limit the name types' usage or applicability.
For purposes of clarification to GSS-API implementors, this section's discussion of some name forms describes means through which those forms can be supported with existing Kerberos technology. These discussions are not intended to preclude alternative implementation strategies for support of the name forms within Kerberos mechanisms or mechanisms based on other technologies. To enhance application
For purposes of clarification to GSS-API implementors, this section's discussion of some name forms describes means through which those forms can be supported with existing Kerberos technology. These discussions are not intended to preclude alternative implementation strategies for support of the name forms within Kerberos mechanisms or mechanisms based on other technologies. To enhance application
Linn Standards Track [Page 12] RFC 1964 Kerberos Version 5 GSS-API June 1996
Linn Standards Track [Page 12] RFC 1964 Kerberos Version 5 GSS-API June 1996
portability, implementors of mechanisms are encouraged to support name forms as defined in this section, even if their mechanisms are independent of Kerberos V5.
portability, implementors of mechanisms are encouraged to support name forms as defined in this section, even if their mechanisms are independent of Kerberos V5.
2.1. Mandatory Name Forms
2.1. Mandatory Name Forms
This section discusses name forms which are to be supported by all conformant implementations of the Kerberos V5 GSS-API mechanism.
This section discusses name forms which are to be supported by all conformant implementations of the Kerberos V5 GSS-API mechanism.
2.1.1. Kerberos Principal Name Form
2.1.1. Kerberos Principal Name Form
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
krb5(2) krb5_name(1)}. The recommended symbolic name for this type
is "GSS_KRB5_NT_PRINCIPAL_NAME".
This name form shall be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) krb5(2) krb5_name(1)}. The recommended symbolic name for this type is "GSS_KRB5_NT_PRINCIPAL_NAME".
This name type corresponds to the single-string representation of a Kerberos name. (Within the MIT Kerberos V5 implementation, such names are parseable with the krb5_parse_name() function.) The elements included within this name representation are as follows, proceeding from the beginning of the string:
This name type corresponds to the single-string representation of a Kerberos name. (Within the MIT Kerberos V5 implementation, such names are parseable with the krb5_parse_name() function.) The elements included within this name representation are as follows, proceeding from the beginning of the string:
(1) One or more principal name components; if more than one
principal name component is included, the components are
separated by `/`. Arbitrary octets may be included within
principal name components, with the following constraints and
special considerations:
(1) One or more principal name components; if more than one principal name component is included, the components are separated by `/`. Arbitrary octets may be included within principal name components, with the following constraints and special considerations:
(1a) Any occurrence of the characters `@` or `/` within a
name component must be immediately preceded by the `\`
quoting character, to prevent interpretation as a component
or realm separator.
(1a) Any occurrence of the characters `@` or `/` within a name component must be immediately preceded by the `\` quoting character, to prevent interpretation as a component or realm separator.
(1b) The ASCII newline, tab, backspace, and null characters
may occur directly within the component or may be
represented, respectively, by `\n`, `\t`, `\b`, or `%%BODY%%`.
(1b) The ASCII newline, tab, backspace, and null characters may occur directly within the component or may be represented, respectively, by `\n`, `\t`, `\b`, or `%%BODY%%`.
(1c) If the `\` quoting character occurs outside the contexts
described in (1a) and (1b) above, the following character is
interpreted literally. As a special case, this allows the
doubled representation `\\` to represent a single occurrence
of the quoting character.
(1c) If the `\` quoting character occurs outside the contexts described in (1a) and (1b) above, the following character is interpreted literally. As a special case, this allows the doubled representation `\\` to represent a single occurrence of the quoting character.
(1d) An occurrence of the `\` quoting character as the last
character of a component is illegal.
(1d) An occurrence of the `\` quoting character as the last character of a component is illegal.
Linn Standards Track [Page 13] RFC 1964 Kerberos Version 5 GSS-API June 1996
Linn Standards Track [Page 13] RFC 1964 Kerberos Version 5 GSS-API June 1996
(2) Optionally, a `@` character, signifying that a realm name
immediately follows. If no realm name element is included, the
local realm name is assumed. The `/` , `:`, and null characters
may not occur within a realm name; the `@`, newline, tab, and
backspace characters may be included using the quoting
conventions described in (1a), (1b), and (1c) above.
(2) Optionally, a `@` character, signifying that a realm name immediately follows. If no realm name element is included, the local realm name is assumed. The `/` , `:`, and null characters may not occur within a realm name; the `@`, newline, tab, and backspace characters may be included using the quoting conventions described in (1a), (1b), and (1c) above.
2.1.2. Host-Based Service Name Form
2.1.2. Host-Based Service Name Form
This name form has been incorporated at the mechanism-independent GSS-API level as of GSS-API, Version 2. This subsection retains the Object Identifier and symbolic name assignments previously made at the Kerberos V5 GSS-API mechanism level, and adopts the definition as promoted to the mechanism-independent level.
This name form has been incorporated at the mechanism-independent GSS-API level as of GSS-API, Version 2. This subsection retains the Object Identifier and symbolic name assignments previously made at the Kerberos V5 GSS-API mechanism level, and adopts the definition as promoted to the mechanism-independent level.
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
generic(1) service_name(4)}. The previously recommended symbolic
name for this type is "GSS_KRB5_NT_HOSTBASED_SERVICE_NAME". The
currently preferred symbolic name for this type is
"GSS_C_NT_HOSTBASED_SERVICE".
This name form shall be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) service_name(4)}. The previously recommended symbolic name for this type is "GSS_KRB5_NT_HOSTBASED_SERVICE_NAME". The currently preferred symbolic name for this type is "GSS_C_NT_HOSTBASED_SERVICE".
This name type is used to represent services associated with host computers. This name form is constructed using two elements, "service" and "hostname", as follows:
This name type is used to represent services associated with host computers. This name form is constructed using two elements, "service" and "hostname", as follows:
service@hostname
service@hostname
When a reference to a name of this type is resolved, the "hostname" is canonicalized by attempting a DNS lookup and using the fully- qualified domain name which is returned, or by using the "hostname" as provided if the DNS lookup fails. The canonicalization operation also maps the host's name into lower-case characters.
When a reference to a name of this type is resolved, the "hostname" is canonicalized by attempting a DNS lookup and using the fully- qualified domain name which is returned, or by using the "hostname" as provided if the DNS lookup fails. The canonicalization operation also maps the host's name into lower-case characters.
The "hostname" element may be omitted. If no "@" separator is included, the entire name is interpreted as the service specifier, with the "hostname" defaulted to the canonicalized name of the local host.
The "hostname" element may be omitted. If no "@" separator is included, the entire name is interpreted as the service specifier, with the "hostname" defaulted to the canonicalized name of the local host.
Values for the "service" element will be registered with the IANA.
Values for the "service" element will be registered with the IANA.
2.1.3. Exported Name Object Form for Kerberos V5 Mechanism
2.1.3. Exported Name Object Form for Kerberos V5 Mechanism
Support for this name form is not required for GSS-V1 implementations, but will be required for use in conjunction with the GSS_Export_name() call planned for GSS-API Version 2. Use of this name form will be signified by a "GSS-API Exported Name Object" OID value which will be defined at the mechanism-independent level for
Support for this name form is not required for GSS-V1 implementations, but will be required for use in conjunction with the GSS_Export_name() call planned for GSS-API Version 2. Use of this name form will be signified by a "GSS-API Exported Name Object" OID value which will be defined at the mechanism-independent level for
Linn Standards Track [Page 14] RFC 1964 Kerberos Version 5 GSS-API June 1996
Linn Standards Track [Page 14] RFC 1964 Kerberos Version 5 GSS-API June 1996
GSS-API Version 2.
GSS-API Version 2.
This name type represents a self-describing object, whose framing structure will be defined at the mechanism-independent level for GSS-API Version 2. When generated by the Kerberos V5 mechanism, the Mechanism OID within the exportable name shall be that of the Kerberos V5 mechanism. The name component within the exportable name shall be a contiguous string with structure as defined for the Kerberos Principal Name Form.
This name type represents a self-describing object, whose framing structure will be defined at the mechanism-independent level for GSS-API Version 2. When generated by the Kerberos V5 mechanism, the Mechanism OID within the exportable name shall be that of the Kerberos V5 mechanism. The name component within the exportable name shall be a contiguous string with structure as defined for the Kerberos Principal Name Form.
In order to achieve a distinguished encoding for comparison purposes, the following additional constraints are imposed on the export operation:
In order to achieve a distinguished encoding for comparison purposes, the following additional constraints are imposed on the export operation:
(1) all occurrences of the characters `@`, `/`, and `\` within
principal components or realm names shall be quoted with an
immediately-preceding `\`.
(1) all occurrences of the characters `@`, `/`, and `\` within principal components or realm names shall be quoted with an immediately-preceding `\`.
(2) all occurrences of the null, backspace, tab, or newline
characters within principal components or realm names will be
represented, respectively, with `%%BODY%%`, `\b`, `\t`, or `\n`.
(2) all occurrences of the null, backspace, tab, or newline characters within principal components or realm names will be represented, respectively, with `%%BODY%%`, `\b`, `\t`, or `\n`.
(3) the `\` quoting character shall not be emitted within an
exported name except to accomodate cases (1) and (2).
(3) the `\` quoting character shall not be emitted within an exported name except to accomodate cases (1) and (2).
2.2. Optional Name Forms
2.2. Optional Name Forms
This section discusses additional name forms which may optionally be supported by implementations of the Kerberos V5 GSS-API mechanism. It is recognized that some of the name forms cited here are derived from UNIX(tm) operating system platforms; some listed forms may be irrelevant to non-UNIX platforms, and definition of additional forms corresponding to such platforms may also be appropriate. It is also recognized that OS-specific functions outside GSS-API are likely to exist in order to perform translations among these forms, and that GSS-API implementations supporting these forms may themselves be layered atop such OS-specific functions. Inclusion of this support within GSS-API implementations is intended as a convenience to applications.
This section discusses additional name forms which may optionally be supported by implementations of the Kerberos V5 GSS-API mechanism. It is recognized that some of the name forms cited here are derived from UNIX(tm) operating system platforms; some listed forms may be irrelevant to non-UNIX platforms, and definition of additional forms corresponding to such platforms may also be appropriate. It is also recognized that OS-specific functions outside GSS-API are likely to exist in order to perform translations among these forms, and that GSS-API implementations supporting these forms may themselves be layered atop such OS-specific functions. Inclusion of this support within GSS-API implementations is intended as a convenience to applications.
2.2.1. User Name Form
2.2.1. User Name Form
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
generic(1) user_name(1)}. The recommended symbolic name for this
type is "GSS_KRB5_NT_USER_NAME".
This name form shall be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) user_name(1)}. The recommended symbolic name for this type is "GSS_KRB5_NT_USER_NAME".
This name type is used to indicate a named user on a local system.
This name type is used to indicate a named user on a local system.
Linn Standards Track [Page 15] RFC 1964 Kerberos Version 5 GSS-API June 1996
Linn Standards Track [Page 15] RFC 1964 Kerberos Version 5 GSS-API June 1996
Its interpretation is OS-specific. This name form is constructed as:
Its interpretation is OS-specific. This name form is constructed as:
username
username
Assuming that users' principal names are the same as their local operating system names, an implementation of GSS_Import_name() based on Kerberos V5 technology can process names of this form by postfixing an "@" sign and the name of the local realm.
Assuming that users' principal names are the same as their local operating system names, an implementation of GSS_Import_name() based on Kerberos V5 technology can process names of this form by postfixing an "@" sign and the name of the local realm.
2.2.2. Machine UID Form
2.2.2. Machine UID Form
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
generic(1) machine_uid_name(2)}. The recommended symbolic name for
this type is "GSS_KRB5_NT_MACHINE_UID_NAME".
This name form shall be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) machine_uid_name(2)}. The recommended symbolic name for this type is "GSS_KRB5_NT_MACHINE_UID_NAME".
This name type is used to indicate a numeric user identifier corresponding to a user on a local system. Its interpretation is OS-specific. The gss_buffer_desc representing a name of this type should contain a locally-significant uid_t, represented in host byte order. The GSS_Import_name() operation resolves this uid into a username, which is then treated as the User Name Form.
This name type is used to indicate a numeric user identifier corresponding to a user on a local system. Its interpretation is OS-specific. The gss_buffer_desc representing a name of this type should contain a locally-significant uid_t, represented in host byte order. The GSS_Import_name() operation resolves this uid into a username, which is then treated as the User Name Form.
2.2.3. String UID Form
2.2.3. String UID Form
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
generic(1) string_uid_name(3)}. The recommended symbolic name for
this type is "GSS_KRB5_NT_STRING_UID_NAME".
This name form shall be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) string_uid_name(3)}. The recommended symbolic name for this type is "GSS_KRB5_NT_STRING_UID_NAME".
This name type is used to indicate a string of digits representing the numeric user identifier of a user on a local system. Its interpretation is OS-specific. This name type is similar to the Machine UID Form, except that the buffer contains a string representing the uid_t.
This name type is used to indicate a string of digits representing the numeric user identifier of a user on a local system. Its interpretation is OS-specific. This name type is similar to the Machine UID Form, except that the buffer contains a string representing the uid_t.
3. Credentials Management
3. Credentials Management
The Kerberos V5 protocol uses different credentials (in the GSSAPI sense) for initiating and accepting security contexts. Normal clients receive a ticket-granting ticket (TGT) and an associated session key at "login" time; the pair of a TGT and its corresponding session key forms a credential which is suitable for initiating security contexts. A ticket-granting ticket, its session key, and any other (ticket, key) pairs obtained through use of the ticket- granting-ticket, are typically stored in a Kerberos V5 credentials cache, sometimes known as a ticket file.
The Kerberos V5 protocol uses different credentials (in the GSSAPI sense) for initiating and accepting security contexts. Normal clients receive a ticket-granting ticket (TGT) and an associated session key at "login" time; the pair of a TGT and its corresponding session key forms a credential which is suitable for initiating security contexts. A ticket-granting ticket, its session key, and any other (ticket, key) pairs obtained through use of the ticket- granting-ticket, are typically stored in a Kerberos V5 credentials cache, sometimes known as a ticket file.
Linn Standards Track [Page 16] RFC 1964 Kerberos Version 5 GSS-API June 1996
Linn Standards Track [Page 16] RFC 1964 Kerberos Version 5 GSS-API June 1996
The encryption key used by the Kerberos server to seal tickets for a particular application service forms the credentials suitable for accepting security contexts. These service keys are typically stored in a Kerberos V5 key table, or srvtab file. In addition to their use as accepting credentials, these service keys may also be used to obtain initiating credentials for their service principal.
The encryption key used by the Kerberos server to seal tickets for a particular application service forms the credentials suitable for accepting security contexts. These service keys are typically stored in a Kerberos V5 key table, or srvtab file. In addition to their use as accepting credentials, these service keys may also be used to obtain initiating credentials for their service principal.
The Kerberos V5 mechanism's credential handle may contain references to either or both types of credentials. It is a local matter how the Kerberos V5 mechanism implementation finds the appropriate Kerberos V5 credentials cache or key table.
The Kerberos V5 mechanism's credential handle may contain references to either or both types of credentials. It is a local matter how the Kerberos V5 mechanism implementation finds the appropriate Kerberos V5 credentials cache or key table.
However, when the Kerberos V5 mechanism attempts to obtain initiating credentials for a service principal which are not available in a credentials cache, and the key for that service principal is available in a Kerberos V5 key table, the mechanism should use the service key to obtain initiating credentials for that service. This should be accomplished by requesting a ticket-granting-ticket from the Kerberos Key Distribution Center (KDC), and decrypting the KDC's reply using the service key.
However, when the Kerberos V5 mechanism attempts to obtain initiating credentials for a service principal which are not available in a credentials cache, and the key for that service principal is available in a Kerberos V5 key table, the mechanism should use the service key to obtain initiating credentials for that service. This should be accomplished by requesting a ticket-granting-ticket from the Kerberos Key Distribution Center (KDC), and decrypting the KDC's reply using the service key.
4. Parameter Definitions
4. Parameter Definitions
This section defines parameter values used by the Kerberos V5 GSS-API mechanism. It defines interface elements in support of portability, and assumes use of C language bindings per RFC-1509.
This section defines parameter values used by the Kerberos V5 GSS-API mechanism. It defines interface elements in support of portability, and assumes use of C language bindings per RFC-1509.
4.1. Minor Status Codes
4.1. Minor Status Codes
This section recommends common symbolic names for minor_status values to be returned by the Kerberos V5 GSS-API mechanism. Use of these definitions will enable independent implementors to enhance application portability across different implementations of the mechanism defined in this specification. (In all cases, implementations of GSS_Display_status() will enable callers to convert minor_status indicators to text representations.) Each implementation should make available, through include files or other means, a facility to translate these symbolic names into the concrete values which a particular GSS-API implementation uses to represent the minor_status values specified in this section.
This section recommends common symbolic names for minor_status values to be returned by the Kerberos V5 GSS-API mechanism. Use of these definitions will enable independent implementors to enhance application portability across different implementations of the mechanism defined in this specification. (In all cases, implementations of GSS_Display_status() will enable callers to convert minor_status indicators to text representations.) Each implementation should make available, through include files or other means, a facility to translate these symbolic names into the concrete values which a particular GSS-API implementation uses to represent the minor_status values specified in this section.
It is recognized that this list may grow over time, and that the need for additional minor_status codes specific to particular implementations may arise. It is recommended, however, that implementations should return a minor_status value as defined on a mechanism-wide basis within this section when that code is accurately representative of reportable status rather than using a separate, implementation-defined code.
It is recognized that this list may grow over time, and that the need for additional minor_status codes specific to particular implementations may arise. It is recommended, however, that implementations should return a minor_status value as defined on a mechanism-wide basis within this section when that code is accurately representative of reportable status rather than using a separate, implementation-defined code.
Linn Standards Track [Page 17] RFC 1964 Kerberos Version 5 GSS-API June 1996
Linn Standards Track [Page 17] RFC 1964 Kerberos Version 5 GSS-API June 1996
4.1.1. Non-Kerberos-specific codes
4.1.1. Non-Kerberos-specific codes
GSS_KRB5_S_G_BAD_SERVICE_NAME
/* "No @ in SERVICE-NAME name string" */
GSS_KRB5_S_G_BAD_STRING_UID
/* "STRING-UID-NAME contains nondigits" */
GSS_KRB5_S_G_NOUSER
/* "UID does not resolve to username" */
GSS_KRB5_S_G_VALIDATE_FAILED
/* "Validation error" */
GSS_KRB5_S_G_BUFFER_ALLOC
/* "Couldn't allocate gss_buffer_t data" */
GSS_KRB5_S_G_BAD_MSG_CTX
/* "Message context invalid" */
GSS_KRB5_S_G_WRONG_SIZE
/* "Buffer is the wrong size" */
GSS_KRB5_S_G_BAD_USAGE
/* "Credential usage type is unknown" */
GSS_KRB5_S_G_UNKNOWN_QOP
/* "Unknown quality of protection specified" */
GSS_KRB5_S_G_BAD_SERVICE_NAME /* "No @ in SERVICE-NAME name string" */ GSS_KRB5_S_G_BAD_STRING_UID /* "STRING-UID-NAME contains nondigits" */ GSS_KRB5_S_G_NOUSER /* "UID does not resolve to username" */ GSS_KRB5_S_G_VALIDATE_FAILED /* "Validation error" */ GSS_KRB5_S_G_BUFFER_ALLOC /* "Couldn't allocate gss_buffer_t data" */ GSS_KRB5_S_G_BAD_MSG_CTX /* "Message context invalid" */ GSS_KRB5_S_G_WRONG_SIZE /* "Buffer is the wrong size" */ GSS_KRB5_S_G_BAD_USAGE /* "Credential usage type is unknown" */ GSS_KRB5_S_G_UNKNOWN_QOP /* "Unknown quality of protection specified" */
4.1.2. Kerberos-specific-codes
4.1.2. Kerberos-specific-codes
GSS_KRB5_S_KG_CCACHE_NOMATCH
/* "Principal in credential cache does not match desired name" */
GSS_KRB5_S_KG_KEYTAB_NOMATCH
/* "No principal in keytab matches desired name" */
GSS_KRB5_S_KG_TGT_MISSING
/* "Credential cache has no TGT" */
GSS_KRB5_S_KG_NO_SUBKEY
/* "Authenticator has no subkey" */
GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
/* "Context is already fully established" */
GSS_KRB5_S_KG_BAD_SIGN_TYPE
/* "Unknown signature type in token" */
GSS_KRB5_S_KG_BAD_LENGTH
/* "Invalid field length in token" */
GSS_KRB5_S_KG_CTX_INCOMPLETE
/* "Attempt to use incomplete security context" */
GSS_KRB5_S_KG_CCACHE_NOMATCH /* "Principal in credential cache does not match desired name" */ GSS_KRB5_S_KG_KEYTAB_NOMATCH /* "No principal in keytab matches desired name" */ GSS_KRB5_S_KG_TGT_MISSING /* "Credential cache has no TGT" */ GSS_KRB5_S_KG_NO_SUBKEY /* "Authenticator has no subkey" */ GSS_KRB5_S_KG_CONTEXT_ESTABLISHED /* "Context is already fully established" */ GSS_KRB5_S_KG_BAD_SIGN_TYPE /* "Unknown signature type in token" */ GSS_KRB5_S_KG_BAD_LENGTH /* "Invalid field length in token" */ GSS_KRB5_S_KG_CTX_INCOMPLETE /* "Attempt to use incomplete security context" */
4.2. Quality of Protection Values
4.2. Quality of Protection Values
This section defines Quality of Protection (QOP) values to be used with the Kerberos V5 GSS-API mechanism as input to GSS_Wrap() and GSS_GetMIC() routines in order to select among alternate integrity and confidentiality algorithms. Additional QOP values may be added in future versions of this specification. Non-overlapping bit positions are and will be employed in order that both integrity and
This section defines Quality of Protection (QOP) values to be used with the Kerberos V5 GSS-API mechanism as input to GSS_Wrap() and GSS_GetMIC() routines in order to select among alternate integrity and confidentiality algorithms. Additional QOP values may be added in future versions of this specification. Non-overlapping bit positions are and will be employed in order that both integrity and
Linn Standards Track [Page 18] RFC 1964 Kerberos Version 5 GSS-API June 1996
Linn Standards Track [Page 18] RFC 1964 Kerberos Version 5 GSS-API June 1996
confidentiality QOP may be selected within a single parameter, via inclusive-OR of the specified integrity and confidentiality values.
confidentiality QOP may be selected within a single parameter, via inclusive-OR of the specified integrity and confidentiality values.
4.2.1. Integrity Algorithms
4.2.1. Integrity Algorithms
The following Quality of Protection (QOP) values are currently defined for the Kerberos V5 GSS-API mechanism, and are used to select among alternate integrity checking algorithms.
The following Quality of Protection (QOP) values are currently defined for the Kerberos V5 GSS-API mechanism, and are used to select among alternate integrity checking algorithms.
GSS_KRB5_INTEG_C_QOP_MD5 (numeric value: 1)
/* Integrity using partial MD5 ("MD2.5") of plaintext */
GSS_KRB5_INTEG_C_QOP_MD5 (numeric value: 1) /* Integrity using partial MD5 ("MD2.5") of plaintext */
GSS_KRB5_INTEG_C_QOP_DES_MD5 (numeric value: 2)
/* Integrity using DES MAC of MD5 of plaintext */
GSS_KRB5_INTEG_C_QOP_DES_MD5 (numeric value: 2) /* Integrity using DES MAC of MD5 of plaintext */
GSS_KRB5_INTEG_C_QOP_DES_MAC (numeric value: 3)
/* Integrity using DES MAC of plaintext */
GSS_KRB5_INTEG_C_QOP_DES_MAC (numeric value: 3) /* Integrity using DES MAC of plaintext */
4.2.2. Confidentiality Algorithms
4.2.2. Confidentiality Algorithms
Only one confidentiality QOP value is currently defined for the Kerberos V5 GSS-API mechanism:
Only one confidentiality QOP value is currently defined for the Kerberos V5 GSS-API mechanism:
GSS_KRB5_CONF_C_QOP_DES (numeric value: 0)
/* Confidentiality with DES */
GSS_KRB5_CONF_C_QOP_DES (numeric value: 0) /* Confidentiality with DES */
Note: confidentiality QOP should be indicated only by GSS-API calls capable of providing confidentiality services. If non-zero confidentiality QOP values are defined in future to represent different algorithms, therefore, the bit positions containing those values should be cleared before being returned by implementations of GSS_GetMIC() and GSS_VerifyMIC().
Note: confidentiality QOP should be indicated only by GSS-API calls capable of providing confidentiality services. If non-zero confidentiality QOP values are defined in future to represent different algorithms, therefore, the bit positions containing those values should be cleared before being returned by implementations of GSS_GetMIC() and GSS_VerifyMIC().
4.3. Buffer Sizes
4.3. Buffer Sizes
All implementations of this specification shall be capable of accepting buffers of at least 16 Kbytes as input to GSS_GetMIC(), GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting the output_token generated by GSS_Wrap() for a 16 Kbyte input buffer as input to GSS_Unwrap(). Support for larger buffer sizes is optional but recommended.
All implementations of this specification shall be capable of accepting buffers of at least 16 Kbytes as input to GSS_GetMIC(), GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting the output_token generated by GSS_Wrap() for a 16 Kbyte input buffer as input to GSS_Unwrap(). Support for larger buffer sizes is optional but recommended.
Linn Standards Track [Page 19] RFC 1964 Kerberos Version 5 GSS-API June 1996
Linn Standards Track [Page 19] RFC 1964 Kerberos Version 5 GSS-API June 1996
5. Security Considerations
5. Security Considerations
Security issues are discussed throughout this memo.
Security issues are discussed throughout this memo.
6. References
6. References
[RFC-1321]: Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC-1321]: Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC-1508]: Linn, J., "Generic Security Service Application Program Interface", RFC 1508, September 1993.
[RFC-1508]: Linn, J., "Generic Security Service Application Program Interface", RFC 1508, September 1993.
[RFC-1509]: Wray, J., "Generic Security Service Application Program Interface: C-bindings", RFC 1509, September 1993.
[RFC-1509]: Wray, J., "Generic Security Service Application Program Interface: C-bindings", RFC 1509, September 1993.
[RFC-1510]: Kohl, J., and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC-1510]: Kohl, J., and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[FIPS-PUB-113]: National Bureau of Standards, Federal Information Processing Standard 113, "Computer Data Authentication", May 1985.
[FIPS-PUB-113]: National Bureau of Standards, Federal Information Processing Standard 113, "Computer Data Authentication", May 1985.
AUTHOR'S ADDRESS
AUTHOR'S ADDRESS
John Linn OpenVision Technologies One Main St. Cambridge, MA 02142 USA
John Linn OpenVision Technologies One Main St. Cambridge, MA 02142 USA
Phone: +1 617.374.2245 EMail: John.Linn@ov.com
Phone: +1 617.374.2245 EMail: John.Linn@ov.com
Linn Standards Track [Page 20]
Linn Standards Track [Page 20]
一覧
スポンサーリンク
