Subject: Re: [abfab] Comments on draft-ietf-abfab-gss-eap-02.txt

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Dec 2011 14:14:45 -0500

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> 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.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 25 Dec 2011 12:58:09 +0000

Hi Sam,
Commenting on a couple of your replies (I am either Ok or need to double 
check other things you've mentioned):

On 16/12/2011 19:14, Sam Hartman wrote:
  [...]
> I spent 10 minutes and failed.
I think RFC 6066 is the right reference.
>      Alexey>  receive over the wire here, right?
It might be worth clarifying to help the first time readers ("sending 
EAP failure in the EAP Request subtoken type" sounds a bit weird to me.)