Subject: [anonsec] Much ado about little?

From: Black_David at emc.com ([email-masked])
Date: Wed Nov 24 05:32:48 2004

> Currently, channel bindings are part of the KITTEN WG, which is arguably 
> a better place for that particular focus.

That's not correct.

To be precise, channel bindings *for GSSAPI* are in KITTEN.  Unlike
NFSv4, iSCSI and the IP Storage protocols do not use GSSAPI.  While
there may be a draft in the works that will enable GSSAPI for iSCSI
in order to improve Kerberos support, the CHAP mechanism (the most
common iSCSI authentication) described in my initial message on
channel bindings does not use GSSAPI and never will (hint: RADIUS
servers don't understand GSSAPI).

> To the extent that PKI4IPSEC needs interaction with bindings,
> that argues to merge it with KITTEN, not BTNS.

Asking KITTEN to work on IPsec-related issues is one of the
sillier suggestions I've heard - KITTEN is a GSSAPI working
group, not an IPsec one, so pushing IPsec channel
bindings into that WG doesn't make much sense.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed Nov 24 07:24:50 2004

> servers don't understand GSSAPI).

One argument for dealing with channel bindings is to handle an API 
issue; APIs are being dealt with in KITTEN, not in PKI4IPSEC.

As to NSFV4 and KITTEN, see below.

> bindings into that WG doesn't make much sense.

IMO, it makes as much sense as moving BTNS - designed to avoid PKI - 
into PKI4IPSEC.

And one specific issue KITTEN is:

"This working group is chartered to specify a non-backward compatible
GSSAPI v3 including support for the following extensions:
o Clarify the portable use of channel bindings and better specify
channel bindings in a language-independent manner.
o Specify thread safety extensions to allow multi-threaded applications
to use GSSAPI
o Definitions of channel bindings for TLS, IPSec, SSH and other
cryptographic channels based on work started in the NFSV4 working
group.
...:

The first and third item in this list deal with issues BTNS is being 
asked to deal with. It would be confusing to have two WGs dealing with 
'portable use of channel bindings' and 'channel bindings for ...IPsec...'.

Note, BTW, the specific reference to NSFV4 WG in the last line.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20041124/c3410ea2/signature.bin

---

From: kent at bbn.com (Stephen Kent)
Date: Wed Nov 24 08:00:48 2004

At 7:22 AM -0800 11/24/04, Joe Touch wrote:
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature";
>	boundary="------------enigCED4148BEE206A21ACA7CD4A"
>
>
>
>>>Currently, channel bindings are part of the KITTEN WG, which is 
>>>arguably a better place for that particular focus.
>>
>>
>>That's not correct.
>>

Well, if they can't spell IPsec properly, I don't know that I have 
confidence in their ability to design an appropriate API :-)

Steve

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Fri Nov 26 16:45:56 2004

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

    Stephen> Well, if they can't spell IPsec properly, I don't know
    Stephen> that I have confidence in their ability to design an
    Stephen> appropriate API :-)

That was probably my fault.  I think I may have suggested the text
leading to that charter item.  It's not easy for me to pick up on
capitalization and spelling.

I'm happy to correct mistakes I make when they are pointed out to me.

--Sam

---

From: kent at bbn.com (Stephen Kent)
Date: Mon Nov 29 08:37:47 2004

At 7:35 PM -0500 11/26/04, Sam Hartman wrote:
>_______________________________________________

No problem, just part of my long term crusade to get folks to use the 
same capitalization as the standards, not the trade mags (or one 
major vendor's style sheet!).

Steve