Re: draft-ietf-ipsp-ipsec-apireq-00 comments

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "The" == The Purple Streak, Hilarie Orman <[email protected]> writes:
    The> I think the "motivation" section, even with the edits posted by
    The> Bill Sommerfield, remains sufficiently unclear as to probably baffle
    The> most of the WG members.  This, absent the minutes of the interim

  okay.

    The> meeting held at the beginning of summer, makes it difficult for
    The> the WG to comment on the draft.  In positive terms, what is the
    The> motivation for the API?  We need to get this right before asking the
    The> WG if this should be taken on as a WG item.

  The notes are at:
      http://www.sandelman.ca/SSW/ietf/ipsp/pf_policy/ubur-2003-06-03-notes.txt

  As for whether or not an API fits into the WG... Hmm. It isn't in the
charter. I thought it was. Yet, we've talked about PF_POLICY at every meeting
since we started. 

    The> The draft states that it should be possible "to implement this" (the
    The> API?) 
    The> with IKEv1, IKEv2, KINK, ..."  This seems to be verging into
    The> architecture, 
    The> and I'm knot sure what the exact goal is.  Is it that the API should
    The> have a mapping to any protocol that support IPSec keying?  What are
    The> the essential attributes here?  Is identity the only one?  Later, the
    The> draft talks specifically about IKE SA's, implying that the API might
    The> have 
    The> additional dependencies on the key management.  We need more generic
    The> language 
    The> to get the requirements right.  However, I think that IKEv{1,2} MUST
    The> be 
    The> supported.

  The intention is that the protocol should not be IKEv1 or IKEv2 specific.
It should be general enough that, yes, it should be implementeable for any
IPsec key management protocol. Since we have IKEv{1,2}, clearly, yes, that is
a MUST that these systems be able to support the API.

    The> What is the relationship of the API to IPSec structures, such as
    The> SA's, SPD's, 

  I don't know how to answer the question.

  Applications should not deal with SPDs or SAs. They deal with sockets.
  The purpose of the API is to take a socket (or a potential socket) and have
the required SPD created by the "system". (Where this may be the library, the
kernel, the key manager, etc. But definitely not the application).

    The> etc.?  This would be the explanation of the statement "system policy
    The> trumps all", I would guess.  There seems to be an implication that
    The> applications have security policies that map to things specified by 
    The> the API reqs.  An explicit statement of this would help motivate
    The> the need for the API.

  I can not parse this part.

    The> The requirement that "nominally authorized" communication failures be
    The> visible to the application needs additional thought.  Presumably these
    The> are communications related to a socket for which the application has
    The> some authorization (how fine-grained is such authorization?).
    The> Should it see failures on incoming packets that fail the integrity
    The> check?  These may be spoofed, and the system policy may forbid
    The> applications to see them.  MUST the API reveal these?

  You are thinking about IPsec here. That may be appropriate thinking for
connectionless protocols. for instance, the VoIP people have suggested that,
for instance, that failed data is better than no data.  This is a different
security model than VPNs.

  We are thinking about mis-matched public keys, lack of system policy
authorizing the session, etc. 

  Someone has to tell the user that they used the wrong smartcard!

    The> I personally disagree with the HOW section.  This is an API for IPSec
    The> policy, and all identifier names used in IPSec should be fair game
    The> for the API, down to the awful algorithm names in their full glory
    The> and including IKE key exchange methods and group names.

  This is not an API for setting IPsec SPD. We have one. It is called PF_KEY.
  (SPD = Security Policy Database!)

  Application writers, including very clueful ones who implement IPsec code
do not want to code PF_KEY into applications. It is just way too low level.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email protected] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [
  
  

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat

iQCVAwUBPya0CoqHRg3pndX9AQGs1wQAxZCEiQQSB5YlyzE7hy6QIGFy/hCwn+wN
EWMHI7oFrmG0zLI/L1pRAwrnhmehNd06KaEASJGGX/oc0SoKLKmHJy8t5ks3XVC5
/1RwO3Ejxot3OnjVF5EUd8RLf8VqGU+XDumUd6Oxd0AZnfFyJ4qTT+aXHCQ8L2Tv
w0zwVCguwaA=
=YmRL
-----END PGP SIGNATURE-----