Subject: Guidelines for GSS-API mechanism designers

From: "Josh Howlett" <[email-masked]>
Date: Mon, 9 Mar 2009 20:27:05 -0000

The KITTEN WG charter states:

  This working group is chartered to revise the GSSAPI v2 RFCs for the
  purpose of clarifying areas of ambiguity:
  ...
  o Guidelines for GSS-API mechanism designers

Has any material for this item been produced yet?

Any pointers to general reference documentation on GSS-API would be
welcome also.

TIA, josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

---

From: Shawn M Emery <[email-masked]>
Date: Wed, 11 Mar 2009 01:27:27 -0600

> Has any material for this item been produced yet?

No there hasn't.  But there are a number of new mechanisms that are 
being proposed (PKU2U, LIPKEY, etc.), that this should probably warrant 
another look into this area.  What mechanism are you proposing, perhaps 
we could answer specific questions you may have?

> Any pointers to general reference documentation on GSS-API would be

For a general reference from a application developer point of view you 
can start here:

http://docs.sun.com/app/docs/doc/816-1331

Shawn.
--

---

From: "Josh Howlett" <[email-masked]>
Date: Wed, 11 Mar 2009 09:54:08 -0000

Shawn wrote:
> No there hasn't.  But there are a number of new mechanisms 
> that are being proposed (PKU2U, LIPKEY, etc.), that this 
> should probably warrant another look into this area.  What 
> mechanism are you proposing

