Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt

[Martin Rex <[e-mail]>]

Liqiang wrote:
> 
> Olga Kornievskaia wrote:
> > First, I hope that the 1st sentence refers to "tokens" not just the 
> > 1st (AS_REQ) token. As its written, it says that AS_REQ token is framed 
> > but the AS_REP token is not which doesn't make sense.
> 
> Your understanding is correct. Only the first message has the framing.
> This is consistent with RFC4121 and RFC4178.

NOPE, it is significantly different from rfc1964 and rfc4121.

rfc4121 only dropped the framing on the per-message tokens, it
still uses the same=full framing as rfc1964 for all of the context
level tokens:

quoting rfc4121:

   [RFC1964] describes the GSS-API mechanism for Kerberos Version 5.  It
   defines the format of context establishment, per-message and context
   deletion tokens, and uses algorithm identifiers for each cryptosystem
   in per-message and context deletion tokens.

   The approach taken in this document obviates the need for algorithm
   identifiers.  This is accomplished by using the same encryption
   algorithm, specified by the crypto profile [RFC3961] for the session
   key or subkey that is created during context negotiation, and its
*  required checksum algorithm.  Message layouts of the per-message
*  tokens are therefore revised to remove algorithm indicators and to
   add extra information to support the generic crypto framework
   [RFC3961].


I don't like the idea of dropping the generic framing on any of
the context level tokens.


> 
> > Second, what does the "subsequent context establishment tokens" refer 
> > to? AP_REP/AP_REQ or a something else (ie. , new pku2u sessions)?
> > Furthermore, there shouldn't be any unframed tokens in GSS-API
> > mechanism.
> 
> Only the first message has the token framing. This is how all other
> GSS-API mechanisms work today.

The GSS-API spec only requires the generic token framing on the initial
context token.  There is no requirement for any other (context level
and message protection tokens).

rfc4121 is actually the only mechanism that I know which does not
use the token, and it only does so for the message protection tokens.

rfc-1964 (Kerberos 5 gssapi mechanism) has been using the generic framing
on all tokens, as well as rfc-2025 (Simple Public Key GSS-API mechanisms).

Quoting rfc-2025 (SPKM):

   The above GSS-API framing shall be applied to all tokens emitted by
   the SPKM GSS-API mechanism, including SPKM-REP-TI (the response from
   the Target to the Initiator), SPKM-REP-IT (the response from the
   Initiator to the Target), SPKM-ERROR, context-deletion, and per-
   message tokens, not just to the initial token in a context
   establishment exchange.  While not required by RFC-1508, this enables
   implementations to perform enhanced error-checking.

and using this framing throughout is an extremely reasonable approach
(you may remember that I opposed that change in rfc4121... :)
section 6.1 of rfc2025:

6.1. SPKM_Parse_token call
  [...]

   If all tokens are framed as suggested in RFC-1508, Appendix B
   (specified both in the Kerberos V5 GSS mechanism [KRB5] and in this
   document), then any mechanism implementation should be able to return
   at least the mech_type parameter (the other parameters being NULL)
   for any uncorrupted input token.  If the mechanism implementation
   whose SPKM_Parse_token() function is being called does recognize the
   token, it can return token_type so that the application can
   subsequently call the correct GSS function. 

 
-Martin

_______________________________________________
SPKM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/spkm