Subject: RE: looking for feedback on crypto draft: cipher state chaining

From: [email-masked]
Date: Thu, 6 Jun 2002 15:06:45 -0400

Sure, I imagine that most folk here would agree that the overhead of TCP/IP is justifiable if the goal is to have an internetwork.

Whereas some of the overhead of KRB_PRIV/KRB_SAFE doesn't appear to me to be justifiable if the goal is to perform stream encryption. It's not just the app tags, the pvno, and the DER encoding overhead that are unnecessary for stream encryption; the sequence number, the HostAddress (directional or not) also are a waste, as is the rcache used by KRB_PRIV/KRB_SAFE implementations.

If you want stream encryption then (cipher state + confounders + different sub-keys for each side + a message length header + padding to cipher block size) or something close to that ought to suffice, IMO. The cipher state doubles for the lost sequence number, the different sub-keys double for the missing directional host address (i.e., it defeats reflection attacks).

Disclaimer: IANAC (the 'C' stands for cryptographer).

Cheers,

Nico
--  

> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]]
> Sent: Monday, June 03, 2002 12:55 PM
> To: Williams, Nicolas
> Cc: [email-masked]
> Subject: Re: looking for feedback on crypto draft: cipher state chaining
> 

[...]

> What was the protocol overhead of TCP(IPv4) over Ethernet again?
> I think it was somewhere around 40 octets per datagram.
> 
> The "protocol overhead" is therefore ONLY significant for low-bandwith
> communication anyway (like pure ascii characters from a users 
> keyboard).

[...]

> -Martin

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 07 Jun 2002 17:59:30 -0400

>Whereas some of the overhead of KRB_PRIV/KRB_SAFE doesn't appear to me to be
>justifiable if the goal is to perform stream encryption. It's not just the
>app tags, the pvno, and the DER encoding overhead that are unnecessary for
>stream encryption; the sequence number, the HostAddress (directional or not)
>also are a waste, as is the rcache used by KRB_PRIV/KRB_SAFE implementations.

Two additional things comes to mind.

When you're fitting Kerberos in to a particular application protocol, you
sometimes are constrained by the limitations of that protocol.  For example,
when I was looking at putting Kerberos into SNMP, one of the requirements
of SNMP is that a integrity-protected payload had to be completely "in the
clear" ... which meant that you couldn't use KRB_SAFE.

Also, programmer complexity is something to consider.  Just using those
message formats is a bit hard to get going with current Kerberos
implementations; sometimes I don't want to bother and would rather use
a simpler mechanism.

--Ken

---

From: Martin Rex <[email-masked]>
Date: Mon, 10 Jun 2002 18:15:40 +0200 (MET DST)

> clear" ... which meant that you couldn't use KRB_SAFE.

Which is another reason why secure RPC uses GSS-API's message integrity
functions gss_getmic()/gss_verify() to provide integrity protection
-- the MIC is seperate from the data and the data can still be interpreted
my implementations that don't recognize the MIC.

-Martin

---

From: "Nicolas Williams" <[email-masked]>
Date: Mon, 10 Jun 2002 13:43:36 -0400

> clear" ... which meant that you couldn't use KRB_SAFE.

?

KRB-SAFE sends the data payload in the clear. Or did you mean that the
framing added by KRB-SAFE interferes with the guidelines for such
protocols as you describe?

In any case, stream encryption would not be appropriate for such
protocols (assuming that indeed there is good reason to not encrypt).

> implementations; sometimes I don't want to bother and would rather use

The APIs could make it easier...

Cheers,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 11 Jun 2002 01:41:29 -0400

>protocols as you describe?

To be pedantic ... KRB-SAFE isn't in the clear.  It's an opaque blob.
Now, if you know what the ASN.1 structure of KRB-SAFE is, you can peek
inside of it and see the original data.  But that doesn't meet the requirement
of SNMP (which says that integrity-protected messages _must_ have 
payloads visible by SNMP).

>The APIs could make it easier...

A rather hercurlean task, eh?  And with GSS-API, it's already too late :-/

--Ken

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 11 Jun 2002 01:28:18 -0400

>my implementations that don't recognize the MIC.

Just in case anyone is curious ... another limitation of SNMP is "one
round trip" which of course kills GSS-API (also, you can do some funky
Kerberos things which makes it perform better than vanilla GSS-API).

--Ken

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Jun 2002 17:59:25 +0200 (MET DST)

> Kerberos things which makes it perform better than vanilla GSS-API).

That's not completely accurate.

It may not support "generic" GSS-API and things like SPNEGO, but it should
work just fine with specific gssapi mechanisms that offer the required
characteristics.

1) GSS-API does allow unidirectional 1-way authentication and
   most rfc-1964 Kerberos implementations should support it
   (MIT's implementation does and Microsoft's W2K Kerberos does).