An EAP GSS mechanism (for the avoidance of doubt, not a GSS EAP method -
I'm aware the previous work on this).

> perhaps we could answer specific 
> questions you may have?

That would be greatly appreciated. I have questions, but I wasn't sure
if this was the appropriate forum for GSS newbies like myself to pose
them.

best regards, josh.

---

From: Shawn M Emery <[email-masked]>
Date: Wed, 11 Mar 2009 23:46:04 -0600

Josh Howlett wrote:
>>>   This working group is chartered to revise the GSSAPI v2 
>>>       
>> RFCs for the
>>     

Ah, right WG then.

> if this was the appropriate forum for GSS newbies like myself to pose

Please post your questions to the list.  I'm sure other people here will 
be interested in the topic.

Shawn.
--

---

From: "Josh Howlett" <[email-masked]>
Date: Wed, 18 Mar 2009 17:12:12 -0000

> Please post your questions to the list.  I'm sure other 
> people here will be interested in the topic.

Ok, here's my first three questions.

First, I'm puzzled about the relationship between TLS and GSS-API with
respect to their confidentiality and integrity services.

I observe that, in the wild, most application that use GSS-API tend to
do so only for entity authentication during context establishment, and
use TLS for confidentiality and integrity (and sometimes also
authentication of the acceptor). For example, Negotiate over HTTPS with
an X.509 cipher-suite and authentication of the server certificate is a
common configuration.

Now, RFC2743 section 1.2.2 does not mandate support for per-message
security services. Given this is optional, and no-one seems to use
per-message security anyway, what is the motivation for a GSS mechanism
designer to address that?

I am aware that using GSS-API + TLS in the manner described above can
lead to channel binding problems. Are there any other reasons?

Secondly, my feeble-minded interpretation of section 4.2 of RFC 4121 is
that the design of these per-message tokens (unlike the
context-establishment tokens) are independent of Kerberos; and so the
same scheme could be used for any mechanism. This interpretation appears
to be supported by section 7 of RFC3961 'Use of Kerberos Encryption
Outside This Specification'. Is this interpretation correct?
Consequently, can a GSS mechanism designer simply point to section 4.2
of RFC 4121 for definitions of per-message security services?

Thirdly, if this is the case then I assume that there must be some
definition of what constitutes an acceptable base key. I had a look in
RFC 3961, but I can't find it. I have concluded that I'm either looking
in the wrong place, grossly confused, both of these, or worse. Some
clarification on this matter would be greatly appreciated. 

Many thanks, josh.

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Mar 2009 01:17:38 +0100 (MET)

Hi Josh,

Anything answers I can think of are neither simple nor short...
(you probably expected that...)

> respect to their confidentiality and integrity services.

There actually is NO real relationship between TLS and GSS-API.

The two were designed as entirely independent solutions to substantially
different problem spaces.

The reason why they may look similar is that they both apply to
"online" communication between two communication peers.  Another
similiarity (at least during the childhood of GSS-API)
was the use of cryptographic algorithms for

  - verification of a cryptograhpic proof for an asserted identity
  - message protection (integrity and confidentiality)

Bottom line, that's all they have in common.

In most other areas, TLS and GSS-API have historically had a very
different focus and different areas where they excel in, which is
why there are more and more environments that ask for the best
features of both approaches and come up with combinations of both like
the one you found.

SSL/TLS: focus on many many unrelated end entities
         focus on internet (open untrusted networks),
         focus on encrypted communication channel
         secure client authentication (by TLS) rarely used
         => in general no client TLS credential available
         in many environments server is only identified, not authenticated
         - server TLS credential only used for secure key-exchange
           of SSL handshake.
         focus on wire-format
         focus on interoperability between packaged apps of
            independent vendors
         SSL/TLS encompasses/wraps then entire communication, ususally
            it is another ISO layer 4 protocol above TCP
         strong ties to the underlying transport

GSS-API: focus on homogeneous, centrally administrated users
                               (or realms thereof) 
         focus on secure authentication of the client
         => GSS-API client credential required
         in many environments server is only identified, not authenticated
         => (real) GSS-API server credential might be optional
         focus on Application programming Interface
         the absolute minimum of wire-format (the generic framing of
            the initial context-level token).
         focus on single-source applications for use in a
           distributed environment
         focus on the possibility to add GSS-API tokens in a transparent
           and backwards compatibile fashion at arbitrary protocol
           layers to existing apps.  GSS-API is only half-a-layer
           in the OSI model, it must be combined with some kind of
           application specific transport protocol semantics
           (usually PDU+semantics, but at the minimum semantics).
         focus on adding secure authentication and secure communication
           capabilities into applications with the possibility
           to re-use an already existing authentication infrastructure

TLS was originally born under the name SSL in the home of Netscape,
with the purpose of providing an encrypted communication channel
between a web browser and a web server (both available as
products from Netscape back then) for use in the internet between
independent end entities.  In order to meet crypto export
regulations, SSL was only neutered down to 40-bit RC4, 512-bit RSA
EXPORTable ciphersuites.

GSS-API was originally born in a combined effort of several Unix vendors
http://en.wikipedia.org/wiki/Distributed_Computing_Environment
DCE itself is an extension of the Kerberos 5 protocol.
In the original GSS-API (v1) design a GSS-API mechanism was assumed
to provide at minimum a secure non-disclosing authentication of
the client to the server plus message integrity protection facilities.
In order to meet crypto export regulations, GSS-API was neutered
from the requirement to provide message confidentiality protection
for application data (aka encryption).

The idea to allow GSS-API mechanism without message integrity protection
materialized much later (during GSS-API v2 discussion), in a kind of surprise
during an IETF meeting when a mechanism without that functionality
was presented.  :)

The reason why the designers of GSS-API (v1) never thought about
GSS-API mechanisms without at least message integrity protection is
that these are real security problems by itself when communicating
over a communication channel that is not tamper-proof.

Technically, one can build a GSS-API on top of a disclosing authentication
scheme -- in which case the absence of message protection facilities should
not come as a surprise...  The reason why GSS-API was adopted in some
of the areas was not in order to immediately solve open security problems,
but instead to first move to a common API and obtain the option to
replace an existing insecure authentication scheme with a secure one
without further app modifications in the future.

However, if no message protection (which is cryptographically bound
to the the authentication process) is applied to the application
data following the authentication, then an attacker might modify
that application data in transit while it traverses insecure
communication channels and neither of the communication peers
will be able to detect such modification prior to processing
the data/messages.

> an X.509 cipher-suite and authentication of the server certificate is a

That is probably what it looks like to you.

