>>>>> "Alexey" == Alexey Melnikov <[email protected]> writes:
Alexey> General comment: the document is using terminology for
Alexey> multiple technologies (EAP, GSS-API and even SASL). While I
Alexey> think the document is correct and it explains most of the
Alexey> terms used, some additional references on first use would be
Alexey> very helpful in order to improve readability. In particular
Alexey> I am thinking about Section 1 and its subsections,
Alexey> e.g. Section 1.2.
I think we're good on references at this point; please suggest specific
text if you believe we need more.
I think references have been added since you wrote the review.
Alexey> 5.1. Mechanisms and Encryption Types
Alexey> 5.2. Processing received tokens
Alexey> Implementations of this mechanism maintain a state machine
Alexey> for the context establishment process. Both the initiator
Alexey> and acceptor start out in the initial state; see Section 5.4
Alexey> for a description of this state. Associated with each state
Alexey> are a set of subtoken types that are processed in that state
Alexey> and rules for processing these subtoken types. The reciever
Alexey> examines the subtokens in order, processing any that are
Alexey> appropriate for the current state.
Alexey> What happens to the subtokens which are not appropriate for
Alexey> the current state?
I think it is fine to leave that undefined.
I did clearly add a requirement that unknown tokens MUST be ignored.
Alexey> 5.4.2. Acceptor Name Request
Alexey> The acceptor name request token is sent from the initiator
Alexey> to the acceptor indicating that the initiator wishes a
Alexey> particular acceptor name. This is similar to TLS Server
Alexey> Name Indication.
Alexey> This needs an Informative Reference.
Can you find the right reference?
I spent 10 minutes and failed.
Alexey> In Section 5.5:
Alexey> o If the acceptor receives an EAP failure, then the
Alexey> acceptor sends this in the Eap Request subtoken type. If
Alexey> the initiator receives an EAP Failure, it returns GSS
Alexey> failure.
Alexey> Can you expand on what you mean here. "receive" doesn't mean
Alexey> receive over the wire here, right?
I think it does.
Alexey> Also, what does it mean
Alexey> to return a "GSS failure"?
That's a return status from a GSS call.
Alexey> 5.6.2. Channel Bindings Subtoken
Alexey> Again, only the application data is sent in the channel
Alexey> binding. The initiator and acceptor addresses are ignored.
Alexey> I am not entirely clear on what you mean here by "addresses
Alexey> are ignored".
They are not included in the subtoken; text clarified in my copy of the
draft.
Alexey> In 5.6.3:
Alexey> The input to GSS_GetMIC is as follows:
Alexey> 1. The DER-encoded object identifier of the mechanism in
Alexey> use; this value starts with 0x06 (the tag for object
Alexey> identifier). When encoded in an RFC 2743 context token, the
Alexey> object identifier is preceeded by the tag and length for
Alexey> [Application 0] SEQUENCE. This tag and the length of the
Alexey> overall token is not inclded; only the tag, length and value
Alexey> of the object identifier itself.
Alexey> 2. A 16-bit token type in network byte order of the RFC
Alexey> 4121 token identifier (0x0601 for initiator, 0x0602 for
Alexey> acceptor).
Alexey> 3. For each subtoken other than the MIC subtoken itself:
Alexey> What is the order of subtokens?
same order as in the inner token; text clarified in my copy of the
draft.
Alexey> Does this cover all
Alexey> subtokens sent during the extension phase? Does this cover
Alexey> only subtokens sent by the initiator/acceptor respectively?
Only subtokens in the current inner token.
Alexey> 6. Acceptor Services
Alexey> The CRK is derived from the GMSK using the following
Alexey> procedur
Alexey> Typo: procedure
Alexey> Tn = pseudo-random(KMSK, n || "rfc4121-gss-eap")
Alexey> How is "n" respresented, in particular how many bytes are
Alexey> used to represent it?
Alexey> CRK = truncate(L, T1 || T2 || .. || Tn) L = output RFC
Alexey> 3961 key size
I clarified than n starts at 0 and is 32-bits in network byte order.
I believ your other comments have been address trivially or already
discussed on the list because someone else brought them up.
Section 8.4 still has not been resolved, but that is being tracked by
issue #31.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
