CAEP / Shared Signals and Events WG
背景
https://gyazo.com/d76775b592712b5f853129367ede13dd
kerberos v5はticketをexpire前にrevokeできない
https://gyazo.com/5d7f45f2e90df8a20e6bac57f44272af
oidc/oauth2もtokenのexpire時にrefresh tokenなりのときに、ユーザーの現在のステータスが反映される
アクセス制御のenforcementがtokenの有効期限に依存している
とはいえ、SNSなどからアカウントが複数のRPにつながる現代において一つのアカウントがexploitされたときに、アカウン
ト乗っ取りが連鎖するリスクがある
各種プロバイダがプロバイダ間の連鎖を緩和（mitigate）できるようにする必要がある
どうするか？
OPとRP間のコミュニケーションを実現して、コントロールプレーンがアクセス制御decisionをリアルタイムにできるようにする
コントロールプレーン: この場合だとOP...かな？
Shared Signals and Events WG とその用語
Shared Signals and Events WG
OIDCのWG
CAEPとRISCの標準化
CAEP
リポジトリがない...?
Microsoftの図から説明
RISC Profile:
ユーザーのアカウントのライフサイクルで状態遷移がおこる関係のセキュリティイベントのJSON構造体を定義
Subjectが特定できるSubject Identifierと呼ばれる構造
ex: Amazon as RP used by Gmail
Amazon赤がgmailによって作られたり、更新されたりした場合、Amazon -> GoogleへRESTによるRISC Eventsを通達
IETFのSET (Security Event Token), Push/Pull Based SET Token Delivery using HTTPを下敷きにしている
CAEP Event Schema: デバイス・クライアント・アプリ・ユーザーのsecurity postureに影響のあるcontextの変化やセキュリティイベントのスキーマ
RISC Event Schemaとの違いはわからない。。。
説明の順番
CAEP -> RISK
code:event.json
{
...
"events": {
"user": {
"subject_type": "email",
"email": "user@example.com",
},
"device": {
"subject_type": "mac",
"mac_address": "00:11:22:33:44:55:66",
},
"revoker": {
"subject_type": "email",
"email": "admin@example.com",
},
...
}
}
}
CAEP: Continuous Access Evaulation
https://gyazo.com/775288a4a618c0c4e86f14992df82794
https://gyazo.com/8a4c6996f4fef47770d2b3cd29c827a9
RPとOP間でイベントを相互にコミュニケーションする
OP -> RP: アカウント乗っ取り、アカウント無効化などの管理者的操作
RP -> OP: オフィスの移動（trusted ip -> カフェ あるいは国）など、RP側のセキュリティ機能(DLP)
正当なトークンであってもstop honoring (言い回しが好き) , 有効期限を優先させない。
よりContextベース + 制御
ただRP側がtokenの有効期限を優先させることは否定してないように思う。
adminによるアクセスだったらより頻度高いAuthn/Authzを要求するのは、ポリシーとしてはアリ
exp への依存から、コントロールへ、っていう考えた方だと想う
クライアントのサポートが必要
Microsoftのケース
以下のクライアントアプリでサポート
https://gyazo.com/d15afa89c807bfd44e453e5c52e66855
token: 28hr有効期限
Conditional Accessとは分離しているらしい
キャッシュされたaccessトークンで有効期限内でもRPが拒否できるように。
claim challengeという機構: トークンが拒否され、新しいトークンの再発行が必要であることを示す
Critical イベント
ユーザーアカウントの削除・無効化
パスワードの変更・リセット
MFA有効化
管理者によるリフレッシュトークンの執行
Azure AD Identity Protectionがユーザーリスクの上昇を検知したとき
Policyクライアント側に伝達されて、OPアクセスができない場合に、ローカルで判断できないだろうか
RISC Profile
claim challengeがこれにあたる？
SET (Security Event Token)
他のjwtとの混同をさけるため、jwt headerに typ:secevent+jwt をつける
伝達方法はこちら
code:risk_profile_email.json
{
"jti": "756E69717565206964656E746966696572",
"iat": 1520364019,
"aud": "636C69656E745F6964",
"events": {
enabled": {
"subject": {
"subject_type": "email",
"email": "foo@example.com"
}
}
}
}
...
"events": { <- RISK Event
"user": {
"subject_type": "email",
"email": "user@example.com",
},
"device": {
"subject_type": "mac",
"mac_address": "00:11:22:33:44:55:66",
},
"revoker": {
"subject_type": "email",
"email": "admin@example.com",
},
...
}
}
}
OAuth Event Types
aud はOAUth 2 Clientの識別子を想定（例" Client ID)
subject_type が oauth_token か oauth_clientのやつ
oauth_tokenの場合以下のフィールドが必要
token_type : access_token, authorization_code, refresh_token
token_identifier_alg: plain, prefix, hash_*
prefixがよくわからない...
token: tokenの識別子。jti とか？
oauth_client の場合、以下のフィールドが必要
client_id
event_type が以下のもの
token_issued
token_revoked
client_disabled
client-enabled
client-credential-changed
iana-subject-identifier-type-registry : sectionしか定義されていない
例 (token issued event):
code:oauth_risk_event_token_issued.json
{
"jti": "756E69717565206964656E746966696572",
"iat": 1508184845,
"aud": "636C69656E745F6964",
"events": {
"subject": {
"subject_type": "oauth_token",
"token_type": "refresh_token",
"token_identifier_alg": "plain",
"token": "7265667265736820746F6B656E20737472696E67"
},
"token_subject" {
"subject_type": "iss-sub",
"sub": "75736572206964"
}
}
}
}
例: token-revoked event
OAuth RIsk Profile特有のsubject_typeが設定されてないのは、subjectがoptionalであるため？
code:oauth_risk_event_token_revoke.json
{
"jti": "756E69717565206964656E746966696572",
"iat": 1508184845,
"aud": "636C69656E745F6964",
"events": {
"subject": {
"subject_type": "iss-sub",
"sub": "7375626A656374",
},
"reason": {
"user": "revoked by this user",
"issuer": "revoked by this issuer"
}
}
}
}
OIDC Event Types
subject_type は iss_sub 固定っぽい
iss_sub がそもそも RISK Profileにおける id_token_claims subject typeを内包してそう
event_type が以下のもの
account-credential-change-required: Credentialの変更が求められる場合のイベント
account-disabled
possible values: hijacking, bulk-account
account-enabled
identifier-changed
値は email か phone のどちらか
providerがイベント発行することを想定 (should)
identifier-recycled: identifierが別のユーザーで使い回された場合
値は email か phone のどちらか
明示されてなかったけど、identifier-changedと同じくproviderがイベント発行することを想定 ？
sessions-revoked
recovery-information-changed
recovery-activated
opt-* : ユーザーがRISCイベントの対象になるか選択できるもの。エンプラだったら管理者がデフォ設定/Static値をきめめられるようになってほしいところ
opt-in
opt-out-initiated
opt-out-cancelled <- いる？?
opt-out-effective
Questions
IoC等と合わせる形になる？
TXAXII/STIX互換性？
Ref