Hi,
Thanks for your comments. In fact, the draft just went under an IESG review. They
expressed similar comments. We are now in the process of clarifying a few points
in the draft and should publish a revision shortly.
We hope that the clarifications will answer your comments.
L-N
> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de]
> Sent: Monday, June 10, 2002 7:14 AM
> To: rap@ops.ietf.org
> Subject: 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>
>
>
>
>