[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MMUSIC] Re: [Sipping] Review of draft-saito-mmusic-sdp-ike
Hi Dan,
A couple of responses inline:
The advantage of SIP over Dynamic DNS is explained in
slide 3 of http://www3.ietf.org/proceedings/07jul/slides/sipping-11.ppt,
namely;
<snip>
* ability to delegate user authentication (identity) to a
3rd party (rely on SIP-Identity's signature rather than
a meaningful subjectAltName).
You can already delegate authentication to a CA in IKE. You're just
replacing the CA key with the Authentication Service's key.
* hole punching. RFC3497 won't work if both endpoints are behind
NATs; RFC3497 only works if the IKE initiator is behind a NAT
and the IKE 'server' (VPN concentrator, most typically) has a
public IP address and its IKE UDP port is not firewalled.
I'm not sure of the utility of this. It's not like IKE uses a whole
bunch of different ports like RTP does -- it's always on port 500. If
you want to allow IKE, just open port 500.
* re-use of existing SIP infrastructure, which takes advantage
of the above features for VoIP, to deploy a new, non-VoIP service
This is irrelevant -- "SIP infrastructure" includes DNS infrastructure
(to support REFC 3693 routing), so if you've got SIP infrastructure, you
might as well use the DNS. And conversely, not using SIP (just DNS)
allows people who only have DNS to do the same redirection.
draft-saito-mmusic-sdp-ike does not replace or supercede IKE,
so I don't understand what needs to be said. Can you provide
additional guidance on what you'd like to see here?
Sure. Section 4.4.3 of RFC 4301 defines the authorization mechanism for
IPsec -- the Peer Authorization Database, or PAD. The PAD has entries
that contain:
1. An identifier or set of identifiers
2. Authentication protocol(s) (e.g. IKE, KINK)
3. Authentication method(s) (either X.509 or PSK)
4. Authentication data (either X.509 trust anchor or the PSK)
When an request for a new SA comes in (via IKE), the IPsec endpoint
checks (in order) that
1. The authenticated identifier (e.g. X.509 DN) has a PAD entry
2. The authentication parameters in the PAD match what actually
happened, e.g., the identifier was authenticated through IKE with a
certificate verified by the included trust anchor.
With respect to the first check, you need to specify how identifiers are
derived from the self-signed certificate (i.e., where the SIP identity
needs to be placed)
Without more explanation, I'm not sure how you would handle the second
check: You're obviously not using a PSK, and there's no trust anchor to
verify a self-signed certificate. You may want to look into the work
that the BTNS working group is doing.
I only found one such discussion in section 2, Protocol Overview:
That paragraph seems to imply that the IPsec (Child) SA should be
terminated when the BYE request is accepted, and that any IKE
negotiations in process should be terminated. (Note that it's the SA
that's discarded, not the policy!) Is this what you meant to say?
If so, you need to address two issues:
1. IKE has its own mechanisms for negotiating SA lifetimes, so you'll
need to specify how to set IKE parameters to be compatible with this.
2. How should IKE SAs be handled? Should they be terminated on the BYE
as well?
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic