Questions regarding Session & Media Authorization

hi

it was interesting to read your document about session and media
authorization drafts. the idea of linking different protocols that somehow
depend on each other (sip & rsvp) with regard to the authorization phase
seems to be very useful. however by reading your documents some
comments/questions came into my mind:

in [framework] you describe three models: Coupled Model, Associated Model
and the Non-Associated Model
from your description it was not clear to me whether in one of the models
crypgraphic processing (related to the token) needs to be done by the
first-hop router (Edge Router). i assume that no cryptographic verification
takes place at the edge router.

in [auth] you describe different means to protect the information inside the
token. the means for protection seem to be strongly related to rsvp which is
not obvious to me. the choice for including non-cryptographic protection
(ascii and unicode credentials) are difficult to understand since you pass
the token to the end-host and mention in [framework] that the end-host is
not trustworthy. hence i would suggest to remove these credentials since
they provide no use. the use of kerberos might be difficult in practice
since the entity issuing the token needs to know the who is going to verify
it (appart from the message size ~ 500bytes for the kerberos token). the
verification steps of the kerberos ticket as explained in 5.3 of [auth] seem
to be wrong: the verifying entity receives the session ticket and decrypts
it to retrieve the session key. this key is then used to verify the keyed
message digest with either HMAC-SHA1 or HMAC-MD5 (or digital signature as
you call it).

the usage of pk-based credentials also seems to be adopted from rsvp. the
fact that pk-based credentials are not really used is not really promising.
additionally there are concerns related to the size of the token in case of
pk-based credentials and the digital signature. in section 8 of [auth] you
state that pk-based credentials have an advantage of good scalability but it
infrastructure support. since there are only a few entities creating the
token and only a few entities verifying the token scalability does is no
scalablity problem.

in [framework] you describe the Non-Associated Model whereby no
trust-relationship exists between the policy servers (RCD and SCD policy
servers). why should someone rely on the policy decision of a policy server
which is not trusted. if there is a trust relationship between them why not
to establish a session key to verify the token or to exchange the required
information?

my main question is: why is it necessary to include so much information into
the token (qos parameters, credentials etc. - e.g. section 3.3.8 of [auth])
although this information could easily be exchanged between the policy
servers. all they need is only a "pointer"/identifier to the stored
information. section 6. "The Associated Model <<using Two Policy Servers>>"
in [framework] shows such an interaction between the two types of policy
servers. hence in such a case the token is much smaller since it only has to
contain the necessary information, the protection of the token is simplified
by only using a keyed message digest. finally bandwidth is preserved
(consider that each session creates a token which has to be sent to the
end-host and back).

additionally you should include a short statement about what prevents a user
from reusing an old token.

what do you think?

ciao
hannes

[auth]	"Session Authorization for RSVP",
<draft-ietf-rap-rsvp-authsession-02.txt>
[framework] "Framework for session set-up with media authorization",
<draft-ietf-rap-session-auth-03.txt>