2) In 1996 the "GSS_C_FLAG_PROT_READY" facility was added for just
   such a purpose, so that protected data could be transmitted
   along with the initial context token from the initiator to
   the acceptor in spite of a 2-way authentication.  It was proposed
   by Bob Blakley (sp?) from IBM for use with Kerberos in
   protocols that required a single round-trip for the whole
   communication.

-Martin

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 11 Jun 2002 12:18:54 -0400

>work just fine with specific gssapi mechanisms that offer the required

While that's true ... if it only works with specific mechanisms, then I
have to wonder what's the value of using GSSAPI instead of raw Kerberos
in that protocol.  Certainly it could never be standardized.

--Ken

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Jun 2002 21:35:37 +0200 (MET DST)

> in that protocol.  Certainly it could never be standardized.

HUH?  Of course it could be standardized that way!

Althought GSS-API supports authentication schemes with n-way (n>2)
token exchanges, it's PERFECTLY FINE when applications have specific
constraints on the characteristics of the gssapi mechanisms that
they find acceptable.

If your underlying SNMP protocol will not support it, then there
is *NO* way how you could get it working with n-way (n>=3) authentication
whether you use GSS-API or write your own API.

The advantage of GSS-API is that it is already there,
the behaviour is well defined and the gss_getmic()/gss_verifymic()
provide a message integrity protection token seperate from the
protected message.

As you mentioned, KRB_SAFE will not do the job since it frames
the message into an ASN.1 structure.

-Martin

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 11 Jun 2002 16:37:09 -0400

>HUH?  Of course it could be standardized that way!

I am skeptical; I cannot honestly imagine the IETF standardizing on a
GSSAPI-based application protocol that only worked with mechanisms with
one round trip.  That was the reason given for Kerberos-TLS, IIRC.

>the message into an ASN.1 structure.

*shrug* I got it working fine with the existing Kerberos APIs which
are simplier than GSSAPI (I'm not sure what you mean by "it's already
there"; the Kerberos APIs are also already there), so like I said, I'm
not sure I see the value (the other thing I didn't mention was that
we're going to be doing authenticator caching to reduce SNMP PDU size,
and I don't believe there's a way to do that wth GSSAPI).

--Ken

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Jun 2002 17:31:53 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Ken Hornstein wrote:
    >>  >> Just in case anyone is curious ... another limitation of
    >> SNMP is "one >> round trip" which of course kills GSS-API
    >> (also, you can do some funky >> Kerberos things which makes it
    >> perform better than vanilla GSS-API).
    >> >
    >> >
    >> >It may not support "generic" GSS-API and things like SPNEGO,
    >> but it should >work just fine with specific gssapi mechanisms
    >> that offer the required >characteristics.
    >> 
    >> While that's true ... if it only works with specific
    >> mechanisms, then I have to wonder what's the value of using
    >> GSSAPI instead of raw Kerberos in that protocol.  Certainly it
    >> could never be standardized.

    Martin> HUH?  Of course it could be standardized that way!

    Martin> Althought GSS-API supports authentication schemes with
    Martin> n-way (n>2) token exchanges, it's PERFECTLY FINE when
    Martin> applications have specific constraints on the
    Martin> characteristics of the gssapi mechanisms that they find
    Martin> acceptable.

I think several people active in the Kerberos community would much
rather see raw Kerberos messages used in this case than GSSAPI
restricted to specific mechanisms.  RFC 1964 is sufficiently broken
(enctypes and session expiration if nothing else) that I'd rather see
people use raw Kerberos messages or primitives from the crypto
framework than non-generic GSSAPI.

Also, I would be very uncomfortable standardizing on some set of
GSSAPI mechanisms that was not the entire set of mechanisms or an
explicit enumerated set.  It seems very easy for generic frameworks to
use inappropriate mechanisms in any other case, and the probability of
that failure would in many cases cause me to want to avoid specifying
a protocol that could be used with any GSSAPI mechanism that worked
with the protocol.

---

From: "Nicolas Williams" <[email-masked]>
Date: Tue, 11 Jun 2002 17:41:39 -0400

> one round trip.  That was the reason given for Kerberos-TLS, IIRC.

Bad example. Kerberos-TLS doesn't use AP-REQ/REP messages. If that gets
through...

Cheers,

Nico

---

From: Derek Atkins <[email-masked]>
Date: 11 Jun 2002 17:52:29 -0400

> Bad example. Kerberos-TLS doesn't use AP-REQ/REP messages. If that gets

Ok, if it doesn't use AP-REQ/REP, what DOES it use?

-derek
-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Martin Rex <[email-masked]>
Date: Wed, 12 Jun 2002 00:39:22 +0200 (MET DST)

> one round trip.  That was the reason given for Kerberos-TLS, IIRC.

Wait a second!

You said that you have an existing scenario/protocol (SNMP) where the
whole communication is just one round-trip.  If this is a given,
then there is no value in discussing whether it's good or bad that
n-way gss-api mechanisms can not be used.

Re-using an existing API is **definitely** much better than
inventing yet another API -- which is what you seem to be doing.

> and I don't believe there's a way to do that wth GSSAPI).

