Subject: [anonsec] btns-ipsec-apireq.txt

From: yaronf at checkpoint.com (Yaron Sheffer)
Date: Sun, 23 Apr 2006 19:48:21 +0300

Hi Michael,

I understand your reasoning, and the complexity of adding identity into the
API. OTOH, "identity binding" is an often required feature.

Let me give an example, and please point out where I am getting it wrong:
the "responding system" is a RADIUS server, and it wants to perform access
control on its clients based on something stronger and easier to manage than
the authenticator value. The server might want to compare the alleged
NAS-IP-Address (or NAS-Identifier) to the authenticated identity. If we
provide standard mapping for the common identity types (IP address and
FQDN), this would be easy.

Thanks,
	Yaron

------------------------------

Message: 4
Date: Sat, 22 Apr 2006 10:06:17 -0400
From: Michael Richardson <mcr at sandelman.ottawa.on.ca>
Subject: Re: [anonsec] btns-ipsec-apireq.txt
To: anonsec at postel.org
Message-ID: <v0y7xxr9gm.fsf at marajade.sandelman.ca>
Content-Type: text/plain; charset=us-ascii

>>>>> "Yaron" == Yaron Sheffer <yaronf at checkpoint.com> writes:

    Yaron> One nit and one question: 1. In the Terminology section, should
    Yaron> be: it does *not* imply any specific API...

  Thanks.

    Yaron> 2. The "WHO" section is missing the most obvious identity
    Yaron> information, which is the IKE ID payloads (or SubjectAltName
    Yaron> attributes) when these are available, i.e. in the non-anonymous
    Yaron> case. Is this omission intentional?

  Yes. 
  I specifically do not want to teach application how to parse DNs, FQDNs,
Kerberos principles, etc. Also note that in the first revision of the
requirements, we are focused on the responding system, not the initiating
system. 

  We wanted the identifiers to have an opaque format that could be trivially
compared. (In the API that envision, these would actually be pointers, which
would equal() whenever they are eq(), but one would still need to use the
proper IsIdentifyEqual() function)

  For auditing purposes, there should be a way to get a string from the
opaque identifier. By making it unidirectional, we do not require that the
mapping be reversable. So, if you have a nice human readable, printable form
of the DN, you can display that. It might be perfect for the input side.

  For the case of certificates, if one takes a page from the HIP API, then
the application doesn't really care/know --- it just loads a file that the
user provided. 

  I notice that I'm now on multimobsec-api at ietf.org, and I want to know if I
should be CC'ing that list as well. Does this indicate that Sam thinks that
perhaps this work should be in a new WG?

 (  https://www1.ietf.org/mailman/listinfo/multimobsec-api for those that
didn't get subscribed )

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls
[
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net
architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device
driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security
guy"); [

    "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr

------------------------------

_______________________________________________
ANONSEC mailing list
ANONSEC at postel.org
http://www.postel.org/mailman/listinfo/anonsec

End of ANONSEC Digest, Vol 19, Issue 10
***************************************

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Mon, 24 Apr 2006 17:28:47 -0400

>>>>> "Yaron" == Yaron Sheffer <yaronf at checkpoint.com> writes:
    Yaron> Hi Michael, I understand your reasoning, and the complexity of
    Yaron> adding identity into the API. OTOH, "identity binding" is an often
    Yaron> required feature.

    Yaron> Let me give an example, and please point out where I am getting it
    Yaron> wrong: the "responding system" is a RADIUS server, and it wants to
    Yaron> perform access control on its clients based on something stronger
    Yaron> and easier to manage than the authenticator value. The server
    Yaron> might want to compare the alleged NAS-IP-Address (or
    Yaron> NAS-Identifier) to the authenticated identity. If we provide
    Yaron> standard mapping for the common identity types (IP address and
    Yaron> FQDN), this would be easy.

<dodge>
  In the case of authenticating against the IP address, your work is already
done. You don't need an API. The credentials that were used to establish the
IKE session would have had to have something that permitted the peer to
assert that it is IP address FOO.  The kernel components will keep all
other peers from impersonating IP address FOO, so at that point,
  getpeername() returns what you want.
</dodge>

  The API has to have a method of comparing identifiers.  

  I'm trying to make it clear that you compose the identifiers in some
fashion, you get an iToken handle to it, and then you compare against what
you were given. It may well be that:
    "192.139.46.73"

and
    "C=CA, ST=Ontario, O=Openswan, L=Toronto, CN=herring.sandelman.ca,
    ipAddress=192.139.46.73"

are in fact equal(). Do you want your appliation to have that logic? I don't.
(it might depend upon which CA signed that certificate...)

=======

  How can I make this intention clearer in the API requirements?

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 25 Apr 2006 10:15:09 -0500

>   getpeername() returns what you want.

Yes, that is a dodge, that's why we're here :)

> you were given. It may well be that:

So, you want some sort of canonical tokenized form for names that can
then be compared octet-wise for equality?

Sort of like what the GSS-API provides?

This would undoubtedly work where the IDs are IKEv2 IDs that can be
asserted on the wire or BTNS publickey IDs, and HITs.

Of course, if folks then want to do granular authorization then we'll
get into the same space that KITTEN WG is in right now...  But we can
cross that bridge when we come to it; KITTEN is proof that we can leave
that for later.

Nico
--

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Tue, 25 Apr 2006 15:22:27 -0400

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20060425/f43754ce/attachment.bin

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 25 Apr 2006 15:05:15 -0500

On Tue, Apr 25, 2006 at 03:22:27PM -0400, Michael Richardson wrote:
>     Nicolas> Of course, if folks then want to do granular authorization then
>     Nicolas> we'll get into the same space that KITTEN WG is in right now...
> 
>   Please give us more pointers.

 - KITTEN WG charter page :)

   http://www.ietf.org/html.charters/kitten-charter.html

 - Desired Enhancements to GSSAPI Version 3 Naming

   http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-04.txt

 - GSS-API Naming Extensions

   http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-01.txt