Hi all,
I read through the document and I believe it addresses an
important
problem. I am obviously open to reflect deployment
constraints for the
protocols we develop.
Thanks for writing the document.
Needless to say that the document requires a lot of work.
Hence, only
some high-level comments.
Ekr pointed it already out that the document tries to
provide two
functions.
The first part limits the number of fields that are signed.
This concept
is already known from DKIM and we should re-use it.
Now, my problems start with the second part of the document
and the way
how it is tied to this specific problem. In some cases it is
useful to
tie the SIP signaling exchange with the subsequent exchange
along the
media path. That's why we did that with SIP and HIP
([I-D.tschofenig-hiprg-host-identities]), DTLS-SRTP
([I-D.ietf-sip-dtls-srtp-framework]) and SIP IKE
[I-D.saito-mmusic-sdp-ike]. However, I see these aspects as
a largely
orthogonal issue. I think that these are two independent
problems (with
only a minimal relationship, see below).
In an abstract sense (keeping the work on SIP SAML in mind)
the identity
assertion you are conveying to the recipient has constraints
attached
that limit it's scope.
In case of SIP identity the the assertion is very closely
tight to the
specific SIP session. With SIP SAML there was also the
possibility to
tie the assertion to a separate key and to use an
independent protocol
to proof possession of that key. We documented that stuff in
an earlier
version of the SIP SAML document; obviously nobody was too
much excited
about it since it introduces dependencies to other
protocols.
Often, it is not really desired to accomplish such a tight
binding
between the assertion and the subsequent message. In some
cases you
would rather want to keep the binding quite loose in order
to reuse the
assertion (intentionally) over multiple sessions. The best
examples can
be found with the usage of SAML (SAML independently of
SIP).
Conclusion: I believe it is sufficient to limit the number
of fields
that are being signed (in the same fashion as DKIM does it).
The binding
between signaling and media traffic should be treated
independently.
Thereby you can still limit the scope of the assertion and
prevent
replay attacks.
Ciao
Hannes
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors cs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
