Subject: Re: GSS-API extensions for AEAD

From: Luke Howard <[email-masked]>
Date: Sat, 11 Sep 2004 17:18:14 +1000

OK, so I made a few typos:

> *	token_header_buffer contains the GSS-API token as
> *	received from the peer

token_header_buffer contains just the GSS-API token header;
obviously this assumes an application message format that
can identify the token header separately. This suited our
application (DCE RPC) but may not suit all applications.

> *	associated_data_buffer contains the complete data
> *	over which the checksum is to be verified;

s/verified/computed/

-- Luke

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Ken Raeburn <[email-masked]>
Date: Sat, 11 Sep 2004 04:39:38 -0400

> application (DCE RPC) but may not suit all applications.

This would be an annoying new imposition, I think.  Where a protocol 
currently sends one blob of data for GSS_Wrap, it has to effectively 
send two (which may be one blob plus an offset at which it gets split 
apart) for GSS_Wrap_Ex.  That would also make it impossible to use a 
theoretical new Kerberos ASN.1 object KRB-PRIV-AND-SAFE (or a modified 
EncryptedData defined to incorporate associated data) that encapsulates 
AEAD at the Kerberos layer, if one were so inclined.  And unless we 
make serious changes to GSS_Wrap, the mechanism is already going to 
have to implement the ability to figure out where the checksum or MAC 
or whatever is in a single data blob.

Remember, too, that the associated data need not necessarily actually 
be sent on the wire.  Forcing the application to reassemble the 
associated data and the encrypted data into one buffer seems wasteful.

I'd prefer just using the one output buffer like GSS_Wrap does, and one 
additional input buffer to unwrap for the associated data.

Additional stuff that needs to be considered if it's going to be 
written up:

- Any relationship between this and the Wrap and MIC tokens, especially 
in degenerate AEAD cases where either associated data or encrypted data 
is empty.  I.e., do we require that they be distinct (one not useful 
for fabricating another even if the application doesn't know what kind 
of message to expect), or can they be the same?

- Do we allow a mechanism to not provide it?  If it's required, 
GSSAPIv2 mechanisms won't be compliant with whatever this goes into (a 
v2 extension or v3) without updates, probably new OIDs, etc.  If it's 
optional, do we need to know up front or is it a characteristic we find 
out after establishing the security context.  (If we want updates, you 
may know I've already thought about AEAD for the Kerberos crypto spec, 
though I haven't written it all up so far.)

- Or, is there some reasonable and general way we can specify automatic 
extension of v2 mechanisms (those that support confidentiality) to 
support this?  Probably impossible unless we allow a Wrap_Ex token to 
look like a Wrap or MIC token that has somewhat different data in it.

I wouldn't mind seeing it written up.  But write up both the GSS-API 
description and the C binding, separately.  Maybe in the same document, 
but the main part of the write-up should be independent of the C API.

Not sure I agree with the need, though.  For compatibility with some 
DCE RPC implementations (does this translate to anything more than 
"Microsoft SSPI"?), which evidently aren't actually using GSS-API?  How 
about interoperability with other non-GSSAPI schemes too? :-)  I'm 
willing to be convinced, but I don't want it to be that we just want to 
make existing protocol XYZ into a GSSAPIv3 protocol by defining 
GSSAPIv3 and A, B and C mechanisms such that they match what XYZ 
already does on the wire.

Ken

---

From: Luke Howard <[email-masked]>
Date: Sun, 12 Sep 2004 01:30:45 +1000

>additional input buffer to unwrap for the associated data.

I should note that I added the separate token header argument to make
things easier for the DCE library, which needs to place the GSS token
header after the application data. However we can make this work just
with GSS_Wrap() and, being unrelated to AEAD, I have no objection to
removing the extra argument.

>though I haven't written it all up so far.)

I think it is reasonable to allow AEAD to be optional and negotiated in
some mechanism-specific way. That is how NTLM does it, and something
similar could be done with the Kerberos mechanism.

It also seems reasonable for a GSS_Wrap_Ex() token without additional
associated data to be identical to a GSS_Wrap() token. Need to think
about this some more though.

If AEAD is optional then some way of conveying to the caller whether
associated data was protected would be useful.

>already does on the wire.

Understood. Ideally we can come up with something that is interoperable
and elegant. At least if we can agree on a standard API then DCE can be
treated as a special case by the mechanism implementation.

-- Luke

---

From: Martin Rex <[email-masked]>
Date: Mon, 13 Sep 2004 15:41:14 +0200 (MET DST)

Luke,

I'm a little confused about this proposal.

Where exactly is the difference between your gss_wrap_ex(), gss_unwrap_ex()
and the EXISTING gss_getmic() gss_verifymic()?

As far as I remember, the GSS-API was originally designed
by Engineers at Digital Equipment Coorporation (DEC) for use
with DCE.

-Martin