eap Mailing List: Re: hopefully final changes for draft-ietf-eap-keying

[Jari Arkko (jari.arkko]

Glen,

> Section 5.3 is muddled at best, not clearly delineating RADIUS & Diameter &
> lumping them together as "AAA" when convenient (but not necessarily
> appropriate) & making statements about RADIUS that are impossible to
> reconcile with the actual protocol.
> ...
> This appears to be a Standards Track document, purporting to use standards
> language as defined in RFC 2119.  RFC 2119 says about the "MUST" keyword:
>
>    1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>       definition is an absolute requirement of the specification.
>
> Maybe its just me, but I'm having more than a little trouble reconciling
> this definition with your statement that "The purpose of the document is not
> to dictate...".  It's easier to see the connection between your description
> of the document's purpose, what it actually says & the following (also from
> RFC 2119):
>
> ...
>
> If the purpose is actually documentation then at the very least the intended
> status of the draft should be changed to Informational.
> ...

First, let me remind you that I actually agree with you that the
requirements are too tight. If we were to fix that, I think the
appropriate change would be to change the keywords, not the
document status. I think we need to look at the proxy issue.

However, as I said to Bernard, this is not the stage where the WG
gets to have a new discussion about what it should put to the
document. You had a last call, and the document was sent forward.
Sometimes we run into serious problems and the WG as whole
decides that they are bad enough that the document should be
pulled back and corrected. My strong recommendation is to
finish this particular multi-year project rather than let it live
any longer.

I think the proxy issue is potentially a big issue. However, here's
what I would suggest: given that the issue starts from RFC 4962's
requirements, it does not seem possible to fix it entirely within
this document. If you believe the issue is big enough, lets organize
a discussion about what the right requirements ought to be,
and revise both RFC 4962 and this RFC based on the result of that
discussion.

> No offense, but that is utter & total nonsense: we are not talking about
> what I tell Acme about what you did or didn't do, we are talking about the
> effects of my lying to you about my name.  Far from answering my question,
> you prove my point: the verification of my identity has nothing to do with
> my ability or tendency to modify your data or misrepresent your actions
> _later_ in the session.  
> ...
>
>
> If channel bindings are to be required, it does seem like their actual
> utility (& the actual "potential for causing harm" in their absence) is
> strongly related to this document.
>   

Then let us disagree. I believe there are several people who do believe
channel bindings are useful.

And again, we're not changing the document as sent from the WG
with regards to this issue. The only change on this was an misquoted
text from RFC 4962, detected during IESG review.

Jari