Re: I-D ACTION:draft-ietf-tls-ac509prof-00.txt

[Stephen Farrell <farrell@xxxxxxxxxxxx>]

Hi John,

Thanks for taking the time to review the draft.

> I think this draft represents interesting work in a valuable area.
Someday, I'll do valuable work in an interesting area :-)

> Given the statement in Sec. 4.4.1 that an attribute type which occurs in the
> attributes field must  not also occur in the restrictions field, can there
> be an algorithmic way to determine which restrictions associate with which
> privileges?

I guess that in general, there isn't. One possibility, (not explicitly called 
out in the draft), is that the restrictions extension also contain the 
privilege value(s). For example, use one attribute to represent "member of 
admin  except for backups" but place that in the restrictions extension 
and not in the attributes field). It really would be nicer if there
were a restrictions field in the base AC, maybe with a syntax like
{OID, ANY, ANY} where the first ANY contains the privilege value(s) 
and the second the restriction value(s).
 
> Per 4.4.3, the AC targeting approach defines a fairly involved mechanism
> which is effectively advisory: it's up to a target receiving an AC to
> determine whether or not it's one of the targets the initiator intended,
> either directly or indirectly via group membership.  Is there consensus on
> the value of such controls if they're advisory rather than strongly
> preventing use by unintended delegates?

I wouldn't agree that this is purely advisory, and in thoses cases where
it is advisory, its actually quite simple (which may point up a reason to
better split direct target controls from delegate/target controls, but that's 
a different issue).

The targeting information is not advisory once the AC is delegated, say
it gets sent from Init to Intermediate to Final. When Final looks at the AC, 
it can check whether or not Intermediate is allowed to forward the AC
(and to whom). This is the point of the targetting stuff - to prevent ACs
being "stolen", even by "good" targets.

On the other hand, when Intermediate gets the AC the information is 
advisory as you say, but given that the AC could have been simply
copied from the network, I don't see that anything in the AC itself can
be better than advisory for direct targets unless we insist that pretty
much all of the AC is always encrypted (which causes other problems).

Even for the advisory case though, there is still some value. Say you're 
a network administrator and you've got a lot of servers which you trust 
and want to allow someone access to just one of them. Ensuring that 
there's a direct target check allows this to be done in way which is pretty
easy to administer.  (Actually, we've seen this used quite a lot in "extranet" 
type cases.)

Regards,
Stephen.


---
You are currently subscribed to ietf-tls as: [ietf-tls-archive@xxxxxxx]
To unsubscribe, forward this message to leave-ietf-tls-435N@xxxxxxxxxxxxxxxxxxx