>>>>> "Jim" == Jim Schaad <[email protected]> writes:
Responding only to things I can respond to without reading the
document. I''m in the middle of another document.
I'll get to the rest sometime next week.
Jim> * In section 5.1 (para 3) - The following sentence does not
Jim> make sense to me. Message i2 is the information the AAA server
Jim> receives from the last hop in the AAA proxy chain which is not
Jim> necessarily the authenticator.
Jim> Specifically I do not follow the last clause and what it is
Jim> referring to. Are you stating that the element in the AAA
Jim> proxy chain may not be the authenticator?
Yes.
Jim> If so, I would omit
Jim> the clause as it seems obvious to me since you are talking
Jim> about a chain.
I'd appreciate comments from others.
Jim> * How does authenticated vs non-authenticated information get
Jim> denoted in a AAA message?
It doesn't. All information in an AAA message is integrity-protected
hop-by-hop.
How much you trust it is up to your local policy.
Jim> * It is not clear to me if the EAP server is to reflect the
Jim> values from the EAP client in the response message or if it
Jim> should reflect values from the NAS/AAA path.
EAP client.
Jim> * Is it reasonable/possible that a policy would pull some
Jim> attribute from the AAA path that is not supplied by the EAP
Jim> client and therefore need to reflect it to the EAP client as
Jim> part of the response? Or is the set of values to be reflected
Jim> back to the EAP client restricted by the set of values that it
Jim> supplies?
In this version of the spec it's restricted to thes included by the EAP
peer.
I think we may need to relax that in the future, but there is
significant complexity surrounding some issues there.
So, clients MUST ignore unknown attributes
but right now we don't send them.
Jim> * Section 7.2 - I am afraid I don't understand what this new
Jim> RADIUS attribute is supposed to be carrying.
It describes the protocol between the peer and the NAS.
It's sent in the channel binding and potentially over the AAA path.
I think the name is correct: RFC 3748 (EAP) does call that a lower
layer.
Jim> * Section 8 - You are talking about this information as being
Jim> validated by the AAA server as oppose to being validated for
Jim> consistency against the i1 data by the EAP server. Is this
Jim> what you are really intended?
I'm not intending to make that distinction in section 8.
No, we're talking about the same validation as in section 5.
I think this may be terminology rot; will check when I reconcile your
comments against the document.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
