[MMUSIC] Re: [Sipping] Review of draft-saito-mmusic-sdp-ike

[Richard Barnes <rbarnes at bbn.com>]

> To delegate authentication to a CA in IKE, you need a certificate
> whose subjectAltName matches something that makes sense -- such
> as being the hostname or username or friendly name.  This is what
> we're trying to avoid.

IKE and IPsec don't make any particular demands on the relationship 
between the certificate and the authenticated identifier, just on what 
goes in the IKE ID payload.  To quote RFC 4301:
"
   This document does not require that the IKE ID asserted by a peer be
   syntactically related to a specific field in an end entity
   certificate that is employed to authenticate the identity of that
   peer.
"

However, you will need to define what identifier gets put in the IKE ID 
field, since that's the identifier that gets used for IPsec 
authorization.  So if you define which identifiers to use, the 
certificate can be whatever you want (subject to policy) -- provided 
that you work out the issues with self-signed certs I mentioned before.

> Yes, I don't see any reason to keep IKE active after the SIP BYE.

On the other hand, I don't know if you should necessarily throw the IKE 
SA away after the SIP BYE.  There are reasons to keep IKE SAs around for 
some time, namely that it saves a Diffie-Hellman computation from the 
next setup (in IKEv2; there are other, different savings in IKEv1). 
It's reminiscent of credential caching used by other protocols.

I guess you need to clarify what the SDP in the SIP transaction is 
describing: The IKE negotiation, the IKE SA, the IPsec SA, or some 
combination of the above.  If it's just the IKE packets that you're 
worried about, you could send the BYE after I think 6 IKE packets and 
let the SAs carry on.  If you're worried about the BYE tearing down 
whatever NAT magic you've done, then you'll need to postpone it until 
the IPsec SA is done.  Perhaps instead of saying "tear down the IPsec 
stuff when you see a BYE", you should say "don't send a BYE until you're 
done doing IPsec".

--Richard


_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic