Subject: [MULTIMOBSEC-API] feedback from btns api draft

From: Miika Komu <[email-masked]>
Date: Sat, 13 May 2006 11:54:45 +0300 (EEST)

Michael, you might want to have a look at the requirements section 3.1.2 
(compatibility, fallback to TCP/IP, and forward compatibility using ED) 
from my thesis. Also sections 3.2.1 (representation of public keys, 
anonymous/public identities) and section 4 might be useful:

http://gaijin.iki.fi/hipl/hip-native-api-final.pdf

> 3.    Motivations for this work

Code reuse is also one motivation. Using IPsec in general reduces the need 
to adapt networking software to use e.g. SSL libraries. This applies 
especially to legacy applications and partially to native applications.

> 5.  Requirements

How about adding two additional requirements to this chapter:

   * IPsec aware applications (endpoint descriptors)
   * Fallback to non-IPsec based communications
   * Application specified public keys (see section 3.2.1 from my thesis)

> 8.1.  OPAQUE IDENTITY

I don't see how the name of this section correlates with the contents of 
the section.

> It should be possible to determine that two IPsec-protected 
> communications conducted within a short to medium time frame were with 
> the same authenticated peer; it should be possible to use a received 
> identity to initiate a communication back to that identity.

In the case of HITs (or EDs), this may not be possible, at least directly.

> 8.3.  ACCESS CONTROL
> 
> While policy rules may allow traffic to be blocked entirely, it's
> often necessary for a program to provide services to mutually
> suspicious clients.

Could you clarify the term "mutually suspicious client"? I think you are 
referring to anonymous clients that cannot authenticate each other e.g. in 
p2p environments.

> 8.4.  ATTRIBUTES/CREDENTIALS
>
> [Mission Creep Alert] In many cases, an application is not so much
> interested in the peer's name, but rather in some other attribute of
> the peer.

By name, you mean host name?

> 10.  Security Guarantees

This was something that was missing from my thesis, good catch! It 
was missing because I though it was too obvious, but it really is not.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

_______________________________________________
MULTIMOBSEC-API mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/multimobsec-api