Historically, the application started with an application-level and
application-specific authentication (e.g. HTTP basic, HTTP digest or
form based authentication).  Then the possibility to use TLS was
added to the application or application-hosting Web-Server.

In order to take the burden of "creation/assignment, distribution
and verification" of client authentication off the shoulders of
the application and to replace it with secure authentication
there were two possible approaches:  either start using TLS
with client credentials (X.509 certs) -- or try to leverage
the use of an existing authentication infrastructure -- which
today comes often with GSS-API as one of its interfaces.

If your clients are members of a centrally adminstrated authentication
infrastructure already (and in particular, if that authentication
infrastructure does not use X.509 certs for authentication), then
the TLS client cert approach is probably not what you are looking for.

If one is already using a GSS-API based authentication infrastructure
that is based on X.509 certs, then the solution is usually to make
those credentials accessible to the SSL/TLS protocol stacks of
the client software (e.g. Web Browsers) of your users.  That's
what we did 9 years ago.

> lead to channel binding problems. Are there any other reasons?

Well, there are actually a number of subtle ramifications
(read: security vulnerabilities and potential security vulnerabilities)
if there is no cryptographic binding between the message integrity
check on the application data and the authentication procedure.

> same scheme could be used for any mechanism.

In theory, yes, one can do that (reuse per-message PDUs of an
existing gssapi mechanism for a new gssapi mechanism).

Most of the time when a "new" gssapi mechanism is designed, it 
is actually the wrapping of an existing authentication system
or existing authentication technology and comes with PDUs
for integrity and confidentiality protection of application data.
So the only thing that the "new gssapi mechanism" adds to the
picture is the wrapping/unwrapping from native tokens into
GSS-API context-level and per-message tokens.

It is usually a good idea to reuse existing and proven cryptographic
protocols and protocol PDUs rather then to invent them from scratch
(and fail).  However, arbitrarily mixing and matching PDUs from
different existing cryptographic protocols might sometimes get
you into trouble.

>
>                                          This interpretation appears

I'm not a Kerberos protocol wrangler, so I'm having difficulties
commenting on this.

RFC-4121 section 4.2 does not seem to define per-message security services.

I'm more familiar with the predecessor of rfc-4121: rfc-1964
and that did not (newly) define per-message security services, but
instead, it defined how to map/convert exising Kerberos PDUs to and from
GSS-API context-level and per-message tokens.

-Martin

---

From: "Josh Howlett" <[email-masked]>
Date: Thu, 19 Mar 2009 11:32:34 -0000

Hi Martin,

> (you probably expected that...)

Indeed, and I am grateful for your detailed response.

> > Secondly, my feeble-minded interpretation of section 4.2 of 
> RFC 4121 
> > is that the design of these per-message tokens (unlike the 
> ..............

I infer from this that, in general, the GSS community would in principle
support re-use of RFC4121 per-message PDUs for another mechanism, where
it makes sense. Is that a reasonable summary?

> RFC-4121 section 4.2 does not seem to define per-message 

You're right, the question that I asked didn't make sense (I think I
mixed up the definition of a PDU (section 4.2 of RFC4121) with the
algorithms that protect the data within those PDUs (RFC3961)).

Let me try again; hopefully this makes more sense.

Assuming that the inference that I stated above is correct (the general
desirability of re-using per-message PDUs), I presume that this can also
be extended to the re-use of the algorithms defined in RFC3961. This is
certainly implied by section 7 of that document ('Use of Kerberos
Encryption Outside This Specification').

However, to use RFC3961 security services in other contexts seems (to
me) to require that there is some definition of what constitutes an
appropriate base-key. RFC3961 does not appear to explicitly define the
properties of an appropriate base key. I assume that it is the
sub-session key (or a derivation thereof), but I can't find this
explicitly called out.

In any case, it would be useful to know what, if any, expectations of
this key exist.

The reason I ask is that, for an EAP mechanism, the GSS peers will both
be wielding an EAP MSK at the conclusion of context establishment and I
need to understand how that is best exposed to RFC3961-like security
services.

best regards, josh.