I'm quite aware of that & if, in fact, the attributes were opaque> data that
passage would certainly cover it. However, it doesn't> appear that either
the Location-Information nor the Location-Data> Attribute is actually
"opaque".....
Strictly speaking, since the attribute contents are framed by field>
delimiters defined only in the attribute definition, and not in another>
protocol document, these attributes don't meet the definition of "opaque"
as> currently used in the RADIUS Design Guidelines.
I think the key question here is whether a RADIUS server would need to
explicitly parse these attributes in order to carry out the requirements in
the document. If so, then the attributes could not be classified as
"opaque", because RADIUS server code would need to change.
o If the RADIUS server requires location information for computing> > the
authorization decision and the RADIUS client does not provide> > it with
the Access-Request message then the Requested-Location-> > Info Attribute
is attached to the Access-Challenge with a hint> > about what is required.
Two cases can be differentiated:
The question is whether the RADIUS server makes this
determination based on the presence/absence of an attribute, or
based on parsing its contents. If it's the latter, then the data can't
be classified as "opaque".
1. If the RADIUS client sends the requested information then the> > RADIUS
server can process the location-based attributes.
For the RADIUS server to determine whether the client sent the
set of location information that was requested previously
(as opposed to just whether the client send an attribute that may
or may not correspond to what was requested), it would seem
that parsing would be required.
2. If the RADIUS server does not receive the requested> > information in
response to the Access-Challenge (including the> > Requested-Location-Info
Attribute) then the RADIUS server may> > respond with an Access-Reject
message with an Error-Cause> > Attribute (including the
"Location-Info-Required" value).> > > > The RADIUS server "requires
location information for computing the> > authorization decision". How can
it make a decision based upon data> > that it cannot understand?
If the RADIUS server can make the determination purely based on the
presence/absence of the attribute, then it wouldn't need to understand
the contents. However, if parsing is required (which seems to be implied
by the term "requested information"), then I'd agree that the attribute
is not really "opaque".
AFAICT, the only way that the RADIUS server can tell if it has > > actually
received the information it requested is to examine the> > Code and Entity
sub-fields of the returned Location-Information > > Attribute and check
that there is an associated instance of the > > Location-Data Attribute by
matching the Index fields of the Attributes.>
If the goal is to determine exactly what kind of information was sent, and
whether the requirements were met (as opposed to just determining if
an attribute was present or not), then I'd agree.
Neither the Location-Information nor the Location-Data Attributes seem> >
to be used for authentication (authorization != authentication) or> >
security.
Yup. An exception can't be granted based on that criteria.
WRT the Index fields of the Location-Information and Location-Data> >
Attributes, the fact that they are both mandatory and large avoids many> >
of the drawbacks mentioned WRT tags in the Design Guidelines document,> >
nevertheless that document does state 'new attributes SHOULD use the> >
grouping method described in http://www.ietf.org/internet-drafts/draft-> >
ietf-radext-extended-attributes-03.txt'.
The question here is whether the Index field is actually related to grouping
or not.
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf