[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: application layer cross checking

At 3:51 PM -0700 5/3/01, Michael Thomas wrote:
>Stephen Kent writes:
>  > At 2:36 PM -0700 5/3/01, Michael Thomas wrote:
>  > >Derek Atkins writes:
>  > >  > Because applications may not be ipsec peers...  Or, in most cases,
>  > >  > ipsec will be host-based, not user-based?
>  > >
>  > >    This seems like a rather single user PC based
>  > >    mentality. If we were running a multiuser timesharing
>  > >    system, being able to supply credentials on a per
>  > >    user basis would be rather necessary, no? Or
>  > >    perhaps I have a smart card which does the
>  > >    signatures which identifies me regardless of
>  > >    which machine I'm using, etc, etc. I don't see
>  > >    what prevents the SPD from having rules like
>  > >    "for 5-tuple [a,b,c,d,e], demand credentials in
>  > >     realm X" where those credentials might require
>  > >    a human to insert a piece of hardware, or type
>  > >    into a dialog box slapped up by the keying
>  > >    daemon, or whatever.
>  >
>  > The SPD is a means of specifying access controls and security
>  > services for traffic at layer 3. It would be  inappropriate to do
>  > what you suggest here.
>
>    [???]
>
>    What does that have to do with the means that
>    you supply those rules into the SPD, and checking
>    up on who was authenticated to those rules in
>    the SADB?
>
>    I can't believe you're seriously suggesting that
>    the SPD shouldn't be able to deal with rules like:
>
>    "to [src=*, dst=me, proto=UDP, sport=*, dport=1234]
>     method=EXTERNAL, callout=GetSmartCardSignFromLuser(),
>     realm=fOoThEFunLoVIngbAR".
>
>    This is purely a local implementation issue.
>    Likewise, an API which allows you to view the rule and
>    credentials which a particular SA authenticted with
>    -- or not -- is also purely a local implementation
>    issue.
>   
>    How can that possibly be "inappropriate"? It's my
>    machine, after all.


2401 defines a minimum compliant SPD, so you are right that it could 
be extended in ways that have only local significance and do not 
interfere with externally visible operation.  However, you have not 
made a good argument why the SPD is the place where one would 
configure extra info re local options for how local user 
authentication is effected (citing your example above). Why would 
that be different on a per SPD entry basis, vs. consistent for all 
local user authentication actions. IUf one tries to extend this model 
to peer authentication, then it is no longer a local matter. Maybe I 
don't understand the scope of what you propose.

The example you give above seems like an odd way to represent a 
simple notion, i.e., the local user has a token to protect his 
private key. How a private key is protected is certainly a local 
matter, outside the scope of IPsec. But I don't know, from your 
example, what "method" is supposed to apply to re an SPD entry? Why 
is it bound to the "me" value for the IP dest addr?  Maybe it's just 
a poor example that you have chosen to illustrate your point, but if 
one tries to think about a standard API (which we don't do yet 
anyway), one would need to be a lot less vague about the nature of 
the extra parameters.

Steve
References: