Subject: [secdir] SECDIR Review of draft-ietf-radext-design-05

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 9 Feb 2009 14:04:59 -0800

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments. 
 
The purpose of this document is to explain the workings of RADIUS attributes for the benefit of those involved in the design of future RADIUS attribute specifications. As such the document is very clear and provides advice that will no doubt prove useful.
 
The Security Considerations section could do with some additional work however.
 
The discussion of encryption of attributes is somewhat confusing. Mention is made of encryption, followed by mention of MD5 and SHA1. While it was common to describe the use of one way functions to obfusticate passwords as 'encryption' in the 1980s, this is not current terminology and this needs to be explained.
 
Also I would like to see specific mention made of whatever provisions are made for message authentication in the protocol, if none, then this should also be specified. This is a major concern in what is essentially a protocol that supports the authentication/authorization process.
 
Finally, I would like to see some mention of the use of a secure tunnel such as IPSEC and which types of attributes might need superencryption within such a tunnel.

---

From: Alan T DeKok <[email-masked]>
Date: Wed, 11 Feb 2009 15:07:33 +0100

Hallam-Baker, Phillip wrote:
> The discussion of encryption of attributes is somewhat confusing.
> Mention is made of encryption, followed by mention of MD5 and SHA1.
> While it was common to describe the use of one way functions to
> obfusticate passwords as 'encryption' in the 1980s, this is not current
> terminology and this needs to be explained.

  OK.  We will update the document to clarify this "obfuscation" !=
"encryption".

> Also I would like to see specific mention made of whatever provisions
> are made for message authentication in the protocol, if none, then this
> should also be specified. This is a major concern in what is essentially
> a protocol that supports the authentication/authorization process.

  The protocol supports a Message-Authenticator attribute, which is an
HMAC-MD5 of the packet contents && secret key.  We can add a note on
this to the security section, though it's already discussed in the other
RADIUS documents, too.

> Finally, I would like to see some mention of the use of a secure tunnel
> such as IPSEC and which types of attributes might need superencryption
> within such a tunnel.

  It may be best simply to reference RFC 3579 && RFC 3580, which already
have extensive discussion of these issues.

  Alan DeKok.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 12 Feb 2009 04:46:41 -0800

That should do it.

-----Original Message-----
From: Alan T DeKok [mailto:[email-masked]]
Sent: Wed 2/11/2009 9:07 AM
To: Hallam-Baker, Phillip
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [secdir] SECDIR Review of draft-ietf-radext-design-05

  Alan DeKok.