>>>>> "Jim" == Jim Schaad <[email protected]> writes:
Jim> Sam and Josh, I apologize; I have been going through unsent
Jim> mail and other files where I make comments. I had actually
Jim> done most of a review, but had not completed it and therefore
Jim> had not sent the review to the list. I thought it was out but
Jim> was in error, thus my earlier message.
Jim> Jim
Jim> 1. In section 1.2, under what circumstances would an acceptor
Jim> fail to respond to an initiator short of a transport failure?
Jim> Can this ever happen in a success case? If it cannot then I
Jim> would suggest that /acceptor may respond/ be changed to
Jim> /acceptor responds/
I've made the change.
Technically some protocols declare failure at a level higher than GSS
and abandon the authentication at the GSS layer.
In this case, the acceptor never responds at the gss layer ever though
gss has not failed.
However, I don't think this complexity is worth going into so I've
adopted your proposed change.
Jim> I guess there would also be a question of
Jim> the initial negotiation being anything other than
Jim> query/response - for example an EAP retry would be sourced from
Jim> the acceptor and might not be expected by the initiator.
EAP retries MUST never happen with gss-eap.
We don't seem to say that though.
I've added a sentence to that affect in 1.2.
Jim> 2. In section 1.2 para #2 - we have not established what the
Jim> peer and authenticator are for EAP. It would be a good idea to
Jim> identify who is whom. Suggest adding a sentence similar to the
Jim> first sentence in the previous paragraph.
I did so, it's much more complicated though because of the split between
the passthrough authenticator and EAP server.
Jim> 3. In section 1.2 - I have always been worried about the
Jim> statement that EAP authentication can start w/ the peer, but
Jim> the first message is always from the authenticator. I believe
Jim> that it would be more correct to state that EAP authentication
Jim> always starts with the authenticator, but it may start with the
Jim> peer for any given EAP mechanism.
No. What's meant by that statement is that either the peer or the
authenticator's lower layer machinery may trigger the EAP state machine
into action.
That always happens with the peer in our lower layer, so I'm removing
the statement.
I've also added a note that we need to prod the EAP authenticator into
doing something to get things started.
Jim> 4. In section 1.2 - I would suggest that /GSS-API peer/
Jim> becomes /GSS-API acceptor/ This keeps the term peer to be used
Jim> only for EAP and only for the GSS-API initiator (possibly
Jim> unless we are dealing with terms for an EAP pass-through
Jim> system)
right.
Jim> 5. In section 1.2 - You say that the GSS-API acceptor acts as
Jim> an EAP pass-through authenticator. I am not sure if that means
Jim> that the GSS-API acceptor needs to deal with the requirements
Jim> for an EAP pass-through such as the fact that it is supposed to
Jim> check the record value of EAP item rather than just pass-it
Jim> through.
It should.
Jim> 6. In section 3 - I have a real problem with the first sentence
Jim> in the section. I don't believe that it is a true statement.
Jim> What is authenticated is going to be based on what the EAP
Jim> method is and what is expected. I have always assumed that it
Jim> starts by authenticating a user to a realm as the single
Jim> authentication and different things for mutual authentication.
Jim> It might be that the sentence was supposed to be "EAP
Jim> authenticates within a realm."
The sentence reads "EAP authenticates a user to a realm," now.
Jim> 7. Is the BNF in section 3.1 supposed to ensure that a name
Jim> cannot be "[email protected]"? Currently you would need to
Jim> say "shartman/@janet.edu"
The BNF is wrong; I have review comments on this and will deal. Sorry
that failed to happen for the last update.
Jim> 8. In section 3.1 An example of a GSS_C_NT_HOSTBASED_SERVICE
Jim> name would be useful for people w/o sufficient background. I
Jim> would need to look farther on this, but based on this text I
Jim> would end up with something like "smtp.example.com@SMTP" as a
Jim> host name. However this looks very strange to me.
You'd actually have something like [email protected] imported as
GSS_C_NT_HOSTBASED_SERVICE would become smtp/example.com@ .Any chance
you could provide example text that would clarify what you
found confusing?
Jim> 9. In section 3.3 -- Which acceptor name must be sent in the
Jim> AAA transport? There are three different ones listed above, or
Jim> this could be a completely different field. It might also be
Jim> that the portions are to be re-composed in order to send onto
Jim> the client in the EAP channel, if this is the case then why do
Jim> the decomposition?
You want to send all the non-empty portions.
The reason to decompose is to make life easier for proxies; different
portions are verified at different places.
Also, acceptors may not known their realm, but proxies may insert this.
Jim> 10. In section 3.3 - is the client signaling mutual
Jim> authentication on the EAP channel or on the GSS-API channel?
GSS channel; clarified.
Jim> 11. In section 5.5 - who does the initiator return the error
Jim> message to? What state should it transition to? Should it
Jim> still accept an error from the acceptor in the GSS-API
Jim> protocol?
GSS_Init_Sec_context returns an error. I clarified no output token is
produced in this case. That terminates the initiator state machine; the
context is invalid at that point according to 2743.
Jim> 12. In section 5.6 - It is not clear to me if one can progress
Jim> from the Extension State to the Extension state rather than the
Jim> completed state as part of negotiation of option features. Is
Jim> this something that needs to be clarified?
Not currently.
There is not currently a transition from extensions to extensions.
You could presumably include messages in earlier states as optional
tokens indicating support for that and then include an extension that
required that, but the current state machine does not support this.
I think we don't need the complexity now and I think it's sufficiently
future-proofed that we can get it when we need it.
Jim> 13. In Section 5.6.1 - is the flag bit of 0x1 reserved for
Jim> some purpose? If so this needs to be documented. If not then
Jim> why not start with mutual auth at 0x1 rather than 0x2.
These flags are intended to align with flags in RFC 2744 for convenience
of implementation.
Jim> 14. In section 5.6.3 - Do I assume that it is so obvious that
Jim> it does not need to be stated that the EAP negotiated key is
Jim> used for the MIC w/o any further key derivation work?
No; that's actually kind of non-sensical.
The EAP key is a bit string.
GSS_GetMIC requires indirectly an RFC 3961 key.
The CRK is used.
I've added a reference.
Jim> 15. In section 5.7 - I am not clear what set of channel binding
Jim> data needs to be included in the EAP method. Would this be
Jim> data about the channel carrying the GSS-API methods or the
Jim> GSS-API/AAA channel or both? I assume this should really
Jim> include channel data all the way from the acceptor to the EAP
Jim> server but I don't know that. How much does this differ from
Jim> the acceptor name referenced in question 9?
It's exactly the same; there is already a reference to 3.3 in that
Jim> paragraph.
What additional text would you like?
Jim> Typos:
Jim> s/thearchitecture/the architectural/ or /the architectures/
Jim> s/authorisation/authorization/ - American English spellings
Jim> preferred check if passthrough is a single word or should be
Jim> pass-through. My dictionary dislikes it as a single word.
Jim> s/receievs/receives/ s/faris/far is/
fixed, thanks.
All appearing in the next update to be published within a week or two.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
