[FWD: Comments on the WSS Kerberos Token Profile 1.0, Draft 5]

[Nicolas Williams <Nicolas.Williams at sun.com>]

The OASIS Web Services Security Kerberos Token Profile 1.0, Draft 5,
recently came to my attention.  I have read and reviewed the document
and posted my comments to the WSS comment list.

Other participants of the IETF KRB and/or KITTEN WGs may be interested
in reviewing said draft specification.

I note that the IETF has no liaison to OASIS, nor does the OASIS WSS TC
have a liaison to the IETF.

Nico



----- Forwarded message from Nicolas Williams <Nicolas.Williams at sun.com> -----

Date: Thu, 14 Apr 2005 16:35:22 -0500
From: Nicolas Williams <Nicolas.Williams at sun.com>
To: wss-comment at lists.oasis-open.org
Subject: Comments on the WSS Kerberos Token Profile 1.0, Draft 5

The Web Services Security Kerberos Token Profile 1.0, Draft 5 appears,
in some ways to be incomplete.

Additionally, I believe it is quite unfortunate that the Kerberos V
GSS-API mechanism was not used instead.  I can understand that the lack
of a keying facility may well have led to this unfortunate design, but
you should know that the IETF KITTEN WG is currently holding a Working
Group Last call on a GSS-API extension for (and corresponding Kerberos V
mechanism specification of) a pseudo-random function keyed internally by
a GSS-API security context.  This new feature of both, the GSS-API and
the Kerberos V GSS-API mechanism should provide all the functionality
needed by OASIS for a profile such as the one I'm commenting on.

Besides my above comment on the non-use of the GSS-API, I have the
following comments on Draft 5 of the profile:

 - Naming
 
   There is nothing in the profile about Kerberos V principal naming.

   What kind of service principal names should be used?

   Or is this to be specified by applications that use this profile?

   If so then this should be pointed out.  But since this profile seems
   to be closely connected with SOAP I suspect that naming
   considerations need to be discussed in the profile.

   Are non-Kerberos names to be mapped to Kerberos V principal names?
   If so, how, or where is this specified?


 - Session key negotiation and key re-use

   The profile should say whether or not the optional sub-session key in
   the AP-REQ's Authenticator MAY/SHOULD/MUST be present/absent, which
   of the Ticket's or Authenticator's session key "wins" when the
   Authenticator asserts a sub-session key.

   Assertion of sub-session keys in Authenticators is an excellent
   approach to key re-use prevention.  I'll have to review the other WSS
   specifications and drafts (and probably SOAP as well) to get a good
   idea of whether key re-use is prevented elsewhere.

   I suppose, though I will have to review the other WSS and related W3C
   specs/drafts to be sure of it, that proper key derivation is done
   elsewhere.  It would be useful, to readers not familiar with OASIS
   specifications, to mention where key derivation happens, along with
   references.


 - Replay protection and mutual authentication

   This profile says little about replay protection and nothing about
   mutual authentication.  While it may be sensible to leave replay
   protection to the "mechanisms described in WS-Security" I get the
   impression from the text in section 4 that there are special
   considerations related to this particular profile, yet no
   RFC2119 terminology (MAY/SHOULD/MUST/...) is used to indicate what,
   if anything, implementors should do.

   As for mutual authentication, if the "mechanisms described in
   WS-Security" provide it, then that should be explained in the
   profile, just as with replay protection.


 - Error handling

   This profile does not make use of the KRB-ERROR Kerberos V PDU, nor
   does it mention any Kerberos V error codes.  Instead it refers to
   error codes "defined in the WS-Security specification" without giving
   any indication of how Kerberos V error conditions on the server
   (acceptor) side should be mapped to WSS errors, if at all.


 - Channel binding

   Section 4, last paragraph (lines 214-215) says "It should be noted
   that transport-level security MAY be used to protect the message and
   the security token."  I think this needs some clarification.

   Why should the AP-REQ message require additional protection from
   lower layers?  From what sorts of attacks?  What if no such
   protection is available?  Shouldn't the session key from the AP-REQ
   be used to provide integrity protection to the S11 header?

   Or is this text indicating, obliquely I suppose, that it is possible
   to use this profile for authentication but rely on lower network
   layers for session protection?

   If the latter, note that there is a channel binding problem in that
   more normative text is needed to ensure that the end-points of the
   lower-layer channel and the application layer are effectively the
   same, else MITM attacks may be possible.  [Note: I assume that the
   "transport-level security" is secure against MITM attacks, but MITM
   attacks may be feasible nonetheless by misdirecting the
   system/application so that one layer or the other it is speaking to
   an otherwise properly authenticated attacked.]  This can be avoided
   with some additional requirements.


 - Normative references to soon-to-be-obsoleted documents

   RFC1510 will be obsoleted as soon as the RFC-Editor publishes

   draft-ietf-krb-wg-kerberos-clarifications-07.txt

   as an RFC.  That Internet-Draft has already been approved as a
   Proposed Standard by the IESG.

   The WSS Kerberos Token Profile should be reviewed with kerberos-
   clarifications in mind and, if it should not progress from Draft
   status prior to the publication of kerberos-clarifications as an RFC,
   then it should be changed to list the new RFC as a normative
   reference for the Kerberos Network Authentication Service (V5).


 - General silliness

   Section 3.5 says that "[when] a Kerberos ticket is referenced as an
   encryption key, the encryption algorithm MUST be a symmetric
   encryption algorithm."  At first glance this would seem self-evident
   given the normative reference to RFC1510, but since the encryption in
   question is not based on Kerberos specifications this is not so
   obvious, which leads me to ask...

   ...why not say the same thing in section 3.4?

   Also, section 2.3 lists terms not used anywhere else in the document,
   such as 'UCS' and 'UTF-8'.  Is the document incomplete, perhaps with
   regards to internationalization (I18N)?  Note that Kerberos V
   currently can only be interoperably used where principal and realm
   names are limited to US-ASCII characters (the IETF KRB WG is working
   on properly internationalizing the protocol).


Finally, I will give the IETF KRB and KITTEN WGs a heads-up about this
OASIS profile, as their participants may not be aware of this profile
and may wish to review and comment on it.

Cheers,

Nico
--



----- End forwarded message -----

_______________________________________________
Kitten mailing list
Kitten at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten