Thanks for catching this.
>Keying material MUST be bound to the appropriate
context.
>
>MCV>>In general the binding of some strong
requirement word like "MUST" to
>a vague word >like "appropriate" is a red
flag for me, as it allows for
>attorney-like type of argument.. Perhaps this >is not
an issue if the
>"appropriate context" was clearly defined
elsewhere (I did not see that).
I believe that the sentence above came out of an earlier
version of
"Guidelines for AAA Key Management", although it
is not identified as such.
On looking through the -06 version, the requirement has been
expanded upon
and clarified.
This brings up two questions. The first is whether the
requirements should
be explicitly identified. This came up in RFC 4017, and to
delineate
requirements that needed to be satisfied, the term
"Requirement:" was put in
front of them. I believe this would be a good idea for
this document as
well.
The second issue is synchronization of requirements between
the "Guidelines
for AAA Key Management" document and this document.
To ensure this, I will
need to go back over the requirements in Section 3 of the
"Guidelines"
document to make sure that all requirements are discussed in
Section 5, and
that the requirements text in both documents are aligned.
After I have
done this, I'll post the revised text for Section 5.
>The Secure Association Protocol (phase 2) conversation
may utilize
>different identifiers from the EAP conversation (phase
1a), so that
>binding between the EAP and Secure Association Protocol
identities is
>REQUIRED.
>MCV>> "may utilize" --> MAY
utlilize?? If so, then it's strange that a
>REQUIREDis tied to a MAY.
This sentence also came out of the requirements in the
"Guidelines"
document; in looking through -06 it appears that this
requirement has also
had some text changes.
----------------------------
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