What exactly do you mean by "authenticator caching"?

I assume that this could be achieved by "security context caching"
at the GSS-API level.

All of the GSS-API functionality is available for Microsoft W2K Kerberos,
while much of the native API that you might have been using to create
your GSS-API replacement API might not available for use on Microsoft W2K,
which IMHO would make this approach definitely second-best.

-Martin

---

From: [email-masked]
Date: Tue, 11 Jun 2002 18:48:25 -0400

>whole communication is just one round-trip.

Yes ...

>If this is a given,

I would agree ... my point only was that here's an example of a protocol
where GSSAPI isn't suitable.

>inventing yet another API -- which is what you seem to be doing.

I never said I was inventing a new API.  I was using APIs that already
exist.  Where did I say that I invented a new API?

>What exactly do you mean by "authenticator caching"?

One thing people in the SNMP world complain about is large PDU size;
If a server can remember that they used a particular authenticator to
authenticate the first time, they don't need to send it in every message,
making the PDUs much smaller.

>I assume that this could be achieved by "security context caching"

I'm not sure ... how do you tell when a security context has expired?

>which IMHO would make this approach definitely second-best.

*shrug* I've used the same API on Windows 2K, so I don't think that's an
issue.

--Ken

---

From: Martin Rex <[email-masked]>
Date: Fri, 14 Jun 2002 16:45:57 +0200 (MET DST)

> framework than non-generic GSSAPI.

If there's a problem with rfc1964 then go ahead and fix it.
If used correctly, GSS-API is plug'n'play, so you are encouraged
to create and use a better gssapi mechanism if you don't like
what is available.

The basic GSS-API spec is almost as flexible as the myriads of
specs that comprise X.509 certificates.  Although it's sometimes
nice to have a very generic high-level spec as the basis, you
need to define some constraints to make the spec anywhere near
useful for a specific application.  For X.509 certificates,
there are plenty of so called "profiles" that put constaints
on what and where and why.

You definitely should not be afraid to define a kind of profile
for GSS-API mechanism characteristics for specific application
areas.  In fact, that is **MUCH** more useful than comeing up with
new APIs for each new application.  (The X.509 example might be
a little extreme, though, because for a standard it is pretty
much a FUBAR).

> a protocol that could be used with any GSSAPI mechanism that worked

The GSS-API spec was never meant to be a panacea or "one size fits all"!

It was meant to be an abstraction across an _extremly_wide_ variety of
"mechanisms".  The advantage of using GSS-API instead of the native
API of a mechanism is that with a one-time effort you can cover
all **compatible** mechanisms that fit all of the requirements of your
application protocol.

Many of GSS-APIs features are optional (for the mechanism to provide
and for the app to call).  It would be a misinterpretation of the spec
that an application could rely on the availability of many of the
features.

Look at the FTP security extensions that inappropriately takes
the availability of gssapi channel bindings for granted.
Channel bindings are optional for the mechanism to implement
and for the application to use.  Now Microsoft W2K Kerberos doesn't
implement gssapi channel bindings but MIT Kerberos does and
the FTP security extenstions implies its use.  Unfortunately
neither the FTP security extensions nor the GSS-API spec
itself says what to do when one mechanism implements it and
the other one doesn't ...

So if you want to add security extensions to an existing
application protocol and also want to use an existing
security protocol exchange, you should definitely try to
use the GSS-API model and write down the constraints
(i.e. required characteristics) so that one can see
which kind of mechanisms will be usable with this application
and which will not be usable.

There are a lot of other probably not so obvious constraints
that limit which gssapi mechanism can be used and which cannot.
It is possible to wrap an OTP-based authentication with GSS-API,
but for distributed applications which are going to be making
many automatic (re-)authentications (from 10 to >1000) under
the covers (i.e. negotiating that many security contexts)
and OTP-authentication scheme is simply unusable; a true
single sign-on is imperative.

There are similar problems with mechanism that implement
more-or-less straight SPKM (rfc2025 the simple public key mechanism).
Since with SPKM each authentication must be based on the
longterm credentials (the current protocol doesn't allow you
to create a ticket-like temporary keypair where you sign
the public key with your end-user certificate).

Current PC-based smartcard terminals for RSA-smartcards require
about 20-seconds per full authentication procedure with a 1024-bit key.
That's a significant burden on the server when the client slows
down the security context negotiation this much.

Worst of all, the SPKM spec goes even as far as suggesting
to use true digital signatures with your longterm user certificate
for integrity protection of the message protection services
for application data...

Anyway... I think that using GSS-API for adding integrity protection
to SNMP would be a great idea.  I would suggest that you talk to
Mark Eisler from SUN who did the RPC security extensions.
I have never any of the RPC+GSS-API rfcs, but it might be
worth a look (rfc2203 and in particular rfc2623).

-Martin