About RFC4121, especially write about checksum and tokens in fragment
summary
this document introduce RFC4121 to everyone.RFC4121 tell us about Kerveros ver5.0.
It is used for discussing about internet protcols and its improvements.tokens transfer between GSS-API peers for security context establishment are also described in this document.
Key derivation for Per-Message Tokens
this document defines 4 keys usage values that are used to derive specified key for signing and sealing messages from the session key or sub key.
Name Value ------------------------------------- KG-USAGE-ACCEPTOR-SEAL 22 KG-USAGE-ACCEPTOR-SIGN 23 KG-USAGE-INITIATOR-SEAL 24 KG-USAGE-INITIATOR-SIGN 25
For example, KG-USAGE-ACCEPTOR-SEAL behave as wrapper tokens.
quolity of protection
a zero QOP value is used to indicate the default protection.using defferent algolthm than the one for which the key is defined may not be appropriate. when the new method is used, the QOP value is ignored.
The encyption and checksum algorithms in per-message tokens are now implicitly defined by the algorithms associated with the session key or sub key. Therefore, algorithm identifers as described in RFC1964 are no longer needed and are removed from the new token headers.
Following are the TOK_ID values used in the context establishment tokens.
Token TOK_ID Value in Hex ----------------------------------------- KRB_AP_REQ 01 00 KRB_AP_REP 02 00 KRB_ERROR 03 00
where Kerveros message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR are defined in RFC4120.
checksum flags Field
the following context establishment flags are defined in RFC2744.
Flag Name Value --------------------------------- 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
I am surprised that Kerveros implements are also described in another RFC.In the near future, i wanna investigate their features that are used to transer and bind with several values and more.
